Turtle Trouble

#1GAM July 2016: Turtle Trouble

The Game

The Game, called Turtle Trouble, is hosted on GameJolt and you can play a web-version or download the desktop version (Windows/Linux/Mac). It’s a short platformer with six levels that will take you about 10 to 15 minutes to complete.


For my first monthly Game I decided to create a simple platformer, doing my part of the job to reinforce the indie cliche. Additionally I wanted to focus on the player controls to feel good, and I’m quite happy how they turned out.

It was planned for July but I only finished it now, because it was far too ambitious and far from “simple” for a month long project. I’ll consider it a delayed fail for the July Challenge. I intend to do a small bullet point post-mortem for every monthly challenge, so here it goes:

What went well:

  • Cut it out: I wasn’t afraid of cutting out a lot of features I initially thought were absolutely necessary. It’s really shocking when you realize, that the game is perfectly fine without them. But those features were cut out too late, out of necessity, instead of in the initial planning phase (see the bad points.)
  • Mario-like physics: There are some awesome people out there that completely reverse engineered the physics for the original Mario games (and also Sonic). The physics for Turtle Trouble are loosely based on the physics of Mario, and it really helped making it feel quite responsive and fluid.

What went wrong:

  • No MVP: There was no real point during development where I thought: “I could ship this now, and nobody would notice there are things missing/not properly done”. Instead of finishing one feature after another, I half-assed a bunch of them and only completed them by the very end.
  • Level Design not fully explored: It’s surprising how there are still a lot of interactions/combinations of existing features that are missing and could be explored. But to keep scope small I decided on a small amount of levels. There are two player abilities that are only really needed once (stomping, sliding), and that’s the time they are introduced. Other objects that would have interacted with this two abilities were cut, which makes them feel like tacked on. Further strengthening the point that it’s better to have a few fleshed out features, before you start implementing new features you don’t even know you need yet.
  • Art isn’t my strong point: I spent far too much time on sub-par graphics. I should either decide on a less graphics intensive art style, have someone else make the graphics (or get pre-made ones) or else I’ll have to plan a lot of hours on graphics alone (which eventually turn out to be mediocre).
  • Abrupt ending: Another thing that was cut, was the bossfight that should represent the finale. Not having a bossfight is ok, but there is nothing to provide a proper conclusion. The difficulty at the end is not especially harder than the rest of the game. It sort of just suddenly ends, making it feel almost incomplete.
  • Crunch Mode: Approaching the last week of the month I started crunch mode, working unhealthy hours on it, just to try and get the list of features working in time (before I eventually cut scope in half (again)). This was due to underestimating the amount of work needed for the scope I came up with and overestimating the amount of hours available in a day for Gamedev when already working a 40 hour week. (Just writing this post delayed everything another day, aaaaaahhhhhh)

Lessons learned:

  • Create a Minimum Viable Product:
    • Less is More: Boil the features down to the bare minimum. All those fancy features you think you will need, are actually completely unnecessary. The complexity of adding new features seemingly rises exponentially, as new features will interact with every other part of the game already present.
    • Vertical instead of Horizontal Prototype: Fully implement the current feature, before starting another. It’s better to have one complete level, than a hundred incomplete levels.
  • Quick Animations: If you can’t draw well, go for quick animations with a high frame rate. The individual frames don’t have to look that pretty and fluid animations look a lot better than “fancy” choppy animations.
  • Reduce Scope Even More: There are far less hours in a day than you think. Don’t plan on having to do Crunch to complete your scope, but reduce scope beforehand instead. There are other things in life than Gamedev too.


A lot of these points are actually nothing groundbreaking. They are tips that can be read over and over again. I literally linked to a video going over most of them in my last post, and yet I keep forgetting about them. That’s why I’m writing them down, as I think having to put them in your own words helps appreciating them.

Any time now I’ll have an twitter account set up, I swear. It’s just that naming things is really hard.

Also I have yet to find a way to easily record Gameplay GIFs on my Linux machine. As the handy GifCam is only available for Windows.