What went right

1. Play a little, make a little.

I built most features in order the the player needs them:  reveal fog, sail around land, get a cannon, shoot a pirate, get gold, eat fish, save at a city, and so on.  I would play and say, for example:  hm, that pirate needs gold.

2. Familiar with some simple games of discovery.

I started with inspiration from my teenage play of Civilization I and Starflight.  I could already imagine sailing.  save points like Robot Wants Kitty, revealing tiles like Civilization I, limited fuel like vehicles in Advance Wars, and side-shooting like R-Type I (although more whimsical as in Trip on a Funny Boat).

At first I had shooting forward, but by shooting both left and right automatically, shooting felt relaxing.  By shooting only to the sides, I only needed enemies (like te sea dragon) to attack on the sides.  Also the unrotated ships are more plausible when considering most motion is only from left to right.

There had been rocks, crags to crash against, and shooting a herring or a monster getting to a herring would kill it.  About seven hours before the deadline, the frame dropped to 12 FPS.  I gutted the collisions and crags, and in giving the computer less to worry about, I also gave the player less to worry about.

3. Tools and engine handle the stress.

Flixel handled the 256×128 tile map.  As did DAME, the level editor.  The frame rate is fast and stable, which is essential for shoot’em up action.  I had practiced using each tool and technique in previous two-day games, so I could focus on the design.

What went wrong

1. World map is too large.

The world map is 256×128 tiles.  That is nearly 100 screens.  Until 9 hours before the deadline, I only had a few center islands.  In some miraculous feat of about three hours, I made the remaining 80 or so screens of the world.  Next time I would rather iterate on a world about 128×64 (about the size of Robot Wants Kitty).

2. Distracted by more ideas than I can make.

I told myself I would start programming and play something within the first five hours.  But what?  I drafted two segments of screenplays for two hours, before finally convincing myself that an old world sailing shooter would be a more consistent setting for the features I had in mind.  I had so many ideas though:  galaxy or old world sea, food container upgrade, animated bosses, treasure chests, and more.  But, how do I program boss behavior in two hours?  The dragon’s large size, rush in a narrow inlet, hit points was the simplest I could make.

3. Graphics pipeline overkill.

I like the visual interface and convenience of DAME a lot.  But somehow it flipped half of the sprites (without that option being checked) and made a couple of other strange changes, such that I don’t think I can maintain the map without replacing many sprites.  I didn’t need that, and could have loaded monsters from tiles instead of sprites.  I also exported from Flash CS4 a SWF for city, player, HUD.  I had a hard to read text HUD in Flixel that I replaced with a CS4 SWF.  It works well, but setup cost me an extra hour.  I drew the graphics in Flash CS4, but the vector shark and hydra scaled down to be imperceptible on a 25×25 tile, same with dragon’s ruby eye.  All this attention to my graphics pipeline kept my procrastinating sound.  I knew SFXR and like it.  I tried for last minute sound, really last minute.  So I wound up with no sound.

Healthy sleep and diet

Finally, I could have made more if I had kept a consistent diet and slept well Friday night.  A couple of naps and grogginess cost me a couple of hours.  And I could have enjoyed Monday after if I had not stayed up until the last minute (3 a.m. here in Amsterdam) Sunday night.

Altogether, I’m proud of the voyage in the tiny world of Here Be Monsters!  It’s worth your trip.