As a solo game developer, it's important to learn as much as you can about everything you can, including the process you follow when making games. The process I will discuss consists of the following steps:
I hope to provide you with helpful tips on each stage of this process so that you can improve the speed of development and the quality of your games.
First of all, it's important to note that this isn't a linear "waterfall" process. It is very organic. While you will always start with an Idea, the following steps of Prototyping, Iteration, and Playtesting will happen in an unorderly fashion. This is good because it encourages experimentation and goes against the rigidity of a game's design, which allows positive evolution of the game. Over time, you'll get a feel for how you usually follow the process and how you can improve.
Beginner game developers sometimes think this is the most important step in the process, and that all development should halt while an idea is being thoroughly explored. As a result of this, they tend to overdesign (ex. huge game design documents), scale it too large for their skills, and overestimate the value of ideas. This also makes a design much more rigid, which ends up affecting the game negatively in the long run.
While the idea is important, it is most important to understand how little you can learn without making a prototype and playtesting that idea. You'll find that ideas in your head sound really fun, but actually playing a prototype of that idea ends up being really dull. You'll also find that a prototyped "dull" idea can be really fun!
During this stage, make sure that you have your goal and constraints clearly defined. For example, "make a fun game" is not a very clear goal, while "make a game in a month that uses the 'Flowers' theme and preferably utilizes the new COM system" is. The second example also shows good constraints. Some very immediate constraints that apply to most everyone are making the game in a certain amount of time ("before death" even) and staying within (and very slightly exceeding) your skill range. Constraints can help you think of more ideas, but it is often good to fluctuate the amount of free movement you have on each game project.
Inspiration is a word that often comes up when talking about ideas. Just remember that inspiration comes from anywhere, such as your life, other media, game design theory, or even random generation! The most important thing you need to know about "inspiration" is to not jump on an idea! When you are "inspired", your brain is pumping in those reward chemicals for your successful idea generation, which makes it very hard to see the bad in the idea! All you have to do is give it time. No matter how good it sounds at the moment, give it at least three or four days before doing anything more than thinking about it and writing it down.
At a lower level, it is important to focus on the mechanic(s) of your idea. Remember, you're writing a game, not a story, so you need gameplay! If you cannot think of good gameplay for that story, maybe that story is best expressed using another form of media.
When you get an idea and have waited a sufficient amount of time (and it still sounds good), the next thing you need to do is scale it down to its most basic form. Look for what makes you really like that idea. You need to find the most primal, core element(s) that makes that idea so appealling to you. This is the first thing you need to prototype as your entire game will be relying on these elements!
On a more somber note, remember that you will die. Keep that in mind, and make the game as if it was your last.
If the Idea section hasn't nailed it into you enough, I will repeat: you cannot see the potential (positive or negative) of an idea until you prototype it! Thankfully, this is often the most fun step in game development because you get to see your idea come to life! However, it is still critical to prototype correctly in order to use it most effectively.
When prototyping, you must be open to failure. If you fear failure, you will never release that game. I like to keep my prototypes outside my source-controlled Development folder and in my Desktop folder, just because it emphasizes the temporary playfulness that prototyping needs to succeed. If you mess up, it's important to tell yourself that that is expected and completely OK!
With this openness to failure, you also need to develop your prototypes faster, because chances are you will experience that failure many times before you create a winning prototype. A ton of speed can be obtained by optimizing your code. I don't mean performance optimizing, but life optimizing. You want to engineer your code for maximum reuse and simplicity, which means building a game library full of useful reusable code, and making a game template that you can copy and reuse. This game template should include an open window with rendered sprite, input, and a working makefile etc. You are going for convenience!
Also, you should avoid using "easier" tools for prototyping; rather, stick with what you know and have the most experience with, because that will make the fastest (and most useful) prototype. I write most of my prototypes in C++ because I have four years of experience with the language and the library.
Before you touch a line of code, make sure you have a well-defined question that you want the prototype to answer. This question should be very simple and involve the most important and/or "risky" parts of your game idea first. Optimally, you should write down the question somewhere clearly visible so you do not get off track. As soon as the prototype answers this question and explores a bit, you should move on to another.
Once you've made the prototype(s) that affirms the power of the idea, find the core element that affirms it and cut everything else away. Simplicity is the key to an elegant design!
At this point, you've made enough prototypes to confirm the positive potential of your idea. You've also confirmed the technical feasibility of the idea and how you might approach implementing it in production code. You've also found what you most enjoy about the idea and trimmed away what wasn't necessary to the experience. If you haven't, go back and make more prototypes!
When I say iteration, I mean the development and refinement of the final product. You should avoid using a prototype for your production code because that prototype was tailor-made to answer one question, not to become an entire game. At this point in development, you are using your most sustainable coding practices to build the production game. There are many articles that teach these practices, so now is the time to use what you've learned about high quality coding. The prototype was not the time to use these practices because they are going to be thrown away anyways!
Iterations should go from most important elements to least important (like prototypes). If you code a main menu or fancy graphics before you have your main mechanic running, you are doing something very, very wrong! No one cares about your graphics or your menues, they care about the gameplay! Make the "toy" first, and save the menues and polish for last.
Though you are now working on the "final" code, you should still experiment. Be very careful with such experiments as they can make you lose your vision of that core element that you focused on before. Make sure that you know why your game is engaging. Nine times out of ten it's not because you have realistic ragdoll physics or you can mine metals underground! Your experiments should be made seperate from production (if you're using source control, this is where "branching" becomes handy) and easily undoable. You should focus such experiments on improving the core element only! If the experiment is too divergent from the core element, you should write it down and prototype it later.
Do NOT, under ANY circumstances, prematurely optimize! As a programmer, you've probably heard of KISS, which stands for "Keep It Simple, Stupid!". Follow this principle as closely as you can! Jonathan Blow talks about algorithms and data structures and how they are optimized for performance or memory, but are not "life optimized". It is more important to finish a game in a month that runs at 20 FPS than finishing it in a year for 60 FPS!
When it comes to coding during the Iterative cycle, you want to recognize systems that can easily be reused in future games and add them to your library rather than making them game dependent. This will not only improve your library, but also make every subsequent game (and prototype) faster to develop. Don't try to reuse systems that are too specific though!
While furthering your game library through Iteration, focus on features that a) are useful not for their performance, but for what they accomplish and b) encourage code reuse and shorter development times. For example, collision detection and resolution is extremely useful and worth taking the time to implement, but implementing an "optimized" collision routine is not. Remember, don't make it unless you need it! As an example of (b) features, I recently implemented my own COM (or CES) system because I saw how much easier code reuse becomes with it. Sure, you take a performance hit, but the idea of dynamic, portable and reusable components makes up for it in life optimization!
If you're this far, there isn't any reason to scrap the project! Sure, you've learned a lot from coding mistakes and a complete recoding would probably do the project good, but don't waste your time! Many beginner game devs continuously scrap projects right in the middle of development. This is the main reason why they are still beginner devs! You've hit what's commonly known as "the Wall", the point at which you no longer want to continue development on a project. Just push through it, or all of the work you've done will be worth nothing (to consumers, at least)! I've released seven games, and two of them ended up being hell near the end. I pushed through it though, and learned from my mistakes. You MUST completely finish your projects! Do NOT give up!
Iteration will be heavily influenced by the next step, which is...
I have to admit, I have a lot of trouble with playtesting. It's quite difficult to do it correctly, but when done correctly it will end up massively improving your game. Playtesting is quite straightforward, so I will present a few rules of thumb you can use to do it more effectively.
First, playtest early, playtest often! You can never playtest too much! Playtest as early as the prototype stage, and as late as release. You'll find that parts of your game that make perfect sense to you will completely confuse others, so do not develop in a vacuum!
Next, diversify! This includes people and technology. Run on as many devices and operating systems as you can. One of my games worked well on my two computers (with quite different specs) and virtual operating systems but had game breaking movement bugs on most other computers! When it comes to people, do not eliminate any demographic. Let anyone play your game, no matter what gender, age, or interest! The more diverse your playtesters are, the more diverse your audience will be, and the less biased your game will be.
Don't burn out playtesters. After a while, they get quite biased, especially because they've seen earlier versions of the game. You want the playtester to have a clean slate and an open mind, so make sure to switch out people often.
Observation is the most important thing you need to learn how to do during a playtesting session. Watch when they speak, when they stop speaking, when they die, when they succeed, and when they stop playing. Chances are most people will do the same, even though you effect them because you are there. Observation is also the only thing you should do during a playtesting session. Do not give them a background, or explain something, or help them out, or anything. Just watch, and take notes.
After they are finished playing, you should ask them the following three questions:
That gives you very clear feedback on what you need to emphasize and what you need to change. Also, when the player gives you a suggestion for improving the game, focus not on the suggestion but what made them give you that suggestion.
If you've made it this far, you're ready to finish your game! The last 10% of development often feels like 90%, but you must not give up! Remember that even a "90% completed" game is worthless! Finishing is all about pushing yourself through the Wall and getting all of the loose ends wrapped up. Look back at how far you've come already, and look how far you have to go. It's not that far away!
While you put the finishing touches on and zip it up for the first time, test on as many platforms as possible. You need to test everything, even your "readme" files (one time my newlines were Unix-style and didn't work on Windows computers :) )!
You want the path a player takes from discovering your game to playing it as short and smooth as possible. Lower all of the barriers you can, and make it extremely easy for them to check out your game. Convenience is key at this point.
If you're wondering why your game still looks and feels like a "hobbyist" project, it's because it isn't polished enough. Very small things, like menues or loading screens, can make a big difference on the player's feelings towards your game. Remember, the very first thing the player will see will be one of those things, so it is very important to get it right. Study "professional" games and why they look more "professional". Polish is largely by feel, so you will just need to practice to get it right, but it is well worth the extra time.
If you're extremely embarassed by the "quality" of your game or know that it has serious flaws, fix as much as you can and push it out there. Finish your project, learn from your mistakes, and do better on the next game.
You've now made a game! Congratulations! Now do it again, only avoid the mistakes that hurt the quality of the last game.
I've covered a lot, so I'm just going to do a quick outline on each step:
10 Jul 2013: First Release
- Idea
- Prototype
- Iteration
- Playtest
- Finish
I hope to provide you with helpful tips on each stage of this process so that you can improve the speed of development and the quality of your games.
The Process, Step By Step
First of all, it's important to note that this isn't a linear "waterfall" process. It is very organic. While you will always start with an Idea, the following steps of Prototyping, Iteration, and Playtesting will happen in an unorderly fashion. This is good because it encourages experimentation and goes against the rigidity of a game's design, which allows positive evolution of the game. Over time, you'll get a feel for how you usually follow the process and how you can improve.
Step One: Idea
Beginner game developers sometimes think this is the most important step in the process, and that all development should halt while an idea is being thoroughly explored. As a result of this, they tend to overdesign (ex. huge game design documents), scale it too large for their skills, and overestimate the value of ideas. This also makes a design much more rigid, which ends up affecting the game negatively in the long run.
While the idea is important, it is most important to understand how little you can learn without making a prototype and playtesting that idea. You'll find that ideas in your head sound really fun, but actually playing a prototype of that idea ends up being really dull. You'll also find that a prototyped "dull" idea can be really fun!
During this stage, make sure that you have your goal and constraints clearly defined. For example, "make a fun game" is not a very clear goal, while "make a game in a month that uses the 'Flowers' theme and preferably utilizes the new COM system" is. The second example also shows good constraints. Some very immediate constraints that apply to most everyone are making the game in a certain amount of time ("before death" even) and staying within (and very slightly exceeding) your skill range. Constraints can help you think of more ideas, but it is often good to fluctuate the amount of free movement you have on each game project.
Inspiration is a word that often comes up when talking about ideas. Just remember that inspiration comes from anywhere, such as your life, other media, game design theory, or even random generation! The most important thing you need to know about "inspiration" is to not jump on an idea! When you are "inspired", your brain is pumping in those reward chemicals for your successful idea generation, which makes it very hard to see the bad in the idea! All you have to do is give it time. No matter how good it sounds at the moment, give it at least three or four days before doing anything more than thinking about it and writing it down.
At a lower level, it is important to focus on the mechanic(s) of your idea. Remember, you're writing a game, not a story, so you need gameplay! If you cannot think of good gameplay for that story, maybe that story is best expressed using another form of media.
When you get an idea and have waited a sufficient amount of time (and it still sounds good), the next thing you need to do is scale it down to its most basic form. Look for what makes you really like that idea. You need to find the most primal, core element(s) that makes that idea so appealling to you. This is the first thing you need to prototype as your entire game will be relying on these elements!
On a more somber note, remember that you will die. Keep that in mind, and make the game as if it was your last.
Step Two: Prototype
If the Idea section hasn't nailed it into you enough, I will repeat: you cannot see the potential (positive or negative) of an idea until you prototype it! Thankfully, this is often the most fun step in game development because you get to see your idea come to life! However, it is still critical to prototype correctly in order to use it most effectively.
When prototyping, you must be open to failure. If you fear failure, you will never release that game. I like to keep my prototypes outside my source-controlled Development folder and in my Desktop folder, just because it emphasizes the temporary playfulness that prototyping needs to succeed. If you mess up, it's important to tell yourself that that is expected and completely OK!
With this openness to failure, you also need to develop your prototypes faster, because chances are you will experience that failure many times before you create a winning prototype. A ton of speed can be obtained by optimizing your code. I don't mean performance optimizing, but life optimizing. You want to engineer your code for maximum reuse and simplicity, which means building a game library full of useful reusable code, and making a game template that you can copy and reuse. This game template should include an open window with rendered sprite, input, and a working makefile etc. You are going for convenience!
Also, you should avoid using "easier" tools for prototyping; rather, stick with what you know and have the most experience with, because that will make the fastest (and most useful) prototype. I write most of my prototypes in C++ because I have four years of experience with the language and the library.
Before you touch a line of code, make sure you have a well-defined question that you want the prototype to answer. This question should be very simple and involve the most important and/or "risky" parts of your game idea first. Optimally, you should write down the question somewhere clearly visible so you do not get off track. As soon as the prototype answers this question and explores a bit, you should move on to another.
Once you've made the prototype(s) that affirms the power of the idea, find the core element that affirms it and cut everything else away. Simplicity is the key to an elegant design!
Step Three: Iteration
At this point, you've made enough prototypes to confirm the positive potential of your idea. You've also confirmed the technical feasibility of the idea and how you might approach implementing it in production code. You've also found what you most enjoy about the idea and trimmed away what wasn't necessary to the experience. If you haven't, go back and make more prototypes!
When I say iteration, I mean the development and refinement of the final product. You should avoid using a prototype for your production code because that prototype was tailor-made to answer one question, not to become an entire game. At this point in development, you are using your most sustainable coding practices to build the production game. There are many articles that teach these practices, so now is the time to use what you've learned about high quality coding. The prototype was not the time to use these practices because they are going to be thrown away anyways!
Iterations should go from most important elements to least important (like prototypes). If you code a main menu or fancy graphics before you have your main mechanic running, you are doing something very, very wrong! No one cares about your graphics or your menues, they care about the gameplay! Make the "toy" first, and save the menues and polish for last.
Though you are now working on the "final" code, you should still experiment. Be very careful with such experiments as they can make you lose your vision of that core element that you focused on before. Make sure that you know why your game is engaging. Nine times out of ten it's not because you have realistic ragdoll physics or you can mine metals underground! Your experiments should be made seperate from production (if you're using source control, this is where "branching" becomes handy) and easily undoable. You should focus such experiments on improving the core element only! If the experiment is too divergent from the core element, you should write it down and prototype it later.
Do NOT, under ANY circumstances, prematurely optimize! As a programmer, you've probably heard of KISS, which stands for "Keep It Simple, Stupid!". Follow this principle as closely as you can! Jonathan Blow talks about algorithms and data structures and how they are optimized for performance or memory, but are not "life optimized". It is more important to finish a game in a month that runs at 20 FPS than finishing it in a year for 60 FPS!
When it comes to coding during the Iterative cycle, you want to recognize systems that can easily be reused in future games and add them to your library rather than making them game dependent. This will not only improve your library, but also make every subsequent game (and prototype) faster to develop. Don't try to reuse systems that are too specific though!
While furthering your game library through Iteration, focus on features that a) are useful not for their performance, but for what they accomplish and b) encourage code reuse and shorter development times. For example, collision detection and resolution is extremely useful and worth taking the time to implement, but implementing an "optimized" collision routine is not. Remember, don't make it unless you need it! As an example of (b) features, I recently implemented my own COM (or CES) system because I saw how much easier code reuse becomes with it. Sure, you take a performance hit, but the idea of dynamic, portable and reusable components makes up for it in life optimization!
If you're this far, there isn't any reason to scrap the project! Sure, you've learned a lot from coding mistakes and a complete recoding would probably do the project good, but don't waste your time! Many beginner game devs continuously scrap projects right in the middle of development. This is the main reason why they are still beginner devs! You've hit what's commonly known as "the Wall", the point at which you no longer want to continue development on a project. Just push through it, or all of the work you've done will be worth nothing (to consumers, at least)! I've released seven games, and two of them ended up being hell near the end. I pushed through it though, and learned from my mistakes. You MUST completely finish your projects! Do NOT give up!
Iteration will be heavily influenced by the next step, which is...
Step Four: Playtesting
I have to admit, I have a lot of trouble with playtesting. It's quite difficult to do it correctly, but when done correctly it will end up massively improving your game. Playtesting is quite straightforward, so I will present a few rules of thumb you can use to do it more effectively.
First, playtest early, playtest often! You can never playtest too much! Playtest as early as the prototype stage, and as late as release. You'll find that parts of your game that make perfect sense to you will completely confuse others, so do not develop in a vacuum!
Next, diversify! This includes people and technology. Run on as many devices and operating systems as you can. One of my games worked well on my two computers (with quite different specs) and virtual operating systems but had game breaking movement bugs on most other computers! When it comes to people, do not eliminate any demographic. Let anyone play your game, no matter what gender, age, or interest! The more diverse your playtesters are, the more diverse your audience will be, and the less biased your game will be.
Don't burn out playtesters. After a while, they get quite biased, especially because they've seen earlier versions of the game. You want the playtester to have a clean slate and an open mind, so make sure to switch out people often.
Observation is the most important thing you need to learn how to do during a playtesting session. Watch when they speak, when they stop speaking, when they die, when they succeed, and when they stop playing. Chances are most people will do the same, even though you effect them because you are there. Observation is also the only thing you should do during a playtesting session. Do not give them a background, or explain something, or help them out, or anything. Just watch, and take notes.
After they are finished playing, you should ask them the following three questions:
- What did you enjoy?
- What did you hate?
- What confused you?
That gives you very clear feedback on what you need to emphasize and what you need to change. Also, when the player gives you a suggestion for improving the game, focus not on the suggestion but what made them give you that suggestion.
Step Five: Finish!
If you've made it this far, you're ready to finish your game! The last 10% of development often feels like 90%, but you must not give up! Remember that even a "90% completed" game is worthless! Finishing is all about pushing yourself through the Wall and getting all of the loose ends wrapped up. Look back at how far you've come already, and look how far you have to go. It's not that far away!
While you put the finishing touches on and zip it up for the first time, test on as many platforms as possible. You need to test everything, even your "readme" files (one time my newlines were Unix-style and didn't work on Windows computers :) )!
You want the path a player takes from discovering your game to playing it as short and smooth as possible. Lower all of the barriers you can, and make it extremely easy for them to check out your game. Convenience is key at this point.
If you're wondering why your game still looks and feels like a "hobbyist" project, it's because it isn't polished enough. Very small things, like menues or loading screens, can make a big difference on the player's feelings towards your game. Remember, the very first thing the player will see will be one of those things, so it is very important to get it right. Study "professional" games and why they look more "professional". Polish is largely by feel, so you will just need to practice to get it right, but it is well worth the extra time.
If you're extremely embarassed by the "quality" of your game or know that it has serious flaws, fix as much as you can and push it out there. Finish your project, learn from your mistakes, and do better on the next game.
Conclusion
You've now made a game! Congratulations! Now do it again, only avoid the mistakes that hurt the quality of the last game.
I've covered a lot, so I'm just going to do a quick outline on each step:
- Idea
- Prototyping is still essential
- Set a well-defined goal and constraints
- Give it some time
- Find the core element that makes the idea shine
- You will die, so make it count!
- Prototype
- Be open to failure
- Do it as quickly as possible, and make the code as convenient as possible
- Use the tools you already know
- Have a well-defined question to answer
- Iteration
- Make high-quality code
- Go from most important elements to least important
- Experiment, but don't lose vision of the core element
- KISS/life optimize/NO premature optimization
- Add reusable code to your game library
- Only add features to your game library that make development faster or add capabilities (do not code something for speed unless you need it)
- Do not abandon/give up on a project at this point!
- Playtesting
- Playtest early, playtest often
- Diversify your playtester demographics
- Swap out overused playtesters
- Ask questions
- Finish
- Push through it
- Test, test, test!
- Make it easy to start playing
- Add polish
- Release it and learn from your mistakes
Note: This article was written with the help of many others. There are so many that I cannot list (or remember, for that matter) all of them. If you know what article I was talking about or want me to add links, just PM me or add a comment.
Article Update Log
10 Jul 2013: First Release