I’m all about that ancient tech yo.

I did quite a few game jams as a college student. Now that I’m a grownup with a 9-to-5 routine I figured I’d mix things up and get back in the game jam groove.

Currently learning Phaser and working on an Oregon Trail-alike.

I have to face the facts: there’s no way I’m learning a whole new engine in 72 hours. I need to come out of this with a game.

Unity, my long lost love, I return to you.

Previously, in LD36…

The design is simple. The mule creature in the center is basically a bio-mechanical caravan housing a family of post-apocalyptic pilgrims. (Mmm, bio-mechanical. What a sweet word, Mr. Giger.) Things happen to your people along the way — think FTL without real-time elements. The main challenge for the player will be resource management.

I made an events queue system. The game will be divided into days, and each day will be divided into time periods. Each of these time periods will constitute a turn. On each turn, an Event will take place. Events can be added to the queue as needed (e.g. if a trader appears, queue up a Trade event) but only one event will be played on each turn. If there are no events in the queue, a NoOp event is created, and the game renders that as “Nothing happens”.

Events can be flagged as “major”; major events are immediately moved to the top of the queue. This is essential for critical events such as character deaths — after all, if you’ve got a bunch of minor events queued up and a character falls into the furnace, you’d want to get notified for their death as soon as possible rather than watch them burn for multiple turns as the queue empties out.

As is typical of game jam entries, this is all driven by a GameManager god class. It looks deceptively clean for now, but I know what’s coming. The bugs are out there, waiting to sneak into my haphazardly written, tightly coupled, singleton-oriented spaghetti code. And I shall let them in, in the name of progress and speed, and in the hope that a few of them manage to transcend their cursed nature and reveal themselves as… features.

Previously, in LD36…

The design is simple. The mule creature in the center is basically a bio-mechanical caravan housing a family of post-apocalyptic pilgrims. (Mmm, bio-mechanical. What a sweet word, Mr. Giger.) Things happen to your people along the way — think FTL without real-time elements. The main challenge for the player will be resource management.

I made an events queue system. The game will be divided into days, and each day will be divided into time periods. Each of these time periods will constitute a turn. On each turn, an Event will take place. Events can be added to the queue as needed (e.g. if a trader appears, queue up a Trade event) but only one event will be played on each turn. If there are no events in the queue, a NoOp event is created, and the game renders that as “Nothing happens”.

Events can be flagged as “major”; major events are immediately moved to the top of the queue. This is essential for critical events such as character deaths — after all, if you’ve got a bunch of minor events queued up and a character falls into the furnace, you’d want to get notified for their death as soon as possible rather than watch them burn for multiple turns as the queue empties out.

As is typical of game jam entries, this is all driven by a GameManager god class. It looks deceptively clean for now, but I know what’s coming. The bugs are out there, waiting to sneak into my haphazardly written, tightly coupled, singleton-oriented spaghetti code. And I shall let them in, in the name of progress and speed, and in the hope that a few of them manage to transcend their cursed nature and reveal themselves as… features.

Got a cool dawn/daytime/evening/nighttime cycle. This will help the engine show appropriate events for each time of the day.

I’m no game designer. I try, but I’m better at worldbuilding than actually creating engaging gameplay and presenting interesting choices. That’s why I went for this super linear design where all you do is click through a series of events.

This morning. I was feeling hopeless. My game was not a game. It was a slideshow. Sure, I could just introduce FTL-style multiple choice screens. But I would need dozens of those just to keep the game interesting.

Nevertheless, I marched on and started coding the last feature in my To-Do list: a linear minimap.

And there it was. It was pretty simple, really. Just a long line that the game can add and remove markers from.

Wait… remove markers? Why would you ever remove a marker from the minimap?

And then it hit me. What if you could choose to discard the current route and get a new (possibly harder) one?

And suddenly my game was not a slideshow anymore – nor was it an Oregon Trail ripoff. There is now one action, one choice the player can make at any point in the game, and that choice makes a world of difference.

That’s what I call inspiration from iteration. My fascination with the generation of diversion knows no cessation. Ideation is my vocation, the eradication of procrastination, and though my creation ain’t no sensation it is my heartfelt motivation to release it all over the nation.

My excuse

The one thing I needed to make my game complete was to be able to tell when you’ve hit an obstacle or thing.

Pretty simple, right? Add a collider to each thing and then check if the player’s thing is touching any other thing. Unity’s physics engine makes this as painless as it can be.

But that didn’t work for me. Even when my objects were touching one another, they still failed the collision check every time.

Can you guess why? I’ll give you Unity pros a second to figure it out.

Yes, all the objects had proper box colliders.

Yes, the collision areas were overlapping properly.

No, they weren’t on separate layers.

The problem is that colliders are not updated synchronously.

They only get updated when the physics engine does its thing; that is, on FixedUpdate(). And my game doesn’t use FixedUpdate() or even Update(). It’s turn based; all iterations of the game loop are triggered by the Next button.

So when you click Next, the mule moves forward, touches the obstacle/relic/whatever, and the game immediately checks if they’re touching; but they actually aren’t, because even though their positions have moved, the colliders haven’t yet.

I don’t know what the right thing to do is in my situation. Maybe I should store the locations of the obstacles in an array. Maybe I should use colliders and refactor the game logic to run in FixedUpdate. Either way, LD36 is over.

What I learned

• unorthodox gameplay mechanics means you’ll end up spending more time on design and iteration
• simulations are a terrible idea for game jams — good thing I discarded that idea early on
• I’m a million times more productive outdoors, with no chores or cat to distract me
• (from looking at other entries) having unique art is wayyy more important than having unique gameplay
• stick to a color palette dammit
• work with your engine’s strengths
• some bookbinding trivia