Games page! - and how to ramp up your skills

A new Games page is available on the blog now, you can access it through the navigation bar at the top. On this page I'll list all my finished games and somewhat noteworthy work-in-progress projects. Make sure to take a look! So far I've made 3 actual games, and I hope to increase this amount soon. Building up experience and keeping the pace up is important in the field of game development. Like any skill, you lose your edge if you don't stay busy.

Learning and modesty
I've been reading about a more scalable approach to building up your skills in game development. What a lot of developers have trouble with, including me, is choosing a project that fits your expertise. What Chris DeLeon is basically saying (in the articles linekd above) is that chances are high that the first game project X you will try to make is of complexity X''''. But before you can envision X'''' you need experience making X'''. The same goes for X''' and so on until X', where X' is something you can realise with little to no experience of the field.

Even more so, you can break anything down like this! Suppose you have this grand 4X strategy MMO action shooter game (classic!), let's call it Y, envisioned as your first project. Naturally this project is of an impossible scale already for a single developer, but let's break it down anyway.

Let's say Y has first person shooter combat, online multiplayer and a meta-strategy game on top of it! Yeah, that should work. We can call those elements A, B and C respectively. Those game elements won't work together just like that, so assume that they will be of complexity A'''', B'''' and C''''. You don't have experience in either of these skills, so how are you going to get them all up to the right levels?

A mistake that is made by a lot of developers is to simply start making Y anyway, and "learn as they go". Or saying that "at least you can try". I'm an opponent of this method. Much rather I'd like to think about what A' could be, which is the first stepping stone towards reaching A''''. In the case of A being "first person shooter combat" we could, for instance, try making a game about any basic combat, which would represent A'. From there you can continue towards first person combat (A''), first person multiplayer combat (A''') and finally our target A'''' which is something like first person multiplayer combat integrated into a bigger system of a 4X strategy. Hey, I didn't say this was a good (or original?) idea in the first place!

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".

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.

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.