Stalls and sputters

One of the hardest parts of working on a game is getting over the stalls and sputters as I go through implementing every feature I come up with for my game. Scope creep is another problem, but I'll talk about that in a future post.

So what do I mean by stalls and sputters? When you are in the ideation phase of a game design, you don't know what is going to be a challenge and what is going to be smooth sailing in your development effort.

A real world example which I've seen while learning and developing Gestalt: Scavenger is the save system. I gave mysrlf 2 weeks to build the inventory system, but 13 days into that work, i realized that the Unity serialization system can't write my inventory data structure out to disk using the simple methods I've used for saving health and position of things. That's a sputter.

So with that new unknown coming into focus, I made the decision to go out and learn how to create customized serializing and de-serializing methods around your data structures. But my experimentation with customized serialization wasn't yielding successful results. Another series of sputters.

đź’ˇ
At this point, I really should have collected my thoughts and reached out to a mentor to get some help filling in my gaps in knowledge around data structures and how to serialize them, but hindsight is 20/20, and my foresight was closer to “blind as a bat” in this particular case.

With my timeline already gone past three weeks at this point, I went looking for another way out of my stalemate with the save system and I picked one of the worst solutions to facing a problem in a complex project, I grabbed another asset from the asset store and began work to integrate it. Now my actual development towards the original goal has stalled.

I evaluated Odin for serializing, I looked at Easy Save for its save structuring, and I finally settled on replacing my whole build system with Easy Build System because it has a robust grid, collide, and snap build system, as well as a built in grid saving and loading mechanism.

Of coarse, this means that all that time spent learning each of those three assets wasn't put into moving the game forward, and each asset, while powerful and a great jumping off point for adding robust features, your integration will only ever be as good as your understanding of the asset, and deeply understanding an asset takes time away that you needed to be working on the fun elements of your game.

—

When this happens with one item in my todo list, it isn't that bad, but just like a clogged engine, when I've sputtered once, I am more likely to sputter again or worse get to an all out stall of my progress on the game if I don't take a step back and now and fix my process.

Possible solutions to sputters

To break the pattern of sputters before they stall your games development, you need some process tools in your tool belt to help you break the problem down.

Don't conflate this solution with other work you were doing previous to hitting this stutter. The goal here is to break the problem down to as small of a unit of work as possible and to strictly focus on the problem that is slowing down or halting your progress.

The first mental tool which I use is to acknowledge the problem and to give it a name. If you I am tracking my project with tickets or cards, I create a new one just for the problem I am facing. If not, then I use the rubber duck method to explain the ploblem, in detail, to an inanimate object on my desk (such as a rubber duck).

I start my explanation by expressing exactly what my environment is, what exactly I am trying to do, what is happening when i do that, and what I expected to happen. You may recognize this as the process for filing really good bug reports, but I find that this process helps me step a bit away from the problem, collect my thoughts, and to open up a fresh mental workspace to solve for just this one problem.

Once I've expressed in words what the problem is, if I am working in any kind of source control, I create a new branch off of my main or develop branch to avoid conflating other work into this branch to keep me focused and make the review of the solution as simple as possible. I try to name the branch for the problem I am trying to solve, not the method which you I plan to try first. This may take multiple attempts, and I want to keep focused and clear on what I'm solving.

Now, I dive into the problem in this fresh mental and project workspace which I've created but I give myself a time limit. If haven't made substantial progress by a certain date, then I move onto asking for help.

Effectively Asking for Help

The good news here is that the work which I did previously gets me pretty far along in asking for help. I just need to identify where it is that I am most likely to find someone who understands my domain really well and who might