Coding for fun

In many news groups and game development forums there are always general questions from newbies that would like to create games.  The oldies that frequent these sites give good advice, but the utility of this advice depends the assumption the oldie makes about the experience of the newbie.  A newbie may be disheartened  by an answer that goes into too much depth, or feel that the advice is too superficial.

I think the question we newbies should ask ourselves is: Why do I want to create a game? There are many possible reasons.  For example, you may want to pursue a career in the gaming industry; impress someone with your technical aptitude; explore your own creative genius; learn a new language; or you may simply want to create games for your own personal enjoyment (a.k.a. fun).

Whatever it is, be sure you know the particular motivation that drove you to the task of creating a game.  And then stay true to yourself in that regard.  For example. if you want to join the gaming industry, my advice is to make sure you explore all areas that is of interest to you, then choose a speciality. Focus all your efforts on learning the current state-of-the-art tools and techniques in that speciality.  If you don't like it, switch to another area - and so on.   I would also argue that you would do well to ignore me and ask advice from someone that has actually tried to make it in the industry.

For a person like myself that create games only for the fun of it; any advice that does not directly pertain to fun should be taken with a good dose of salt.  Now, if we talk about fun - that is a different story. About that we can talk for hours. Soon we might conclude that  fun is not objective and it is a very personal thing.  But, all is not lost, there is one absolute truth about fun: you are the only judge of your fun.  If you say 'that was fun', no one can disagree; and if you say 'that was not fun' no one can disagree that you did not have fun.

So, if fun is your motivator, I propose that you are the only judge of your game.  If the game was fun to create, it was a successful, otherwise it was an utter waste of your time.  This proposal presupposes that you have in fact completed a game.  Clearly, on the road to completion you may have to spend some time (hopefully not too much) that may not be fun.  But take heart; this process is like any other worthwhile human endeavour. The acquiring of fun is usually preceded by the attainment of a reasonable level of skill.  The pursuit of the latter is filled with toils and troubles that are overcome only by an adequate level of personal commitment.

Of course, when your aim is to have fun, your level of commitment is relatively low.  You quickly recognise problems that are far beyond your current skill and promptly avoid solving them.  This is a fine approach, but it may be problematic.  This is mostly because creating a game for fun is not a competitive sport, like tennis for example.  You may enjoy playing tennis without ever thinking about becoming a tennis pro.  You like to play tennis with other people that are more or less on your skill level; and as they get better, your game may also improve.  If your competitors always beat the living crap out of you, tennis won't be much fun..

Likewise, when you create a game, and you evaluate your product with the product of a professional game studio, creating games won't be much fun.  You need a good competitor.  Realise that the only competitor you have - and the one you must always strive to beat - is no one else but the previous version of yourself.  So it is very advisable to start with Tic-Tac-Toe or some other simple game.  This way you create a worthy opponent; an opponent that has drawn a line in the sand, and dares you to cross that line.  For your next game, you must focus on giving that opponent a real beating - and then draw a new line in the sand.

Before asking on a forum which is the best language, the best platform, the best graphics engine for creating games, or the best game idea, first ask yourself what is more fun for you.  For me, it is currently more fun to program in C++ than in Java or in C#.  It is more fun to use OpenGL than it is to use Direct X.  It is more fun for me to use SDL than it is to Orge3D.  These are assertions I make because I have explored these (and many other) choices.  And I had fun doing it.

Go ahead, start working towards that vision of a game you always wanted to write.  But start by creating a lesser game - a game you know you can write.  Take that first step; who knows where to it might lead. It could even be fun!

Boogaloo

It has been some time since I did a bit of game development. Recently, a local game competition inspired me to do another little game. After puddling around a bit, I decided to stop development and to call the game finished [a.k.a. version 1.0].

The game itself is the simple snake-eats-apple game with an interesting twist: you have to control two snakes at the same time. Surprisingly, this small variation to the original idea adds a little bit of puzzle and a lot of fun.

I built the game using Scala, Swing and Java2D. I also made use of an indie game library (GTGE). The game is very simple, so the services I used from the library were minimal. However, I must say I liked the simplicity of the library API and I would gladly use GTGE again.

It is the first time I tried the JAVA VM to develop a game. As an experience, it was not as bad as I expected. The deployment package is a single JAR file that you should be able to start playing with a double-click on the jar file (on most modern PC platforms).

Why not give it a try -- download the executable jar file from box.net.

If you get more than 600 points, you should really consider quiting that day job ;-).

BreakOut clone updated

Although I am working on one or two other ideas, I figured I should not let my first (and only) completed XNA game rust away. So, I picked up ye old shovel and upgraded some code to VS2008 and XNA 3.0. The upgrade process was quite painless - apart from an issue I picked up with XACT.

In fact XACT does not seem to be working on my machine at all. Even the XACT tool fails to play any media. I googled a bit for an answer, but could not find any good reasons for this behaviour. Luck was on my side: XNA 3.0 offers an alternative to XACT for audio processing. The game is quite simple, so it was easy to remove XACT from the code, and plug in the new pieces.

I do not know what advantage XACT has for a simple game like this one. XACT took a bit of figuring out; while the new method is very straight forward. My crystal ball says most new developers will sidestep XACT while they can.

Anyways if you are interested in trying out this very basic clone, get the zip from the release on codeplex. But calm down those high expectations -- I suspect reading the code is more interesting than playing the game :).

Teaming Up

It is clear that collaboration does not come free. Compared to the work of a solo developer, there is definitely additional effort required to start and maintain a successful collaborative project. Collaboration is driven by the need to be part of something great, something cool, or even something profitable. Even though total satisfaction is not guaranteed, one thing cannot be denied: the team is stronger than the individual.
A few days ago, I posed a question at SA game dev to get some thoughts on the team issue. The feedback was very interesting. Here are some of the key points that were highlighted.

A "main dude" is needed for success.
* This is the guy with the full picture in his mind. He defines the project, sets it up and invites other to join. He is possibly the key contributor, and he directs and controls the work done by other (possibly part-time) contributors.
* If you want to be this dude, your attitude is important. Setup you collaborative site, but assume that you will do all the work yourself. The success of the project hinges not on the contributions of others, but on your ability to see it through.

Your idea must be pragmatic.
* The game idea must be clear. You must know how to implement the idea. Think about breaking down the idea into small milestones so that each can be reached relatively quickly.
* An alternative is to start with a small idea and finish it with some collaboration. Then come up with a more complex idea that will take the willing participants to the next level. Finish that as well. Gradually gaining collaborative momentum.

Consider the team issues before you start.
* Make sure you ideas and plans are communicated clearly. The team will function properly only if they work from the same knowledge base.
* Think about how team members will participate. Perhaps a person can choose which discipline he wants to be involved with. Maybe the idea lends itself to episodes or mini-games - giving your team members more autonomy.
* Choose tools that promotes collaboration amongst developers and also amongst artists.
* Keep in mind that some potential team members are less technical, and they may need custom written tools before they will help you. For instance, an artist might become more interested when he can view his creation in a setting that resembles the game in some way.