How To PLAN your Game as a Solo Developer

Thanks for watching my video!

Thank you all so much for your support!

[KryyssTV]

Nintendo actually uses this exact approach for most of their in-house games. They have teams who just develop game systems with no planned products to use them. When they come across something fun then the senior staff decide what franchise would make best use of that gameplay, then the product is developed around those systems. This approach seems to be the legacy of when Nintendo was a toy company as that industry does a lot of prototyping for toy concepts and the best are chosen to go into production.

This method is why we have Splatoon. If you ever watched documentaries on its development you'll discover that the senior Nintendo folks loved the prototype but didn't feel that it fit with anything like Mario, Zelda, Metroid or any IP they had. But rather than discard it, they created an all new IP built around the gameplay - and so the Squidlings were born.

[thomrade]

This is a really smart take on project management. A lot of people get bogged down for example, in fine tuning graphics and content really early on, when they could drop in some ms-paint placeholders and focus on getting the mechanics done. Thats especially common in the RPG maker community, you can build an entire game with the standard assets and come back later and replace and refine them as needed. I really nenjoyed this video, would love to see more like this!

[erikahlundhelguera]

I decide to make an arpg game using Godot, HeartBeast starts his arpg series literally the day after I begin.
I get unmotivated, a few days later HeartBeast has a video about him feeling unmotivated and how he deals with that.
I take a break and start thinking about how to manage my time and the project in general. Again, LITERALLY the day after, HeartBeast posts a video about it on youtube... Are you in my head or what?
I swear if I ever finish the game it'll be thanks to you <3

[ghaydn]

I think, very important thing in solo developing is change of activity. When I code day after day, at some moment I get tired and my productivity is declining. At that moment I need to switch to writing music or drawing graphics. If I don't do that (like, I cannot draw graphics when I don't know where to use it), I won't be able to get any progress and will abandon the game for several months. That's not what I want, so it's important to always have possibility to switch between prototyping and production.
It is sometimes very hard to finish something, if it is big enough. Not hard or complicated, just big.

[vast]

Really important: keeping files, assets, code-examples, design docs and workflow-steps etc organized. Projects often run into a complexity trap, where adding a new system or mechanic is exponentially more complex than in the early prototyping phase, simply because there are so much more files and dependencies to regard, a much larger codebase and unclear workflow in the asset pipeline.

[wulfsnack]

It's good to note that if you're a hobbyist solo game developer with no desire to make money, you can do whatever tf you want! Just make games that sound cool to you without worry of making a successful hit or filling a space in the market.

[cool.guy.]

One critique I want to make and that you should address is, as a fellow solo developer, it’s really important for me to break up the monotony, working too long on systems or content production can really be draining mentally. On the other hand, alternating between content production and systems can really be fulfilling once you get into a sustainable rhythm.

I feel like the most important aspect of making games, especially if you haven’t released any commercial games yet, is fostering your motivation and creative drive. If you are not fulfilled with your current project it is often too easy to switch to another project.

Take this with a grain of salt tho as I’ve only released my first commercial game last year haha

[pigdev]

Awesome content Ben!

Regarding the "when to switch to production phase", had you read Sprint? The Google's book about prototyping? There they mention something that really stuck to my head:
- Each prototype should answer questions that must be known by the time of the actual production

Things like "how players react to X mechanism" or "which GUI is more intuitive". So I think that when you have these important questions answered with a prototype, it's time for production

[julio]

Shoutout to the book “algorithms to live by, ” you’ll get nuggets of wisdom like that (like the multi arm bandit problem). Definitely worth your time to anyone interested. Audiobook is great too.

[apoxfox]

I feel like the first indicator that you’re ready for the production phase is when the prototyping slope reaches its limits. I can get caught up polishing my prototypes “game feel” forever, so I think that’s probably the first hint that it’s time to move on

[siidaf]

I find this approach very useful
phase 1: experiment and find a solid and fun "game loop".
phase 2: complete levels, graphics, music, fix bugs, etc...
Thank you

[SinfulCreature]

As a learning solodev with a bad habit for leaving or forgetting projects, starting a new project... this video has helped me think about prioritising what I need to focus on and what can be done later in development

Thanks for keeping the gears in my head turning!

[GnRGaming]

One thing that really helps you learn proper planning of a solo project is to participate in game jams. You have limited time to get everything done, so in order to finish on time you have to learn really fast what's gonna help you progress & what's gonna slow you down. And when you're done with the jam, you can keep working on the project using the same methodology applied to a longer period of time.

[Ivorforce]

This is solid advice! You know a solution is valuable when after you heard it, it seems obvious. I have previously experienced similar problems and come up with similar solutions, but you put it down very concisely and clearly!

[tumbleweb]

Discovered this naturally while working on a game. It's nice to have a system put into words so I can better understand the flow. Thanks for making this!

[SebLeCaribou]

Excellent deliniation.

I might add that, as boring as they can be to create and to use, unit test can be life savers for the prototyping phase and the transition from prototyping to production. With tests that make sure that the systems in place are working fine, you can catch very early on when you are building something that breaks the rest of your systems on a code level. Say you are creating a LootDrop system that goes on top of a damage dealer for enemies, and you somehow messed up something, it might take a while to see that you messed up, especially when testing just for fun you might be focusing on the feature you are building. With unit testing you just see the gauge go red and say "yep, something's wrong, I might want to do that differently".

Oh and version your project for the love of you! Make feature branches for the prototyping and merge into dev or main when it's polished enough (and when it passes all of your unit tests ;) ) You'll feel even more free to go bonkers if you know you can just switch branch to go back to the clean project.

[landnavgame]

This is very useful. Thanks.

one thing I might add from my experience as solo developer is that in prototype phase you may also need to prototype your production pipeline. Depending on the sort of art assets you are using, it may be a serious endevaour to figure out how or if you'll be able to produce the content you need, and so you need to actually go through the process of making that stuff to ensure you'll be able to survive the production phase.

And so if you have to do a bit of that, then you sort of end up making a vertical slice by the end of your prototype phase - that is, you have a good bit of "finished" art ready, anyway.

Obviously it depends on your games art needs. If you are relying on bought assets and wont need to make things on your own, you probably wont have to spend time validating production pipeline liek this.

[usarian]

REALLY great info. I'm a self taught database developer who moonlights picking up gigs on upwork, and I just don't have any training with managing projects at all. I've been doing it by the seat of my pants for 20 years, but I recently landed a bigger contract and I'm drowning in managing it to the point where every time I sit down with it I just stare at the screen not knowing what to do next.

Your concepts are applicable to general programming. I can kind of cross apply most of this, but I would love to see another video where you abstract this out and maybe even talk about tools that help you manage everything.

[TackerTacker]

Thanks for clearing up in my face attic.
I was already doing most of this intuitively, but more in a jumbled messy way, really great to see it all clearly laid out like that. That should really help.

[mindrunegames]

It's great to see you here 😀. This is an amazing advice on management, and I'll probably apply this to my game development process (solo dev here). And I would definitely buy this book. Thanks!