• Create Account

# 4. Player Registration and Account Creation, Data Storage Within The Game

For a singleplayer game it has recently become standard to allow the player to enter their name or name the location they own within the game (ranch/farm/zoo/store/house/estate/tribe/country). This is a simple input and storage of a text string. This name may be used when the game or an NPC speaks to the player or about the player. It may also be incorporated into the save game file's name. Many singleplayer games do not bother with a password system, but such a system can be used if it seems likely that multiple people will have their own game accounts on the same computer, and players might want to protect their own account from meddling siblings or friends. Passwords in general need to be stored using some kind of encryption. Some singleplayer games are in a free trial mode by default, unless and until the player purchases the game online, receiving an activation code or script. Entering this code or running this script is part of the process of registering the player as an official owner of the game, but it may take place after the player has already been playing the game for an hour or more.

So, where are you storing all this data? A completely singleplayer game typically uses a saved game file stored on the player's own computer. This is possible because with a singleplayer game it does not harm other players if anyone hacks game files on their own computers. Some games even encourage user-modifications, and may offer an online system for distributing these to other players. The Creatures series, Sims series, and Spore are some examples. Multiplayer games on the other hand do not want to put any important data on the players' computers where it is vulnerable to being altered. It's common to have the player's computer store a client, which is more or less an engine for displaying the game's data to the player, and also remembering the player's customized settings and patch history. They also may cache on the player's computer sound files, graphics files, and other data used only by the player's computer to display the game to the player. This can reduce constantly re-downloading the same files from the server, which is annoying to the player and costs bandwith for both the player and the server. For a while people were experimenting with putting hackable data on players' computers and just checking it against the server to make sure it hadn't been tampered with, but players kept finding ways to get around this checking so this method is basically extinct.

Some games, especially those with minimal graphics, store all their data online and don't put anything on the player's computer except possibly a browser cookie. Most browser-based games are in this category. This method can be advantageous because it removes the need for players to wait for a possibly long download before they can start playing, a traditional hurdle to getting potential new players into the game. But on the other hand the game may have a fairly long load time for every play session, which could have been shorter if some of the things being loaded had been cached on the player's computer.

On the server-side of multiplayer games, because the server has data for many, many players, in addition to data for various monsters and items which have many instances within the game, it makes a lot more sense to store all that data in a database rather than a file for every player, every monster, and every item. A database is a system that structures and indexes information so it's fast and retrieve the data you want from it. For example, a common thing a game needs to do is to generate the loot a player gets after winning a combat. Each monster has a standardized set of database entries associated with it, one of which is a loot table. When generating the loot, the game only needs the loot table, not the monster's other data like hp or appearance, so it would be inefficient if they were in the same database entry. And the game needs to quickly grab the loot tables for every monster that was killed in the combat if more than one was. Well-known databases include all those variants of SQL, along with Oracle and Access. Anyway, although someone has to design the particular way a game's information will be stored in a chosen database or saved game file, that's getting more into programming issues and is off-topic for this guide.

If your game has servers or realms, helping the player select one and recording that selection is also part of the registration process. Typically the player will want to know the server's age and how full it is. In some cases you will want serves to be functionally different: PvP vs. PvE, or normal vs. heroic (larger rewards and harsher penalties possibly including permadeath), under-18 vs. over-18, or f2p vs. subscriber-only. So you will need to tell the player which servers are which, and also check the player's age or subscriber status to see if they are allowed into a restricted server.

Another standard part of many registration processes is to test the validity of the email address that has been entered by sending a test mail with an activation code, which the player must click on or copy and paste to activate their account. Un-confirmed players may be able to play with some features disabled – usually multiplayer ones like trading and chatting or posting to forums. This is because the email-validity check is designed to help filter out previously-banned people, spammers, and goldfarmers, all of whom cause problems by interacting with other players but aren't really a problem when playing solo.

Hey look, we've gotten to the end of the statement of purpose! For the last sentence you should write something along the lines of “Gameplay will take place [on the player's computer or phone/in a client communicating with an online server/entirely online via a browser.]

Then let's strike while the iron is hot and start the features list! This is the list that will develop into the main part of your design document (and a non-detailed version of it will be your table of contents). But right now let's just make a list, you will need to look back at what you decided in the first 3 parts:

- Game Data Storage

- [Offline saved game file/Online database/Mainly offline with minimal online friends network or cash shop or ad serving]

- Account Creation and Registration

- [If online, are you handling account creation yourself or is a store or stable handling it for you?]

- [What data do you want to collect from each player?]

- [If you have a free trial, how do you tell whether a player is in that mode or fully activated mode? Some distributors, such as Big Fish, have a standardized free trial system that they apply to all games sold through them.]

- [Do you require email confirmation, credit card confirmation, or age verification? What can't the player do before they are confirmed?]

- [If you intend to have multiple servers, what differentiates them?]

- [Graphics Type]
- [Gameplay Genre(s)]

- [Looking at the description of your genre, what major features does this genre have that you want your game to have? E.g. Combat, racing, crafting, puzzles... Give each of these its own entry here.]

- Story (unless your game has none)

- [Linear or Interactive]

- [Story Genres(s) E.g. Horror, Fantasy, Humor, Romance, Adventure, Mystery]

- [Theme(s)]

- Story is shown to the player through [NPC dialogue, written pages or books, cut-scenes between play segments, comic/manga pages between play segments, direct narration to the player, item flavor texts, graffiti/murals/stained glass images on level walls, etc.]

- Notes: [Any story ideas you have had so far]

- [Number and Type of Playable Characters]

- [Continue to section 5 for the rest! :) ]

# 5. Avatar Creation: Human vs. Pet, Clothing Systems, The Avatar's Role(s) Within The Game, Avatar Equipment Slots, Stats, and Abilities.

Probably most of you are familiar with the concept of an avatar as a 2D image which you choose to represent yourself on a forum, IM network, or social networking site. Some games use that kind of avatar, notably Facebook games where the players already have such avatars as part of their Facebook account. This kind of image can either be provided by the player or chosen from a list provided by the game. That's fine, and if that fills your game's need to visually identify players to each other, well and good. But that's not actually the kind of avatar I'm going to talk about here.

Some games do not have avatars. These include 1st person games where you cannot see the main character because you are looking out through their eyes, and also large-scale strategy or sim games where your role is that of a general or business manager, and there is no point showing the player's body because the player doesn't do any gameplay through an individual body. In 1st person games sometimes the mouse pointer is characterized as the player's hand, or a gun the player is holding is visible in the bottom center of the screen. In strategy and sim games the player's identity is more that of their whole army or company, often combined with a color, insignia, or faction. Think of board games – it's common to say, “I'm red” or “I'm the blue army”. Or for an insignia example, “I'm the shoe” in Monopoly, and for a faction example, “I'm the Orcs” in Starcraft. This can be a standalone system or included alongside more complex avatars. Games that allow the player to create a guild or corporations generally also let the player create an insignia for it, and games that allow building a castle or fortress often let the player design a flag. If you want this kind of system in your game it needs to be designed like any other graphical system – make a note in an appendix. But it's still not what I really mean by avatars.

What I actually wanted to talk about is the concept of the avatar as a playable character through which the player acts out gameplay actions and the main role in the game's story. An avatar is the player's primary worker, explorer, fighter, and problem-solver, and also a way of showing the player's physical and emotional involvement in the story. In a pet game these avatars may be humanoids or non-human creatures, depending on the player's role in the story.

Multiplayer games often have highly customizable avatars, and make avatar customization its own kind of gameplay. Singleplayer games often don't have much customization because it's not as interesting to players to customize their appearance when there are no other players to see that appearance. On the other hand singleplayer games have the option to pre-create a character with a distinctive appearance, name, and story like that of a novel or movie, and get the player to play as that character. This is less tolerated by players of multiplayer games. Some games equate one player with one playable character, while others allow the player to start a new parallel journey through the game with each new character, while still others give the player simultaneous control of a team or small army of characters. Is your player a pet owner or other person who works with (NPC) animals, or is your player an animal themselves? Some virtual pet sites avoid having a human avatar by giving the player a minimal role as a pet owner but delegate much or all of the gameplay to the player's active pet; the player thus acts through the avatar of this pet. This limits the possibilities for telling any kind of personal story about the player, so it's only an appropriate choice of you don't want your game story to be about the player's own heroic adventures, but instead about the pet's adventures. Some pet games have both humanoid and pet avatars; either their roles in the game are split, with the humanoid doing the interaction with NPCs and the pets doing the combat/competition, or the player controls a mixed team of humanoid(s) and pet(s) in combat/competition.

Some specific uses of avatars: Avatars are appropriate to tactical games where the player controls ten or fewer units in combat. (A unit is each humanoid or pet which participates in combat; real-time and turn-based RPG-style combat usually has 1-3 units while tactical games often have 4-10.) Avatars are also appropriate to time-management and energy-management games where the player can only act through their avatar and that avatar is what the player uses to run around trying to get all their tasks done in an efficient order. Avatars are appropriate to games where one of the game's activities is solving the problems of NPCs, since it is difficult to tell this kind of story about inter-personal interaction without giving the player a person with which to carry out their half of the interactions. (Though, dating sims are commonly 1st person, and they are very personal and emotional stories. This is because they are single-player games and the lack of avatar customization is extra-likely to alienate players in a game where the player is supposed to imagine themselves in a romantic relationship with one or more NPCs.) And finally avatars are appropriate to RPGs and action adventure games which typically have stories of personal growth (bildungsroman), adventuring, and exploration; again, it's difficult to tell a story about a character's adventures and progress without a visual representation of that character.

So in conclusion, the type of avatar system you choose for your game, if any, should be appropriate to the kind of actions you intend the player to perform within the game and the kind of story you want to tell about the playable character(s). If you want to tell a personal story where the player is equated with the main character, you need to either give the player an avatar or make the game be in 1st person POV. Avatars are appropriate to games where the main activities are those carried out by one or a few characters within an interactive world. (Or games which are primarily forums, where people want to present an image of themselves for social communication purposes.) On the other hand, games where the player's main activities are detail tasks like solving puzzles or large-scale tasks like acting as the general of an army can work quite well without an avatar, beyond the possible characterization of the mouse pointer as the player's hand or use of a faction color or symbol. And games which have neither a social element nor a story probably don't require avatars.

Avatar creation is often considered part of the pre-play or setup portion of a game; if all or most gameplay must be done through the avatar, the player pretty much can't play until they have created an avatar. However, avatar customization can be much more than a setup-type activity. Customization can be a major type of gameplay within the game. Avatar customizations make good quest rewards and thing the player can enjoy shopping for. Some games even include a ticker or progress bar where the player can set a goal item they want to buy and its price, and the game will display the player's current money as progress toward this shopping goal. Avatar appearance plays an important role in socialization between players, and changes of costume associated with holidays contribute to making a multiplayer game world feel alive to players. In class-based RPGs character appearance (especially weapon type) is commonly tied to class and can tell other players at a glance what the character's fighting style is, or if they are a healer or other support class.

In games where there is one avatar per player, the data for the avatar may be stored directly in the database entry for the player's account (or saved game file for a singleplayer game). If multiple characters are possible, the player's account database entry should contain links to the database entries for each character. In singleplayer games instead of allowing multiple avatars per player the game may allow multiple players, which may be equated to saved games, or may be allowed multiple saved games. In this case, if a player wants a new avatar and a new journey through the game they can simply create a second player account (because it's free, unlike in many online games, and it's easy to create a player account and switch between them).

In some games a human avatar's appearance is its only relevant property. Appearance traits typically include: gender, species/race if the game has multiple kinds of playable humanoids, body build if there are multiple options per gender, skin color, hair color, hair shape, and face (sometimes the shapes, sizes, and positions of individual facial features can be chosen). In more highly customizable games eye color, makeup, tattoos, height, and animalistic accessories such as horns, ears, tails, and wings are all possible avatar traits. In some games where a pet is necessary for combat the player may need both a human avatar and a first pet which is also created like an avatar.

Pet avatar systems depend on whether the pets in the game have predetermined appearances, with or without animations, or whether the pets' appearances are genetically generated from either layers of 2D images or body part models and textures. Even when pets are highly customizable via a genetic system, most of this system will be closed off to a starting player, as unlocking the branches of this genetic tech tree is usually a major part of the gameplay. So the player's creation of a first pet will be limited by that. Some systems do not allow the player to create a pet, but instead limit the player to choosing from a small selection of standard starter pets, adopting a pet another player has abandoned (or the game has randomly generated). Or the player may be required to start with a specific type of pet. For example, in a system where all newborn pets are amoebas which evolve into different animals through gameplay, it would be logical that all players must start with an amoeba. Some systems require the player to start with an egg or egg-equivalent, whether the pet type is choosable or not. That egg might appear as the player's avatar until the player manages to hatch it. Some pet systems do not have gendered pets, or do not visually distinguish between male and female pets. Some pet systems allow the player to choose the color and/or markings of a pet, some do not.

Avatar Clothing And Other Equipment

Then of course there is the clothing. Newly-created humanoid characters are usually given default clothing. This could be a universal default or a default for their gender or class. Occasionally the player is allowed to choose the colors of this default clothing, or chose between a small number of clothing styles. Some games allow pets to wear clothing, but even when they do newly-created pets often have no clothing at all, or only a collar. But once the player begins playing the game, many more clothing choices can become available. Clothing in games can come in a wide range of customizability, from a non-customizable whole outfit, to different colors of that outfit, to 3-piece mix-n-match gear (waist-up, waist-to-knees, and knees-down), to separate hats/masks, cloaks, shields, weapons, and gloves, to a highly layerable wardrobe and a wide assortment of jewelry, and even to objects which are not clothing but instead visual effects such as glows, sparkles, or falls of petals or feathers, backgrounds that appear behind the avatar, decorative borders or symbols near the avatar's name, or accessory objects either attached to the character or following nearby.

A character's mount may also be considered part of the character's equipped items, and that mount itself may be customizable with different saddles, barding or body armor, headgear, leg armor, and/or mane and tail styles.) The same goes for a character's currently equipped pet (or pets if the game allows more than one to be equipped at once). Current buffs and debuffs (aka status ailments) applied to a character may also be considered part of that character's equipment; they may have visual effects such as causing the character to appear transformed into a monster, causing the character to glow red with berserk rage, white with healing power, green with sickness, etc.

In some games, especially RPGs and RPG hybrids, the avatar may have dozens statistics which describe its abilities. Many of these are only relevant in combat, and those will be discussed in the combat section, along with whether classes and races are actually a good idea. But some may affect the character's behavior outside of combat: level, class(es), race/species, faction alignment, reputation with various individual NPCs, running speed, jumping height, ability to lift and/or carry various items, resistance to damage from falling, resistance to harsh temperatures and poison, swimming ability, flying ability, ability to sit or meditate to heal, available emotes and gestures, ability to identify and gather different kinds of resources, and learned non-combat spells and skills. The actions a character is able to perform can further be enabled, disabled, or altered by a spell, skill, tool, consumable item, equipped pet or mount, or currently applied buff or debuff.

Now you should be able to add the following to your features list:

- [Number and Type of Playable Characters]

- [What role does the avatar serve within the game? Exploration, combat, sim-play, picture next to forum posts and messages...?]
- [Describe a default avatar's stats and abilities]
- [Describe a default avatar's appearance. Is it Customizable? Is it tied to class? Is it genetic? Can characters be customized before play begins, during play, or both?]
- [Describe the equipment part of the customization system. Is there a clothing system, and if so how does it work. Weapons, tattoos, and jewelry are included, as well as backgrounds and special effects. Does equipment affect the character's stats, and if so, how?]
- [Are there mounts? If do, are they customizable or all of one type or of a few specific types?]
- [If the pet has both humanoid and creature characters which have different customization systems, repeat the above entries for the second type of characters.]

# 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.

Almost all pet games have an inventory of some sort. In games where the player is expected to collect many pets they usually have their own inventory system, separate from equippable and consumable items. Tycoon games have one of the most minimal kinds of inventories, so let's start there. A pet breeding tycoon game generally has one playing field functioning as a visual inventory of currently owned pets, optionally a secondary playing field with pets being sold in your shop, an inventory category for eggs or frozen animals, optionally a secondary inventory category which is a book recording all pets you have bred so far and which sets you've completed and earned an achievement and rewards for, one inventory category for upgradeable tools, an inventory category for consumable items like medicine, vitamins, food, and insta-grow, and the basic one for money and optionally the other basic ones for XP and/or energy/magic. It may not be immediately obvious that the playing field is an inventory, but there is often a limited number of pet slots, whether those are stalls, nests, pots for plants, or simply a capacity limit. It's also often possible to buy additional space, either within the playing field, as additional copies of the playing field, or in the other inventory categories such as the shop and egg storage. Upgradeable tools are technically "key items" or "plot items" which are generally items the player can't sell and which don't get consumed when used. Sometimes these items have their own XP bars and level up with use.

Equippable gear with combat stats (armor, weapons, accessories) is another standard inventory category. Typically the clothing inventory interface include some sort of paperdoll or wireframe representation of what items are currently equipped on the character, as well as the character's stats as modified by the gear. Some clothing systems have a double clothing inventory; in one set of slots go the stat-bearing gear, but there is a second set of slots where more attractive gear or statless clothing can be placed to cover up the not-necessarily-matched-or-attractive gear.

Consumable items in an RPG-type game can include all the breeding and pet food sort of items from tycoon games, as well as scrolls that teach a skill, armor-repair kits and bandages, various sorts of buffs in pill, potion, or human food form, and gatherables/monster drops which are consumed through crafting. Gatherables include things you pick from plants, dig from the ground, or otherwise find while exploring. Drops include things you can get from tending tame animals (wool, milk, eggs, beeswax, possibly leather and meat if the game allows players to slaughter tame animals) as well as things you can get from fighting monsters and also fishing and similar minigames. The consumable items category can also include crafted items which are used to craft more complex items. (Things like string, fabric, boards, bricks, metal ingots, dye, glue, etc.)

Key items in RPG-type games may include quest-related items in addition to tools and even emotes in online games. Like character customizations, special emotes make nice quest rewards.

Most genres have only one or two inventory locations, though a location may be divided into categories. An inventory location may be an abstract place reachable by a menu, a backpack or similar portable container, a bank which can only be accessed from specific locations within the game and probably has usage fees, or a chest/safe/warehouse built or bought by the player at a specific location within the game (commonly in the player's house). In some systems items can be manipulated within the inventory, either by using a tool on an item, or by using one item on another, or by selecting multiple items and attempting to use a “combine” function. In some cases there may be multiple copies of the same kind of inventory; for example each avatar may have their own backpack or the player may have 3 fish tanks.

So, how is the storage internally structured, and how does the user rearrange it or get things in and out? If a player cannot have duplicates of an item, that's pretty simple: they have it or they don't. Let's call this a binary inventory, because the number of each item is either 0 or 1. Tools and upgrades often follow this paradigm. Also, checklists of achievements, such as areas of the map that have been discovered, types of pet that have been captured or bred (often recorded in a book), and many 1-time quest objectives. These may not be physical objects in an interactive inventory, but the way in which the game keeps track of them is like a read-only inventory. In some cases the player may have an inventory size limited by slots. For example if the inventory has 20 slots the player can carry 20 items, but if they try to pick up a 21st they will either be unable to or will be prompted to discard something.

Another type of inventory would be the stack inventory. In this case, whenever a player gets a new type of item it starts a new stack, then all additional items of the same type are added to that stack, up to a predetermined maximum number the stack can hold. 10, 20, and 100 (or 9 and 99) are common stack sizes. In some systems stack size varies to create the impression that some items are larger or heavier. For example 100 feathers might fit in a stack, while only 10 iron bars do. If a game has this type of information it is stored as part of the data for each specific item, though there is usually a default stack size for a generic item. This is related to the programming concept of inheritance, which... is getting off topic. The player may or may not be allowed to have a second stack of that type of item after the first is full; usually this rule applies to the whole system, not individual item types. As with a binary inventory the player may have a limited number of slots; in this case each slot can only hold one stack of same-type items, regardless of whether it is a stack of 1 or a stack of 100.

Inventory type #3 is the weight inventory. Every item has a weight (or in some cases separate weight and volume numbers). The character's stats determine how much weight and volume they can carry. The two numbers might be affected by different stats, for example the character's strength might determine weight while the backpack they have equipped might directly give a volume. The character can then carry as many of each type of item as they want, but if they try to carry too much weight or too much volume they are overloaded (or pinned) and cannot walk until they discard something. Some games don't allow an overloaded character to pick up more items, others do as long as the character can do it without moving. Some games don't actually allow the character to become overloaded, instead giving the player an error message when they try to pick up an item that will put them over the limit. Those usually still need the functionality of being pinned when overloaded, though, because a character carrying a legal weight may get debuffed so that they are now unable to carry what they were already holding. Some games block the trading function on overloaded characters; I've never quite understood the goal of this rule.

Inventory type #4 is the puzzle inventory. In this case the player's storage is a 2D grid and each item has a 2D shape; the player can carry whatever they can fit into the grid. This is intended to simulate the experience that real backpacks and suitcases can hold more when they are packed efficiently than when you just throw things in.

Finally, there is the rummage inventory. This type of inventory displays each item or stack as a 2D image, and each of these images is on a transparent layer. The player can only access items which don't have other items on top of them. This is intended to simulate the experience of rummaging around in a purse or rucksack and occasionally needing to dig out items from the bottom. Also the visual image of all one's possessions lying in a pile may seem more realistic then having them neatly organized in a grid, especially in a low-tech game world.

Oh, a bit more about the playing field as a visual inventory, especially of pets (or plants). This varies hugely based on the individual game. In some games you have a piece of property, usually with a square grid, on which you place all your buildings, appliances, crops, and/or animals. You're usually not intended to be able to fill up all this space, so the limit on number of animals you are allowed to have on your property may be much lower than the number of grid squares you could hypothetically park animals on. But still, your property functions as an inventory, similar to the puzzle inventory described above. In other games there is no such grid. Fish tanks are a nice example. A fish does not generally stay parked in one square of the tank, it wanders all around and can pass in front of or behind other fish and decorations, through the use of image layers. But the tank does have a limit on the number of fish it can hold. In this case the tank is probably programmed as a binary inventory where the tank holds a set number of binary items, each one being a fish. This is likely because each fish typically has individual data, like age and health, so they couldn't be effectively treated as a stack of a single type of fish.

- [Inventories]

- [For the first inventory, describe its location, the kinds of things it can contain, and starting size]

- [For each inventory, describe how it can be upgraded if this is possible.]

- [Repeat for each additional inventory]

- [Ditto]

- [Item types]

- [For each item type, describe how it functions and some example objects of that type. If you have listed pets as avatars, but the game has a different mode where pets function more like items, you may have to list them here too. Or if pets function as different types of items in two game modes, make an entry here for each mode.]

- [What properties or statistics, if any, do items of this type have?]

- [Repeat for each additional item type]

- [Ditto]

# 7. Gathering and Crafting: Climbing the Tech Tree, Recipes, Skills, Building Up Infrastructure, and Crafting Gameplay.

Crafting is any act of processing a resource to alter it or combining two resources into something new. The resources upon which crafting is performed are usually gatherables or drops. Gatherables are items the player can pick up from their environment. Some items are gatherable by default: berries, mushrooms, and fallen branches are common examples. Some items require tools to enable gathering them: for example a pick may be needed to mine ore, while a bucket or bottle is needed to gather water. Some items require a skill to gather them, and perhaps even to detect them in the first place: ectoplasm might be gatherable from ghosts, but you might need to learn spirit-version before you can see ghosts, much less interact with them. Drops on the other hand are items received after winning a combat or playing a minigame. Combat drops commonly include body parts of the monster killed: horns, feathers, scales, bones, teeth. If a humanoid opponent is killed drops might logically include bits of broken armor, fabric, potions, and anything else the humanoid might have been wearing or carrying. In some games combat drops are the major source of player gear, but droppable gear combines badly with a deep or extensive crafting system; I personally suggest that anyone who wants crafting to be a major part of their game should not make gear droppable. Minigame drops should have some thematic relevance to the game; they often include collectibles and consumables, since it's logical to assume that minigames are created by NPCs within the game, and would have prizes those NPCs could manufacture or buy in bulk.

A game's path of advancement in crafting ability is called a tech tree. The roots of the tree are the abilities the player begins the game with. The tree grows upward and branches out every time the player masters a current ability or builds a new piece of infrastructure which unlocks new abilities and/or crafting recipes. For example, a player may begin with the ability to pick up two rocks and bang them together. Initially there is a low chance of creating a stone blade, or the blade produced will be of low quality. But after banging rocks together 20 times the player masters the ability, meaning it permanently has the highest possible chance of success, whether this is 100% or slightly lower, and the blades produced are either of the highest possible quality or usually very good. More importantly, mastering the ability to make stone blades may unlock the player's ability to start practicing a more advanced skill, like making stone knives with handles. In turn, stone knives with handles may allow the player to skin killed monsters to obtain raw leather. Then the player may get to practice curing leather until they master that, which unlocks their ability to make leather armor.

Just as a tool may be needed to enable gathering, tools or larger-scale appliances or buildings may enable various crafting techniques. These tools, appliances, and buildings taken together are termed infrastructure. They are typically the result of crafting themselves, such as the knives just described – perhaps two knives can be crafted into a pair of scissors, and this tool is needed to unlock the crafting technique “fabric cutting” which is required for a whole range of clothing crafting recipes. For a building example, domesticated animals commonly require building an enclosure to keep them in, such as a pen for sheep or a barn for cows. In the rare event that a piece of infrastructure is not craftable by the player it is probably obtained from an NPC; it might be purchased or might be a quest reward.

NPCs are also a source of skills. Basic skills are often given away free, because the purpose of the player's interaction with the NPC is more to teach the player how crafting works in the game and where to find the relevant NPC than to pose a challenge. But basic skills don't have to be free, and non-basic skills rarely are. Just talking to an NPC isn't gameplay, the fun is in tackling a challenge. The NPC may name a test or price, in exchange for which they will teach the player a new skill. Or it can happen the other way around, with the character teaching the player the skill but keeping the first few results of that skill.

So, a tech tree is the map of all these skills within a game, and which needs to be learned to enable the player to learn the next. Designing a game's crafting system consists largely of creating this tech tree: both the recipes for crafting every item, and the conditions for unlocking each branch. In a pet game sometimes all of these skills are directly related to breeding or training pets. Other times pets are just one branch of a much larger tree, or may be broken up into multiple branches, like combat-companion pets vs. non-combat mounts which increase traveling speed vs. beetles which are bred to be ground up to make colorful paint from their shells. Sometimes the skills gained become part of the player of their avatar, sometimes they may exist within a pet, or sometimes they may exist within a piece of infrastructure.

Crafting gameplay can be as simple as selecting ingredients and then an action to be performed upon them, then possibly waiting for the task to be carried out. This is easy to implement and requires no skills from players; it's kind of boring as gameplay, though. Another option is that each crafting (or gathering) activity can be its own minigame. Any kind of minigame can be plugged in as a crafting step, though of course some will be a better thematic fit than others. Minigames aren't as appropriate for an activity where the results are binary (success vs. failure) or worse activities which are always successful. A minigame is much better-suited to an activity where the results are a range (minimal success, average success, perfect success; failure may or may not be included in the range). For example, it might require twenty units of ore to start a game of “smelting”, which might be a tetris-clone. Surviving level one would yield a minimum amount of metal from the batch of ore, while surviving many levels would yield more metal and maybe a bonus item, like one unit of a different metal or a piece of charcoal or a refund of some of the ore.

Get at least a general outline of the crafting system written down, but it's ok if you don't know all possible gathering and crafting processes yet. Specific minigame designs should go in the mini-game section, but we won't get to that for a while yet, so if you currently have ideas for minigames write them down and stick them into an appendix for later. Similarly, put any specific ideas for crafting items, tools, appliances, buildings, quests, etc. in an appendix. I haven't talked about prioritizing core features yet either; the basic concept is that the fewer features you need to create at first, the more likely you are to actually get to a point where the first (alpha) version of you game is playable. This is often a big boost for morale and recruitment, as well as a playtesting opportunity that can result in big redesigns. I mention it here because while you may want your main crafting system in the alpha feature set, you may want to postpone some portions of it and/or any secondary crafting systems to a beta or later version of the game. It's convenient if you have separate bullet points for anything you want to postpone, so it's easy to color-code them or move them into another section when you do your prioritization step.

- Crafting system(s) [Skip this section if your game does not have crafting of any kind, or note if you intend to postpone all crafting until post-alpha.]

- [Describe your game's (primary) crafting system: what are you crafting out of what, by what sort of gameplay?]

- [Describe the most common process by which gathering is carried out.]
- [Describe each additional process by which gathering is carried out.]
- [Describe the most common process by which crafting is carried out.]
- [Describe each additional process by which crafting is carried out.]

- [Describe each additional crafting system (it is additional if it has a separate tech tree). For example cooking is often separate from crafting gear. Note if you intend to postpone any of these until post-alpha.]

- [List the types of things which may be required to unlock a recipe or skill. Is the avatar's combat level a prerequisite (if your game has combat levels)? The avatar's property ownership level, if any? Is the avatar's gender, class, race, etc. a prerequisite? Do you want to have consumable items that teach skills? NPC quests? Tools which must be equipped (to what kind of slot?) or tools which must be carried in the avatar's inventory but don't need to be equipped?]

# 8. Trading, Shops and the Marketplace

This section is about the exchange of money and/or items between the player and the game or between two players. “Money” can be any kind of currency, not just bills or coins. Gems, tokens, tickets, pretty much anything can be used as a game currency. Many games have multiple currency systems with some kind of restriction or difficulty preventing the two from being directly exchanged. Or sometimes they can be directly exchanged but the exchange tax/fee is high enough to discourage doing this except in special cases. Secondary currencies are used to regulate the player's time within the game; for example if the player needs 1000 casino tickets for an item they can't buy with the main currency, this encourages the player to spend enough time playing the casino minigame(s) to earn that many tickets. If the casino did not have unique rewards some players would spend little or no time playing the games there; not necessarily because the games weren't fun, but because min/max calculations told the player it wasn't the most efficient way to earn money. The players would then get bored with the game as a whole faster because they aren't experiencing the full breadth of its content. Another common example of this is PvP reward tokens which can be spent in a PvP rewards shop. Cash shop currency is a special case of a secondary currency, with the purpose of encouraging the player to contribute real money to the game in order to immediately get things that would otherwise be impossible or a lot of work for them to get within the game.

The most basic use of currency in a game is the NPC shop, which allows the player to purchase items within the game. Most literally, this is a storefront presided over by an NPC, who is ostensibly the one receiving the player's money, and adding new stock to the store as the game progresses. Functionally, NPC shops can include vending machines or automatic stores which have no NPC, and can also include NPCs which sell or exchange items or tickets but have no physical store. A simple NPC shop works like so: There is a button showing a picture of an item, and it's price. The player clicks the button to buy the item, or drags the item onto their inventory. The game checks if the player has enough money, and if they don't, an error message says so. The game checks if the player has enough room in their inventory, and again an error message will warn the player if they don't. If the player has enough money and space the item is added to the player's inventory and the money is subtracted from their wallet/money pouch/whatever the game calls the player's stock of money. Optionally you can add a step in there asking the player if they are sure they want to buy the item, or would prefer to cancel the transaction. Another option is to allow the player to buy multiple of the same item at once, by selecting or entering the quantity they want to buy. The game does multiplication to find the total price, then the rest of the transaction proceeds as usual.

An NPC shop can also allow the player to sell unwanted items back to the game. Sell-back prices are typically half or less of the shop's prices if it sells the same item. In a marketplace system sell-back prices effectively set the minimum price for which a player will sell an item to another player. Selling is just like buying in reverse – either items in the players inventory need to have sell buttons and prices, or dragging an item from the inventory onto the store should give the option to sell it. Optionally some games keep track of the last six or so things the player has sold, in case the player wants to buy them back. Some items may not have sell-back prices. They may be discardable, either by dropping it on the ground or by using a trashcan option in the inventory, but the player can't get money out of them unless they are able to trade the item to another player.

Trading is any exchange of money or items between players. As such it is not relevant to games which have no multiplayer features. (Buying from or selling to an NPC doesn't count.) Some multiplayer games do not allow this kind of exchange between players. The purpose of this may be to avoid complaints about accounts being hacked and trade-scamming, or simply because trading is off-topic to some kinds game, like those where the player has no permanent inventory or equipment; they may own items during minigames or duels, but they don't retain those items after the minigame or duel ends.

If you do want to have some kind of trading mechanism, there are two ways to make this kind of exchange relatively scam-resistant. The two methods are direct exchange (with double approval) and exchange through a shop or market, (with two-step single approval). Approval is simply when the game asks a player, “Are you sure you're okay with this?” and shows them the details of the trade they are agreeing to.

Exchange through a shop or marketplace solves the problem of players wanting to trade offline or in batches. But it is less flexible than a direct trade, because most systems don't allow mixed batches of items to be sold, nor items to be sold for anything but money. A few games have a barter system which does allow trade lots and allows the player to describe the general kinds of things they want in exchange. Barter systems are interesting but I think they are ultimately a dead end in economic evolution, which is why no one uses them in real life any more. I don't recommend adding one to a game unless it seems to fit extremely well with the flavor of the game (such as a game which chooses not to have money at all to create the feel of an ancient economy). Shops and marketplaces both use 2-step single approval: the first step is when the seller player specifies what and how many of the item they want to sell. For a flat sale they also specify the price and how long the item should be listed for sale before being delisted and returned to the player (unless the game lets sales last forever unless the player cancels them). Or for an auction they specify the minimum bid, the bid increment, and possibly an autobuy or reserve if the system has those. The seller player looks at all the information and approves it, though they may still have the option to cancel a listing if no one has bought it yet, or bid on it if the item is being auctioned. Then the buyer player looks at the item for sale and the price asked or the price they can bid, and approves that.

So what is the difference between shops and marketplaces? Personally I hate player shops, but I'll try not to be biased here. A player shop gives the player a personalized area in which they can sell multiple items for prices they specify. Some games require the player to be offline, or worse, online but idle, in order to be in shop mode. Most games don't allow prospective buyers to ask the game where they can get the cheapest currently-available one of an item they want; instead they have to look at one shop after another, hoping to find the item they are looking for at a reasonable price. So player shops are inconvenient for both buyers and sellers. The main argument in favor of player shops is that they are a realistic exchange system for a low-tech culture. An additional factor is that some players look at a player shop system and would prefer to use it like a display case instead of actually selling anything, which results in items being listed for sale at ridiculously high prices because no one is intended to buy them. That's just messy and can frustrate buyers. This can be worked around by offering players a display-case or collection gallery system which is better-suited to the purpose than a shop system. If you want some kind of player display system, I'll talk about those in the Player Property and Housing section.

Marketplaces, by contrast, have all sorts of convenience features like searching by keyword, browsing by category, sorting by price or item quantity, and the ability to choose an auction sale type in addition to a flat price sale type. In some games players must visit a physical location or NPC auctioneer to access the marketplace, while in other games it is accessible from anywhere through a menu or GUI icon. Marketplaces enable some interesting economic gameplay, like attempting to buy up all of an item to create an artificial shortage and inflate prices, then sell the hoarded items at a profit. This is illegal to do in reality, but that's no different from attacking other people with bladed weapons, stealing cars, and other things that are fun in games even though they aren't allowed in the real world. Some games try to discourage this sort of market manipulation with auction fees or other sales taxes; I'm not personally in favor of taxing marketplace use, but it's a legitimate design strategy and realistic place to put a gold sink, so it works well in some games.

Trading cash-shop currency. Many games do not allow players to trade cash shop currency, possibly because they think they will sell less cash-shop currency this way. I think it's actually the opposite; it's very difficult to convince a player to make their first purchase of cash-shop currency, but someone who is already inclined to buy cash-shop currency for their own uses can be easily convinced to buy more by the opportunity to exchange it with other players for items or in-game currency, or use it to gift other players with cash-shop currency or cash-shop items. Trading cash-shop currency is especially useful in games where many items purchased from the cash shop are soulbound to the purchaser and can't be traded at all. (The purpose of this is to ensure that players buy new ones instead of passing the same ones around from player to player within the game for years, and the same applies to games where all crafted gear is bind-on-equip).

Mail. Some games allow sending money or items through the mail (otherwise known as the private message system). This is not a trade, since nothing is received in return. This is useful if a player needs to send items from one character on his account to another, since it's (usually) impossible for the two to be online at the same time. It's also a convenient way for the game to send an item to the player, such as returning an item that failed to sell on the marketplace, or giving the player a holiday gift or subscription reward.

- Money System [This is applicable to both singleplayer and multiplayer games; only skip it if your game has no currency whatsoever.]

- [Describe the primary money system: What is the currency called? What denominations does is come in? How does the player earn this money? What is the player intended to spend this money on? Is there any special story explanation behind this currency?]

- [Describe each additional money system, if any]

- NPC-Owned Shops [This does not include quest-givers which give or take something from the player in a one-time exchange.]

- [Describe the shop use method and GUI.]

- [If possible, list each specific NPC owned shop and describe the range of items it sells. But if there are a large number, just describe an example one and put the rest in an appendix.]

- [Describe the trading method and GUI, any restrictions on trading certain types of items, and any fees or taxes on trading.]

- Player-Owned Shops [Skip this if your game has no player shops].

- [Describe how they work.]

- Marketplace(s) [Skip this if your game has no marketplaces where players sell items to other players. Simulated markets where all items are supplied by the game go under the NPC-Owned Shops category.]

- Flat Sale Method [If your game has this, describe how it works. What parameters can the player set, such as sale duration, lot size (quantity of items), price per item or price per all items. Are there any fees or taxes on flat sales?]

- Auction Method [If your game has this, describe how it works. What parameters can the player set, such as minimum bid, bid increment, auction duration, lot size (quantity of items), reserve, autobuy, etc. Are there any fees or taxes on auctions?]

- Browsing Structure [This should be based on your description in part 6 of what item types there are in the game. Cash shop currency may be an additional item type.]

- Sorting and Filters [How can the player narrow down to only the sales they are interested in and prioritize them for convenience? Lowest price per unit and ending soon are probably the two most popular ways to filter sales. Gear by level equippable is also popular.]

- Search Feature [The player might like to search for all gear of a type, all gear for a class, all clothing that is a particular color, or an item that they only remember part of the name. It's common to want to combine two search criteria.]

- Delivering items to buyers and returning unsold items to sellers. [How does it work?]

- [If there are multiple marketplaces that actually sell different stuff or work differently, describe each.]

# 9. Forums, Messaging, Chatting

Purely singleplayer games, of course, have no need for a forum or messaging system. Games with minimal multiplayer may have the messaging system without the forum; usually in this kind of game the purpose of the messaging system is to send gifts and friend invites or PvP challenges to other players, and optionally the player can type a message to go with this. If your game is part of an existing social network or game stable, they may already have a system in place for this kind of thing. Similarly game stables often have a forum in place outside any of the games where they will create a new subforum for any new game in the stable. And of course there are many free services that will let you make a forum if you are trying to get your game going on the smallest possible budget, though it's not extremely professional looking for a finished game to be using one of these free boards. If you are recruiting a team of volunteers one of these free forums can be helpful to have as a place where team members can talk about developing the game with all conversations being preserved for future reference and there's no need to schedule everyone to be online at the same time. For some purposes or some types of people a voice chat or text chat room may be preferable, and the benefit of real-time communication may outweigh the scheduling difficulty.

One of the few areas of game design where pet games have actually been pioneers is in the incorporation of forum-posting physically into the main game and functionally into gameplay. VPSes and the closely related genre of social gaming sites are some of the only places where game avatars are automatically used as forum avatars and forum posting is rewarded with game currency, as well as a way for players to negotiate trades and other cooperative activities within the game. Some of these sites also make chatrooms available to their players; this part is a traditional feature of MMOs, existing in even text-based MUDs and MUCKs before they evolved into MMOs. (Chat has also long been a feature of networked PvP board games and strategy games.) There may be a chatroom for the whole game, a chatroom for a physical area within the game, a chatroom for people waiting for PvP matchups or trying to recruit a dungeon party, a chat room for each guild or faction, a server for private voice chats within the game, etc.

Private Messaging (aka mail) is usually handled by using the forum system. A private message (note, mail, etc.) is no different from a private forum post that can only be viewed by the sender and receiver. I'm particularly fond of approaches where replies to and from the same pair of people are displayed as a thread, rather than a list of separate mails. Some share a copy between these two people, such that if the sender edits the message after sending, the copy in the receiver’s inbox will also be changed. Other systems do not allow messages to be edited after being sent, and may generate a second copy of the message for the receiver (while the original copy goes in the sender's sent box). Some systems have various storage limitations, such as automatically deleting stored messages that are a month old, not having sent boxes, or not saving sent messages unless the sender checks a check box on each individual mail. These economizations are mildly annoying to players, but players may also indirectly benefit from the system not having to deal with storing as much data, so it's pretty much a judgment call.

Some private message systems incorporate the ability to send one or a few items attached to a message. If you want a private message system but not a forum, then you might instead take the approach of starting with the trading system and adding the functionality to comment on an offered trade. An invite or similar request is like sending a trade where instead of an item a clickable link is displayed, which runs a little script to carry out the friend list addition or other request. It's also possible to have private chat messages sent through a chat system as a main private message system instead of anything more like a forum post or email.

There are various commercial forum softwares available, most of which come with a private message system included but may or may not have good chat functionality. Vbulletin is a widely-used example, and one of several that use the UBB standard. I haven't looked into free opensource forum softwares but there probably are some. It's possible to create your own forum system, but you are re-inventing the wheel; I don't recommend attempting it unless you really need your forum to have some features that you can't adapt a commercial software to have. GaiaOnline is an example of a social site that made their own forum software and has integrated several custom features into it over the years, starting with the way players earn money by using the forums and their avatars are displayed by their posts, and then adding signature image automation and regulation, adding the capability to display a car or fishtank, making the banner across the top of the forum interactive, and various temporary forum modifications for events. But the core of their forum software isn't very good, which is most easily visible in the fact that some of their subforums are almost impossible to use due to not handling high traffic well and not supporting thumbnail images beside thread titles. DeviantArt is another example-of a well-known website which made their own forum software and ended up with featureless, user-unfriendly forums. Chat clients are somewhat easier to implement yourself, but again there are an assortment of commercial and free ones available, both closed-source and opensource, and some of them will be more featureful and user-friendly than anything you could make without a lot of time and effort.

So, as a designer you mostly need to plan which of these communications systems you want and how you want to integrate them into the game. Do you want your forum to be usable when your game itself is having server maintenance? If so then you have to plan for them to not be hosted in the exact same place, and probably for user log-ins and money earned from forum use to be hosted separately from the main game.

- Forum(s) [skip if you don't want one]

- [Describe what you want the main game's forum to be like – is there any kind of censoring system, can players block themselves from seeing posts from specific other players, do players earn money for forum use, can players include links and images in their posts, are signature images or text allowed, are forum avatars the player's avatar or something else, does the information below the avatar contain links to a player's collections, property, guild, a view of what items are equipped on the avatar, etc.]

- [If you want to have private forums, such as for guilds or private roleplaying, describe how those should work, such as whether players can have moderator abilities over private forums or threads they create, whether the visual themes of private forums are customizable by players, whether rules about images or signatures are different from those of the main forum, etc.]

- Private Message System [skip if you don't want one]

- [Is this done using the forum software, trade interface, an external network, or something else?]

- [Describe how you want it to work – can items be sent, are sent messages stored, are they editable, can messages be sent to more than one recipient, is there a length limit, do you want to have some automatic message types such as requests, etc.]

- Chat [skip if you don't want one]

- Text Chat [What channels or rooms are there, is there censoring, can emotes be used, are urls automatically made clickable, can clicking an item in your inventory create a link to that item's info in chat, are there different rules for private chats, etc.]

- Voice Chat [If you are providing this, describe what you want to provide.]

## 10. Pets In More Detail: Functionality Within The Game, Capturing, Breeding and Genetic Systems

As you may have noticed, I've been using a very loose definition of the term “pet”. Basically, I think any interactive animate being the player owns or controls can be considered a pet. That vague definition includes humans, which wouldn't normally be considered pets, but in games like the Sims they certainly function like pets. Pets function so differently across the spectrum of games that any more narrow definition would exclude some pet games. But, if you would prefer to define pets a bit more narrowly, that's fine, because this section is all about narrowing down which type(s) of pet you want in your game!

## Some common kinds of pets:

Avatars As Pets – The most minimal element that might justify calling something a pet game is when the playable character looks like an animal or monster. This would include all games where the player is a puppy, horse, dragon, etc. The playable character does not act like a pet

Vanity Pets and Transformations – Vanity pets are the simplest kind of pet because they have no gameplay functions aside from character customization. In other words they are just there to look pretty following the player's avatar around or living on the player's property, thus the term 'vanity'. In some cases they may have minimal interactivity, such as needing to be fed or occasionally saying randomized dialogue. They typically wander around a bit, though anchored to the player's avatar or to a placement point on the player's property. Or they may wander around inside a tank or pasture. Transformations are when a normally human avatar is shapeshifted to look like a pet, but this does not affect the way the avatar functions (emoticons or chatting might be affected, but those are also 'vanity' elements). Sometimes vanity transformations are the lowest level of something upgradable into a functional traveling form or combat form.

Mascots – This is any kind of companion character that gives the player feedback on their actions. Clippy from Microsoft Office, Navi from the Zelda series, and Issun from the Okami series are some examples of this 'helpy' type of pet. By 'companion character' I mean an NPC which follows the player around, is a part of the game's GUI or always available via menu, or pops up regularly to deliver tutorials, tips, and/or narration. A mascot may function as a tool, such as a compass, radar, grappling hook, digger, or backpack-carrier. Perhaps the most developed case of a mascot-type pet ever is the blob from game A Boy and His Blob – this was originally an NES game but a new version is currently available as a wii game. This is a puzzle game where the pet blob functions as a swiss army knife of tools used to help the avatar travel through the level.

Mounts and Traveling Forms – This is any pet used as a vehicle in a way which is more than just looks – the creature must actually increase the avatar's speed or be capable of movements the avatar is not, such as jumping, swimming, or flying. In some games (many racing games for example) the avatar is not capable of moving at all without their vehicle. A mount is a pet the player sits on or is otherwise carried by; a traveling form is a shapeshift which transforms the player into the pet. An interesting classic example of pets as vehicles is the NES game Little Nemo the Dream Master; this game is a platformer with many puzzles that must be navigated by using different pets as vehicles, each of which have different abilities. Mascots are sometimes usable as mounts or transformations

Infrastructure Pets – These are pets which produce or process resources. Cows produce milk, sheep produce wool, hens produce eggs, and various animals produce manure, feathers, pearls, or fantasy resources like gems and mana orbs. Beavers might process trees into logs or boards, fire-breathing dragons might process ore into ingots or wood into charcoal, hens might incubate dinosaur eggs to hatch them into dinosaurs; the possibilities are infinite. Infrastructure pets can even include alien or fantasy creatures which function as buildings or furniture. Typically infrastructure pets are found in sim and RTS games, though they would work in any game where the player has a “home base” which they upgrade between missions.

Combat Pets and Combat Forms – This is any pet which which increases or alters the player's abilities in combat. The creature may fight alongside the avatar, fight under the direction of a non-fighting avatar, be equipped onto the avatar as a weapon or armor, or be a transformation of the avatar. This includes all Pokemon, all Monster Rancher monsters, all creature units in tactical combat games, all pets of the Hunter and Warlock Classes in WoW, all non-vehicle transformations of the Druid Class in WoW, and vehicle pets which also have combat abilities. The most common kind of pet in games which have combat.

Capturable Pets – The flip side of combat pets, these are creatures that fight against you. (They often turn into combat pets after you capture them, though they can also turn into infrastructure pets or become available as shapeshifts.) There are two main dynamics of capturing pets – either you fight them to weaken them then must capture them before they are quite dead or run away, or you must NOT fight them, instead distracting them with bait or getting them to chase you into a trap or enduring their attacks while you wait for your capture spell to be cast or a tameness meter to fill. It's also possible to have capturable pets in a game with no combat – they might be randomly encountered while exploring and captured by paying money, using a consumable item such as a net or collar, or playing a minigame where a sufficiently high score is needed to capture the pet. Capturable pets occur mainly in RPGs.

Collectible Pets – Games with collectible pets are also called “Gotta Catch 'Em All” games. They typically give the player quests or achievements for accumulating numbers or sets of pets, and keep track of the first time the player collects a pet of each type in a book or list. Pets can be obtained either by capturing or by breeding, and this kind of pet occurs mainly in RPG and sim games. Pocket Frogs and Fish Tycoon are two examples of collection by breeding instead of capturing. (Plant Tycoon is a similar game with somewhat different/improved features, if you consider plants to be pets). But unfortunately, neither of these games are good examples of a collection quest/achievement system. Monster Rancher is slightly better – it keeps track of your discovered pets in a book and notified you when you have found a new one. Still no quests or rewards for breeding though.

Breedable Pets – Breeding pets can be a large portion of the gameplay in some pet games. In some games the player may be breeding pets of specific appearances to sell to customers, either by filling an NPC's order or in a pet shop where each type of pet has a set price. In other games the player may be breeding for stats, related to combat or competition. The game does not actually have to contain competitions; Celebrity Pedigree is a game where pet quality is measured in stars, and the overall goal is to have a certain number of 5-star (maximum quality) pets. The game's theme implies that the pets are competing as celebrities in the entertainment industry, but they presumably are entered into this competition by their new owners after you sell them.

Craftable Pets – Aside from breeding or capturing, pets can also be produced by crafting. For example an artificer might build clockwork and golem pets, or a mage might gather spell ingredients to summon a mythological pet with a magic potion or ritual, or a sci-fi toy factory might assemble pets on an assembly line. Less literally, an NPC might give a pet to the player in exchange for a batch of ingredients or crafted items. Craftable pets would be especially suited to time-management games, where the player would run their avatar around at top speed to efficiently gather the crafting ingredients to fulfill pet recipes. But craftable pets could occur in a sim, RPG, etc. Craftable pets can be combined with capturable or breedable pets if the pet captured or bred is a basic type which can be developed into a more advanced type.

Consumable Pets – These are creatures which, once captured, bred, or crafted, can be used once or a set number of times to give some particular stat bonus, work, or other assistance to the player. The fairies in the Zelda series which can be captured in bottles and stored until the player needs to be healed are consumable pets. In a game where the character is a summoner, summoning a pet into combat might consume it or wear it down.

Any type of pet which is breedable needs to have some type of genetic system. This may, but does not have to, bear any resemblance to real genetics (which IMO don't make for great gameplay). Sometimes it bears a resemblance to the discredited concept of Lamarckian inheritance instead – this is a system where offspring inherit a stat bonus based on their parents' training and accomplishments, instead of their parents' genetics. This is nice, gameplay-wise, because it means that successive generations of the same type of pet can reach slightly higher ranks of competition (or whatever) before they must be retired (assuming the game has pet aging). It's like a “new game plus” for individual pets. Many pet breeding systems do not have pet gender, because it simplifies things for the player if any pet can be bred to any other pet (sometimes including itself) and if there are no sex-linked genes or non-genetic appearance variation by gender.

Genetic systems can be about appearance only, stats only, or both. The stats part is pretty simple – a type of pet may have a basic set of stats with possible bonuses from inheritance, or an individual pet's stats may be entirely determined by its parents' stats, with minor randomization. Often the genetic process is slightly biased in favor of offspring getting good stats. So, for example, if HP is one of the pet's variable stats, the genetic algorithm could average the HP stat of the two parents, the randomly choose a value in the range from (average – 20%) to (average + 35%). Or if that type of pet had a base HP stat, you would subtract that base from the average, randomize as above, then add that back to the base. That's just one really basic example – there are all sorts of ways to design the math behind inheritance in your game.

Appearance inheritance systems can be done in three ways:

The first way is that there are set pet shapes, but each shape can come in different colors. So a red pet of type A and a blue pet of type B could be bred to result in a blue pet of type A, among other combinations. In some cases purple pets might also result from breeding a red pet with a blue pet. In a 2D bitmap/raster system the pet shape would consist of a lineart layer (unless it's a lineless art style), coloring layers, and shading layers (each layer would also have a layer mask, with the possible exception of the lineart layer. The pet's color would be changed by bucket-filling or mathematically rotating the color layers. The final sprite is flattened and saved as a PNG file with transparency. In a 2D vector system there are no masks and each color-area is its own object on its own layer. But the basic principle is the same, an image built up from color fills and areas of shadow and highlight. The color can be changed by bucket-filling but it's more efficient to do it mathematically, with the search-and-replace function. For example you can tell the vector graphics program, “Replace all areas of color #FF0033 with color #AA00FF.” The final image can be an SVG file or can be flattened and exported as a PNG. In a 3D system the pet shape is a model and the color is a texture or procedural color applied to it. For the final version the model and textures can be stored separately in any of several file types and combined by the game engine, or the model and texture(s) can be bound together, or the textured model can be rendered to a 2D sprite.

A second way of doing appearance inheritance is having body parts with set colors which can be mixed and matched. The 2D version of this system, whether bitmap/raster or vector, is called a paper doll, and is the same kind of thing as a 2D avatar clothing system. Each body part is an image file and the game assembles them in a predetermined layering order. (For clothing the game might let the player choose the layering order, but this is unlikely to be useful for pets.) The 3D version of this system divides the model into smaller models, each of which has its own texture.

The third way combines the first two – the pets have both mix-n-match body parts and a genetically determined color scheme. Some systems have one or two colors (main and accent) for each body part, but the results may look nicer if the color genetics determine a scheme of 2-4 colors for the whole pet and this scheme is applied to the body part shapes selected. Really sophisticated 3D systems like that in Spore can have the body part models be adjustable and the connectors between them generated procedurally, instead of both the body parts and connectors being of predetermined size and position.

Appearance inheritance is a bit less math-friendly; in some cases you might need something more like a spreadsheet or some rules expressed through if/else programming loops (or whatever your programming language of choice calls them). I mean, you can convert colors into hex values and then do math on those, but that can be ugly, in more ways than one. And converting body parts into numbers is also dubious, unless you are talking about numbers for dominance and recessiveness, which only apply to polyploid systems (systems where each creature has two or more sets of chromosomes). Many pet systems are monoploid for simplicity, because in a monoploid system genotype is always the same as phenotype. If you did not understand that sentence you would have to go study genetics before you would be able to design a realistic genetic system. Having a set color palette of somewhere between 10 and 40 colors that pets can come in, and/or a list of shapes each body part can come in, is my personal favorite approach.

 White L. Brown L. Orange L. Red L. Purple L. Blue L. Green L. Yellow Gray Brown Orange Red Purple Blue Green Yellow Black Dk. Brown Dk. Orange Dk. Red Dk. Purple Dk. Blue Dk. Green Dk. Yellow

The top, middle, or bottom row is determined by a brightness gene which can be A, B, or C. Assuming the system does not have dominance and recessiveness, the inheritance algorithm could look like this:

A + B = 50% A, 50% B
B + C = 50% B, 50% C
A + C = 25% A, 50% B, 25% C

The color inheritance rules would be a bit more complex:

Orange + Red = 50% Orange, 50% Red
OR 25% Orange, 50% Brown, 25% Red
Orange + Purple = 25% Orange, 50% Red, 25% Purple
OR 25% Orange, 25% Red, 25% Brown, 25% Purple
OR 100% Brown
Orange + Blue = 30% Orange, 30% Blue, 10% each other color excluding brown and gray
OR 25% Orange, 50% Gray, 25% Blue
OR 100% Gray
Brown + Brown = 40% Brown, 10% Each other color excluding gray
OR 100% Brown

There are many, many other ways this could be done. For an utterly different but still monoploid genetic system you could google a walkthrough of Plant Tycoon, and there are other walkthroughs and wikis which explain the breeding systems in various games. I just wanted to give an example of what genetic algorithms might look like. Now lets finish up with your features' list entry for this section:

- [For the primary type of pet in your game, which category(ies) do they belong to?]

- [Describe how the pet's functions within game fit primary category.]

- [Describe how the pet's functions within game fit each additional category.]

- [For each additional type of pet, which category(ies) do they belong to?]

- [Describe how the pet's functions within game fit primary category.]

- [Describe how the pet's functions within game fit each additional category.]

- Pets inherit [appearance, stats, both, or skip this section if there is no inheritance]

- [If there is stat inheritance, how does it work?]

- [If there is appearance inheritance, how does it work?]

- [2D bitmap/raster, vector, or 3D]

- [set forms or mix-and-match body parts]

- [set colors per form or body part, standard palette of colors, numerical]

# 11. Tutorials, Quests, Reputation, and Levels

Playing a game is all about having interesting stuff to do within the game. So what exactly do you intend your player to be doing within your game? Game design philosophy is divided into two camps, those who favor sandbox play and those who favor structured play. I prefer structured play, myself, because I like the experience of being given assignments with rewards attached. In my experience structured games do a better job at being fun in the same way a novel or movie is. In a story the main character's goals are what drive the character to strive against their opponents, make progress through the plot, and better themself as a person. Goals create dramatic tension and also help give the player a sense of their role within the social and philosophical context of the story. Not that all structured games have story, but in games without story a structured sequence of goals first helps teach the player how to play and after that continues to guide the player through all of the game's content in a sequence that makes it feel intuitive to tackle each new challenge; sequence also regulates the pacing of the player's experience, helping avoid either long stretches where nothing is new or overwhelming floods of too many new things at once.

Though they are not my personal cup of tea, I'll try to give a fair description of why sandbox fans like that kind of game. Sandbox games are more toy-like than structured games, and their design often takes inspiration from toys like building blocks and Legos, doll houses, train sets, science experiment kits, and the namesake of this kind of game, sandboxes with their associated sand-shaping tools. They are fun in the same way that playing with blocks and dolls is. This type of game is supposed to support the players in choosing goals for themselves and telling stories to themselves. (Whether most existing sandbox games are actually any good at asking the player what goals they choose or giving positive feedback to the player for accomplishing those goals, well...) Sandbox games are compatible with player-created content, which in turn can be a strong part of participating in a game's community. One goal of sandbox game design is enabling emergent gameplay, where the players can use the pieces provided by the game to build more things than the designers ever dreamed of. Sandbox games can potentially provide a more free and realistic experience than the scripted dramatic experience of more structured games.

Tutorials, quests (or achievements), reputation, and levels, while more characteristic of structured games, are all allowed in sandbox games too; it's more about how you use them. Sandbox games pretty much should not have required content and should have limited amounts of sequential content. In a sandbox game tutorial and quests, if present, should not get in the player's face but instead be available as optional activities that can be done whenever the player wants help or feels bored and is looking for an idea for want to do next. Reputation and levels, if present, should also be like optional quests – the player can decide they want to work specifically to earn these because of associated benefits, but it shouldn't prevent the player from playing the game if they are not interested in pursuing these.

In a sandbox game glimpses of impressive future possibilities and initial educational tasks might be presented in a more exploratory manner. If the game has NPCs, it's common to have low level NPCs standing around playing with some of the in-game elements, and high-level NPCs with fancy armor and architecture serving as living examples of what the player might choose to strive for. Talking to them might give the player an option to listen to that NPC explain what they are doing. Of course players of a sandbox game come into the game expecting to explore and experiment; they look at the mouse pointer and GUI options for clues and poke anything that looks interesting in a way other gamers aren't conditioned to do or aren't interested in doing (adventure gamers might be an exception). But still, in many games there are objects that it's just not obvious how you use them. Error messages are a pretty good solution to this. For example, say there are large rocks in your game and the player tries to gather one. This action shouldn't fail silently, or worse insult the player without specifying what they are doing wrong. (Humorous insult error messages can give a game character, but they should be helpful too.) Instead it's important to have helpful messages like, “You need to break this into smaller pieces before you can lift it.” or even more directly, “You bang the hammer on the rock but nothing happens. Maybe if you had a chisel...”

What is a quest or achievement? Level requirement and mission objective are more terms for the same thing. Basically this is a task that you assign to the player. You can present the task through an NPC (including a mascot pet), through a building acting as an NPC (schools are commonly implemented this way), through a found or activated object like a scroll, bulletin board, or obelisk, or through a menu-accessed list. Typically the game maintains a list of all quests the player has accepted or been mandatorily assigned, including the dialogue or written text that the player heard or read when first presented with the quest. This quest tracker may contain additional help, like information about where necessary objects can be found on the map, how many necessary items are currently in the player's inventory, or how many specified tasks have already been done.

Common quest types include:

- Kill X of monster Y
- Kill monsters of type P or Q until they drop X of quest item Z
- Go to location A and talk to NPC B
- Obtain X of item C and give them to NPC D
- Craft X of item E
- Grow X of crop F
- Tend a pet of type G X times
- Own X of pet type H
- Get a score above X on mission/competition I
- Win X missions/competitions
- Perform complicated combo J for the first time

What is reputation? This is when an NPC or faction of NPCs want the player to do tasks for them or tasks they approve of, and the game counts the number of these the player does to determine how friendly the NPC or faction is to the player (and sometimes how hostile an opposing faction or enemy NPC is). In a dating sim the reward for having a strong relationship with an NPC is having that NPC requite your love. In a more platonic situation an NPC who is very friendly may sell you rare items or give you discounts if they own a store, or may allow you to recruit them if it's a tactical game or adventuring-party RPG, or may teach you secret crafting recipes and techniques, not to mention that you may unlock more advanced quests from this NPC. A faction is similar – they often sell special items or discounted items, teach advanced recipes and techniques, and offer advanced quests to a player who earns a high rank within that faction. Faction tabards (outfits), tattoos, and mounts are some of the most popular faction rewards in MMOs, as well as ranks or graphics which decorate the avatar's name.

Levels are something everyone has encountered, but should your game have them? What is their purpose and how do they work? Well, levels measure the amount of time a player has put into a game. (This can get fouled up if you have major gameplay types that don't generate XP, unless this is balanced by them generating more money or other benefits than XP-producing activities.) Some games have separate level systems for different types of gameplay, such that a player might be a level 12 crafter, level 10 fighter, or a level 20 PvP-er, level 17 PvE-er. Levels have a secondary function of helping the player select battles and quests of appropriate difficulty, while still allowing them to select easier ones if they find the game difficult or harder ones if they find the game too easy. Leveling-up commonly rewards the player with an energy/health/mana refill, gives them stat or ability points to spend, and unlocks new quests, abilities, purchasable items, and sometimes new areas of the game or new areas of personal property (for the player's garden/ranch/house/town).

It's common for levels to be quick and easy to earn at the beginning and slower as the game progresses; however one of the most common mistakes online games make is stretching the interval between levels so far that players get bored and frustrated with their inability to advance and stop playing. I instead recommend setting a standard amount of time leveling-up should take starting at around level 20; or in terms of time, gaining a level should never take more than 2 days of intense play or 5 days of casual play (about 10 hours). In an RPG with classes, class balancing also needs to take this into account – if one class takes longer to kill the same monster, that class needs to either need less XP per level or receive more XP (and loot) per monster.

There are two functional ways to hybridize structured gameplay with sandbox gameplay: alternation or blend. Alternation would mean that the player gets to spend time in a sandbox area in between missions or levels. This is common for tactical, RTS, tower defense, and speedpuzzle campaign games. Blending is when structured content and sandbox content exist in parallel; for example the player might have to complete the next quest or mission in a linear progression to advance the plot, but the player can take a break whenever they want to do non-linear sim or minigame activities, which might even give rewards that made it easier for the player to get past a difficult quest or mission. Most MMOs are a blend, which is one of their major differences from singleplayer RPGs, which tend to have few or no sandbox elements. When singleplayer RPGs do have sandbox elements they tend to be minigames, and are usually all locked at the beginning of the game; the player must unlock them one at a time by progressing through the main plot. Well known examples include The Gold Saucer in Final Fantasy 7, Triple Triad in Final Fantasy 8, and fishing, snowboarding, battleship, archery, etc. in the Zelda series. Of the pet-themed singleplayer RPGs I've seen, those that have minigames tend to use them in a structured way instead, as required activities to train the pets, or as contests that only occur at certain times in the plot.

- Gameplay Experience: [Structured, Sandbox, Alternating, or Blended?]

- [Describe how the major activities in this game create this type of experience.]

- [Describe your game's tutorials and how they teach basics]

- [Describe how content near the beginning of your game acts as a teaser/contract with the player.]

- [Describe your game's quests & etc. if any]

- [Describe your game's individual NPC reputation system, if any.]

- [Describe your game's factions and their reputation system, of any.]

- [Describe your game's leveling system, if any, and what type of things it rewards.]

# 12. Combat

Combat is the single broadest area of game design. Some games do not have combat at all, but a large percentage do, and in a large number of varieties. The simplest kind of combat is random combat: flipping a coin, rolling a die, or rock-paper-scissors. This is not satisfying, because even if the player chooses heads or tails (or whatever) that choice doesn't matter. There is no strategy. Even the first generation of primitive games rarely bothered with completely random combat. Instead programmers invented AI, which is programming telling enemies how to react to the player's actions (or changes in their environment). AI is the source of strategic challenge in singleplayer games. That most basic strategy consists of studying enemy AI to be able to predict what you should defend against or how you can manipulate enemies into making themselves vulnerable. (In some cases the player will have one or more AI-controlled ally creatures, which it is also strategically advantageous to be able to predict the behavior of.) Completely predictable AI is also rather boring, because once you solve the initial strategic challenge you don't need to think any more, just repeatedly do what you decided was the most advantageous. So, many AI systems add a moderate amount of randomness to spice things up a bit. This is realistic, because random variation occurs in real life combat (or other activities that AI can direct an NPC unit to participate in) and randomness is certainly easier to add than more complex AI (which wouldn't even have fit in the oldest games due to storage space restrictions on floppy disks and cartridges).

Even today, it is still unknown whether it will ever be possible to create an AI that can simulate realistic human behavior, though some amazing AI programs have been created to accomplish all sorts of goals, from entertaining behavior for robotic toys to word, speech, and face recognition software. Don't be intimidated, though; anyone who knows how to play a game, how to analyze their own behavior, and some basic algebra can design monster AI for a game. It does not require mastery of a programming language to design AI, only to implement that design. The design itself can be done by making a flowchart or a written description of how a unit's decision-making process should work. But, enough about AIs, and back to combat.

The oldest kind of computer game combat is one hit = death (though the player may have multiple lives). This kind of combat originated in text adventure games, but could be seen more recently in many sidescrollers and platformers. The Super Mario series is a well-known example: Mario is traveling toward the right side of the screen, a goomba is traveling left, and whichever one is struck by the other first will die. They don't die simultaneously because they have different vulnerable zones – Mario is vulnerable on his sides, but not beneath him, so he can kill the goomba by landing on top of it. The goomba is vulnerable on its top but not on its sides, so it can kill Mario by walking into him. Of course that's only the most basic situation: Mario may be powered up, and if so the first hit will cause the power-up to fall off instead of instant death. Some monsters are tougher and may need to be hopped on multiple times. A few monsters cannot be killed by hopping on them, but instead must have a turtle shell or other object thrown/slid at them, or a fireball shot at them. The raccoon tail or cape gives him a side attack with a slightly longer range than his vulnerable side area. Etc.

So, as enemies become tougher, it may take several hits to kill them. The monster's toughness is thus called HP (hit points). And then, games where a single mistake kills you tend to be more on the stressful side than the fun side. So we can give the playable avatars and pets HP too, so they won't die from a single hit. It's nice if the player can see how much life they have, so they know when to use health potions or retreat. This is usually shown with a HP meter. There are three standard approaches to visualizing health. The simplest is a bar where the left side represents 0 health and the right side represents maximum health. In some games the maximum health and/or the current health are shown as numbers. The health meter often changes colors from red at low health through yellow or purple at medium health to green or blue at full health. Other color schemes or locations of colors can work too. In some games an injured character has a red nimbus (full-body halo or form-fitting cloud) while a healthy character has a white one, and in other games the whole screen's colors become desaturated (grayed-out) as the character is injured. The second approach is showing health as a clock-shape, where the clock begins filled with color and with a 'hand' pointing upward to 12 o'clock. As the character becomes injured this hand sweeps clockwise, revealing a gray or black of missing health. Again, numbers are optional. The third approach is a heart shape. The heart can either have a vertical meter that shows how full of life the heart is, or can behave like a heart-shaped clock. Horizontal health bars also sometimes include a heart as a graphic indicating that the meter is for health. If numbers are included they are usually written as a fraction: current/max.

Before health meters, landing a direct hit, completely blocking or reflecting a direct hit, and status changes like slowness/quickness, temporary invulnerability, size change, and range decrease/increase were the only things that could happen in combat. The addition of HP enabled DOT (damage over time) attacks and status ailments, such as poison and burn. Not to mention healing (partially or completely refilling an HP meter) and healing over time, commonly known as regen. It also enabled partial blocking and reflecting of damage, and attacks that hurt the user a small amount to hurt the enemy a large amount. Both of these add cost-benefit-analysis strategy to combat, making it more complex and interesting.

Health is far from the only stat playable characters and enemies can have. Magic, energy, and rage are other possible meters that the player might need to manage during combat; in some cases the goal is not to run out, in other cases the goal is not to have too much. Magic, energy, rage, and health are called by a variety of names in different games. There are several other kinds of stats characters and enemies can have which are not typically represented with meters, because they don't go up and down a lot during combat. In turn-based tactical and strategy games these may include action points and movement points, which regenerate at the beginning of each turn and are spent on the character or enemy's actions and movements during that turn. And in RPGs and RPG-influenced genres the character may have long-term stats affected by their equipment, class, stat points that have been spent on that character, and current buffs and debuffs. This group of stats may include defense (armor class), speed (initiative), intelligence, spirit (wisdom), charm (charisma), luck, and stealth.

So from simple platformer combat and turn-based combat the next things that evolved were arcade fighters, which are characterized by the ability of individual moves to add up to combos, and skill cooldowns, which make frequency of use a new factor in combat strategy. Both of these can be found in both turn-based and real-time combat systems. The realtime versions are probably more familiar – cooldowns take the form of a timer, while combos require performing a sequence of actions correctly within a certain time frame without being interrupted by an enemy action or a critical failure. In a turn-based system cooldowns are take the form of a turn number count-down, or more rarely a damage-taken or damage-dealt count-down. Turn-based combos can be executed by two units acting on the same turn (or an enemy and a unit who reflects or counterattacks in response) or they can be executed by one unit taking a set-up action on one turn and then a follow-up action on the next turn.

Another evolution at approximately the same time was the addition of terrain. Technically platformers have terrain, such as spiked ground, slippery surfaces, ground that crumbles when walked on, and underwater areas the playable character must use a different or slower kind of locomotion to travel through. But that's 1D terrain, more or less, and 2D terrain in tactical turn-based combat, strategy combat, FPS, and live-action RPG combat adds more complexity. Distance affects the range of attacks and the speed at which units can pursue or flee each other. In a turn-based game this is usually implemented by giving each unit a number of movement points per turn, while in a real-time game it is usually implemented as a running speed stat. Different kinds of terrain can also give bonuses or penalties to units standing on them or trying to cross. Some terrains types are beneficial to all units or detrimental to all units, while other terrains are sympathetic to some types of units and antagonistic to some types of units (often this is about a unit's elemental affiliation, like fire terrain benefiting fire units and penalizing ice units). Terrains may have obstacles that make them unable to be walked on and may block line-of-sight attacks. Finally, terrain allows for the player to construct fortifications, traps, and other buildings or immobile units, as well as destroy or activate ones which the game has placed there before the beginning of the battle.

So, that's pretty much the whole list of elements that the various modern styles of combat are built out of. Several genres add yet more complexity by blending non-combat elements into combat. RTS games put the infrastructure and workers onto the battlefield where they must be protected from attack. Tactical, RTS, and deck building card game-style combat all may require the player to spend gathered or crafted resources to summon units into play. FPSes and an odd assortment of other games allow avatar(s) to change equipment during combat. Action-adventures may allow adventuring tools to be put to unorthodox use in combat.

What constitutes modern styles of combat? Here is a list. Yes, it's biased. I am deliberately excluding random combat, text-based combat, automated combat, simple turn-based combat as either antiquated or just bad.

- Platformer, Arcade, and Action/Adventure combat: This is a realtime form of combat where the player controls a single unit to perform actions usually bearing some resemblance to martial arts (or things like biting and clawing if the avatar is non-human). Whether armed, unarmed, or able to wield magic in place of/in addition to a weapon, common actions include an upper body attack, a lower body attack, jumping, ducking or rolling, possibly blocking, and possibly a projectile attack or magic attack. Combat takes place in the main/exploring game mode, and the player may end up fighting several enemies at once. During combat the player maneuvers around the screen, trying to place themselves in a position to attack while dodging enemy attacks and also avoiding any holes or other terrain hazards that happen to be present. As with all real-time games, commands must be entered quickly; this limits the avatar's possible actions to a small number of button presses most players can memorize, and limits the amount of strategic thinking the player will have time to do. Some games pause the action to allow the player to select a special action from a menu, but more commonly the player must choose before combat begins which special action(s) to equip to their available button(s) or key(s). Typical features include collision detection, knockback, combos, an obstacle-course-like environment, tool use on both the environment and enemies, and simple status ailments that quickly wear off on their own. Racefighting combat would also go in this category.

- Tactical Turn-based combat: This is a turn-based form of combat where the player controls between one and ten units on a field of terrain. If the player only directly controls one unit they probably can summon AI-controlled allies (e.g. pets) instead. As with all turn-based combat this is slow-paced, and instead of being about adrenaline and resources it is about strategic complexity. Generally the player gets a budget of a set number of movement and action points per unit per turn and each unit has its own stats and set of equipment; in singleplayer versions units may be able to access the player's inventory of consumable items, while in multiplayer games item-use may be unavailable during combat. Combats take place in a limited area with a limited population of enemies, and eliminating all enemies concludes the combat. Common actions include movement across the terrain, ranged attacks which require line of sight, area effect or splash-damage attacks, setting traps, summoning units onto the battlefield, and units healing or buffing team members. Deck building card game combat is a variant of this which usually substitutes some kind of zones and/or creature types for terrain. For example, the player's hand may be one zone and the player's deck another zone, while flying creatures may be assumed to be in a hypothetical sky and non-flying creatures are on the ground.

- Shooter/FPS: This is a realtime form of combat where the player controls only their own avatar, who is generally not visible except as their gun barrel or crosshairs. Common actions consist mainly of sneaking/making use of cover, shooting enemies and picking up found items such as different guns, ammo, and healing items. The emphasis is on reflexes and skill (also luck) rather than stats. Kill combos may be possible (e.g. 3 blue enemies in a row).

- MMORPG: This is a realtime form of combat where the player controls their own avatar, possibly accompanied by 1-3 AI-controlled pets; if there are AI-controlled pets either they or the avatar take a tank role while the other takes a DPS and healing role. Combat takes place in the main world, and it's common for two or more players to fight the same enemy. Enemies are anchored to small territories, which usually prevents more than two enemies from attacking the same player, and enemies will 'leash' back to this territory if the player flees. Enemy AI is usually less complex than in a tactical/strategic system; this is a side effect of class balancing more than a result of the simplicity required of all realtime combat. Typical features include timed skill cooldowns, aggro (enemies preferentially attack whichever unit they are the most mad at), a party system with automatic or configurable loot division, spellbars, a basic attack that repeats automatically, classes with different combat styles and equipment (this is not necessarily a GOOD feature), and player-alterable stats/purchasable skills.

- [Combat Type]

- [Are enemies visible before combat begins, and is combat in the main game mode or its own separate mode? What non-combat activities, such as resource gathering and constructing buildings, can or must be done during combat?]

- [What unit(s) is the player controlling in the fight and what can the player do with them, including movement and types of attacks?]

- [Are there AI allies of some kind?]

- [What attributes do units have? Equipment, an equipped/learned subset of available abilities, what types of stats from HP to AP and Movement/Speed, or elemental attributes, and are these stats player-alterable...?]

- [What is the battlefield like and in what ways can it effect combat?]

- [Can items be used in combat, and if so, how?]

- [What is the typical number of enemies fought at once, as well as the minimum and maximum number?]

- [Are enemies typically different in stats or other capabilities from player-controlled units?]

- [What is typical enemy behavior and common variants on that?]

- [What are the typical rewards of combat?]

# 13. Minigames, Puzzles, And Other Combat Alternatives

While combat is the main activity of many games, other games do not have combat at all, or alternate combat with some other major activity. Changing-up the player's experience by alternating two major activities is done with the goal that the player doesn't get bored as fast. The entertainment value of any activity will last longer if a player only does it occasionally than if they do it for several hours straight. Non-combat possibilities for a major activity of a game include:

- Gathering and Crafting (Covered in an earlier section)
- Tending and Babysitting (Growing Plants, Raising Pets, Lemmings, Sims)
- Dexterity and Timing Games (Racing, Fishing, Dance Dance Revolution, Guitar Hero)
- Speedpuzzles, Physics Puzzles, Adventure Game Puzzles, and Solitaires (Card Solitaire, Mahjongg, Memory, Tetris, Match-3, Angry Birds, and adventure-game-style puzzles)

Tending and babysitting are relatively simple. Each unit that needs to be tended has either a predetermined schedule of needs, a table of percentages from which randomized needs are generated, or a timer that determines how often a new need is generated. For example, in a turn-based sim where each player action is one turn or one action is allowed per pet/plant per turn, then each pet/plant which has had a need satisfied on one turn will display a new need the next turn. 'Need' is a loose term, it could include a “ready to compete” state or a “ready to be milked/sheared” state where the pet 'needs' to put out effort instead of taking in effort. If pets/plants age, age is typically determined by number of turns; some systems only count turns the pet/plant is interacted with, other systems count all turns, and some only count until the pet/plant reaches adulthood or until it reaches old age. Pets/plants which have age stages typically have different needs per stage.

In a realtime tending and babysitting game pets typically generate needs based on a timer (or they may not generate needs but instead walk across the playing field toward dangers). The pet/plant may have pre-set need requirements, or may have meters (e.g. happiness, hunger, health...) which fall over time until the player raises them by filling a need. If a need falls too low the pet/plant may run away or die. The same thing happens if a wandering pet encounters a hazard, like walking off a cliff or into spikes. The player's actions are scored either when the pet/plant changes age states or when the round of play ends. The pet/plant or round may have specific requirements or simply a required number of points. There may be multiple sets of requirements, which give the player different verdicts: failure/lowest possible stats/worst type into which the pet can mature, normal success/average stats/average type of pet, gold star success (achievement) /high stats/best type of pet.

Dexterity and timing games range from the very simple to the very elaborate. Occasionally they are too simple to actually be fun – one of the most pathetic excuses for a minigame I've seen, and seen more than once, is a cursor that bounces back and forth between two ends of a meter and you have to try to stop it as close to the meter as possible. This kind of dynamic can work fine as part of a larger game, such as pulling the plunger back in a pinball game or casting a fishing rod, but it just doesn't work as a game by itself. Now fishing on the other hand, there's a nice simple example of a minigame. Or at least it can be nice, when done well. There are several timing and dexterity elements involved – the fish's movement in the water (if it's the kind where you can see the fish before you cast), the force and direction of the cast, yanking the rod promptly after the fish strikes, and possibly angling the rod to counteract the fish's sideways pull or alternately reeling the fish in when it's not resisting and letting out more line if it resists a lot and the line tension gets too high.

Arrows-on-tracks games, such as DDR and Guitar Hero, are another simple, popular kind of timing game. They evolved from conveyor-belt speedpuzzle games like the classic arcade puzzle game Klax. You can see the arrows traveling toward you, so you can try to get ready for them, then you have to push the corresponding key or button when they get to you. In some versions all arrows travel at the same speed, in other versions different tracks can travel at different speeds. Sometimes there is an extra, rarely-used button that works differently (space bar or whammy bar) This kind of game typically has combos, like an arcade fighting game or rogue MMO combat. It's also pretty similar to pinball, oddly enough – they are scored in a very similar way, and pinball also requires using the paddles promptly when the ball gets to them, though pinball has physics sim elements that arrows-on-tracks games don't. Breakout is another similar game, it just adds some puzzle-elements to the paddle-and-ball dexterity challenge of a pinball game.

Racing and related games where you do acrobatic flying, show jumping, agility, jousting, skateboarding/snowboarding/stunt biking, slalom, &etc. are at the complex end of the spectrum of timing and dexterity games. Racing can be simple, such as a hurdle race where the avatar runs straight forward at a set pace and the player's only input is when to jump. But the complexities that can be added on top of that are what really bring the magic to this genre. Endurance meters, the ability to raise or lower the basic running/flying speed, a sprint ability that drains the meter extra-fast, curvy tracks which make jockeying for position and controlling speed important, an assortment of obstacles to jump over or duck under, and stars/balloons/bonus items to collect as a goal the player must balance their goal to get to the end as fast as possible, are all typical features of this genre.

Speedpuzzles are kind of a hybrid between timing/dexterity games and puzzles, but I think they fall more on the puzzle side of the line because many of these games have some levels/missions judged on speed but others judged on efficiency or accomplishing a specific goal; some also let you choose whether to play in a timed mode or a zen/relaxed mode. Speedpuzzles are usually about a stream of falling pieces or a screen full of pieces that you move to make patterns (3 or more in a row, 4 in a square, a complete row across the screen). The completed patterns vanish, and new pieces appear to take their place, often rearranging the other pieces in the process so you can get bonus cascades.

A minor variant on the pattern-making speedpuzzle is the shooter speedpuzzle, e.g. Frozen Bubble and Zuma. In this kind of game the patterns are created by shooting additional pieces at the constantly or periodically increasing mass of pieces in the level which will overflow (a loss condition) if the player is not quick enough to trim the back.

A completely different type of speedpuzzle is the time management game. In this kind of game you control a single worker you have to run around the screen as fast and efficiently as possible. The difference between this and a realtime babysitting game is that instead of taking care of emoting units, you are usually doing chores and interacting with machines; you set the schedule instead of simply reacting to the schedules set by the units. Combatless strategy speedpuzzles are related; these games focus on the infrastructure building part of a strategy game, and the goal is to gather resources and build up your infrastructure as quickly and efficiently as possible. Both of these games are crafting-like in that your mission objectives can easily take the form of a recipe, e.g., “Produce 5 tomatoes, 2 jugs of milk, and 1 chicken.” or “Produce 10 gold, 2 emeralds, and 2 diamonds.” It's easy to imagine these being crafted into a meal and a piece of jewelry, whether the game explicitly states that this is what they are intended for or not.

The physics puzzle genre has recently been popularized by Angry Birds and World Of Goo (one casual, one not), but this kind of game has actually been around a long time. These combine shooting or placing objects with the mouse where they will most disrupt the environment with destructible environments where falling pieces can contribute to (or block) completing the level's puzzle objectives. Magnets, mirrors and lasers, ropes and pulleys, weights and balloons, fire and explosives, electricity and lightbulbs, balls and ramps, and all sorts or rotating and revolving things are traditional elements in physics puzzles.

Adventure game puzzles typically consist of a set of objects which can be arranged into various positions or states, or interacted with in various orders. Usually there is only one correct pattern of positions, states, or orders that solves the puzzle. There is usually no time limit, and the puzzle is free and easy to reset/reattempt. This is because the player is intended to take multiple attempts to solve the puzzles, otherwise they are too easy. Adventure game puzzles should be exploratory – the player should toy with the objects and use deductive and inductive reasoning to figure out the rules by which the objects operate. Adventure game puzzles range from simple mazes, jigsaws, sliding block puzzles, and sudokus, through more complex puzzles like hopping games (peg solitaire, towers of hanoi, solitaire mancala), pushing blocks around obstacles and into holes, flipping/rotating pieces to align them, rearranging weights or volumes to balance them, or flipping switches and rotating pieces to complete a circuit. There is some overlap with physics puzzles, but those are more freeform while adventure game puzzles are generally more structured.

Solitaires are probably familiar to everyone; they consist of a standard set of pieces (such as a deck of cards or set of mahjongg tiles) laid out in a randomized order, and the player tries to eliminate or otherwise resolve the whole set by making moves within the rules of the game. The main distinguishing trait of this kind of game is that unlike other puzzles it is not scored only by perfect completion, but instead it can be scored by degree of completion, which makes it more useful for gambling systems than other puzzles.

Finally, there are many games where combat and puzzles are blended together. Puzzle-like combat is especially common in action adventure, tower defense, and strategy games. (Tower defense games are those where enemies advance toward your base, trying to destroy it, while your units can't move once placed because they are either passive defenses like moats, walls, and caltrops, or automatic defenses like sniper towers and other kinds of gun emplacements. Plants vs. Zombies is the closest thing I have seen to a pet tower defense game, because the plants in that game are animalistic and pet-like.) Strategy games commonly have mission objectives which the player must 'puzzle out' how to accomplish, often through multiple attempts. These mission objectives involve defending an area long enough to build or repair a specific building, taking a foozle or civilian to a target, or running a gauntlet without being able to build up your normal infrastructure. Action-adventure games use adventure style puzzles, minigames where play branches internally and you replay the game until you find the right branch to get a treasure, and bosses which aren't vulnerable to normal attacks or are only vulnerable at certain times.

- [Tending and babysitting, if the game includes this type of activity]

- [What is tended/babysat, how does this activity work?]

- [If there are multiple activities of this type within the game, describe each additional one.]

- [Dexterity and timing, if the game includes this type of activity]

- [What kind of dexterity/timing activity is it, how does it work?]

- [If there are multiple activities of this type within the game, describe each additional one.]

- [Puzzles, if the game includes this type of activity]

- [What kind of puzzle is it, how does it work?]

- [If there are multiple activities of this type within the game, describe each additional one.]

# 14. GUIs and Controls, Game Modes and Context-Sensitive Behavior

GUI stands for graphical user interface. Borders, icons, menu bars, mouse cursors, font(s), the title screen, the credit screen(s), the help/about screen(s), trading and shop interfaces, pop-up menus, tool tips, any backgrounds which are solid colors or gradients rather than artwork, etc. all make up a game's GUI. There are programming toolkits and libraries available to help implement standard GUI elements, but first they need to be designed. This is a tricky type of design because it's half usability and half art. As such, GUI design is a field related to web design and graphic design. Consult your statement of purpose to review what art style and theme/tone you wanted your game to have; the GUI must be consistent with these. For example, you probably don't want to use smiley-faces as indicators of high durability on armor in a horror game.

Controls are the way the player uses an input device to tell the game what they want to do. Each button/key or directional input is a control. The GUI and the control scheme are inevitably related, because if you are making a mouse-driven game then you need to have mouse-friendly controls. If you want the game to be dual mouse/keyboard then it's really helpful to label the mouse-click-able buttons with the keyboard shortcuts that will activate them, or if it's pure keyboard then you need to have a 'cheat sheet' of all the keyboard shortcuts or some other reference the player can consult to learn them. Gamepad controls also require a different GUI – they have fewer buttons than a keyboard, are awkward to use to drive a mouse pointer, but work really well with a cursor that slides or rotates through menu options, and that menu can be completely invisible when the player doesn't need it instead of taking up screen space with a clickable button. Some games even use microphones, cameras, gyroscopes, toys with gamepad buttons built in, and other gamepad-substitutes like dancepads and steering wheels.

Game modes are strongly related to both GUIs and controls. A game mode is situation within the game – account/character creation mode, exploration mode, battle mode, puzzle mode, inventory mode, and a particular minigame's mode(s) are examples of these kind of situations. Each game mode has unique GUI and control needs. Thus each game mode needs a version of the GUI tailored to it, and the controls need to be context sensitive, which means the same button or mouse click can do different things in different situations within the game. It is called remapping the controls when your game assigns different functions to each button/key/whatever when the player enters a different mode within the game.

I haven't really mentioned concept art design in this document yet, so here's a crash course of the steps involved:

1. Make a list of needed features – (Yo dawg, I heard you liked making features lists so I put a features-list-making step in your features list.) Specifically you need to make a list of your different game modes, what information and actions need to be immediately visible to the player in each, what information and actions are necessary but less urgent and should be accessible by a menu, and what controls the player should be using in that mode, including how they access any menus and how they exit that mode.

2. Get source images – Google Image Search is one of the most incredibly useful things on the internet. Make one or more folders on your computer and save copies of anything relevant. You do not own the rights to these images so you can't copy them directly, but looking at them for reference is fair game. That's what a source image is. What are you searching for source images of? GUIs of other games and random art related to your chosen theme and tone. If possible, identify 1-3 example games, animes/cartoons, or similar which have a very similar theme and tone to the one you want your game to have; google those as well as terms for your theme and tone.

3. Make mock-ups (concept art) – You can doodle on paper or use your graphics program of choice, but either way you need to make pictures of what your different game modes, including their GUIs, might look like. If possible, use the proportions you want your game to have on the player's screen. Don't just make one concept; after you make your first attempt try to clear your mind and do something different, then do that again.

4. Revise, Consult, Revise – Look at the different attempts side-by-side, see if there's any way to get something better still by combining part A of attempt 1 with part B of attempt 2. Now, it's almost inevitable that this kind of mock-up is missing something. Many, many, student architects have designed a house with no bathrooms, for example. So even if you are your game's main artist I don't recommend putting your GUI concepts right into development without getting some kind of second opinion. If you have to wait until a later point in your development process to have someone you can ask, then wait. When you make your final revision after getting some input, then your job here is done, unless the required features change or playtesting turns up a problem later. If your document format can include images, add your concept images to an appendix.

- [Input devices you want your game to use, such as mouse, keyboard, and/or gamepad]

- [List game mode(s) with the primary control scheme]

- [Describe the control scheme, both info displayed to the player and input giveable by the player.]

- [List each group of game modes with an additional control scheme]

- [Describe the control scheme, ditto.]

# X. End: An overview of the game development process and how the design document is used during this process.

1. Revise – Theoretically you now have the first two parts of a game design document: a statement of purpose and a features list. Look them over for any inconsistencies or missing information and fix that if you can, or mark it (I use bright red text) as something that needs to be fixed when you can figure out how.

2. Prioritize – Look through your features list and separate it into Core features that you absolutely must have, and Non-Core features that you like but will not start to implement until the core features are done. You can also re-arrange topics within the features list if you think they are more logical or useful in a different order. For example, perhaps the GUI and game modes section should be near the beginning instead of near the end.

4. Revise Appendices – Review your appendices – is there stray stuff in there that should be filed into appropriate places in the features list? Are there any things you know you'll need an appendix for that you don't yet have one for? (E.g. list of locations, list of NPCs, list of weapons, list of armor, list of enemy types, list of crafting resources, list of crafting recipes, list of quests...) Make more appendices for those. Rearrange the appendices until they seem to be in the most logical order.

5. Brainstorm – Go through one feature at a time, then each appendix; for each one, add any other useful and relevant information you can think of. The goal is to get the document as complete as you can make it without outside help, before looking for that outside help.

6. Research – If there is some feature you are interested in but don't have much experience with as a player, research what games have that feature. Read about how the feature works in those games, and consider playing one or a few to experience how the feature works. You may do this part first or multiple times if you like.

7. Copyedit – If you have really long or confusing sentences, improve them. If you have really long paragraphs or no paragraphs, cut up your wall of text into more manageable chunks. Spellcheck. Beware of homophones and use of apostrophes. Have you used consistent formatting for headings and lists? The goal of this step is to make your document as readable and polished as possible before showing it to others.

8. Seek Feedback – The kind of feedback you need will differ depending on what role you intend to play in your game's development, and how complete you've managed to get your design document. You may prefer to recruit a co-designer who will add a lot of their own thoughts to the design document before beginning development. Or you may want to hire a consultant, paying them to sign an NDA and give you all the suggestions they can come up with for your design without becoming a part of your team or having any rights to future income from the game. Or you may want to describe either the general outline of your game or a specific problematic area on a public forum to get volunteer feedback. Or you may want to begin development immediately, either by your own efforts or by recruiting or hiring a skilled programmer or artist.

9. Development – Whoever is the most experienced programmer involved with the project will need to use this design document to make a programming plan: Name the languages, libraries, engine, database, etc. to be used, break the core features into proposed code objects, and plan how those code objects will communicate with each other. Whoever is in charge of the story should make sure enough of it has been created to guide the artist(s) in producing art assets appropriate to the story. Whoever has the most experience with GUI design and/or art will need to set standards for the still images, animated sprites, and/or 3D models and textures the game requires, and use this design document to make checklists of all the art assets that need to be created. As pieces of the game are completed you can mark them as completed within the design document, for example by turning the text relevant to them blue or green.

Now, alas, you have reached the end of the help I can give you. If anyone thinks of a topic I have missed or forgotten here, please let me know in a comment. Otherwise, good luck and happy game designing! ^_^

# Article Update Log

28 Mar 2013: First draft; added "Design is just another word for plan: a game designer plans out a game." to section 0. OMG why are the headings such a horrible shade of orange?! But eh, it's a passible first draft now. Wtf, is it in the programming category? I didn't see a box to choose the category T_T Somebody put it in design please.
03 April 2013 Yay the category is finally right. Thank yous to both Michael Tanczos and Gaiiden for sorting this out!

Mare Kuntz aka sunandshadow is the moderator of GameDev's Writing For Games forum. She has been involved with indie game design for more than a dozen years.

Amazing, I've been searching for information like this for ages

Shame i haven't got time to read more than the first chapter atm. One thing I personally think might help, is could you link to a GDD? I personally have never seen a proper one I know there was a link floating around here a year or so ago.

The only GDD I have laying around that actually belongs to me is the unfinished one from the Xenallure project.  (Single-player RPG with a branching interactive story and some dating-sim and other-sim elements.)  Note, this is a download link, unless you have a view-online plugin for .doc files. http://home.comcast.net/~wickeddelite/XenallureDesignDoc.doc

The thing with finished design documents is, they look utterly different depending on the game's genre.  If you follow through this guide you will have a GDD customized to your game idea.  But if you want a relevant example you pretty much have to search for GDDs specific to your genre, with Google, or maybe over at Gamasutra.  Also in the past people here have linked to some nice examples in the Design forum.

Had a quick skim through it last night and decided to print it off so I could work through it. From what I have read, it is quite detailed and well organised. I will let you know how I get on with it.

Thank you very much for sharing this in depth information

Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.

PARTNERS