While I need to put in some more changes to the website (and think of a new poll too), it’s about time to start posting about my hobby projects, since that is the whole point of trazoi.net.

As you’ve probably guessed from the site my main hobby is game development. My eventual goal is to make the happy, fun, emotional roller-coaster packages of enjoyment that I dream of making. My current method of approaching this goal is “Project Diagonal” - developing my own suite of 2D game development code.

In the rest of this post, I will briefly go over the point of Diagonal, a description of my current game Ice Slider, and other plans for the rest of the year. This is also a test of WordPress’ summary capability, so click the link to see the rest of the post.

Why Diagonal, why 2D, and why make your own library?

Diagonal is a game oriented, nebulously acronymed library. Its purpose is to make life easier for me to make the sorts of games I would like to make. Given nearly every one of the game ideas I have involve 2D cartoonish worlds of one kind or another, the core of each game can be very similar.

I am keeping Diagonal 2D, as I realise I have more than enough 2D game ideas to keep me busy for the rest of my life. As for why I am building my own library rather than use one of the many fine packages already in existence, it basically boils down to experience. I want to get my hands dirty with the internals of building engines and libraries so I have a better understanding of how it all fits together, and so when I add in the special extra features that I desire I will have warmed up my programming skills sufficiently to piece it all together.

The Diagonal Development Strategy

While development of my own 2D game library is the “big picture” goal, the method I feel is best to add to it is to actually build games. While this might sound redundant, I know the big pitfall when building a game library is that it is all too easy to get sucked in to adding features just for the sake of it. I keep getting caught out by this, so the goal for Diagonal is to add features only when games require them.

The general strategy for improvement that I am attempting runs like this:

1. Pick a game concept that involves a few more pieces of functionality from what I currently have
2. Using the code I already have, throw together the game in whatever way seems easiest.
3. Once the game is complete on the surface, go through and clean up the code, incorporating whatever is feasible into Diagonal.

The point of separating out the second and third steps is that I know I tend to get stuck on the design phase trying to decide which approach is best. If I know that whatever I do is only temporary, and I am going to come back and clean up the code regardless, then that gives me more liberty to make mistakes in the design. If Diagonal is designed modular enough then refactoring one component at a time should be relatively painless. And if it isn’t, then that indicates an area for improvement.

I am hoping that after a few iterations of this process then I will end up with a fairly complete, solid core to my game library, which should speed things up enormously and allow me to make more complex games.

Ice Slider

My current game project is called “Ice Slider”, an idea for a puzzle game I was working on last year before Christmas interupted development. It is a pretty simple maze-like puzzle game where you must move your way from the start to the finish, but you can only change directions once you hit a wall.

Ice Slider will be the first fully complete game I will make with Diagonal. Unlike Brixtar, which was more of a tech trial, Ice Slider will stand alone and have enough polish for me to consider it complete. This means decent graphics, sound effects, music and menus.

I honestly cannot estimate exactly how long it will take to complete Ice Slider. I have some messy code from last year I can gain ideas from, but the actual game code was yet to be implemented. Since there is a lot of new problems to solve and I am juggling multiple projects it is hard to figure out a completion time. However I am keen to get this to a nicely polished state by the end of August so I can move on to another game.

Other Issues for 2007: Grad studies, webcomics and 4E6

There are three other big things that may crop up in the rest of this year that need to be mentioned, as they may affect my progress. Firstly, it has to be stressed that this is a hobby project, so there may be times where game development has to be put on the back burner. I am, at present, a PhD graduate student, and my studies are starting to come to a conclusion. This means I’ll be spending a lot more time doing experiments and writing my dissertation, so time is limited.

Secondly, and perhaps paradoxically given that last statement, I really would like to start my own webcomic this year. I find that I like creating cartoon art on the computer and would like to get better at it, and the best way I can think of getting good practice is to do something periodical like a comic strip. However this too will eat into my precious time. If you are interested in the webcomic at present I am in the planning phase, trying to gauge whether the concept is feasible or not, and I don’t expect to have much to be presentable until September at the earliest (and probably October at this rate).

Thirdly, those of you from GameDev.net know of the annual Four Elements contest run every year. I have a feeling that this year’s project 4E6 will start soon. While I have been kicking myself for not properly attempting a game for last year’s contest, I am unable to say whether I can attempt something for this year. With my time so limited I feel the best course of action is for me to stick to my current plan, which means it is far more sensible to stick to game ideas that take about a month rather than ones that take half a year. With luck, the elements chosen will be feasible for a single month project that I can throw together as part of the Diagonal plan, but if not I may have to give it a miss once again.