Planning your development process
Part 3 โ From idea to game: A beginner's guide to creating games with Unity
In the previous articles, you have had a couple of brainstorms, generating ideas for your game. You have chosen one of the ideas after carefully considering your options, and refining it. At this stage, you will have an idea for your game and a list of features and mechanics you could implement.
In this article, I will help you prioritise the ideas you have captured, and then plan the development process with you. This is an important step because it will help you stay organised and on track as you bring your game to life.
Prioritising your ideas ๐ช
By identifying which ideas are most important and which can wait, you can focus your efforts on the most critical tasks first. And let us be honest. Not all of the features and mechanics you have captured will be necessary for a successful game. I know mine are not. That is where prioritisation comes in.
My method of choice for this is the MoSCoW method. I use this daily during my job. If you ignore the O's in MoSCoW, you are left with MSCW. These letters stand for "Must have", "Should have", "Could have", and "Won't have". The idea is to divide your ideas and features into these four categories.
"Must have" items are the most important and must be included to have a playable demo. These are the essentials that are needed to make your game work.
"Should have" items are important, but not as critical as the "Must have" items. These are features that would greatly improve the game but are not essential.
"Could have" items are nice to have, but not critical. They can be added later on if time and resources allow. These are the items you are looking at when you have to change the scope, now or later down the process.
"Won't have" items are not important or simply out of reach and can be eliminated.
To apply the MoSCoW method to your game development, start by looking at your list of features and mechanics. Identify which ones are essential for a playable demo, and flag them as Must. These are the tasks that you need to complete to have a functional game. Next, look at the Should tasks. These are important, but not essential for a playable demo. They can wait until later in the development process. Then, consider the Could tasks. These are less important and can be done if there is time. Finally, the Won't tasks are those that you will not be doing.
By using the MoSCoW method, you can focus on the most important ideas and features first and make sure you have a solid foundation for your game.
Bringing this into practice ๐ค
Now that you have a basic idea of the MoSCoW method, it is time to put it into practice. One way to do this is by using visual aids, such as a task board. In the image below, you see my ideas for mechanics and features on sticky notes. Each sticky note is labelled and categorised accordingly. This makes it easy to see which tasks are the most important and need to be completed first, and which can be set aside for later.
Using this method allows you to focus on the most critical tasks first and make sure you have the most important features first. If you look at the example above, you can see a gameplay loop forming in the "Must have" category. While the things in the "Could have" section could be seen as extra content, rather than touching the core gameplay loop.
One additional benefit is that it also helps you stay organised and on track, as you can move the sticky notes around as you progress through the development process if needed.
It is important to remember that the development process is an iterative one, and you may need to adjust your plans as you work on your game. This is a lot easier if you have a visual aid, such as the MoSCoW board I shared above.
Planning tips and best practices โ
Once you have prioritised your tasks, it is time to start planning the development process. Here are a few key things to keep in mind:
Break your project down into smaller tasks. Instead of trying to tackle everything at once, it can be helpful to break your project down into smaller tasks that are easier to manage. Depending on the scope of your project, you can break it down into creating graphics, writing code, designing levels, or implementing new gameplay mechanics. For me, that is not specific enough, so I tend to go a level deeper. Remember how I clustered the ideas and mechanics in the second part of this series? I like to see those clusters as tasks I can tackle one by one.
Create a (rough) timeline. Once you have a list of tasks, it is important to create a timeline for when each task will be completed. This will help you stay on track and ensure that you are making progress. This is a challenging part, especially when you are learning. What helps me in these situations is knowing it does not have to be perfect. Again, you are doing all this preparation to give you a target, and an idea of where you are heading. That does not mean you can not adjust along the way.
Keep iteration in mind. As you work on your game, you will find that some tasks take longer than expected or that you need to adjust your plans. That is fine. Or to be expected even. The development process is an iterative one, and it is important to be flexible and change course when necessary.
Playtest and test often. This might be a weird one in the planning phase. But playtesting also takes time and you have to keep that into consideration. One of the most important things you can do as you work on your game is to playtest often. This will help you spot improvements you can make, issues or bugs, and ensure that your game is and remains fun.
Forget perfection. It is important to aim for high quality in your game, but it is also important to remember that you do not need to achieve perfection in the early stages. Focus on getting a playable demo done first so you can fine-tune the gameplay loop from there. Additionally, you can also let your friends, family or strangers online playtest the demo and give you feedback. The sooner in the process you can start this, the better.
Putting all this into action ๐
Now that you know what to do, and how to do it, let us take a look at how I applied it to my game idea:
Date | What |
January 1 - January 29 | Game ideation (Including mechanics and features) |
January 30 - February 12 | Create a fish (And fish movement) |
February 13 - February 26 | Create a level, and the start of the economy (Shop, drops, etc.) |
February 27 - March 12 | Improve fish behaviour (Decision making, movement, hunger, etc.) |
March 13 - March 26 | Create hazards, and a UI |
March 27 - April 9 | Playtesting and debugging |
April 10 - April 23 | Review core gameplay loop |
April 24 - May 7 | Playtesting and debugging |
May 8 - May 21 | Finalise the game demo |
This timeline is a rough estimate and will probably change as the development process progresses. I am also aware it is not complete, as there will be more to it than this.
It is worth noting that this is just an example of how you can use the MoSCoW method and plan the development process for a game. Every game and every developer is different, so it is important to find a method that works best for you and your game. Do not be shy to try out new methods or techniques.
Conclusion ๐
Hopefully, you have now learned how to prioritise your ideas and plan the development process for your game. By breaking down your project into smaller tasks, creating a rough timeline, and being flexible and adaptable, you can stay organised and on track as your idea becomes reality.
I hope these first 3 articles have helped you get started on your game development journey with me. I would love to hear about your progress, so feel free to share your updates and ask any questions in the comments. Your feedback is greatly appreciated and will help me improve future articles.
Now that the preparations are done, we will dive into Unity next. Let's build cool shit!