One Game a Month, March Retrospective

Published on 2018-04-04.

One of the things that can make starting a personal project feel so safe and pure, compared to a project commissioned by a client or employer, is the absence of deliverables and a deadline attached to them. “Do whatever you want” as a set of requirements has an attractive mystique to it.

One Game a Month’s rules are left mostly open to interpretation. In my interpretation, the only additional requirement over the “do whatever you want” requirement set is “do it in one month.” OGAM is about delivering a cohesive product each month. That one detail is enough to make it a much different experience than a completely open-ended undertaking.

Ending a project with a self-imposed deadline has been uncomfortable, especially with one eye on the next idea on the horizon, carrying its own short window of opportunity. Writing this retrospective post feels equally uncomfortable, but is obligatory.

March has come to an end, and development on Cats is finished, for now. Cats is a very simple experience. As the observer of the story, you feed two cats from your inventory. If you feed them regularly, they stay alive. If you don’t feed them, they eventually die from weight loss and the game is over.

And that’s about all there is to say about it. This is not a good, interesting, or deep game. It is a failure by many objective measurements.

This work sacrificed on its own promise in order to drive efforts that will benefit its successors. I am proud of it.

Cats has a lot of amateur pixel art that indicates I am getting more comfortable making amateur pixel art. I learned a lot about the fundamentals of lighting, shading, and the use of color palettes. These fundamentals will make it easier and faster to create art for upcoming games.

In lieu of compelling gameplay, we have several major engine features implemented: a functional asset pipeline, entity graphs, animation, sound, tile map rendering, and collision detection. All these things are available for use in future projects.

The bad side of March is that, while we have a running program with a core mechanic, there is very little of a game around it. There’s not much fun to be had this time.

I spent some time thinking about it and understand how this happened. I started with a mechanic that wasn’t fully developed, trusting it would evolve into something interesting. It did, but the end result was too big in scope for the time allotted, so I bailed on mechanics and worked on extracurricular fancy instead; I spent the last couple days of the month developing new features for the ng engine that I know I need for the April game.

I just do.

This was the correct decision. Assuming my game development skills improve with each passing month, it’s more beneficial to set up for success in the next month than to cram more development in for the current month’s entry. With that in mind, it’s important to hit the right balance, so the next thing doesn’t always cannibalize time from the project in progress.

The lesson learned is to pull back ruthlessly on scope, and not rely on emerging gameplay to guide feature development.

Taking this lesson from March, I’m setting a new guideline for April: the game should be playable with the mechanics fundamentally complete by the mid-month halfway point. This leaves 50% time to do refinements and to add features, or to call it done early and move on.

I’ll try this change for one month and evaluate again in the next retrospective.

While March feels like it’s been more of a practice session or warm up than a performance, I’m excited to build on both the new tech and the new skills to create something better in April.

Thanks for reading. Next time, we’ll look at the April game!