• Create Account

### GameDev Marketplace

#### Warriors and Commoners Pack

$140$90

Like
43Likes
Dislike

# General Tips on the Process of Solo Game Development

By Macoy Madson | Published Jul 19 2013 04:38 AM in Production and Management
Peer Reviewed by (Glass_Knife, Dragonsoulj, jbadams)

lone wolf solo production tips

French version (translated by yahiko00) here

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:

1. Idea
2. Prototype
3. Iteration
4. Playtest
5. 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.

When you are developing a new module, do not move on until it's completed and working! This is hard because you will get tired of killing the bugs in the new system, but it's critical that you finish it. This is primarily because bugs will build upon bugs until the entire system collapses. It's also because you will forget the things you know as you build the module, so when you come back to it you will have to take time to adjust and may make mistakes. It's also very rewarding to finish a module completely, so you will get a motivation boost if you do. After you "finish" a module and discover there is a bug, immediately fix it, or you'll put it off and forget about it.

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:

1. What did you enjoy?
2. What did you hate?
3. 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:

1. Idea
1. Prototyping is still essential
2. Set a well-defined goal and constraints
3. Give it some time
4. Find the core element that makes the idea shine
5. You will die, so make it count!

2. Prototype
1. Be open to failure
2. Do it as quickly as possible, and make the code as convenient as possible
3. Use the tools you already know
4. Have a well-defined question to answer

3. Iteration
1. Make high-quality code
2. Go from most important elements to least important
3. Experiment, but don't lose vision of the core element
4. Finish a module before moving on (kill all the bugs etc.)
5. KISS/life optimize/NO premature optimization
7. Only add features to your game library that make development faster or add capabilities (do not code something for speed unless you need it)
8. Do not abandon/give up on a project at this point!

4. Playtesting
1. Playtest early, playtest often
3. Swap out overused playtesters

5. Finish
1. Push through it
2. Test, test, test!
3. Make it easy to start playing
5. Release it and learn from your mistakes

Thanks for taking the time to read this! I hope I helped you!

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
23 Jul 2013: Added note on finishing modules to Iteration

I've been developing games for four years, and my seventh game was released last month. You can check out all of my games and learn more about me in my profile and on my website.

Good article Macoy,

I only think it might be wisely to put your prototype in a separate source repository. This will allow you to be more adventures with developing a prototype. Different branches might be used to focus on separate parts of you prototype. Also being able to revert back all your changes might be needed when you are not satisfied. Besides the normal benefits such as a pc/laptop crash.

I think that prototyping can be more efficient with easy tools than coding, specially C++.

Of course, you should go with what you know, but there is a lot of developers that quits on a project because the process of writing things like collision detection and physics takes too much time.

On a more somber note, remember that you will die.

That's not a very happy thought for a game article.

Maybe so, but it's true and is also popularized by Steve Job's work ethic

Thanks a lot! This is exactly what I was looking for. Because I have a lot of trouble with NOT finishing stuff!!

Great article. When I first started making my own games my biggest issue was establishing a project scope. I would add every idea that popped into my head. Probably goes without saying I didn't finish the first 4 or 5 projects I started.

I think that prototyping can be more efficient with easy tools than coding, specially C++.

Of course, you should go with what you know, but there is a lot of developers that quits on a project because the process of writing things like collision detection and physics takes too much time.

True. I've started using Blender Game Engine a little more with my prototypes, but my game library is such that it is very easy to make games in C++ with it. It handles collisions, graphics, physics, input, etc. in an extremely simple way, and because I wrote it myself, I know the ins and outs very well.

So yes, use whatever tool you can prototype with fastest!

Very interesting article.

Very interesting article.

Absolutely! Use it how you want (as long as it helps people)!

Great article!  I do agree with everything you said but sometimes I deviate from doing the highest priority tasks to some of the easier or fun ones when my motivation is dipping.  It makes me feel like I am accomplishing something which helps motivate me back to the harder tasks.

I also very much agree with waiting on optimization until the feature is basically working first.  This one is hard for me but I know its important.

Oh thanks! I'm going to translate the other parts in the next days. I've shared your article in the French community of the Adventure Game Studio (CASE tool) -- http://adventuregamestudio.fr-bb.com/. You gonna become famous ;)

Please find some feedbacks and questions from French developpers (not myself, except one of them maybe).

PART 1

1. Maybe your article tends to underestimate the importance of "new" ideas in the developper's motivation.

2. In the developpement process, you should maybe emphasize a little bit more about regularly re-adapting the developper's ambitions to reality (skills, time constraints, external events, etc).

3. Maybe for the very first project, we should start without any advice from anyone and just do as we feel. Advices and guides like yours should come when the developper have a clearer vision of the developpement process. Before it is maybe useless and even depressing.

PART 2

1. This part could seem quite abstract, forgetting that the world of video games is huge and diversified. Could we apply the same rules for a cashier game as for a puzzle game or an FPS?

2. Maybe some examples could help to figure out more precisely your argumentation.

Please don't consider those comments as something personal. You know, French people are always complaining!

Thanks for the well-written article. I have a question.

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 Blowtalks 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!

Why do you say this? The answer might be obvious to many, but I didn't catch it. Unless it's just for motivation and forward momentum?

Great article!

Great article, I totally agree with your section about Finishing. I have a really tough time finishing the last 10% of my games....

Please find some feedbacks and questions from French developpers (not myself, except one of them maybe).

PART 1

1. Maybe your article tends to underestimate the importance of "new" ideas in the developper's motivation.

2. In the developpement process, you should maybe emphasize a little bit more about regularly re-adapting the developper's ambitions to reality (skills, time constraints, external events, etc).

3. Maybe for the very first project, we should start without any advice from anyone and just do as we feel. Advices and guides like yours should come when the developper have a clearer vision of the developpement process. Before it is maybe useless and even depressing.

PART 2

1. This part could seem quite abstract, forgetting that the world of video games is huge and diversified. Could we apply the same rules for a cashier game as for a puzzle game or an FPS?

2. Maybe some examples could help to figure out more precisely your argumentation.

Please don't consider those comments as something personal. You know, French people are always complaining!

First off, sorry for the slight delay, I was camping.

1.1: By motivation, do you mean what inspires them to continue? They are right, I did devalue the original idea in the article. It's very important that you decide on an idea that really inspires you and keeps you going, but you should still be open to change. Definitely choose the ideas that you want to pursue, and allow them to change for the better. I mostly lowered the value of ideas because beginner designers will over design/scale too large and not prototype, which wastes a lot of time, because ideas can change drastically after a prototype.

1.2: I'm a little confused by the question, but I'll try as hard as I can. The process is very dynamic, so it's important to just make as many games as possible until you get a feel for how you optimally make games. You then try to improve your process. You'll become more adaptable and reliable over time.

1.3: This is also very true. The first few games you make will teach you a lot more than this article will about making games better. The only thing I would focus on when developing your first games is just to finish. Then you can figure out where you can improve. This will keep you motivated and open to change. It's a very iterative process, so after you finish a game, identify your mistakes and improve. When you are a beginner, the most important thing is to not give up. Don't give up on individual projects or your career as a developer. You need to push through the tough stuff before it gets "fun".

2.1-2: I hope I'm interpreting correctly that you want examples regarding part 2 question 1? But yes, you can apply this same process to all game genres. You can even apply it to other fields, like film production, music production, etc. as they all rely on the basic Idea->Test->Feedback cycle.  You only get more constrained when you go into design details. For a cashier game, you may have different constraints such as how accurate it should be, but you will still follow the process of Idea->Prototype->Iteration->Playtest->Finish.

Hopefully that's what you wanted!

Thanks for the well-written article. I have a question.

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 Blowtalks 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!

Why do you say this? The answer might be obvious to many, but I didn't catch it. Unless it's just for motivation and forward momentum?

It's mostly for forward momentum. Programmers tend to love designing complex systems that use all of the popular buzzwords but take a lot of time to implement. This is dangerous because it harms their potential to finish the project because of all of the time creating a system that isn't really necessary. As an indie developer (not a massive 100+ team, although I'm sure they deal with this as well), you need to focus on speed of development, not frame rate, because you don't have enough time to do everything.

If you set a hard deadline for yourself (OneGameAMonth is what I do), you'll experience the detrimental effect of trying to make things go faster when you realize the deadline's tomorrow and you still don't have a finished game. It's partly a Level-of-Detail problem: you should focus on programming the big, very important systems (gameplay mechanics before menues etc.) before doing optimizations, which are just very small and subtle (albeit time consuming) changes to these systems. It is important to get the small details, but save them for the end when the risk is lower.

If you absolutely HAVE to optimize (your game is 95% done and the framerate is only 15 FPS etc.), do it smartly. Measure what systems are taking up most of the time (10% often takes up 90% of the time is a common mantra), then only optimize those. As soon as you are running at an acceptable speed, release. Finish, finish, finish!

It also involves simplicity. Optimization typically adds a lot of complexity to the design and is a very difficult constraint to deal with.

It's kind of political, so I'd recommend you hear others' opinions as well.

Thanks a lot for your patience !