My entry long ago submitted, time for a postmortem/wrapup/etc.

My original plan was for a god game in the vein of Populous. My final game was a dog running around a tiny circular world and catching frisbees. A lot can change. I spent ~13 hours, total, on the submitted game. It is written in Javascript with a custom “engine” – I pulled in keyboard handling and 60fps rendering/game loop code from a previous 48h comp but otherwise had no pre-built engine. All assets were created in Pickle and modified with Paint.NET and Gimp, depending on my needs. Music and sound effects were created in Aviary’s Roc and tweaked/trimmed in Audacity.

The Populous game ended up being a waste of the entire first evening – I spent too long making something look good (it didn’t) without considering the game, the fun, anything. I went to bed with a triangle mesh sphere that couldn’t rotate north/south and thoughts of just quitting and enjoying the weather forecasted for the next day. Instead, I got an idea that morning for a quickly implementable game and ran with it – run around as a dog, catch frisbees. I had way more ideas than I had time or desire, so I ended up with something far different than the original idea. Which was this:

You are a dog that runs around a (circular) world. You must contend with a basic simulation of running as a dog such as taking a while to turn around and worrying about slipping. There would be pits, obstacles, mud, and other things to hamper the running. A frisbee would spawn, thrown by some unknown entity and a inset hud element would show up like in a space sim; it would contain the velocity, position, spin, and tilt of the frisbee. Having to contend with the wind on top of the environmental hazards, you would attempt to catch the frisbee. Rinse and repeat.

Everything from that but the dog and concept of catching a frisbee got cut – it became about peacefully running around this little planet, getting some air off of hills, and nabbing frisbees. You can see a general progression of the game’s graphics:

The biggest change was the final level of polish. Each segment of the world had, up to that point, been colored by randomly selecting a green in a specific range of colors. Two adjacent segments could be colored randomly and would clash; I modified the coloring to pick a random segment, permute its color by a small amount, and then spread that to the two left and two right neighbors of the segment, falling off a bit at each. The camera also moved up – the ground is boring and plain beyond the hills, but the sky is interesting. Also, when in doubt, look at Mario – he is usually towards the bottom 1/3 of the screen. I also added a “shadow” world behind the main segments to create some fake depth; I initially had it parallax, but this was distracting so it rotates at the same rate as everything else.

What went right

• Polish. Polish polish polish. I spent a long time on “feel” and “style”. Having the dog get air when running off a tall hill; making the dog get a little “ahead” of the camera when running; clouds moving at slightly different speeds. In my (only) previous 48h game, I spent maybe 3/4 of the time writing engine/game rule code; the rest of the time was spent on feel and polish. Here, it was close to 50-50 if not even more time spent on polish.
• Aggressive cutting of features. This was helped by deciding to not spend 48h on the game. I think I spent 13h on it (plus a previous 6-7h on my initially thrown away idea). I took breaks, I sat in the sun. This was a boon, though it also means the game was short on game. But, if anything took more than an hour, I said whatever state it was in was done and I moved on to something else. I might revisit, but an hour was the most time to spend on any one thing. Most times it was 30 minutes or less.
• Simplicity. I didn’t use any engines; only some previously-written (and published) keyboard handling code and canvas2d setup/framerate code. My only collision detection needs were deciding which side of a line a point was on and colliding two arc segments (which is the same as two line segments, hence a single line of code). The previous 48h game, I had a full 2d collision detection engine that did mid-frame detection. It was buggy as hell and entirely unnecessary to write for the jam.
• Knowing my tools. I had previously written an HTML5/javascript/canvas2d game and done simple sprite work in Pickle + Paint.NET + Gimp. The only tool I learned during the jam was Aviary’s Roc for the music/sound effects. Saved a few hours at least by doing this.

What went wrong

• Motivation. Throwing away a night of work, going to bed late and grumpy, and waking up to 80 degrees and sun was hard. I had, in fact, sent an email to my partner saying “you won’t be a code widow this weekend, lets enjoy the weather”. Only to go for a jog, get hit by inspiration, and say “never mind”. I still spent much of the weekend not coding, so the game was short on everything.
• Lack of paper-and-pencil time. I spent barely any time thinking or writing away from the monitor. It is easy to get into a rut or logic loop and lose 30 minutes running in place. You also need to validate your ideas; when you just start coding, it is easy to spend hours working on something that would have taken 5 minutes of thinking-time to decide wasn’t fun.

The rules say I should “publish” my hand-crafted “engine” on this board to qualify – so https://github.com/hazzen/pidgine is my planned base of code, a minimal set of stuff based on my Molyjam entry. Other tools: paint.net/gimp, vim, sfxr if I decide to do sound.