Ludum Dare is an excellent event for those who want to take some time off making games. We had a lot of fun in any case!
You can play Lead to Live here. And by the way, the theme was "10 seconds".
Wednesday, August 28, 2013
Ludum Dare 27 - Lead to Live
Did I mention I participated in the Ludum Dare 27 Jam? Well, I did. Together with Villermen we made a game called Lead to Live.
For those unfamiliar with the rules of the Ludum Dare, it's a "competition" where you have to make a game based on a given theme in 48 hours, or 72 hours if you do the jam version. Before this time period ends you have to post your game to the LD website, and for 20 days after everyone gets the chance to play and vote on each other's games! The prize is having made the game, as the organizers put it.
Ludum Dare is an excellent event for those who want to take some time off making games. We had a lot of fun in any case!
You can play Lead to Live here. And by the way, the theme was "10 seconds".
Ludum Dare is an excellent event for those who want to take some time off making games. We had a lot of fun in any case!
You can play Lead to Live here. And by the way, the theme was "10 seconds".
Tuesday, June 4, 2013
Structuring a game
My finals are over, waiting for the results now. Vacation has started, so here comes the game making.
The biggest problem I had starting development of my game is the software structure. Every time I programmed something of decent size I found myself stuck in a corner, unable to manage all the classes and variables that were made so far.
When asking my cousin, a student in computer science and electrical engineering, he came up with the Model-View-Controller (MVC) design. In MVC you divide your program in three types of components, each having seperate tasks. The model holds data, the view observes the data and changes when the data changes, the controller allows manipulation of the data. However, using the classical form of MVC requires that your model objects are observable. This means that every change of data sets off an event. The C# library doesn't have an implementation for observable objects and it didn't seem like using observables would give that much advantage in the first place.
Then I thought up a bastard son of the MVC design. Instead of using observables, I divided my program as follows: The model still held the data, the view draws whatever data there is, and the controller manipulates data in the model again. Though implementing this design smelled an awful lot of needless complexity, as Robert C. Martin tends to say. What I learned from reading his book about agile software design, you shouldn't abstract a function or class before you find yourself repeating the same piece of code (at least, something in that direction).
In the end, deviating from pattern to pattern did teach me a lot, so at least it was time well spent. I'll just stick to building monolithic classes for now.
The biggest problem I had starting development of my game is the software structure. Every time I programmed something of decent size I found myself stuck in a corner, unable to manage all the classes and variables that were made so far.
When asking my cousin, a student in computer science and electrical engineering, he came up with the Model-View-Controller (MVC) design. In MVC you divide your program in three types of components, each having seperate tasks. The model holds data, the view observes the data and changes when the data changes, the controller allows manipulation of the data. However, using the classical form of MVC requires that your model objects are observable. This means that every change of data sets off an event. The C# library doesn't have an implementation for observable objects and it didn't seem like using observables would give that much advantage in the first place.
Then I thought up a bastard son of the MVC design. Instead of using observables, I divided my program as follows: The model still held the data, the view draws whatever data there is, and the controller manipulates data in the model again. Though implementing this design smelled an awful lot of needless complexity, as Robert C. Martin tends to say. What I learned from reading his book about agile software design, you shouldn't abstract a function or class before you find yourself repeating the same piece of code (at least, something in that direction).
In the end, deviating from pattern to pattern did teach me a lot, so at least it was time well spent. I'll just stick to building monolithic classes for now.
Wednesday, April 24, 2013
A good day for blogging
So I made a blog. You're reading it.
I created this place to vent my opinion on games, giving myself room to develop a more in-depth insight regarding game design and development. You can read that from now on! There will also be development logs going on here, regarding a project that will be started in about a month, and any future projects too. More on that soon.
I created this place to vent my opinion on games, giving myself room to develop a more in-depth insight regarding game design and development. You can read that from now on! There will also be development logs going on here, regarding a project that will be started in about a month, and any future projects too. More on that soon.
Subscribe to:
Posts (Atom)