I was a solo game developer myself when I came up with the idea of HacknPlan, it was something I really needed in order to organize my work the way I wanted.  Maybe I’m a control freak, but I really believe a proper work methodology and planning is key to make a serious project a success, no matter how big it is or how many people work on it. I had been working for some time using Scrum at my full time job as software engineer, when I decided to start applying a more structured methodology to my game development projects. It was a complete game changer. It wasn’t Scrum of course, because that methodology is hardly applicable to one person or even a small team (at least as it is defined, it has some overhead in “bureaucracy”), but I took some of the important concepts of agile methodologies and created a custom process for my specific case. The result? A huge improvement on time efficiency, clearer goals, less errors and forgotten stuff and, more important, a permanent feeling of progress and achievement that boosted up my motivation.

However, I can clearly see this is a commonly neglected topic when it comes to solo devs, small indie teams and people starting up. If people already have experience as developers or in other related fields, they are more likely to use some sort of planning methodology, but when it comes to young or unexperienced people just learning game dev from scratch, this is normally a completely new world. You could just take a look at any game development community and see how many questions or posts you find regarding project management or production compared to technical or marketing stuff. But this is of course normal: when someone learns game development, they do it from passion and vocation, and what everyone wants to do is to code challenging features or create amazing graphics and, at the end of the day, have a cool game to be proud of.

Coming back to the solo dev topic, I’d say this is the kind of dev that is more likely to use no project planning methodology. I’ve seen many people use just paper and pencil to keep an immediate To-Do list and that’s it. I completely agree that if your project is so so (SO) small or you are just prototyping this is fine. Otherwise, not having a proper methodology could lead to problems in the long run you maybe don’t see when you are starting out, when all you want to do is adding more and more cool features to your game as soon as they come to your mind.

Ok, so… what is a good project planning methodology for a solo game developer? These are some good practices you could try.

Break your work into smaller pieces

And then take these smaller pieces and break them again, as if they were Pang! balls.

One of the most common reasons for people to leave a project is they get overwhelmed once they really understand the amount of work they are really facing. This is of course more noticeable on solo game developers, since all the responsibility falls on their shoulders. By splitting your big task (your game) into smaller ones (phases, iterations, milestones, or whatever you call them) and then splitting them again into more detailed pieces (tasks or user stories…), you finally get a set of work units that are manageable, easy to accomplish and short to complete. Then you can focus on each of them individually and forget about the big task in the meantime; your objective becomes the completion of that piece of work and only that. This is good to avoid distractions and to perceive your progress as you complete each of them.

Tip: Try to define your tasks in a way that they produce a clear outcome, something you can see and/or touch. This way the perception of progress is bigger and also the organization of the work is more meaningful. Try to define tasks from of the point of view of what they add to the project and why from a high level perspective. Example: having a task called “Implement player movement” is better than having a task called “Create a PlayerController class that moves the Actor depending on the input” (you can always have more detailed technical tasks, but is good to keep the high level one too).

In HacknPlan, we provide Milestones to create versions or iterations of the game. You can use them to do the big split of your game into phases. It’s also good to put deadlines into those milestones: they help you to have a clear goal and will motivate you to work harder to accomplish it.

So, does this mean that I need to write down everything that I need right from the start? Well, not necessarily, what takes us to the next point.

Planning the agile way

It took a long time for the management world to find a better approach than waterfall, where everything had to be defined and detailed in a sealed monster document from day one. That approach is what we call agile methodology, which is a buzzword these days that many people completely misunderstand (especially business people). Agile doesn’t mean no planning nor is an excuse to throw the first idea you have to the developers and expect them to do it immediately because they are agile. Agile means planning in a clever way, accepting and assuming that requirements change, priorities change and any project, no matter how conservative and clear it seems, has many uncertainties. It means accepting the real world as it is instead of living in a fantasy world where everything you put in a document will magically become real with no flaws and no incidents whatsoever, like if we were magicians that can predict every little thing that could happen during a 1 or 2 years long project, day after day. I bet that never happened in the whole history of project management.

Reducing the scope to our topic, being agile would mean not planning every single aspect of our game from day one. You would fail for sure. Does this go against the whole concept of GDD and all that? Nope, but you need to understand the GDD is not a fixed document where every page written is a contract. It needs to be iterative, improved and detailed as development goes on. A good approach could be:

1. Define the high level of your game, the mechanics, the game itself, prototype it and get a clear vision of what you want to make. Then specify that into a first version of your GDD.
2. Then split your project into small pieces, let’s say versions or milestones. Each one of them is a goal itself, like a project inside your project. The outcome should be something clearly defined, like “Alpha: Playable version with basic mechanics and 1 full level” or “Beta 1: First world, full mechanics plus menus”. Think of each of them as a reduced version of your game instead of an unfinished one.
3. Once you have that, pick them one by one and split them again into high-level tasks. Is not necessary that they are highly detailed, they need to reflect the high-level functionality of your game that will be implemented. As we said, you don’t need to know every single detail you will implement at this moment.
4. Let’s start working on the project! Take the first milestone, take the high-level tasks you have inside, and split those tasks again into smaller and more detailed ones. Now is the moment to care about the details, and have a clear and well-defined set of things to do, because from now on until the completion of the milestone, you will be 100% focused on it, forgetting about the rest. This is what we could call a planning session, and it is very important that you have dedicated time for this, so you are really focused on it. If you plan things as you go while developing or working on something else,  you can commit errors or lose sight of the big picture.
5. After you finish the milestone, you can then enrich your GDD with new things you got from that iteration, review the big picture to add things you detected are needed based on your recently acquired knowledge, plan you next milestone and keep going. For each one you complete, you will have a really important goal achieved and you will be a step closer to your final objective. And more importantly: you will know more about your project than when you started, so you can use that knowledge to review your previous assumptions and adapt them.

Avoid multitasking

This is very important for a solo developer.

You have to do a lot of tasks: programming, game design, art, maybe sound if you’re really talented… and it’s ok, this is what going solo is about. But don’t do more than one at the same time. And I’d say even more: try to group them as much as possible and work the most time you can on the same topic.

Doing more than one thing at once could lead you to errors and can affect your concentration.  This cannot always be avoided, I understand. But just try to minimize it as much as you can, try not to move from programming to drawing something as soon as an idea or inspiration comes to your mind, it will affect your performance for sure. Each time you switch from one thing to another, there is a context change cost that makes this process inefficient; that’s why having a separate time for each thing is very beneficial for your performance and your organizational health. Try to have dedicated days for each different task category and see if your performance improves.

One of the core features of HacknPlan comes as a solution for this problem: the kanban panel separated by technical categories. I used to create different boards for each category when I was a solo dev using another tool, so I thought: why not implement this by design? The goal is to be able to focus in what you are doing at the moment without being distracted by the rest of the pending work.

Conclusion

When you are just a guy working from your bedroom, is easy to think that you don’t need to stick to any specific process and you are okay with just writing down some notes. Maybe you’re right, there is no written rule regarding what has to work for you. At the end of the day, this is about inspecting and finding what is the approach that best suits you. However, a structured and well-defined process is always a good thing, you can improve it with your experience, try new things, evaluate yourself and just try to do better and better every time. It will help you to work with others too, in case you leave the lone wolf route one day. You will have a common methodology to follow that you could also refine with time and experience. Even though you think my suggestions don’t work for you, try to use this as a way of re-evaluating your working process and thinking of ways to improve it. Because nothing is perfect, right?

Are you a solo game developer and are you trying any of these tips? Share your experiences!

Happy planning!