Lesson learned: don’t leave the core gameplay and puzzle initiation algorithm for last. Argh.

The game was supposed to play a little bit like Pipe Dreams. You’re the last engineer on an otherwise vacant starship, the ship’s AI is taking care of navigation and weapons, and you need to make sure the shields, weapons, and life support stay powered under enemy fire. The board starts with a reactor on one side, the ship’s systems on the other, and a bunch of power routing tiles in between. You reconfigure the grid by rotating tiles to provide power to the systems that need it.

What went well

For the first time ever, the graphics came together really well. They were a little time-consuming to make in Inkscape because in between sessions, I forget everything I know about it. I was happy to finally have a game with a consistent graphic style that wasn’t offensive or straight outta MS Paint.

I got the tiles clicking and rotating pretty easily. That was a great confidence booster early on. The background game simulator that powered the ship’s systems and dealt damage to its shields over time went together really well, too. Adding scripted events is as simple as adding a hash with an ‘enabled’ flag, an interval in milliseconds, and a fire() method that performs the game state update and requeues itself.

The Android WordPress app was lovely when the LD site wasn’t under load. Rather than fiddling with screen shots and files and the web UI, I could pull out my phone, snap a pic, and post. Awesome.

What didn’t go well

Eating, sleeping, staying focused, and holiday things that will now turn into last-minute nightmares. And then there’s the technical bits:

The Problem

Given how hard it is to programmatically find a smart route through the tiles between each of the three ship systems and the reactor, I’m now thinking that the Tetris-like pick-n-place behavior may make more sense than starting with a filled grid. I thought the filled grid would be more interesting, but crawling the tiles to find each system’s connected power grid is tricky. Two systems can’t use the same tile. So who gets to use it? The first grid that’s fully explored? That was my first strategy, and it lets one well-connected system take over the board. Maybe the systems have to explore the grid in parallel, each acquiring one tile at a time before the first can acquire another.

The Result

I was really looking forward to completing my first LD. I figured I could cram a bit into the submission hour, even. And then it was too late. I had a bunch of nice-looking tiles that rotated when you clicked them, and I couldn’t figure out why they couldn’t see their neighbors. Heartbreak and disappointment.

Since this is also a sort of prototype for a part of a larger game, the plan is to see it through to some kind of playable state. The holidays may torpedo that plan.

——

CraftyJS bugs I have yet to report:

• Tint component draws tints under my canvas sprites. Not sure why, but that isn’t useful to me.
• Tween component overshoots values; tweening my tiles through 90 degrees of rotation went 5-15 degrees too far.
• Initializing component properties to new objects at the time of declaration (instead of inside the init() constructor method) shares them between all instances of that component. Not good, may not be fixable.
• FPS seems to be fixed at 50fps. Should be adjustable in Crafty.init().
• Typeahead find bug is back? Keypresses bubble up out of Crafty and trigger the browser’s typeahead find.