Biweekly Games - Game 1 Postmortem

Around two weeks ago I decided on taking a challenge to improve my game making and prototyping skills. The idea is: I have to make, release and post about a game every two weeks. The game has to be completed, and after every game I should write about my experience making it.

Initially it would be a weekly thing, but school + work makes it complicated, so two weeks on my spare time seems like enough. This was largely inspired by two sources: Rami Ismail's article on Gamasutra (Game a Week: Getting Experienced at Failure (2014)) and Adriel Wallick's talk on GDC 'Eu 2014 (Game a Week: How to Succeed, Fail, and Learn). If you're a game developer, I highly recommend you give them a read/watch.

I also decided to use a randomized theme constraint for now, in a very game jam sort of way, to help creating new ideas while still keeping them contained and grounded. But I might change this along the way. So, here's game 1: Garbage Day.

Idea

The theme I polled for this game was "The More You Have, The Worse It Is" (which I found out was the theme for Ludum Dare 40). The idea that I ended up going with was to make a game where you would balance a tower of stacking objects to be the smallest possible. During the game, you would collect objects, and if you moved too fast while carrying a big stack, it could fall over and you'd lose. With that, I came up with the concept of being a trash collecting robot, picking up trash falling from above and carrying them to the closest dumpster.

I spent the first day trying to figure ou how to make a stack of items that could behave the way I wanted, but with a couple hours in and no success, I figured it would be hard to do within my time constraints and current skills, so I decided to go with a different approach: the trash would be collected inside the robot, and you'd get slower the more trash you have inside.

What Went Right

I think pivoting early for a more contained and easier to implement idea was a good move, because I think trying to get the stack right (and the game design consequences that would follow) could prove very time consuming. Keeping it simple helped me schedule everything tightly and finishing it on time.

Also I very much like the trash bot's design, and some effects I did to make it all feel nicer (like the movement dust).

What Went Wrong

I playtested this game seriously way too late on the development process. I had the concept, I programmed what I thought I'd need, and then went straight into making all the art and animations. If I spent more time playing and refining the concept, I could've ended up with a more fun and engaging loop.

I also think the end product didn't really achieve what I was hoping for with the theme: a choice between carrying less trash and being faster or carrying more trash and being slower, depending on how much trash was falling from the windows. The way the game is now, you either can move easily or move way too slow for it to matter. Again, iterating on the gameplay would maybe help with this issue.

What I Learned

The ideal thing for a small game like this is for it to be fun and engaging, so playtesting constantly and prioritizing gameplay while compromising on other aspects I think should be a more interesting approach. Also, maybe using more outside art (making it all myself took a lot of time). And time management/scoping is very important (I made all of it in around 24 working hours).