The Game

Oh dear, it's really been a while since I've found time and will to write anything for this blog. But things change and I'd like to write down a few things about this month's GID event.

First, here's a cross-link to the GID's board: http://www.gameinaday.net/viewtopic.php?t=122

Now the game is called Fireworks! and it's about, well you might have guessed it, fireworks, but not really.
I've rather taken a more unrealistic approach and thought about what fireworks look like in cartoons, etc. There they often explode to some drawing or shape, which of course is pretty much impossible. But the idea is nice, and since I've wanted to do some mouse-based/movement-based game, I thought that doing a firework-themed drawing game would be fun.

See the screenshot on the right for what the firewor-theme looks like. You first draw over a shape that is shown and when you are finished the firework starts. You do this to collect as many points as possible to get into the highscore list (doesnt sound like duh?).

The actual idea consisted of actually drawing stuff freely and mistakes would appear in the final firework, too, but I had to give up that idea because I couldn't get T2D to render particles at a certain quantity at low FPS, too, and I didn't want to use separate objects for it. Maybe the invalid strokes will come back , because I kind of like the idea of making invalid strokes more visible.

The score system is pretty ok but the UI suffered because of the time constraint and isn't as dynamic as it should be, but you can get boni and multipliers for lots of things.

Enough said, here's the link to the current final build (there might follow one with sounds later): http://icculus.org/~black/gid/0709/Fireworks!0.99.zip

And here's an excerpt from the readme:

Preliminary Stuff

This is the almost or probably final version of Fireworks!, a GID game (15/16.9.2007).

Pure dev time: 19 hours atm spanning from Saturday till Monday.

The game is released as is, etc.

Most of the source scripts are included, so you can take a look at a few bits pretty clean code midst very hackish stuff.

About the Game

It's pretty simple:
You have to draw over the contours visible in each level to earn points and start/arrange the fireworks (that's pretty much the story).

The score system is pretty simple:
The longer you stay on a contour (the cursor trail is cyan), the more points you get, and after many points in a row, you receive a power multiplier as reward.
Likewise, if you draw fast enough over a part of a contour that hasnt been painted yet (purple at the beginning, green if you've already drawn over it), you'll receive a speed multipier. Also if you manage to finish multiple contours with one, you'll get a combo multiplier.

Each multiplier starts with x2 and increases if you draw accordingly.

But be careful! The multipliers are only applied to the score of your stroke, when you release the mouse button! They add up and multiply your score: e.g. +1000 x + 2 + 2 means 1000 * (2+2). And if you miss a line or your mouse slips a bit and the cursor trail turns red, you'll lose the combo and the power multiplier (not the speed one, though)!
So be careful and don't try to make too big a combo or draw too difficult a contour at once because you could lose lots of points...

If you manage to paint a whole contour line with one stroke, it'll double your current score and also increment your combo multiplier. Same if you manage to paint all contour lines with only one stroke per line. Last but not least, one last word: there's a highscore and there are 5 levels at the moment. There is no game-over condition yet, so you can simply play through all levels and try to get a good highscore.

Post-mortem

• Don't always get lost searching for some stupid tools that aren't really that necessary for the project

Ok, this time I can't say that I did a lot of bad things, although I think I've spent way too much time trying to find a good GIF animator to build the gif movies with (quite possibly 4-5 hours over the course of the last three days).

• Beware possible feature creep and rather try to cut and stay focused on the game vision

Development itself went fairly smoothly although I almost got lost with the particle brush feature: I probably spent 3 hours on it, until I realized that it wouldn't work under the setting I've been planning for it, and I had to refocus on the actual game instead of toying around with it some more.

• Limit yourself on the engine and try to stay inside the game script side of things

I think it was a good decision to use vanilla TGB 1.1.3 (although I maybe should have tried working with 1.1.5 for this game) and not doing any engine changes, because it helped me concentrate on the important gameplay ideas instead of implementing everything cleanly and properly. Plus it kept me from debugging the engine at all. On the downside it again took me half an hour to remember the parameter passing bug in eval statements in vanilla TorqueScript and use the work-around in my code. Also the t2dPath implementation is horrible and buggy! And I thank god, that it didn't blow up all the time and I was able to correct the mess ups with a text editor or simply recreate the level.

• Be flexible about the game design and simply keep it simple, stupid (again!)

The original game I envisioned isn't all that different from the outcome but it still is different enough that I wouldn't have imagined it to be this way. The design changed a fair bit with me making up my mind on it only Sunday morning (while showering). I spent most of Saturday night with feature proof-of-contest coding and setting up everything for the actual gameplay code. Being open to changes helped me a great bit, because I would simply adapt the game look and design to limitations (both time and feature), and keep on creating a playable game.

• Try to reward the player with nice graphics and sounds

I think the visuals help the game a lot because you really rather play something that looks nice. At the same time it's a pity and a real problem that the game doesn't make use of any sounds or background music and this hurts it quite a lot.

• Good/intelligent level design is even more important for small prototypes

Another thing I only learnt a short while ago about is that the order of the levels (something I spent less than a minute on) had a huge implication on how the gameplay was perceived by players. Because the the first levels can be solved by making one continuous stroke, many players thought that this was the main task of the game and were confused when they played on.
For me the level design simply was something to do half an hour before the planned release because I was only concerned with the code and showing that it works well, whereas actually the level design is more important than the code because only it determines how the game is viewed (fun or boring). I certainly have to spend more time and consideration on level design at the next GID.

All in all though it went fairly well and even if the game might not be as much fun as it could have been, I still am of the opinion that it looks and play fairly professional for a game that has been produced in less than 20 manhours.

That's it for today.
Over and out,
BlackHC

This weekend I've participated for the first time in the GID event. The common task is to create a running game prototype in 24 hours (24 hours pure developement time + naps is allowed, too).

I think it went well considering that this was my first participation but essentially I've failed because my game prototype is nowhere near finished. It's rather at an early proof-of-concept stage instead...

Let me introduce the prototype/game quickly - it has no name yet, so let us look at some screenshots instead:

You see, it's about a stickman that can move. I'm not going to go into more details yet because the game doesn't consist of much more right now.
If you want to see a more interesting animation though, click here.

For those interested here's a postmortem.

Postmortem

The first problem arose right when I wanted to start: what should I code?

I've come up with a few different ideas the days before the GID started:
a Zone66/Baryon remake (space-shooter like), a Prince of Persia remake and/or a platform game in general or a game which was consisted of drawing shapes with the mouse - I've played a few very neat games of this kind lately: Chalk and Crayon Physics - and I felt that this was an idea that I'd really love to explore but on the other hand I couldn't come up with an interesting and original gameplay idea.

Beforehand I've prepared a few things for a possible platform game. I really love stickman flash animations (for example the one here) and thus I've decided that a stickman would be the perfect protagonist, especially since it certainly is easy to create good-looking animations for him.

Searching around with Google, I've also found a very neat tool called Pivot Stickfigure Animator, which allows one to easily create animations for stickfigures and other similar shapes and export them to animated GIFs.

An idea I had Saturday morning was a game in which the stickman is running all the time and you have to do cool moves to avoid obstacles and maybe fight enemies. This should create tension and force the player to always pay attention while rewarding him with neat animations and fun gameplay.
The feelings created in the players should be similar to those I felt when playing Prince of Persia: Warrior Within when you're trying to escape from the time guardian - I really love these parts of the game! - but at first I thought that the idea was not worth pursuing. Later though, Juz from #q3mods proposed the same gameplay idea and I told myself that this can't be a coincidence and decided to create my prototype based on it.

So I've only been able to come up with a good game idea late into Saturday afternoon while the others were already working on their games which is the first thing that went wrong: unsufficient preparation.

The next one was that I concentrated too much on creating art and sadly the results aren't stunning despite the time I've spent on creating the animations. A reason for this could have been my horrible and most terrible art pipeline which looks like this:
Pivot Animator -> GIF Constructor -> GIMP -> GIF Constructor -> GIMP -> TGB
This couldn't be automated and every step had to be done by hand.

After about 10 hours of work the game was this far. I've also lost quite some time (~2.5h) developing a movement cache system that wasn't used at all because the game never got far enough to support more complex moves and combos which is another thing that went wrong: wasting time on useless stuff.

It also turned out that although I have already developed a few games in TGB I still didn't know some systems well enough (mainly collisions and physics) because I've never coded a platform game before and I had to use trial&error quite frequently while implementing new features.
Which leads to another thing that I could have done better: know your tools beforehand!

And last but not least, now that I'm looking at my end-product, I realize that I haven't stayed with the simplistic gameplay idea I've had in the beginning but instead diverged to a too complex game ; thus last two items on my list of stuff that went wrong are: violation of the KISS (keep it simple, stupid!) principle and feature-creep.

On the other hand there are a few things that went right, too:
This is the first time I've developed a game using rapid iterative development and it worked surprisingly well: hack a few features into the game first as fast as possible, then clean-up and refactor the code afterwards and repeat. (Normally I'm attempting to write the clean version directly but this takes more planning.)

Moreover I've learnt many things about TGB I haven't known before and I've grown even more fond of it as a game development system.
And ultimately I'm going to continue development of this game even after the GID's deadline because I really like my stickfigures.

On other news I've finally finished my A-Level exams and it seems that I've really rocked them. Tomorrow I'll be allowed to take a look at the marking and hopefully that will explain why I got such good marks..