And then by coincidence I saw two people in the design forum here saying that they didn't really know how to design, so I guess there must be more newbies here than I thought. They are probably not making pet games, but they might get something out of the guide anyway. So! I'm posting the guide here in pieces, asking for constructive criticism, and also to make it available here as a reference like my older writings in this Journal.This document, created by Mare Kuntz (sunandshadow) in 2012, is a free, public guide to making a design document for a pet-themed game, including example pet game design document sections intended for reuse in readers' own game design documents. A design document is not the only way to develop a game; some people favor the alternate method called agile development. But, this document is aimed mainly at people who have little design and development experience, and IMO agile development works better for more experienced people, or for people who are more interested in learning than in making a specific game. I am providing this document as a community service and releasing it to the public domain. It is freely usable by anyone for both noncommercial and commercial purposes. For example, an indie game developer could use this as the basis for a design document for their own pet game. Or anyone doing a school project or teaching a class where they needed an example design document could use this. I would enjoy hearing from people who find this document useful (sunandshadow@excite.com), but you are not required to notify me if you make use of it. I am available as a consultant for game-design-related projects, but I do charge for that kind of service.
[indent=1]Table Of Contents
[indent=1]
0. Introduction: What is a game design document, why should you make one, and how do you use this guide to make one?
1. Genres: What kind of pet games are there, how are they different from each other?
2. Theme: Story, Setting, Playable Character(s), And How These Should Interrelate With Gameplay.
3. Distribution and Monetization: Getting the game to the player and the player's money to you.
4. Player Registration and Account Creation, Data Storage Within The Game
5. Avatar Creation: Human vs. Pet, Clothing Systems, The Avatar's Role(s) Within The Game, Avatar Equipment Slots, Stats, and Abilities.
6. Inventory Systems: Types Of Items And How Each Type Functions Within The Game, How The User Interacts With Storage, Storage Limitations And Expansion As Gameplay.
7. Pets: Storage, Functionality Within The Game, Capturing, Breeding and Genetic Systems
8. Crafting
9. Trading, Shops and the Marketplace
10. Forums and Messaging
11. Tutorials, Quests, Reputation, and Levels
12. Combat
13. Minigames, Puzzles, And Other Combat Alternatives
[indent=1]14. GUIs and Controls, Game Modes and Context-Sensitive Behavior
X. Finale: An overview of the game development process and how the design document is used during this process.
0. Introduction: Game Design Document - What? Why? How?
A game design document is a written description of proposed game. In this guide I am assuming you, the reader, want to create a game. This makes you the game designer. (Or a co-designer if you want to team up with someone who will also contribute ideas.) In order to create a game you must decide what kind of game you want to create. I am also assuming you are going to outsource some or all of the programming and art of your game to other people. The main purpose of a game design document is to paint a clear picture of a proposed game. The document describes what game parts (otherwise known as features) will be in the game, and how they will fit together. The process of creating a document helps a designer clarify their creative vision for a game and make sure there aren't any inconsistent or missing pieces. The finished document is a record of all the design decisions that have been made. It can be given to others, in whole or in part, as a quick clear way of communicating the designer's vision. It can also be used as a checklist to track which pieces of code, art, and other assets have been created, until everything is checked off and the game is done!
What? So, what is actually in a game design document? A game design document usually includes:
[indent=1]1. A statement of the designer (you) or design team's purpose that they want the game to accomplish. You can write this as a serious statement of philosophy if you really want to, but it doesn't have to be anything complicated; instead you can just say "This game will be awesomely fun to play because..." Optionally you can mention a favorite game that you want yours to be similar to, or what genre it will be, or what type of player will really like it. Typically this part will be 1-3 paragraphs long.
[indent=1]2. A list of features you want the game to have (this does double duty as your table of contents).
[indent=1]3. A description of each feature (these are the sections listed in the table of contents, the "meat" of your design document).
[indent=1]4. Appendixes listing all the characters, location, items, puzzles, monsters, etc. needed to complete the game. (These lists are often added later, after the main design document is done. So really there are only 3 main parts - nice and simple. But, if, in the middle of making your design document, you happen to decide something like: "There are going to be six classes of pets in my game: Sun, Moon, Star, Shadow, Plaid, and Rutabaga." then an appendix is where you file that kind of information so you know where to find it later.)
Why? What good is a game design document? How do you use it to help develop your game? As soon as you write a feature description it becomes useful because you can refer back to it when designing a related feature, so you don't forget what you decided. An in-progress design document is like a journal, but more organized because you will be showing it to other people as well as referring back to it yourself. If you are in a team, the design document serves as a record of what has been firmly decided and should not be squabbled over or changed without an important reason. The design document can also be a fast way to orient a new team member to what is going on.
Most importantly, when you have finished writing your design document the feature descriptions you have written are used as a guideline in the development process when programming a feature, creating graphics or sound files for that feature, and playtesting that feature. How? When hiring a programmer or an artist the design document is both a checklist of all the tasks that need to be done to make the game, as well as a source of bite-size "assignments" that your employee(s) can do one at a time. You can do this by copying and pasting from your design document in to an email or forum post to a team member or employee, or by simply showing them your whole design document. The same applies to tasks you are going to do yourself - if you get around to creating something a month after you initially designed it, re-reading what you wrote reminds you exactly what you decided to do and why.
A game design document is also helpful as an organizational tool for your whole development process; it can be used as a plan you can then follow step-by-step to develop your game. You can even check off within the game design document which tasks have already been completed by you and others. As these parts of the game are created, they form the alpha version of your game! And finally, material from a design document's statement of purpose and story section are often reused when creating promotional materials or a webpage for a game project or completed game, while material from the appendixes is often reused in item flavor text, NPC dialogue, and other places throughout the game.
How? Okay, so how do you make a game design document? You follow this guide!
I will describe the various genres of pet game so you can identify which one you want to make. I will describe the various features commonly found in each genre so you will have a starting list of features your game should have. Because this document is public domain (copyright-free) you are welcome to copy and paste as much of it as you can use directly into your own design document. You can also modify it however you want if you want features different than described here. When there are two or three alternative versions of a feature I will try to describe the differences between them and which is better in what context, so you can pick which version you want to use, or you can use this as background knowledge when designing your own version of a feature. You will still need to create some of the material yourself, such as your statement of purpose, your story, names of characters and places, and all the parts where your own creativity is the essential ingredient. But following this guide should be much faster and easier than creating your own design document from scratch, and hopefully the list of example features I'll describe here will make the guide flexible enough to help people design a wide variety of games.