what I learned from the Sinister Ducks
tartley on 2009/09/07 12:33
of Broken Spell
Sinister Ducks is our first PyWeek submission. We had a great time putting it together. Many thanks to Richard and everyone else who contributes to making PyWeek happen, and to all the other entrants for their work and passion and joy and tears and advice.
It is about the simplest game we could think up. We didn't set out with the following goal in mind, but after a day or so it became clear we were pretty much converging on the gameplay of the arcade classic 'Joust'. After realising that, we didn't go out of our way to avoid it - after all, Joust was really fun!
We don't have wild innovation, terrific production values, nor any variation or depth. But it *is* a game, more or less, that provides an amount of fun within its small remit, flapping around bouncing off other birds heads, and we got it uploaded within the deadline, and can point at it and say 'I made this'. That makes me happy.
My lessons from PyWeek:
FOR FUN: PREFER ITERATION OVER PREDICTION
Even with such a simple game, it was surprising to me how difficult the core mechanics were to nail down. For several days we imagined that collecting feathers would give birds a more powerful flap, but then we discovered that this wasn't actually a very desireable thing for the player, so we had to scrap that. So, plan to iterate on game mechanics is one lesson that obviously I've heard others say many times, but I'm learning all over again for myself now.
GET FAMILIAR WITH YOUR TOOLS
We could have worked two or three times faster if we had any experience with the (parts of) the libraries we were using. In particular, for us, we should have seen ahead of time that we would end up doing a 2D sprite game, because that just seems easiest and simplest, and hence I should have invested a little time up front understanding a few of the libraries for doing sprites, by hacking out a spritey demo or game, long before PyWeek.
VALUE GOALS & HANDS-ON EXPERIENCE
I dabble in games and graphics programming in my spare time, although the majority of that time goes into undirected exporation of whatever I'm finding most interesting at the time. Having a tangible goal with a short timeframe like this was a good change of pace for me, because it forced me to grapple with the mundane nitty gritty (like digging out that microphone headset and actually recording some dying-duck noises), rather than just imagining the process and thinking 'yeah yeah, I could do that'.
DON'T OVER-ENGINEER
All four of us on the team are professional software engineers. We like to think of ourselves as being relatively agile and enlightened, as corporate programming drones go. It's clear though that the different environment and parameters of PyWeek caused us to struggle against some of our ingrained mindsets. One of us, when creating a three-line .ini file to store some settings for the game, found himself thinking about how best to acquire / implement a general-purpose config parser - luckily he caught himself in time. I, however, actually spent (wasted?) a few hours refactoring our sprite/image handling code. Although the code is now better looking for it, I didn't then have any time left over to build anything on top of the refactored code, so the user-visible difference is naught. With such a tight timeline, at least for a team like ours that is inexperienced in this domain, and has limited free time at our disposal, everything has to be focused on immediate and visible payoff. What can I do that will improve the game this hour? Within ten minutes?
Right. Time for chicken soup, then some judging...
(log in to comment)
Comments
cyhawk on
2009/09/07 19:16:
I love the self-recorded sound effects! They make a game much more personal than however-realistic samples downloaded from freesound.org (and the copyright is much clearer too), and they are much fun to record. I make them myself too, and last year I even received a "Most disturbing scream" award! :)
tartley on
2009/09/07 19:24:
cyhawk. We might be talking about two very similar games then - Joust also was much fun because of local two-player! It's on the multi-arcade-machine-thingy, it looks like the old r0mz are considerably easier to find these days than I remember then to be a few years ago, so you shouldn't have any trouble, although I would never condone that sort of thing, especially on richard's lovely forumspace.
cyhawk on
2009/09/07 19:36:
nitrofurano on
2009/09/07 16:09:
an oppinion: code for handling sprites is never time wasted - all the time spent to research and experiment them really worth the time spent - as example, only focusing shmups, i would ask you all to see the following arcade games from 80's:- Scramble Formation / Tokyo (Taito)
- Exerion (Jaleco)
- Dangar (Nichibutsu)
- Gradius / Nemesis (Konami)
- Vulgus (Capcom)
- Rygar (Tecmo)
- Legendary Wings (Capcom)
- Xevious (Taito)
(and not exactly about arcades, Uridium is a very special case to analyse)
Each one have complelly different way to deal with sprites, which teaches us we can handle the sprite desing as anything we can imagine as unique - which if we spent 75% of the development time on how the sprites performs, and just coding this stuff separatedly from the whole code (like on some warmup snippets), the result can be really surprising!