Production Point

A project management methodology for solo game developers

In today’s post I’m going to introduce a new project management method that I’ve been working on for the last couple of years. This method is mostly practical in nature. I’ve found it to be useful for me and so I want to share it with others. I believe that solo game developers who use this method will be much more likely to not only finish their games but also to find joy in the process.

However, before I introduce the details of this new method, let’s talk about a problem that went unsolved for decades in the mathematical community.

Multi-armed Bandits

Imagine you are at the casino, sitting in front of 3 slot machines:

Their win rates are 40%, 50%, and 60%.

Obviously, we should put all our money into the machine with the 60%-win rate.

Unfortunately, we are facing 2 big problems:

1. We don’t which machine has the 60%-win rate

2. We only have 30 tokens to spend

This makes the problem rather difficule to solve.

If you like to learn about the exact solution, look into the Gittens index, which assigns a value to each machine and has you pull the machine with the highest value.

No matter how you approach this problem, it has 2 main phases:

One phase where you attempt to gain information about the machines, and another phase where you exploit that information, putting your money into the machine that gives the best payout.

I’m going to propose that we break our new project management method down into these 2 phases as well. We’ll be calling them the prototyping phase, and the production phase.

Prototyping vs Production

These 2 phases are a part of every game ever made. As indie developers we intuitively understand the need for both phases. However, problems can come up when we don’t have a clear dividing line between the 2 phases. These problems can cause us to become stuck.

Stuck in Prototyping

When someone is stuck in the prototyping phase, it can look like this:

They spend too much time planning early on, they don’t get feedback, or they make prototypes forever without ever moving to production.

Stuck in Production

When someone is stuck in the production phase, it can look like this:

They don’t set deadlines, they polish forever, they don’t have a plan.

Maybe you recognize some of these symptoms in yourself? Being stuck in one of these phases will kill your progress and prevent you from finishing your game. However, an even worse fate is when you end up stuck in both phases at the same time.

Superposition

When someone is stuck in both phases at once, they can exhibit any or all of the previous issues at the same time. They end up feeling like a zombie, both dead and alive. Large amounts of effort don’t bring them any closer to finishing their game.

In order to avoid getting stuck in any of these 3 states. We’re going to attempt to define clear boundaries between phase 1: prototyping and phase 2: production. Defining these boundaries will help us to avoid getting stuck. We will know what to focus on and when.

Phase 1: Prototyping

Let’s start by covering the approach we should take during phase 1: prototyping. We’ll talk about our focus, how to scope, what mentality we should have, how to get feedback, and finally, we’ll take a look at a graph that describes how progress is made during this phase.

Focus

During phase 1, you should focus on the systems and mechanics of your game.

This could be your inventory system, your health systems, your hurtbox/hitbox system. Anything that handles the logic for interactions between the entities of your game.

You should avoid creating content. You’ll have to make some content, and the amount of content you need to make will depend on your genre, but your focus should be on the systems and mechanics.

Scoping

During phase 1 you should scope by doing.

Don’t plan your scope. Systems and mechanics are difficult to plan. Anything you can’t make should be considered outside your scope.

Mentality

During phase 1 you should foster a playful mentality.

Don’t take things too seriously, experiment a lot. Make a lot of prototypes. Remember, this is the explore phase in our multi-armed bandit problem. Don’t commit too soon.

Feedback

During phase 1 you should get big picture feedback from 5-10 people in your target audience.

Ask your players specifically about how engaging the game is and how long they are engaging with it. Focus on the big picture. This process should be constant during production. Get new feedback with every new prototype or iteration you make. I recommend getting video feedback to gage reactions.

Progress Chart

The progress chart for phase 1 looks like this:

As you can see, it follows an exponential curve. Adding systems and mechanics to your game gets exponentially more difficult. The more you add, the easier it is to introduce new bugs or break old systems. If you follow good programming practices you can squeeze a bit more progress out of this curve, but eventually it will still shoot up.

This curve also describes why I don’t recommend trying to plan your scope during this phase. It’s really hard to know exactly when things are going to get tough.

Phase 2: Production

We’ve covered prototyping, now we’re ready to cover production. We’ll go ever the same topics, focus, scope, mentality, feedback, and the graph that describes how we make progress during this phase.

Focus

During phase 2 you should focus on content.

This means adding more enemies, levels, items, spells, etc. on top of your existing systems. Avoid any new mechanics or systems. If you’ve done your job correctly during phase 1, you won’t need them.

Scope

During phase 2 you need to plan your scope.

Planning scope for content isn’t always perfect but we can get close. If you’ve already made 1 level, you're going to have a pretty good idea of how long it will take to add another one. Planning our content during this phase also helps us avoid the trap of infinite polish.

Mentality

During phase 2 we’re going to take a more disciplined approach in our mentality.

Habits and good deadlines are our friends. We want to enjoy this part of the process, but we need to be more focused. We are in the exploit phase of our multi-armed bandit problem. It’s time to put on some focus music and put in the hours.

Feedback

During production you should get feedback on quality-of-life issues and bugs.

You’ll want to get a large number of testers to help prepare for launch. This will be near the end of production. Written feedback should be sufficient.

Progress Chart

The progress chart for phase 2 looks like this:

As you can see the “curve” is linear. The work required to add new content is usually similar to the work it required to add that same content in the past.

Again, this graph describes why we should focus on planning our scope during this phase.

The Production Point

Okay, so we’ve covered both phases in this new project management method. We’ve drawn clear lines between our focus, scope, and mentality, and feedback. We also looked at graphs describing how progress should be made during each phase. Now it’s time to put the two graphs together.

Here is a chart that describes the progress of our game in relation to the effort we put into it. We are trying to optimize for progress here to avoid getting stuck.

As you can see, we start off in the prototyping phase, then we transition to production. The point at which we switch to production is the production point. It is the line we’ve drawn between these two distinct phases.

Keep in mind, the duration of each phase will vary. If you are making an RPG in RPG Maker, your prototyping phase will likely be much shorter, as the systems and mechanics are already handled for you by your engine. If you are making a roguelike, you may have a longer prototyping phase since roguelikes have a lot of systems and mechanics.

Conclusion

I’ve experienced the frustration of being stuck on a project and also the elation of a working on a project that was easy to make progress on.

For my game Demonlocke, I’ve been stuck in that superposition between the two phases. It’s discouraging. I’ve been able to contrast that with Tic Tac Tanks, which has followed this 2-phase method and has never been stuck. The difference is clear.

This method has helped me so much and that is why I decided to write this post. We are nearing the closed beta for Tic Tac Tanks and I’m looking forward to releasing the game here in the next month.

I’m confident that if you use this method for your own projects, it will give you a framework and the principles you need to carry your game all the way to completion.

Thanks for reading,
Ben

If you enjoyed this post, please consider subscribing for more like it:

If you’re already subscribed, please consider sharing this post with a friend:

P.S.
I think there is a lot more to explore here and I’d love to go into more details. I’ve written an in-depth book that covers this project management method.

If you have any questions for me about this method, feel free to ask in the comments below.

While I’ve been refining this process for a while, I know there is still more to explore, and I look forward to your help in that process.

FAQ

Q: What if my game requires a lot of content during phase 1?
A: Some games will have longer prototyping phases. Remember that you can create some content during prototyping, but your focus needs to be on the systems and mechanics. You might also be surprised with how little content you can get away with making for a good prototype, even in genres that are known for the amount of content they have.

Q: What about using project templates or engines like RPG maker?
A: Engines or templates that can reduce the amount of time you spend in the prototyping phase are amazing. Take advantage of them as much as you can. Remember that prototyping can look different for different games, for an RPG, prototyping might be folder full of different story ideas and variations.

Q: How do I know when to switch to production?
A: This is not always an easy question to answer. However, you’ll use the feedback you get during prototyping to help answer this question. My rule of thumb is if the players are saying “I love this game already, I just want more.” It’s a pretty good indicator that you’ve reached the production point.

Q: What about doing market research?
A: Market research is vital if you want to make games as a business. Get your market research done during the prototyping phase. This process may include watching trends, studying similar games (and their reviews), and getting feedback from your testers.

Q: When you switch to production, do you rewrite the code for your systems and mechanics?
A: This is a really good question. Early in the prototyping phase you should code quickly. However, if you need to rewrite or refactor parts of your systems and mechanics this should be done at the end of the prototyping phase. Don’t jump into production quite yet.

Q: Does game “feel” fall under the prototyping phase or the production phase?
A: It depends. There may be elements of game “feel” that are necessary to for the experience of your prototype. If your game has a blood splatter system, you may want to implement that during the prototyping phase. However, the graphic used for blood might not need to be polished until the content phase. This is somewhat up to you but remember the principle, focus on the systems and mechanics during phase 1 and content during phase 2.