Another game jam down, another toy game/prototype to show for it! Drunkle is based on the theme “two button controls”, and was made with the help of returning team members Nathan, Peter, and Luke.

Drunkle seems to keep getting himself excessively inebriated. Help him navigate the precarious hallways of disreputable inns and taverns so that he can reach the exit before he makes a terrible mess.

As usual for projects I do in Unity, you can play directly from your browser, or grab the Windows 32-bit or Windows 64-bit build.

If you were a participant in Ludum Dare 34, we’d welcome your ratings and feedback on the Ludum Dare entry page.

Retrospective

Two themes were available for this Ludum Dare, being tied in votes, and I don’t think any of us were very thrilled about either one. In fact, when one looks at the overall votes, it’s apparent that this was a common sentiment; these look to be the two themes that the community disliked the least, in contrast to the two which were liked the most.

But you work with what you got. Growing, despite my prior instinct, failed to inspire any creativity in my mind. And we struggled to come up with ideas for two-button controls which weren’t already done to death. The ideas that did seem somewhat novel were at risk of being hard to control, for no reason other than the arbitrary limitation of two buttons. It doesn’t feel right to me for a game’s challenge to come predominantly from a poorly designed interface.

Somehow or another we decided one particular variant might, might, not be so bad, so we decided to roll with it and at least see how it felt to play an early prototype. And the notion of making our character a drunk overweight Hyrulean warrior as an explanation for the awkward interface also formed during this time. I think Nathan gets the credit for that.

Drunkle, narrowly wobbling past a pit toward the goal.

The first prototype implemented the same two-queue action system as you can find in the final game, but the actions were to turn 90 or 180 degrees to the left/right relative to the player’s current direction, and thus there wasn’t a fixed objective in one overall direction. We found it excessively hard to predict what our actions would do, and so it turned into a button-mashing mess.

Fixing the camera to the player instead of the world helped a little bit, since rotating left or right was easier for the brain to process, but now that the whole world was rotating, it was still messy. I think it was when we made the actions absolute directions rather than relative to the player’s current direction that our minds could actually keep pace with the flow of the game. Upon reflection, we might have been able to do this without making level linear (absolute directions would be the obvious left/right/up/down), but there’s only so much time in a 72 hour game jam to experiment with mechanics. At this point we’d already burned a lot of time experimenting with mechanics we didn’t much like, but the practice with prototype play testing was nonetheless invaluable.

In line with this not-enough-time theme, I’ll note here that we were also hoping to add a wider variety of actions (jumping, sliding, teleporting, slashing a sword, and throwing bombs were all considered), as well as items that one could pick up and use. I have a suspicion that these sort of additions could have a hugely positive effect to the gameplay experience. If done right, naturally.

Anyway, that’s more or less it for the mechanics. Unity worked out pretty well again for implementation, though I will admit that my code was beginning to shape itself shamefully in the form of spaghetti. During normal development, I’d probably have refactored at least once, maybe two or three times before shipping even what we currently have. But kluges and shims always seem so enticing when you have little time left, and it’s mostly working as is.

The camera behavior was something we had discussed since Friday, and I finally put it in at the beginning of the last day. That really began to solidify the concept that this was a drunk guy walking through a precarious environment. Peter figured out how to beautifully represent this context musically, further adding to the mood. And Luke came in on the last day and saved our game from the fate of programmer art with environment sprites and a logo.

All in all, I was happy with the additional experience with Unity, in particular fiddling around with coroutines. I’ve used them in the past, but keep forgetting they exist. Nathan enjoyed experimenting with character art and animation styles, and he’s excited to take Drunkle’s style and go further with it. I think we gave Peter a challenge, essentially asking for music that was dank and dungeony but still somehow drunk and fun at the same time, and he met that challenge wonderfully.

It wasn’t the most organized game jam ever; all four of us had generic life activities take up a notable portion of the weekend. But there’s a good chance we’ll work as a team again for the spring Ludum Dare.