Introduction

Have you been working on your game for what feels like eternity, but have nothing to show for it? Are you stuck on how to implement your game idea? If these sound like you then this is your article. In this article I will talk about planning, game design, and technical designs. I am going to cover the importance of planning and designs, and give you some tools and tips to help you successfully plan and design your next game project.

Why do I need a plan?

The definition of a plan is a "detailed proposal for doing or achieving something.". A proposal is "a plan or suggestion, especially a formal or written one, put forward for consideration or discussion by others.". A plan helps you be successful by putting your goals on paper. It is HOW you will go from having a great idea to a great game. A plan can be broken down into goals, objectives, and tasks. Goals are broad and general, objectives are specific and measurable which when complete achieve a goal, and tasks are very specific things that you need to do to meet an objective. Your day to day work can be broken down into tasks. The tasks when finished complete objectives, and the objectives when finished meet goals. For example if your goal was to lose 20 pounds, then your objectives might be to work out every other day for three months and to consume 1800 calories a day. Your tasks would be your specific workout sessions (the day to day), and preparing healthier meals that meet the objective of consuming 1800 calories a day. Your game plan should be just as detailed. Your goals are not really directly measurable other than knowing when you are finished. Your objectives need to be detailed so you can evaluate whether the tasks that you are completing are really working towards accomplishing the goals.

Adjusting your plan

Plans are always subject to change. Your game plan will change as you encounter the reality of development. There will be things that you have not accounted for, and you will have new ideas as you develop your game. Creating a plan does not mean setting your entire project in stone, but rather it is a general roadmap for success. You might take some crazy detours but as long as you keep track of your goal you will eventually arrive at your destination!

Schedules - Putting dates to your plan

In my mind a schedule is simply putting dates on your plan. If you say that by October 15th you need to have X amount of things done in order to finish the game by December 31st then that is a schedule. Your schedule can change independently of your plan. Some things will take longer than anticipated (that is the nature of game development), but putting real dates to things can help put the plan into perspective (even though we often don't want to really commit to any deadlines). An easy way to keep track of a schedule is to use a calendar application like Google Calendar or iCalendar If you really need to track a lot of resources then you could use something like Microsoft Project or Projectlibre to keep track of all of the details. In the software development world there is a concept called Agile programming and that is a big topic. You can use sites like Assembla to manage software projects using Agile concepts and that goes great with the whole planning concept. I have personally used Assembla and it really makes this process much easier by being able to set milestones, create tasks, ect.

Putting things into perspective

One thing a plan will do is force you to confront the reality of your idea. If your game design calls for 100 unit types, but you can only make one unit type a week, then by making a plan you will find that takes (best case) 100 weeks worth of time. If you realize early that your plan calls you making units for slightly over two years then you are likely to revise your plan to something more realistic.

Realistic estimation

Estimating how long something will take is hard. The best technique I have found for this is to break the task up into very small tasks where each task can be executed in hours rather than days. Then estimate each small task and multiply by 1.5. If you realistically think a task will take you 5 hours, then multiply it by 1.5 and you will end up with 7.5 hours for the task. Add up all of the small tasks with the "extra" time built in. The more you can break down a task, the more accurate your estimates will be. If you are unfamiliar with a task then you might even multiply by an even larger number (2 or more) to your hour estimate to really make sure that there is time for the unexpected. As you work keep a log of your time. You can use this time log to help improve your estimates, gauge your performance, and refine your schedule. Something like My Hours can help you keep track of your time. Assembla also has time tracking functionality.

Stop wasting time

Time is your most valuable and finite resource. There are 1440 minutes in a day. If you want to be productive you need to stop using so many of them watching cat videos :). Game development takes a very heavy investment of time. Even relatively simple games can still take months of development time to complete. If you find yourself not making progress as fast as you would like, evaluate your time log and try to see if you can find ways to use time more effectively.

Ok, but how do I know WHAT to plan?

You know what to plan by looking at your game design document. Your game design document or GDD contains all of the information about your game. It has every story, character, level, mechanic, boss fight, potion, and whatever else that you need to make your game. Your game design is detailed enough when you can have someone off the street read your game design and they can play your game start to finish on a sheet of paper. Even if you are just one person putting all of your thoughts down in a GDD means that you can't forget them (and if you don't write your ideas down you WILL forget them). For a proper GDD you will need sketches of your characters and levels, backstory, character biographies, and all sorts of other supporting information. You really need to put in a lot more details then will make your final game because your job with a GDD is to get everyone working on the game (including yourself) on the same page. If anyone has a question about your game they should be able to answer it by reading your game design document. If they can't answer the question then your GDD is not detailed enough. If your game design document is not detailed enough then it is not complete! Some people will tell you that you do not "need" a game design document. Some people might be able to get away with not properly designing a game. It is likely that you won't be one of those people, and if you neglect your design then it is very likely that your project will fail. Think of creating a design and a plan like a way to improve the odds. It is not guranteed but it improves your chances of having a successful game. Odds are if you can stick with an idea long enough to create a detailed game design and a plan then you have an idea worth implementing! Here are some things that I believe all good game designs should have (in general):

1. Character backstory
2. Character sketches
3. Level sketches
4. Flow chart of the game execution
5. Sketches of the game UI

For mocking up your user interfaces I recommend using a software program like Pencil Project.

Sounds great, but.... what about the programming? What engine should I use!

You now have a game design and a plan. The engine that you choose is determined by your technical requirements. Your technical requirements really depend on your technical design and your technical design depends on your game design. Ultimately your choice of engine depends on what sort of game your game design is saying you are going to make! There are a number of factors that influence what technology to choose for your game including the game mechanics, the schedule, commercial vs free, etc. Often for beginners the statement is that the choices of engine/tech don't really matter, and to a certain extent that is true... However for bigger projects that choice can start to have meaning. For instance does the target technology support the platforms that you want to run on, does the engine support 2D or 3D, if the game is for sale how much will the engine cost out of profits, what sort of asset pipeline does the engine support, etc. Unreal and Unity are fairly comparable, but they do have differences. I might choose Unreal if I had a very art heavy game that needed high graphics performance. I might pick Unity if I had a smaller game but really needed to have complete control over the game logic and if I were more comfortable in C# over C++. I know people might try to argue for one over another and any examples I give might just start a flame war, but the point is that there is generally a rational behind adopting one technology over another.

Technical design

A technical design is a compliment to your game design. Games are software and software has its own language for design. UML is one language to describe your game's technical design. UML really describes what your program does, what objects you will have, and how those objects interact together. Your UML diagrams would form your technical design and the diagrams would have the purpose of satisfying the game design. There are lots of UML tools like StarUML that help to create UML diagrams.

Further reading

Here are some links on these concepts to get you started: 1. Gamasutra - The Anatomy of a Design Document 2. Atomic Sam game design document example 3. Ant's life game design document example. 4. Step-by-Step Guide for Creating an Action Plan to Achieve Your Goals. 5. Types of UML diagrams 6. Unity, Source 2, Unreal Engine 4, or CryENGINE - Which Game Engine Should I Choose? 7. Agile Methodology 8. How to write a software design document.

Conclusion

I hope this article shed some light on the importance of plans and designs and that you learned some information that will help you plan and design awesome games. We covered:

1. A plan: Goals, objectives, and tasks. Should be detailed.
2. 1440 minutes in a day. Don't waste time.
3. Plans can and will change.
4. Schedules: Your plan now has dates. Deadlines are when stuff must be done. Your schedule will likely change.
5. Use Calendar, Time Tracking, and Project Management software to help with plans and schedules.
6. Game Design: The complete source of information for your game idea.
7. Technical Game Design: Also known as a Software Design Document, typically written using UML.

Thank you for reading.

Article Update Log

05 August 2015: Fixed some typos brought to my attention by Casey Hardman. 28 July 2015: Initial release