[reblogged from my game design blog Replay Value]

A few weeks ago, I participated in the Ludum Dare’s 31st edition with the theme “Entire Game On One Screen”. I made a game called Sprotzel, which you can play right here.

Sprotzel

What went right

Choosing constraints …

I find it really helpful to set myself some sort of constraints when working on a game project. Those can range from visual constraints like using only a limited color palette to input constraints like only using only two buttons to play. In this case, I got from the theme of the jam Entire Game On one Screen to the technical constraint The screen never gets redrawn. From there, I quickly came up with some concepts that sounded interesting, one of which resulted in the final game.

… then abandoning them.

However, at some point, once I had the core gameplay and aesthetics implemented, I hit a wall. I wanted to include a new mechanic into the game (collecting pickups), but I just couldn’t seem to find a way to include it without either ruining the visual style, or breaking the constraints I had set for myself. So after some struggle I decided to drop the constraints and do what’s best for the game instead. Letting go of that self-imposed limitation was harder than I expected, but I’m glad I did so. I think constraints, especially technical ones like this, can be useful as a source of inspiration and design challenge, but only until they become obstacles instead of stepping stones.

Staying in the flow.

I didn’t polish the game as much as I could have. I stopped at some point, even though I still had ~24 hours of time left and started a second game. Now this is everything but consumer-friendly and the first game definitely suffered from it, but for me personally it was probably the better choice. Because anything I would have added to Sprotzel after that point would have been dull busywork. Implementing a proper in-game tutorial isn’t fun, it just takes time. And it wouldn’t have added anything substantial to the game experience.

So instead I used the remaining time and motivation to just start something completely new, even if I wouldn’t finish it in time. It actually went so well that I’ll probably keep working on this second project. Had I used another four hours to polish Sprotzel, I don’t think I would have been able to do anything of the sorts. I guess flow is as important for a dev as it is for a player.

 

What went wrong

Not play-testing.

This is really the one thing I regret the most about this jam. I was sitting in a room with five other people for the whole time and in the end each of them only played my game once or twice at all. I didn’t really do any explicit play-testing or ask for feedback, which shows in many aspects of the final game, especially its high difficulty.

Not leaving the comfort zone.

Sprotzel is a typical Waterman7-game if there ever was such a thing. I didn’t really try anything all that new or exciting or challenging. Not on the gameplay- and not on the programming-side. There wasn’t even a crunch-time. Somewhat boring really. It was still fun, don’t get me wrong. I just feel like I didn’t learn as much from this jam as I did from other ones.

Not making audio. Again.

This is slowly becoming kind of a running gag, except it’s tragic instead of funny. Although, this time I at least I gave it a try. The problem was, I tried to learn not only a new program mid-jam, but a whole new design-field. Of course, without any prior experience with sound, the endeavor was doomed from the start. I struggled with some unfamiliar interface and pushed random buttons for some amount of time before humbly resigning to the gods of sound once again. But I will have my revenge. Some day I will face them again, prepared.