These toggle switches are working on desktop and mobile and preserve their layout when the browser window is resized. Earlier today, I wasn’t sure I’d ever get this far.

Happy sleep now.

This’ll be my fifth LD. I’ve failed two. I hope to avoid timesink rabbit holes and my inner editor.

I’m not thrilled with the final round of themes, but I’ll make do with whatever we settle on.

I haven’t decided whether I’m doing the compo or the jam. I’ll decide which tech to use after I figure out what kind of game I want to make.

Languages: HTML5/Javascript, Unity/C#/Javascript, Ruby

Libraries: iTween (Unity), CraftyJS, jQuery, Underscore.js, CanvasInput, howler.js or lowLag.js or jukebox for audio

Networking: My own unproven, in-development attempt at a simple pub/sub server, reflector.

Sound: Audacity, sfxr, iNudge

Art: Inkscape, GIMP

This post serves as my announcement for the reflector server codebase, though the server is more like a tool than a library. I hope to have it feature-complete before the compo kicks off tomorrow.

I’m also organizing a real-world gathering this time around, so I hope to jam next to a bunch of other jam-driven people.

My game’s a local multiplayer HTML5/JS one-button racer. You’re rushing your unicycle around a planet at breakneck speed. Or you would be, if I was finished. With an hour left, it’s not looking great.

But the pizza will be here soon, so that will spur me on. And hey, there’s the Jam as a fallback, right?

Looking forward to the 10th anniversary! Maybe I’ll finish a game! Tools:

- HTML5
- Javascript
- CraftyJS
- Underscore.js
- jQuery
- Jukebox from Zynga? Am I nuts? Maybe!
- Andre Michelle’s sound circle toy (oh no! It’s gone!)
- The Mobile Game Primer (OMG AMAZING)

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.

(more…)

Okay, got some output. My sprites still aren’t rotating properly, but I think I’ve got a hunch why. Still to go: systems icons, meters, reactor graphics, path finding, and action gameplay. Sound? Maybe! Going to be an interesting day.

It’s been a tragically low-productivity day. I have some gameplay description written out and some nice tiles drawn. Gotta forge ahead into some code before it’s too late!

I’m in. HTML5/JS for the cross-platformness. Specifically, CraftyJS, Underscore.js, jQuery…

I have a game idea that I’ll need to fit into the final theme. It’s sort of an action resource management game that draws on pipe tile games like the classic Pipe Dreams or the card game Waterworks. Except you’re on a spaceship that’s under attack.

So many placeholders. My goal for this evening is to finish the “go” button logic that executes your actions on the characters and rooms each night, dress up the placeholders a bit, and get a story put together that can evoke some horror from the player. That’s probably enough to submit for this, though not enough to satisfy me. I might keep polishing it for a while after the mini-LD with an eye toward this month’s Experimental Gameplay and Super Friendship Club.

I was able to formalize the story module format last night. Everything’s in CSV spreadsheets; characters, rooms, story fragments, story-specific game configuration… This lets me almost completely separate content from logic, and should let a person build a story module without learning/modifying the code.

Screen shot below. That’s the basic interface once you’ve started a story. Clicking a room gives you a menu where you can “lock in” an experience type for the night (e.g. noises, dreams, physical manifestations). Once the actions are locked in, the “Begin” button will start the night. You’ll get accounts of the night’s goings-on from the characters the next morning, which will help you understand the story you’re trying to tell them.

Very nearly operational

Still going on the Mini-LD. It’s my first time, so I figure I’ll get the blatant cheating out of the way now; it’s been more than 48 hours on the wall clock. I probably only have 12 hours of dev time so far, so I’m running with that. =)

Javascript is a tricky mistress/master when you’re not accustomed to working with it. I’m learning the CraftyJS framework at the same time (for the second time). Got the concept for a data-driven horror-ish story game pretty well worked out and more than half-implemented. It’s almost interactive now.

The premise is that the player is a location that has experienced something wrong. My sample case is a house which experienced a tragedy. Some folk have chosen to spend the night at the house, and it’s your job (as the house) to communicate the tragedy to the occupants through metaphysical actions. Your basic set of actions can produce different outcomes based on the person and the part of the house they occupy. The player learns the story through the experiences of the visitors.