{"author_name":"Waterman7","cat":"LD #31","comments":[],"epoch":1419693240,"likes":3,"metadata":{"p_key":"4502","p_author":"Waterman7","p_authorkey":"31692","p_urlkey":"57125","p_title":"Postmortem: Sprotzel","p_cat":"LD #31","p_event":"LD31","p_time":"1419693240","p_likes":"3","p_comments":"0","p_status":"UPD5","us_key":"31692","us_name":"Waterman7","us_username":"_waterman7_","event_start":"1417737600","event_key":"26","event_name":"LD31"},"text":"

[reblogged from my game design blog Replay Value<\/a>]<\/p>\n

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<\/em>, which you can play right here<\/a>.<\/p>\n

<\/div>\n \n \n \n \n
\"\"<\/a><\/td>\n <\/tr>\n
Sprotzel<\/td>\n <\/tr>\n <\/tbody>\n <\/table>\n
\n
<\/div>\n
\n

What went right<\/span><\/b><\/p>\n <\/div>\n <\/div>\n

\n

Choosing constraints …<\/b><\/p>\n

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<\/i>\u00a0to the technical constraint\u00a0The screen never gets redrawn<\/i>. From there, I quickly came up with some concepts that sounded interesting, one of which resulted in the final game.<\/p>\n

… then abandoning them.<\/b><\/p>\n

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.<\/p>\n


\n <\/b>Staying in the flow.<\/b><\/p>\n

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<\/em> 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.<\/p>\n

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<\/em>, I don’t think I would have been able to do anything of the sorts. I guess\u00a0flow<\/a>\u00a0is as important for a dev as it is for a player.<\/p>\n

 <\/p>\n <\/div>\n

\n
\n

What went wrong<\/b><\/span><\/p>\n <\/div>\n <\/div>\n

\n

Not\u00a0play-testing.<\/b><\/p>\n

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.<\/p>\n


\n <\/b>Not leaving the comfort zone.<\/b><\/p>\n

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.<\/p>\n

Not making audio. Again.<\/b><\/p>\n

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.<\/p>\n <\/div>","time":"December 27th, 2014 10:14 am","title":"Postmortem: Sprotzel"}