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://data.blog.blackhc.net/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