Game Design: The Design Document

Well here we are again talking about game design. This time we are going to take a look at a tool that is worth its weight in gold; the design document. First let me make a few basic observations: A design document is not required. There isn't a single best format to use. A design can be as detailed or sparse as you want it to be. The design document isn't written in stone. Now imagine that you are going on a vacation. We all like vacations so it should be easy to imagine. Now imagine leaving your home to go on this vacation. Can you see yourself packing your car or going to the train station, or the airport? Now imagine that you are in your preferred mode of transportation and you suddenly realize that you don't have any idea where you are going! You know that you are on vacation; you know that you are going to take a trip to get to your destination. Unfortunately, you have no idea where the destination is. You don't know if it is going to be cold or hot, if you packed the right clothing, if you have enough money, or if it is even possible. That scenario would be an absolute nightmare and a waste of a good vacation. Now I want you to think about the vacation again except this time we will call the vacation our program. We know we want to make a program, but without a solid design, it is impossible to see the destination or figure out how we will get to the destination. This is what the design document does for us. It allows the designer the opportunity to flesh out the program idea, test logic, and evaluate which resources will be needed to accomplish the ultimate goal. Like I mentioned above, there are no set formats to use and while difficult, it is possible to complete a program on the fly without a design. But why would you want to make a difficult task like programming even more difficult by trying to program blind? If you are part of a team the design document becomes even more critical to success by allowing the team to all share the same idea and understanding of how the problem of the program will be solved. There are many resources on the internet and books that will detail different design paradigms and any programmer that is serious about their code will at the minimum familiarize themselves with a design document. For the sake of being more complete, let's talk about a basic list of topics you might want to use in your design document. The following list is comprised of the topics I commonly use but you may feel free to add your own or use only a few of them. The design should be flexible and you should never feel compelled to add information that you do not feel will increase the value of the document. Platform Genre Target Age Short Summary List of Game Details List of Programming Details (functions/classes, systems / sub-systems, etc.) Needed Resources (Graphics, Sound, Music, Writing, etc.) This is a rather small list but they are topics that I find valuable in designing a game. The platform is a no brainer. We are talking about what system the program will be designed for. The genre is important because there are certain conventions that the public is accustomed to, from key mapping, to game expectations. The target age should take into consideration who you believe the primary user will be. A short summary will give you the opportunity to flesh out your idea and see if it sounds as good on paper as it does in your mind. The game details are things that are specific to the game such as levels, bosses, puzzles, items, etc. The programming details should cover everything from coding conventions, classes and systems, to licensing. And the last section I feel is very important is the resources you will need for your game. It is not uncommon to design a game only to realize you lack the proper resources to see it finished, making the whole project useless. These are not the only areas you can include in a design document but they are the select few that I would highly recommend. That is all for now. Good luck with your design!

Share this post