These posts tell the story of rainbow, my LD25 entry. In part 1 and part 2, I talked about ideation and the initial push to a working prototype. In this part I will talk about the refinements and polish I added to reach the finished version.
Sunday Morning: Sound
My Saturday prototype didn't have any sound, so I started out Sunday fooling around in Reason.
I decided to make the background music from a pair of loops (a dull "background" loop and a sparkly "rainbow" loop), which would be mixed according to level state. This seemed like a good option for getting some variability out of the music without having large downloads or making long tracks.
I additionally built some chords for when peons are enlightened, and a little arpeggio for when the rainbow starts.
Note: I took this screenshot on my mac laptop; however, I actually did the music stuff under Windows. This also meant that I had the chance to find a few OS-dependent bugs (most of the dev work was done under Linux).
To get the sounds into the game, I exported various tracks from Reason (selectively muting), then loaded them into Audacity where I trimmed and exported to ogg.
This is much the same workflow as I use for sound in rktcr. It's not very automated, which I think is something of a problem; but it certainly isn't one that I was going to solve during a time-limited game compo.
By noon, I'd added the last (crucial!) sound feature, muting:
I could have just turned off my speakers, but that would have interfered with listening to spotify in the background.
Sunday Afternoon: Polish
Going into the afternoon, I knew I had something that resembled a game, but there were many things that could be improved. I was pretty sure I wouldn't get to all of them, so I made a list and prioritized.
The first thing I added were peon textures. These tied the in-game experience to the intro and outro screens:
As you may notice, my first pass didn't actually change the peons' expressions, just their color. The fading turned out to be easy to add (~10 minutes more work), so I got that in next.
From there, I turned to the rainbow ends. I knew there needed to be some way to tell apart "live" rainbow (that could grow further) and "dead" rainbow (that had -- say -- enlightened a peon). My first attempt was to add fade-outs:
These turned out to be a bit too subtle, as you can see.
So I added sparkles:
I like these because they are higher-contrast than the fade-outs, they clearly indicate where the end of the bow is, and their motion makes them very easy to spot.
At this point, it was around 13:40 in the afternoon. There was a potluck I wanted to go to which started at 5pm; and I was treating this as my unofficial (early) deadline. So I didn't want to start any big changes on the game.
Unfortunately, I still wasn't quite satisfied with the way small rainbows controlled, and this was going to require a rather large chunk of refactoring to fix. Fortunately, the refactoring went better than I'd hoped and I had smoother small-bow control by 15:00.
As a bonus, the refactored control made it easy to draw sparkles that actually showed were controlled rainbows would be going:
This brought me to around 15:20, with the main game basically finished. Since I still had a chunk of time before the potluck, I added some animation (jumping/tipping peons) to the intro and outro screens, and drew additional title cards for these scenes.
At 16:30, I noticed things were no longer working in Firefox and had a 15-minute bug-hunt-scramble. I got the code up on my web page, figured out how to submit, and made it to the potluck by 17:30 or so. (Other times in these posts came from commit messages, the potluck arrival I just have to guess at.)
Final Thoughts
I think I did a good job on this project of picking something with a small scope, and getting it into a working state quickly. I also think I made the right choice by avoiding javascript frameworks and instead working directly with the default HTML5 APIs. This probably cost me some cross-browser compatibility, but it also saved a lot of reading documentation and fixing other people's bugs.
There were some ideas -- e.g. an overworld map to show level progress, color filters, mirrors -- that I could have added given more time. Specifically, the lack of an overworld makes it hard to know how long the game is, which is the biggest problem with the final version. There are also smaller things -- like optimizing the rainbow drawing -- which I would like to have done for perfectionism's sake, but weren't really required to make things work.
During development, I worried that the game was too easy. I had one of my neighbors play the first prototype, and they confirmed my suspicions. The player can see exactly where the rainbow will go, and there is no time pressure in planning its path. I wanted to fix this by having the rainbow constantly grow, but never got around to it. I guess I'm sort of glad that I didn't, as many of the comments on the contest page for the game talk about how hard it is.
Of course, these comments are wrong.
As a procedural note, I'm glad I sat down and rated a bunch of games (my brother helped by sitting with me and offering second opinions). Not only were there some real gems in there, it also meant that rainbow got rated a bunch of times. It's great to get feedback from so many people, and I'm flattered that folks found the game innovative.
Moving Forward
I find that I like this mechanic, and would enjoy producing an extended version of the game. However, my priority at the moment is rktcr.
No comments:
Post a Comment