Eight months ago I was looking towards the future with blazing excitement. Today, I look at the past with mixed feelings. I look back upon my journey, and I am ready to acknowledge the mistakes I’ve made for the sake of progress.
First and foremost, I made a huge mistake underestimating the amount of work it takes to make a cohesive experience with randomly generated dungeons. I can probably attribute 40% of my entire development time to working on the generation algorithms. Heed my advice, randomly generated environments is not an easy way out by any means. It’s like trying to tame a wild beast. You have very little control. The more control you put on it, the more same-y everything will start to feel, and the generation will become stale. The trick is finding a balance, I’ve found.
The greatest problem I had during development was a lack of direction. It might seem trivial, but choosing and sustain a direction can be hard on your own. Ideas constantly flooded into my head during development, and I was constantly inspired to try new things. It wasn’t a bad thing, but it slowed my development time by a ton. Why? At first I programmed things with one idea in mind, but then I wanted to do something I hadn’t originally intended, and I’d have to go back and hack my code to make it work with my new idea. I was doing this daily for the first 3 or 4 months. Afterwards, my code was an absolute wreck and I was nearly forced to go redo all of it.
From that, I’ve learned the true value of planning a thorough game design document. I made a 6-page plan for this game, and in the end only about 1 page of it actually ended up in my game. My design document wasn’t nearly as specific as it should have been. I didn’t consider balancing, tweaking, progression, challenge, or reward. I conceptualized characters, enemies, and environments and dabbled with some features I’d like to have. That’s not a design document. Not on it’s own, at least. A truly useful design document, I’ve learned, should contain specifics and detail the utmost details of player interaction with the game.
The importance of having such a clear document, is that then you’ll know what to program your game for. If you want to leave yourself leeway in design, such as for more weapon or enemies, then you know to do it ahead of time, instead of going back and hacking in support for that later. It’s crucial to development time to never have to take steps back. For one, taking steps back is completely demotivating and hurts your development momentum. Notes for the future!
In retrospect, one of the biggest mistakes I made was choosing a low pixel resolution to make spriting easier for me. Let’s be clear—It didn’t make it easier. It made it harder. The main character is 11x12 pixels. With some good pixel skills you can fit quite a bit of detail in there, but alas it’s still only 11x12 pixels. If I went with a much larger resolution I’d have had much more opportunity to detail my game.
Flash is a great platform for making games. It’s well suited for making nearly any 2D game. Flash is very portable, and very developer friendly. Flash game portals, however, are not developer friendly. I’ve found that they often have a very narrow view of what games they want for their sites. Which is a shame, but that won’t stop me from using Flash for commercial games in the future. I simply won’t be aiming to get my game sponsored on a game site at all.(unless it seems like it fits what game portals want)
That concludes my Pocket Protector postmortem. I guess it was fairly short, especially in respects to how long it took me to make the game. I guess that’s due to all of my trial-and-error’ing along the way. That’s a lesson in itself.
No comments:
Post a Comment