Video thumbnail for How To PLAN your Game as a Solo Developer

Solo Game Dev: The Production Point Project Management Method

Summary

Quick Abstract

Struggling to finish your solo game development project? This summary explores "Production Point," a practical project management methodology designed specifically for solo developers. Learn how to break down your game's development into two key phases: prototyping and production, inspired by the multi-armed bandit problem from mathematics. Discover how to avoid getting stuck in endless loops of either phase and optimize your workflow.

Quick Takeaways:

  • Prototyping: Focus on systems and mechanics. Scope by "doing" and maintain a playful, exploratory mentality. Seek constant feedback on core mechanics.

  • Production: Focus on content creation. Scope by planning with deadlines and adopt a "work" mentality. Prioritize bug fixes and polish with broader, end-stage feedback.

  • Production Point: Creates a clear dividing line between the prototyping and production phases.

Optimize your game dev process and overcome common solo developer hurdles!

Introduction

Good morning, afternoon, or evening, wherever and whenever you are. I'm Benjamin, and welcome to this video. Today, I'll be discussing Production Point, a practical project management methodology I've developed for solo developers. To introduce this methodology, we'll first look at a problem that was unsolved in the mathematical community for a while, the multi-armed bandit problem.

The Multi-armed Bandit Problem

In the multi-armed bandit problem, you're presented with some slot machines. For example, let's say we have three slot machines with win rates of 40%, 50%, and 60%. Naturally, we'd want to put all our money into the 60% win rate machine. However, there are two problems. First, we don't know which win rate is associated with which slot machine. Second, we only have 30 coins or tokens to figure it out.

One approach could be to assign a certain number of tokens to each machine to get an idea of its win rate. With 30 tokens, we might put five tokens into each machine and then allocate the rest to the machine with the best outcome. But because the win rates are relatively close, we could end up with similar results on each machine, like two wins and three losses or three wins and two losses, and still not know which machine is the best.

This problem was solved by a gentleman named Gittins. The solution is the Gittins index, which assigns an index value to each slot machine. The value is calculated using complex math outside the scope of this video, but the key is to always pull the machine with the highest Gittins index. There are other approaches to this problem as well, but they all break it down into two distinct phases: the explore and exploit phases.

The Explore and Exploit Phases in Game Development

I propose that we also break down the project management method for making games into these two phases. In English, "exploit" has a negative connotation, but in this context, it means using the information we've gathered to produce a known good result. We'll call these two phases the production phase and the prototyping phase.

Phase 1: Prototyping

During the prototyping phase, we focus on systems and mechanics. This includes any logic that handles the interaction between entities in the game, such as the inventory system, items, collisions, and gravity. It's difficult to plan during this phase because we can't be sure how the systems and mechanics will work until we have them in a tangible form. So, we scope by doing and prove that we can do it.

Phase 2: Production

In the production phase, we focus on content. This involves making new levels, adding new enemies, playable characters, and items, and building upon the existing systems and mechanics. We scope by planning because it's easy to add content or polish forever. We need to set deadlines and have a clear plan. It's also easier to plan for content because if we've made one level, we have a good idea of how long it will take to make another.

Mentality and Feedback in Each Phase

Mentality

  • Prototyping: Have a playful mentality. This is the explore phase, so explore a lot of ideas, don't take anything too seriously, and have fun. Try different things and don't focus on one particular idea.

  • Production: Adopt a work mentality. Deadlines, good habits, and putting in the hours are important. While it's still important to enjoy the process, it's time to put on your headphones, listen to music, and get to work.

Feedback

  • Prototyping: Get feedback constantly. Ask big questions like whether the mechanics work together, if players enjoy the mechanics, if they're having fun, and how long they play. Use video to gauge players' reactions through their voice tone and facial expressions. You don't need a large number of people; five to ten in your target audience should be sufficient.

  • Production: You won't get a lot of feedback during most of the production phase. However, you should check up on things here and there. Most of your feedback will come near the end during the alpha or beta testing. Aim for a large pool of players, ideally hundreds, to find as many bugs as possible and look for quality of life issues. Written feedback can be used at this stage.

Graphs and the Production Point

Exponential Curve for Systems and Mechanics

During prototyping, the work required to add new systems and mechanics follows an exponential curve. The more systems and mechanics we add, the more work is needed to add new ones. This is why we don't plan during this phase and instead scope by doing.

Linear Curve for Content

In the production phase, adding content generally follows a linear curve. Adding one more level doesn't take significantly more work than adding the last level. This is why we can plan for content.

The Production Point

To optimize for progress, we combine these graphs. The production point is the point at which we transition from prototyping to production. It's the clear dividing line between the two phases. The clearer this line is, the better we can optimize for progress and avoid getting stuck.

Frequently Asked Questions

What if my game requires a lot of content to prototype?

Different genres will have different lengths for the prototyping and production phases. For example, a platformer will have a shorter prototyping phase and a longer production phase as it requires a lot of levels. However, even for games with a longer prototyping phase, you might be surprised at how little content you actually need to prototype.

What about using engines like RPG Maker?

RPG Maker is great for making RPGs as it handles most of the systems and mechanics. This can significantly shorten the prototyping phase, allowing you to jump right into production. However, you may still want to prototype parts of your game, such as the story, using a Google doc to create different variations and get feedback before moving to production.

How do I know when to switch to production?

It's not an easy answer, but generally, you're looking for a prototype that is engaging, completed, and where players just want more content. If your systems and mechanics are finished and players are asking for more, it's time to switch to production.

What about market research?

Market research is crucial if you want to make money on your game. It should be done during the prototyping phase. Check trends, see what players are engaging with, and read reviews of similar games to identify any needs you can fill.

Do I rewrite my systems when I switch to production?

If your prototype has bugs in the systems and mechanics code because it was throwaway code, you'll need to refactor or rewrite it at the end of the prototyping phase to get the prototype ready for production.

Which phase is game feel in?

It depends on the type of game feel. If it's a system, like an intelligent blood splatter system, it should be added during prototyping. However, the graphic for the blood, which is content, should be added during production.

Conclusion

I've experienced both extremes in game development: getting stuck in a superposition of the prototyping and production phases and having a project flow smoothly with constant progress. The contrast for me has been between Demon Lock, where I didn't have a clear line between the two phases, and Tic Tac Tanks, where I used this project management method. I'm taking a break from Demon Lock to finish Tic Tac Tanks and explore this idea further. I'd like to write a book about this methodology to help solo developers have clear steps, a good plan, and a framework for managing their projects and finishing their games.

If you have any questions, are interested in this, or would like to see a book on this, please let me know. I also wrote a Substack post about this, and the link will be in the description and comments below. I hope this was helpful, and I'll talk to you all later.

Was this summary helpful?

Quick Actions

Watch on YouTube

Related Summaries

No related summaries found.

Summarize a New YouTube Video

Enter a YouTube video URL below to get a quick summary and key takeaways.