Project Poisson: Pierre and the Fish - Postmortem

The following is a postmortem for the development of "Pierre and the Fish" (codenamed Project Poisson). While this document is mostly for my own personal development, it may be of interest to other people, so I will try to make this accessible to other people. However, the document will be mostly a brain-dump of ideas as that seems the best way to me to do this thing. Consequently things might be a bit muddled, but hopefully there will be some points of interest buried in there somewhere.


Why complete this project?

Why complete a game for the "One Project One Button 2" competition? In my case, there were a number of reasons:
- I was planning on doing a series of one week challenges myself ever since I heard about the Experimental Gameplay Project. It seemed like a really good way to prototype ideas and to learn techniques.
- I needed the impetus to actually complete a game. Project Nova was going nowhere, and a hard deadline would help motivate me to finish a game quickly. I have noticed that I only really seem to get things finished when there is a deadline looming. By forcing myself to complete a game in a week, I would get things done.
- I would be finishing a research paper just a few days into the competition, meaning I could afford to spend some extra time working on my game development hobby (something I couldn't really do for several weeks beforehand).
- My goal is to become an indie developer who is a "jack of all trades", and this was a good micro-test of the entire suite of game developing abilities.
- Doing all this in a competition, rather than just on my own, seemed like a fun way to achieve the above goals.

I will try to summarise some thoughts about each aspect of game development that I experienced during the project.


Design

While there is an overview of my design progress in this journal, there is a lot of steps missing. Here is an overview of the development of the design behind "Pierre and the Fish" from beginning to end.

The ideas behind project actually started to form a couple of days before the competition. Once I had heard about the competition and decided to compete, I could not help to start idly considering gameplay ideas that only required one button. I quickly decided on the following ideas.
- The gameplay mechanics had be suited to one button, i.e. the game would not be one that was ideally suited for multiple buttons that was crippled to fit the rules of the competition.
- Due to the first condition, the game had to revolve around the idea of simplicity. You cannot get much simpler than a single button, so the game ought to reflect that. This also ties into the fact that with only a week to develop and with my limited development skills it is too risky to try for something complex.
- The game will be 2D, and written in SDL/OpenGL. This is mostly because I wanted to get up to speed with that technology, and the competition was a perfect opportunity for this. Also, I already had a partially completed engine for Project Nova.
- I would make all of the art assets myself; all the artwork, all the music, and all the sounds. While this would cost me time, this is what I aim to do for my games in general, so it was a good test for me.
- Due to my limited resources and the nature of the competition, this meant I should aim for a simple mini-game that would be extremely easy to learn and would be over in a couple of minutes at most

With these rules decides on, I speculated about various ways that one button would make sense. The obvious ideas were one-dimensional movement control (up/down, left/right), or timed events (press the button at the right time). Since I wanted the game to make sense to be controlled with one button, I considered controlling a balloon (button for turning the burner on), or pulling levers. However, the one concept that stuck in my mind was a game about a deep-sea adventurer piloting a crippled submarine that was being chased by a giant fish. In this game, the adventurer had to time the control of his malfunctioning engines to maintain maximum speed to outrun the monsterous fish chasing him. The idea really felt strong to me, so I found myself sketching pictures of the fish and thinking of music ideas for pursuit.

However, once the competiton begun and the theme of "collecting" was suggested, I was a little bit disappointed; my game idea was entirely unsuited to collecting. However since I could not work on the project fully for a few days, that left a while for more daydreaming. I found that I really liked the concept of a submarine chased by a fish, so I decided to adapt my balloon control method to the submarine. The game would have two stages; one where the submarine would collect as many small fish as possible, then a second stage where the submarine must get to the surface as quickly as possible while avoiding being eaten by the fish.

Coding started on the Wednesday of the competition (local time), and this is where the journal picks up. However it was clear late in the competition that the two stages would not be possible to implement in the time available, so I had to make a compromise. I decided to combine the two stages together, and just have the submarine collect as many fishies as possible before being eaten. In retrospect, I think this was a good idea as the idea is now simpler and probably more fun.


Programming

Programming was one aspect that I was unsure of. By training I have a lot of experience with programming; I've learnt several different langauges and written several large programs in my past. However, for the last few years I have only been working with high level academic languages such as Matlab and Prolog, and so I thought that my knowledge of C and C++ had decayed over time.

Once I started coding in Project Nova, however, I realised that this wasn't really the case. I guess the tricky part of programming is the methodology of constructing programs, not the language itself. I soon found that I was back in the swing of things with C style programming. However, C++ is still a little bit trickier for me; I guess I never really mastered it in the first place. But I find that my hybridised version of functional C programming and object-oriented C++-lite seemed to work quite well for this project.

My time programming was sped up by the fact that I already had a partial engine written for Project Nova. While I thought that this engine was incomplete and bug-ridden (which turned out to be true), it was solid enough to quickly throw me into producing results. By the way, the engine itself is based on the Enginuity series of articles written here on GameDev.Net by Richard "superpig" Fine; I've ripped out a lot of the functionality and replaced it with my own little touches here and there, but the game loop part (or kernel) is pretty much the same. I recommend using it as a basis if you are interested in C++ with SDL/OpenGL for your project. The lesson here is that code reuse is invaluable; I will attempt to use this as much as I can from now on.

The other improvement was in the use of third-party libraries for anything hardware based. SDL is used for the basic framework, setting things up, loading files, and for input. OpenGL is used for the graphics. FMOD Ex is used for the audio. The use of these libraries were indispensible, and I will be using them again in later projects. I will detail their use later on in the "Tools and Libraries" section.

One thing I learnt about programming under a tight deadline is that it is better to whip up something that is functionally equivalent then try and implement something new. Most of the mistakes I made that cost me a lot of time was trying to implement things I really didn't need to, such as displaying bitmaps when I already had textured quads, and getting text to work. In this case, I spend hours trying to get SDL to display text correctly, when I should have quickly given up and just used billboarded text and individual glyphs instead. My mistake was to stubbonly keep on trying to get it to work when it was clear that I was losing time.

All in all I think I should be more confident in my programming abilities. The end result was pretty good considering my lack of experience with the technology and the deadline, so I should not be hesitant to dive into programming my next project.


Artwork

Art is presently one of my weak points, as can be seen in the fine details of the artwork available. This was compounded by the severe lack of time to make the art perfect. However, deep down I know that programmer art can be made to look pretty; the trick is to know your limitations and design the whole art concept around the fact that you cannot draw anything with great detail. The cartoon Mario-esque feel with solid colours is something that I know that I can draw, so I decided to go with that.

Art concepts were drawn on paper until I got the feel right, then a digital version was created using a Wacom tablet and the GIMP. While I can get cleaner results using Inkscape, at the moment I find the GIMP faster, which was needed for the competition. The end result turned out quite well.

The billboard-like art style is something that I really like, and I intentionally chose all the technology to go with this. I plan on making a series of games that look a bit like this (except maybe even more so), so I'm really glad that so many people commented on how nice the game looked.

I'm especially pleased with how well "The Fish" looks; I spend several hours getting that fish to look good, and I think it was time well spent. Once I drew that fish, I knew I had to make it the centre-piece of the game.

Still, I think that my art skills need a fair amount of improvement for my subsequent games. With this game I purposely chose a design that only needed a small amount of art; this won't be the case for a fully-fledged game. I will need to get my skills up to the point where I can create a large amount of art assets quickly and competently.


Music

I think that music really helps make a game, so I wanted to include some decent pieces with my game. The severe time constraints were quite daunting; it takes a fair amount of time to make a good piece of music. However, I had the advantage that I have been working on my composition skills for the last few months; I've been practicing connecting chords and improvising tunes every day (mainly because it's a huge amount of fun). I already had a series of chord changes that I thought sounded right for a chase theme, so I wrote the basics of the chase piece at the keyboard before I even started writing the code (in fact, it might have been before the competition even began).

Encoding the music into the computer however still takes me a fair amount of time, and I didn't want to spend more than I could afford. Once I had the two pieces of music firmly implanted in my mind (after playing my keyboard as a break from the computer) though, it only took a couple of hours to write two short 16 bar pieces that sounded quite nice.

One thing I am appreciating more and more is the importance of music. Since I already had the music in my mind before I started coding, it helped tie together the whole dynamics of the gamneplay. Every hour as a break from staring at the screen I would go to the keyboard and play the tune again. Once I had the music written, I would play it in Winamp occasionally to keep my mind on the theme. "The Fish" was drawn with that chase theme looped over and over again constantly throughout the entire drawing process. I really think it helped a lot, and I will be doing a similar thing for my next projects. Maybe this will work for you too; if you don't have a piece of specially written music you can always use something on a similar theme to just help you get into the mood.


Sound Effects

This was the first time I had ever made sound effects for a game, and the end results were a bit hit and miss. I found that the internet is pretty hopeless as a resource for sound FX; while there is a lot of stuff out there the exact details about the copyright are very sketchy at best.

I left the creation of the sound effects until very late in the competition; I think it was about 2 a.m. on Monday morning. This was not a good time to start doing something for the first time with limited resources. All I could do was throw together something using the percussion samples I had for my music by modifying them in Audacity.

The end result wasn't that bad. The "collect" sounds still don't seem quite right, but the drum sound for hitting a seed is nice. However the "bite" sound effect for the fish is really quite nice, especially because that's just four different percussion instruments that have been extensively tweaked and mixed.

For my next project, I will have more time to make the sound effects better. I also should think about either finding a good resource of sound effects for use (such as a CD of royalty-free sounds), or buying a good microphone, or both.


Planning

This is by far my weakest element. I did try to have a plan for the entire competition, with little plans written at the start of each day's work for what I would do in the few hours I had each day. But I found that my estimation of time was way out; for some reason I really did think I would get the alpha version finished on the first day!

I know that organisation isn't my strong point, but it's something I need to get into the habit of if I am going to be professional about this. I guess the time estimation will come with experience, but I still need to keep practicing at the planning.

It also needs to be said that the plan of going straight into an intense programming competition after a crunch period at work, and still expecting to work at maximum efficiency, was slightly flawed. While the competition itself was a big success for me, I needed to factor in that I would need to take a break afterwards. I ended up burning myself out in the week after the competition, costing me time at both my research and game development. This is fine now, but it has to be considered that this comeptition was a sprint, and game development for the long term is much more like a marathon. Working too hard is counter-productive for a long project.


Polish

Part of my philosophy of game development is that polish is a necessary part of any game. Polish is what makes a good game great. Of course, polish can't make a bad game any better, but I really wanted to practice my polishing skills.

To do this with the limited time I had, I decided to make little features such as the spotlight zoom effects, and to spend most of the last day making a great menu. In the end, I think it really was worth it. There's a lot in that menu that I want to include in all my games, and I think it really helped make people think that the game was fun.


Tools and Libraries

I have been collecting various tools and libraries for the last few months that I thought would be useful for game development, and this competiton was a good test of many of them. Here's some of my thoughts about the effectiveness of these tools.

First some general comments:

It is possible to compete a game using free software.

All the development software I used was free; the compiler (MinGW), the IDE (Code::Blocks), the art tools (GIMP, Inkscape), the music tool (ModPlug Tracker), the sound editor (Audacity), even the zip tool (ZipGenius). The libraries were also free: SDL (LGPL), OpenGL (not sure, but definitely free) and FMOD Ex (which is free for freeware). I think the only tool I used that was not freeware was Notepad for the readme file, and that can be easily replaced. So if you have to, you don't need to spend any money on software to make a game.

But is free software worth the cost?

There is a downside to free software, and that is the cost in time. It was painfully aware that several of the free tools I was using had some serious usability issues. I'm looking at you, the GIMP and Code::Blocks. Using a commercial IDE and paint program might be worth the saved time.

Now for general comments about each of the tools and libraries.

Libraries

SDL

SDL is a useful library to use; it certainly saved me some time in initialisation, and it seems to do everything. However it must be noted that the biggest costs to my programming time came from trying to integrate SDL with other code. In particular, the image loading step (getting the images to work with OpenGL), the font loading and printing (never got this to fully work), and blitting bitmaps (ditto) took up nearly a days worth of development. I still think SDL is worth it, though, but it is not as transparent as the other libraries to get working. Yet it was still reasonably easy (compared with other libraries that I've used).

OpenGL

I wanted to use OpenGL, because I thought that it would easily deliver the 2D functionality that I wanted in my games. However, I didn't realise how easy it would be. To put it bluntly, once you get the hang of it OpenGL is a total breeze, and immensely powerful for 2D work. I can't stress this enough; I just can't believe how quickly and easy it was to use. I will definitely be using OpenGL for all my games from now on.

FMOD Ex

I had to quickly integrate audio capability into my game, so I decided to go with FMOD Ex. I only could use the simplest amount of functionality in my game due to the severe lack of time, but it was a piece of cake to use FMOD Ex. If you are making a freeware game, you really should look into using this; there's a whole heap of functionality that I'd like to try out, and for simple stuff it's a snap to use. The only downside is it costs a fair amount if I ever decided to go shareware (considering the limited audio use I will need), but this might still be worth it; FMOD really makes things easy.

Tools

Code::Blocks

I wanted to test this out with Project Nova, so I decided to keep using it for Project Poisson in the competition. Code::Blocks is a nifty freeware IDE. I like the code completion functionality (although it decided to stop working on me on the last day; not good at three in the morning). It seems to have enough functionality to make a small to medium sized project, which is good for my purposes. I haven't fully tested out the debugger however, or looked for profiling tools. My main gripe is the total lack of off-line documentation; my old Watcom C++ compiler at least had some instrucitons on how to use it. I'm not sure if I'll keep using Code::Blocks; maybe for my next project, but I'll have look at some other IDEs.

The GIMP

The best known free imaging tool. It has a lot of functionality, but is lumbered with an interface spawned from the depth of GUI Hell. And yes, it is improved in version 2, but I find that it's like being spawned from the third circle of Hell rather than the eighth. I spent half my time using it swearing at the interface, and I already know how to use the GIMP. Still, with my limited budget and artistic skills it might be sufficient. I'm not sure what else I can use.

Inkscape

A vector line drawing tool; for this project I used it for the text. Although there's some bugs with the interface, and the program sucks up a whole heap of resources, I really love Inkscape. It's probably because I can actually use the interface, rather than with the GIMP, where I fight against it. I've still got to practice using this tool, but I feel that I can make a lot of really good stuff with it once I've got up to speed. I recommend trying it out.

Audacity

A decent free audio editing tool. Does everything that I want, so I can't ask for anything more. The annoying habit of not allowing me to open more than one file at once unless it's through the Audacity menu is annoying, but not a critical flaw. Give this one a try.

ModPlug Tracker

A freeware music tracking program. While I have only created a few pieces with this, I really do love ModPlug Tracker. It's a great free program that once you get the hang of is quite easy to use. I think I will stick to using this for some time.

Hardware

This is not about computer hardware, but hardware tools that I am increasingly finding indispensable.

Scanner

While I don't use a scanner for final images, it's good to scan in some of my draft images to use as backdrops as I sketch. These are relatively cheap these days, so I would consider getting one.

Electronic Keyboard

Indispensable for music composition; also doubles as a sound effect and sample generator. Heaps of fun to use, this is my favourite little toy at the moment.

Wacom Drawing Tablet

If you draw your own artwork for your games, then you need a tablet. This tool makes your art heaps better (even if your drawing sucks in general), and makes drawing much, much easier and quicker. I bought myself the smallest one, and even though this isn't truly suited to drawing work, it is still much better than a mouse. Get one! They aren't that expensive.

I also think I need a microphone and a digital camera to complete my set of tools. Not having a microphone limits the sound effects I can use, and a digital camera is just plain useful.


Conclusions

I learnt a lot about making games in those five days of intense development. From this perspective the time I spent working on "Pierre and the Fish" was worth all the hard work I put into it. I am more excited about game development that I have been in ages, and am eager to work on my next project. Aiming for a one week game was a great way to finally complete a game that I am proud of, and I would recommend giving it a go.

I have to stress again, however, that there is a big difference between aiming for a one week game and working on a large project. I really threw everything into "Pierre and the Fish", because it was a personal test of what I could do. By doing so, especially straight after crunch time at work, I ended up burning myself out (by Friday last week, suffering from insomnia and back at work, I physically couldn't work anymore). This is okay for a simple project like "Pierre and the Fish", but is a disaster for a larger project; you'll only end up hurting yourself, and much less productive than if you pace yourself.

That being said, I am energised again and looking forward to my next project! If I can think of a decent theme for a small game, then maybe I can get another game finshed by the end of the year!

Random Statistics

Time of Proper Development: Five days
Lines of Code: about 4900
Occurances of the word 'hack' in documentation: Five
Favourite Function Header:

void UpdateFishie(Fishie *fish);	// this is pure poetry!

Thoughts and quotes during development:
"C++ templates are just black magic that has been developed to drive me insane."
"It's probably not a good idea to drink too much while coding. Ah, maybe it will help!" (it didn't)
"What the hell?! Why are there two November 17s on my calendar?!"
"Two hours sleep before a Monday. I really must be insane!"


Thanks to everyone who has enjoyed "Pierre and the Fish"! Working on this game has been a whole heap of fun!