This article is intended for beginning and intermediate game designers. It will walk you through the process of creating a design document, including making a features list, identifying your genre(s), brainstorming each feature, doing research, and using your design document in the game development process. This assumes the reader wants to make a pet-themed game and all the examples are pet-related, but it should be easy for the reader to apply the instructions to their preferred game theme. This article was originally posted at the Virtual Pet List forums, and also in my developer journal Designing: The Game And Its Content as Guide To Designing A Pet Game, Parts 0-15. I was asked to reformat it as an article, so here it is.
This document, created by Mare Kuntz (sunandshadow) in 2012, is a free, public guide to making a design document for a pet-themed game, including example pet game design document sections intended for reuse in readers' own game design documents. A design document is not the only way to develop a game; some people favor the alternate method called agile development. But, this document is aimed mainly at people who have little design and development experience, and IMO agile development works better for more experienced people, or for people who are more interested in learning than in making a specific game. I am providing this document as a community service and releasing it to the public domain. It is freely usable by anyone for both noncommercial and commercial purposes. For example, an indie game developer could use this as the basis for a design document for their own pet game. Or anyone doing a school project or teaching a class where they needed an example design document could use this. I would enjoy hearing from people who find this document useful (sunandshadow@excite.com), but you are not required to notify me if you make use of it. I am available as a consultant for game-design-related projects, but I do charge for that kind of service.
A game design document is a written description of proposed game. In this guide I am assuming you, the reader, want to create a game. This makes you the game designer. (Or a co-designer if you want to team up with someone who will also contribute ideas.) Design is just another word for plan: a game designer plans out a game. In order to create a game you must decide what kind of game you want to create. I am also assuming you are going to outsource some or all of the programming and art of your game to other people. The main purpose of a game design document is to paint a clear picture of a proposed game. The document describes what game parts (otherwise known as features) will be in the game, and how they will fit together. The process of creating a document helps a designer clarify their creative vision for a game and make sure there aren't any inconsistent or missing pieces. The finished document is a record of all the design decisions that have been made. It can be given to others, in whole or in part, as a quick clear way of communicating the designer's vision. It can also be used as a checklist to track which pieces of code, art, and other assets have been created, until everything is checked off and the game is done!
What? So, what is actually in a game design document? A game design document usually includes:
Why? What good is a game design document? How do you use it to help develop your game? As soon as you write a feature description it becomes useful because you can refer back to it when designing a related feature, so you don't forget what you decided. An in-progress design document is like a journal, but more organized because you will be showing it to other people as well as referring back to it yourself. If you are in a team, the design document serves as a record of what has been firmly decided and should not be squabbled over or changed without an important reason. The design document can also be a fast way to orient a new team member to what is going on.
Most importantly, when you have finished writing your design document the feature descriptions you have written are used as a guideline in the development process when programming a feature, creating graphics or sound files for that feature, and playtesting that feature. How? When hiring a programmer or an artist the design document is both a checklist of all the tasks that need to be done to make the game, as well as a source of bite-size "assignments" that your employee(s) can do one at a time. You can do this by copying and pasting from your design document in to an email or forum post to a team member or employee, or by simply showing them your whole design document. The same applies to tasks you are going to do yourself – if you get around to creating something a month after you initially designed it, re-reading what you wrote reminds you exactly what you decided to do and why.
A game design document is also helpful as an organizational tool for your whole development process; it can be used as a plan you can then follow step-by-step to develop your game. You can even check off within the game design document which tasks have already been completed by you and others. As these parts of the game are created, they form the alpha version of your game! And finally, material from a design document's statement of purpose and story section are often reused when creating promotional materials or a webpage for a game project or completed game, while material from the appendixes is often reused in item flavor text, NPC dialogue, and other places throughout the game.
How? Okay, so how do you make a game design document? You follow this guide! I will describe the various genres of pet game so you can identify which one you want to make. I will describe the various features commonly found in each genre so you will have a starting list of features your game should have. Because this document is public domain (copyright-free) you are welcome to copy and paste as much of it as you can use directly into your own design document. You can also modify it however you want if you want features different than described here. When there are two or three alternative versions of a feature I will try to describe the differences between them and which is better in what context, so you can pick which version you want to use, or you can use this as background knowledge when designing your own version of a feature. You will still need to create some of the material yourself, such as your statement of purpose, your story, names of characters and places, and all the parts where your own creativity is the essential ingredient. But following this guide should be much faster and easier than creating your own design document from scratch, and hopefully the list of example features I'll describe here will make the guide flexible enough to help people design a wide variety of games.
The first thing to realize is that there are different genres (kinds) of pet games, which have different feature sets. It's very helpful to any game designer to have played a variety of games so they remember experiencing a variety of features and can pick from that “mental toolbox” which features they want their own game to have. If you have only ever played one kind of pet game, you would have difficulty trying to make anything other than that same type of pet game. If you want to make that kind of game, that's fine, though background knowledge of a variety of games would help you avoid designing a game that's just a rehash of something that already exists. So, I encourage all designers to play a variety of games, the same way writers should read a variety of fiction and artists should look at a variety of art. But it's ok if you already have a specific type of pet game in mind because you want to make a game similar to your favorite, or combining features of two or three of your favorites. It's also ok if you just know that you want to make a pet game, but not know exactly what kind yet. Figuring out which kind you want your game to be is the first step in creating your own game design document!
There are different kinds of genres. “Pet Game” is itself a genre, specifically a theme or motif genre. Fantasy, science-fiction, and sports are also theme genres. There are art genres, like 2D vs. 3D and anime style vs. western comic style. There are story genres, like horror games and romance games. Then there are gameplay genres, which is what people usually mean when they talk about genre: RPGs (role playing games), sims (simulations), MMOs (massively multiplayer online games), and others less commonly seen in the realm of pet games, such as adventure games, FPSes (first person shooters), and RTSes (real-time strategy games). The overall point of this section is for you to start writing your design document by listing what genres of different kinds apply to your game. The idea is that a person can pick up your game design document and in the first few sentences you will give them a concise and clear description of your proposed game.
Specifically you are going to fill in the blanks in this sentence: “[NameOfGame] will be a [2D or 3D or ?D] [optionally name the art style, e.g. anime] [singleplayer or multiplayer] [VPS/RPG/SIM/etc.] game where the player has [a small number or a large number] of [type of pet if you know it already] which which they do [combat or other main activity of the game].” Sorry if that looks confusing. Once you plug all the information in it will look like something sane, e.g. “Sunandshadow's Fish Game will be a 2D realistic-art singleplayer RPG/sim where the player has many fish which they use to battle and capture more fish, breed in a fishtank, and craft into fishscale armor, weapons, and potions.” Or, “Sunandshadow's Dragonrider Game will be a 2D anime singleplayer interactive story game where the player has 6 dragons they can attempt to befriend and partner with in dragonrider training class until one of the dragons agrees to permanently bond with the player and accept him/her as their rider.” Or “Sunandshadow's Virtual Pet Site will be a 3D Spore-style multiplayer VPS where the player starts with one pet of the most basic type and, using it to explore and breed, collects all possible pet variants.”
The Name Of The Game
You might happen to have a name in mind already; if so, cool. If you don't have an idea for your game's name yet, that's also fine. This section is not about brainstorming an awesome title which elegantly expresses the project's identity and grabs the attention of the project's target audience. Actually, names are often changed as a creative project develops, and are often one of the last things to be decided. It's almost impossible to think of a great name at the beginning, when you don't fully know yet what the project will be. No, what we want here is a functional working title. Something simple and handy you can use to name the file, discuss the project with others, and later use a search and replace to automatically put the game's real name in all the right places. I recommend something like Jane's Pet Game or Dragon Breeder Game or Pokemon Clone. So just pick something and fill in that first blank. Also, create a new document, name it Jane's Pet Game Design Document or whatever, then copy and paste that bolded sentence into it so you can fill in the blanks there. Unless you prefer to use a pen and paper, that's fine too.
What Are You Doing With Those Pets?
Pet games (or pet monster games, monster capturing games, monster breeding games, livestock ranching games, horse riding games, etc.) are characterized by the player's enthusiasm for some kind of creature. They don't have to be literally animals, but instead anything that can be presented as animal-like, including plants, robots, alien creatures, magical beings, or virtual creatures. Pet games could be divided into those where the player interacts a lot with one or a small number of creatures vs. where the player collects or breeds a large number of creatures, selling unneeded ones, or even slaughtering livestock to harvest crafting resources. Which of those are you more interested in creating? Approaching the question from a different angle, pet games could be divided into games where the pets' main role in the game is combat-related vs. those where it is something other than combat. Does one of these two types sound more like what you want to make? When you combine these you get four of the most common kinds of pet games:
Is one of those what you want to make? If not, here are a few less common options, and of course it is possible to mix and match:
2D vs. 3D
Art type is a challenging topic in game development because it is 1/3 personal preference, 1/3 dependent on what resources you have available because artists and game engines alike tend to only be good with one kind of art of the other, and 1/3 functionality because while some gameplay works fine with both approaches, a few kinds of gameplay work much better with one or the other. Since those thirds are like apples, oranges, and, plums, it's quite difficult to balance them against each other if they conflict. All you can do is try to figure out if some factors are more relevant than others. For example if you, the designer, really hate one of the two styles and don't want to put time and effort into developing a game that will have that type of art, that probably overrules any other issues. Or if you intend to be the primary artist and are only good at one of the two types, or you intend to be the primary programmer and already own a license for a game engine that is focused on one of the two types, that's also a strong argument for which you should go with. Or, if you have a strong idea of some gameplay you want your game to have which is incompatible with one of the two types, that's another strong argument. It's convenient to the development process to decide early which type of art a game will use, but if you really are stuck between the two options it can be postponed until more data is available to reevaluate the choice. There are also a few less common options like 2 ½ D that you might want to research if the two straightforward options aren't working for you. Fortunately the question of art style (as in things like realism, anime, western comic, gothic...) is a simpler issue because it has basically no functional difference, just personal taste and what your available artists have experience with.
Singleplayer vs. Multiplayer
Two main categories of computer games are online multiplayer games, and offline singleplayer games. The big difference between these two types is that in singleplayer games the game's primary activity is always something the player does against computer-generated opponents, whether these are monsters or something more abstract like a time limit. In multiplayer games, on the other hand, competition against other players or cooperation with other players is a significant part of the game (even though the majority of the player's time within the game may still be spent of single-player activities). A few games have a limited online component, such as phone and Facebook apps where the only things the player can do online are buy cash shop items and send presents to neighbors; these have mainly singleplayer gameplay so I will include them in the singleplayer category. Do you know whether you want to make a multiplayer or singleplayer game?
Virtual Pet Sites – Pet Sites are characterized by having their primary multiplayer activities include forum posting and trading items or pets with other players. Some VPS games include a breeding system, and if they do it is commonly possible to use other players' pets as breeding stock. Some games encourage the player to collect pets or other collectibles. Some VPS games include a minigame arcade; if they do this is typically the main source of player income within the game, and players may compete for high scores at the games. Some VPSes include a clothing system, either for pets or human avatars. VPSes are the pet-themed version of social gaming sites, which are usually built around a forum with a customizable avatar and clothing system. This system is intended to facilitate player socialization by allowing players to present a carefully-chosen visual representation of themselves to others, and regularly update this visual representation to reflect holidays and other social events.
Minigame Arcades – Minigames are games which take a short time to play. They consist mainly of speedpuzzle games (Tetris, Frozenbubble, Pouyopouyo), solitaires (cards, Mahjongg, Minesweeper, Hangman, boardgames against a computer opponent), and arcade games (beat-'em-ups, shoot-'em-ups, bullet hells, pinball). In many some cases it is possible but rare to win; in other cases it is impossible to win, instead the player is scored on how long they survived or how many targets they shot or bonuses they collected before losing. A minigame does not have to have a forum or other social component; sometimes they are purely ad-supported and have no cash shop or membership. If a minigame arcade is combined with a social forum such as VPS the arcade is usually the method by which players can earn a daily income of game currency to spend on pets, clothing, or similar items. Minigames may not be terribly memorable or artistic, but they are convenient from a site maintainer's perspective because if one breaks or is disliked by player it is not related to the others and doesn't spoil the players' enjoyment of them. Arcades are also easy to expand by adding new minigames, as opposed to larger games where new content must be integrated and balanced with existing content.
PvP Pet Competition Games – PvP (player vs. player) games are those where the main multiplayer activity is dueling other players; possibly in combat but non-violent activities like racing, show jumping, agility, dressage, or beauty contests are also popular. One of the main goals is to earn a high rank in the competitive league of all players. Another goal may be to have the highest personal score on a particular course compared to your friends or other players who attempted that course during the current week or month. These games come in two flavors, fast-paced for those who crave adrenaline, and slow-paced for those who prefer strategy and patient persistence. The fast-paced kind has a main activity of driving the pet at high speeds while avoiding obstacles with quick reflexes (Or more rarely, fast-paced RTS combat between the armies belonging to two players.) The slow-paced kind is a sim or RPG where the main activity is increasing pet stats through training, breeding, or interacting repeatedly with an individual pet; in these slower-paced PvP games the competitive activity is either automated or turn-based instead of real-time. Both flavors of PvP game may have a singleplayer campaign or series of quests which teach the player how to play and may allow the player to earn higher levels and increased stats for individual pets or for the player's infrastructure. (Infrastructure is the property, tools, and abilities the player uses to produce competing animals: their ranch or other property, appliances and outbuildings for storing and breeding pets, training pets, or crafting useful items, their ability to breed higher-potential or rare baby pets, and their ability to modify pets.)
MMORPGs – MMOs are games where hundreds or thousands of people interact within an explorable virtual world. Whether the game uses 2D or 3D graphics the key element is that friends can, in realtime, see each other doing stuff within the world. RPGs are fighting-focused games where the fighting is strongly effected by stats; the main activity of the game is increasing these stats through leveling up and getting better gear. Progress through the game is typically guided by NPCs (non-player characters) offering quests, but the player is usually free to wander anywhere they don't immediately get killed by higher-level monsters. The most common type of combat is realtime involving spellbars and cooldowns, but many other types of combat are compatible with this type of game, from simple turn-based to turn-based tactical to realtime 3/4 overhead to realtime sidescroller/arcade/platformer, and even racing combat where racers can attack each other during the race. Please see the combat section for more details. Some MMOs are almost completely focused on PvE (player vs. Environment, where environment usually = monsters) combat. Normal difficulty monsters are found by single players or pairs of players in the main game world, while instanced dungeons are populated with elite (high-difficulty) monsters and bosses that require teams players to work together. Other MMOs have a focus on PvP, whether between individuals or in teams of 5 or more. Singleplayer PvP involves dueling other players for personal gain; group PvP can be simple team duels where the last player alive determines which team wins, or can be a more complicated activity of territorial capture by either NPC factions that players join or player-created clans/guilds. However PvP is structured, each player earns a PvP rank by their performance, and improving this rank is a goal and a source of pride. Both PvE and PvP are the main source of player income in games featuring them.
FPSes – I have not actually seen a pet-themed FPS, so I'll speculate on what one might be like. One possibility is that different pets might correspond to different types of guns, or perhaps biological armored suits that happen to include guns, or animal forms the player could shapeshift into which would happen to include distance attacks. The player would have the ability to bond with (or equip) one animal at a time, and which animal was equipped could affect range, firing speed, power, special effects like poison or freeze rays, and maybe things not directly related to shooting like the player's size, running speed, armor, healing speed, max health, jumping ability, etc. There are single-player FPSes, usually those are very similar to either an RPG or a fast-paced PvE racing game. Multiplayer FPS games are more different from MMOs and fast-paced PvP competition games because of the emphasis on short, intense interactions between 4-12 people and their environment (because the environment typically contains weapons, ammo, and healing items that the players have to scrabble for while avoiding being shot). Some FPS games have battle royale rules, meaning all players are against each other and the last one alive wins. Other FPS games have team play, often inspired by capture the flag, with death being a temporary setback from which players respawn until other one team or the other captures the flag (or destroys the other team's base, or whatever the specific goal is).
RTSes – Real-time Strategy Games typically have BOTH a singleplayer campaign and a multiplayer system for allowing 2-4 players to duel. The closest an RTS gets to a pet game is probably where the units are all creatures, and the buildings are either also creatures or are designed to feed or breed creatures. SimAnt is a fairly clear example, while the Zerg race in Starcraft may require a bit of squinting to see as an army of the player's pets. RTSes are all about building up infrastructure and climbing a tech tree, as described in the entry on sims. But in an RTS the play has to do it as fast as possible while being attacked by enemies, and the goal of PvP duels and most singleplayer missions is to exterminate the enemy from the map. Sims on the other hand are generally slower-paced, and instead of extermination sims are usually about becoming the best pet-breeder or similar profession, and earning a lot of money this way.
RPGs – Single-player RPGs typically lack the focus on character appearance customization that MMORPGs often have. Instead single-player RPGs come in two flavors: J and W. J stands for Japanese and W for Western, but that was a historical division that is no longer accurate. These days both types of RPG can be made anywhere. Instead it's best to think of jRPGs as those which have a strong story and pre-created characters and quests, while wRPGs are those in which the player creates the playable characters and the game can generate semi-randomized quests, maps, and/or NPCs to make the game extensible and replayable. In jRPGs the player's progress through the game's story and world is regulated mainly by quests and puzzles which must be solved to unlock the player's ability to move to a new physical are of the game. In wRPGs the game is usually less linear, with the player free to wander anywhere they can stay alive. Both games have a focus on 1-10 playable characters and their use in combat, which can come in all the varieties listed under MMORPG. Singleplayer RPGs by definition cannot have PvP, so all play is PvE, unless the game has limited multiplayer functionality which allows dueling outside the main context of the game. But the main activity of the game is fighting monsters and bosses. The overall goal of this activity is to become the best fighter in the world and beat the biggest bad guy in the world.
PvE Pet Competition Games – These are singleplayer versions of PvP Pet Competition Games. As with singleplayer versions of strategy games, singleplayer competition games are often organized in the form of a campaign, a sequence of increasingly complex and difficult competitions which will eventually result in becoming the world-wide winner of whatever the particular competitive activity is. Like the PvP version the PvE version is split into fast-paced activities like racing and flying games and slow-paced activities like pet shows of the beauty contest variety. This genre is the one that most commonly tends to be confused about whether it is a game or a toy, though VPSes and sims may also suffer from this confusion. This causes problems both during development and for players of the finished game. See the entry below about Virtual Toys for info about avoiding this mistake.
Babysitting Game or Time Management Game – Other pet games often include a babysitting segment for raising young pets or breeding pets. Babysitting games can also be minigames. Technically they are a hybrid between a speedpuzzle game and a sim. A time management game is the non-combat version of an RTS, though in most time management games you control one unit rather than an army of units. What happens in a babysitting game is that the pets have happiness, health, cleanliness, sleepiness, or similar gauges. And these meters will get lower until the pet is very unhappy or dies, if the player does not intervene. Either the player can select the pet to see all of its gauges, or the pet will emote any need that crosses into the danger zone, or both. Emoting can be done by an emoticon symbolizing the pet's need appearing above their head in a thought or speech bubble, or it can be done by the pet's facial expression and/or body language changing to express their need, along with other visual effects like “stink lines” rising off a dirty pet. In some cases pets do not have health gauges; Lemmings is a classic example. The pets move of their own volition and often encounter fatal obstacles. The player must use some pets to solve the level's puzzle while keeping enough pets alive to lead them through the final gate to safety and satisfy the level's victory condition. When babysitting is the main activity of a standalone game the game is typically organized into a campaign, and each level of mission has a time limit. Time management games have a similar dynamic where the player runs around as fast as they can trying to fulfill a variety of needs. These goal of the game is not to maintain happiness though, it's probably to grow, breed, or craft something which can be sold for money, as in a Tycoon game.
Sims and Tycoons – Some Pet Competition games and RPGs overlap with sims, in that they can all include breeding, collecting, and training pets, and amassing wealth, levels, and/or stats and special abilities tied to level. Sims and RPGs may also both include crafting and building up an infrastructure by climbing a tech tree. Where RPGs have an overall goal of becoming the best fighter in the world, sims and tycoons usually replace this with a goal of becoming the best farmer or breeder or collector or crafter in the world. As the player gains experience they usually unlock new resources and special abilities related to this profession. Tycoons are a subgenre of sims; there's no real difference between the two except that tycoons have more of an emphasis on making money via selling the results of your sim-labor, while non-tycoon sims sometimes don't even have a currency system. Sim games usually have tech trees. A tech tree is a structure where the player puts effort into unlocking or mastering low level abilities, which are prerequisites to unlocking or mastering higher level abilities. For more details see the crafting section below.
Adventure Games and Interactive Story Games – Adventure and interactive story are actually two different genres, I'm just combining them here because they are so often seen together. Both of them typically lack combat, though they can be hybridized with a kind of game that has combat (for example the Zelda series are action-adventure hybrids). Both of them are typically singleplayer because, like sim gameplay, puzzle-solving gameplay is very difficult to make multiplayer without interfering with what makes it fun. The difference between these two genres is: Adventure games have physical puzzles that the player solves by flipping switches, turning knobs, sliding things along tracks, using pipes to move fluids around, igniting fires, and that sort of thing. Interactive story games mostly involve talking to other NPCs in a form of interaction called a dialogue puzzle, where the player can choose from a list of options what to say or do, and the choice made affects how the NPC decides to act, which in turn sends the plot of the game in one of a few different directions. In fact an interactive story game as a whole can be seen as one big puzzle where the player tries to carry out the right steps in the right order to get the best possible ending; many interactive story games expect the player to play through the game more than once the same way adventure games expect the player to need to restart puzzles if their first attempt at solving the puzzle turns out to be the wrong strategy. So both genres are about solving puzzles, the difference is just whether the puzzle pieces are physical objects or people. And it's common for games to have puzzle pieces of both types, thus making the game a combination of the two genres. Where do pets come in? Well, pets can be puzzle pieces, such as in a game about herding sheep through mazes. Animal-forms or summons can be puzzle solving techniques, such as a game where the player changes into a spider or summons a spider to weave a giant spiderweb that acts as a net to solve a puzzle, or the player changes into a bull or summons a bull to push a heavy object that they otherwise couldn't move. Or the player could be responsible for a space ark full of animal characters and have to matchmake between the animals so they are ready to produce lots of baby animals when they land on their target alien planet. There are all sorts of ways a game could be about solving complex puzzles involving animals.
Virtual Toys – Virtual Toys resemble games, but they generally have no goals or victory conditions. “Pet games” which are actually toys include the software portions of Tamagotchis, Furbys, and HexBugs, as well as various desktop pets and virtual fishtanks/fishponds. In the realm of non-pet games, Minecraft is the most notable example of a virtual toy in the past few years, though it has grown more game-like features (such as deadly monsters) since it was first created as a virtual lego-like toy. As a designer it's important to be aware of whether you want to make a game or a toy, since players who expect one will be disappointed if they get the other. Games and toys are both fun but not really in the same way, and software which has half game features and half toy features can be confusing and frustrating to the player – in other words, they can fail to be either kind of fun.
A game is a piece of multimedia entertainment where the writing has to work as a partner with the gameplay (which is programming underneath) and the art. Well, not all games have stories, and virtual toys may have story but don't have goals. But this section is aimed at games that have a medium or high amount of story.
The word in the section heading that it's most likely readers will be confused by is theme. So let's talk about theme first. Above, we've talked about games which are focused on combat or competition, exploring at a relaxed pace or being super-efficient, solving puzzles or building up a small empire. I've mentioned that games also come in flavors like funny, cute, scary, magical, high-tech, and many others. All of these are theme, though they don't get at the heart of theme. Theme is the statement your game makes about what the (game) world is like and what the player's role is within that world. Who the player should be and what they should do to be declared the winner of (virtual) life. All forms of fiction, including games, are interpreted by the player's or reader's brain as life experience from which they may learn something about the real world and real life. This is why fiction is referred to as “the lie which tells a truth”.
The details are all made up, but characters act in ways that express truths of human nature, because they are based on the author's experience of themselves and others. The characters must behave in ways the audience finds psychologically and sociologically plausible, otherwise the characters will feel fake and the audience won't be able to suspend their disbelief and get immersed in that piece of fiction. Similarly, fictional worlds, though they can have magic or gameplay conventions that don't match the real world, are based on the creator's experience of the world. They must behave like something in the real world, though it's common to substitute something simpler for something too complicated, random, or slow to be quick fun. For example growing plants in a game is usually much faster and less prone to random disasters than growing plants in real life. And a difficult skill like picking a lock with several tumblers may be substituted for with a simpler locking mechanism like a sliding block puzzle. Fictional worlds must be internally consistent so that players feel satisfied because they are learning to master an interesting new environment, and don't feel like the game is “cheating” or “AI stupid”.
(AI stupid refers to a game being unable to recognize what the player is trying to do or refusing to accept a solution that seems logical and realistic from the player's point of view but the game has not been programmed to understand. For example, say a player must combine a string and a stick in their inventory to make a bow. If using the string on the stick works correctly but using the stick on the string results in an error, that's a classic example of AI stupidity.)
What kinds of themes do games commonly express? A game where the player spends all their time fighting, for example, can't help but promote the idea that the way one wins at life is by being the best warrior. Most of us aren't fighters in real life but the message still comes across that traits which are important to winning fights, like toughness, are important to cultivate in oneself. Also that the problems we encounter in life can be thought of as battles, with enemies we ought to attack and vanquish. An adventure game which has puzzles instead of combat has totally different messages: awareness of one's surroundings, creativity in using tools, and manipulative finesse when dealing with other people are connected with success, while straightforwardly attacking an enemy with a weapon as unsophisticated as a sword seems unlikely to work and unwise. Strategy games are about using one's intelligence and awareness of surroundings to directly and forcefully overwhelm an opponent. A time management game where you have to be efficient and fast to survive can make you reflect that you should be acting more industrious and efficient in your real life, and avoid activities that are inefficient or not obviously productive.
Now, games and stories are not about preaching or brainwashing and don't have a strong effect on most people's beliefs. Usually audiences already have their own beliefs about what kind of role they want to play in what kind of world, and will seek out games that deliver a message they are already familiar with because everyone likes some positive reinforcement, and wants to hear more stories of kinds they already know they enjoy hearing. So as a designer the idea isn't really to say what you think people ought to hear, but instead to analyze the games whose stories you love, and why you love them, and how you can create a game world and cast of characters who will be as much fun for your players. As an added bonus you and your team members will be more motivated on writing bits of story and creating pieces of art to illustrate fun ideas.
So, a simple way to get started brainstorming story ideas for your game is to make a list of game stories you have really enjoyed. Novels, anime, movies, and folktales are all good source material too. Who would you want to be in a game, that your players might enjoy being in your game? What kind of game world would you like to spend time in, that your players might also enjoy spending time in? Since this is a pet game, and you've already decided whether you want one or many pets to be used in a combat or non-combat situation, let's get more specific about that! What should they look like and how would you enjoy interacting with these creatures? No need to limit yourself to story ideas if any gameplay ideas are occurring to you too. Scribble all your ideas down, because it's much easier to work with ideas you can see in front of you than ones floating nebulously around in your head.
If you already have a strong idea of what kind of experience you want your game to be for your players, you can cross out things you like but aren't compatible with this particular project. You can always use them in another project in the future! For example, I think breeding systems are awesome, but a breeding system doesn't fit very well with a game where you want the player to only own and use one or a few pets. So if I wanted to make a game which was about a player bonding with one pet, I'd save my elaborate breeding system ideas for a different game design. Or, if I wanted to make a game about the player as an individual becoming the best warrior ever, I would consider making the player a shapeshifter or animal who fights opponents alone, instead of a human who fights with pet companions. And if there are any other player-controlled animals in the game they could be the civilians who make up the player's home base, the pack/herd/flock the player fights to protect and helps to grow by bringing home the spoils of victory.
I can't talk about every possible case here, or even go into detail about different brainstorming techniques. You can use whatever techniques work for you. I personally like starting with a list of everything that occurs to me, then crossing off irrelevant things, adding new relevant ones, grouping these things into compatible clumps, ordering those clumps in order from ones I like most to ones I like least, then trying to the best or second-best and combine the best parts of the others into it, so that I end up with one big clump of compatible ideas that contains most of my favorites. But some people love mind-mapping/webbing/bubble diagrams, and some people like to analyze 1-3 examples of similar games in detail rather than pull ideas from many sources, and some people prefer to do their brainstorming in a conversation with one or more other people... there are lots of ways to brainstorm that work for different people, or the same person at different times. But the end goal here is to add a description of your game's playable character, world, and thematic appeal to your statement of purpose.
Here's another fill-in-the-blank for you: “The player will control/be [number and type of playable character(s)] who will be [profession] who [game's main activity such as fighting, questing, solving puzzles, or crafting] in the [description of game world] world of [world's name]. [Other important activities] will also allow the player to satisfy their urges to [explore/become wealthy and famous/play mad scientist/help someone/be clever/build something/investigate a mystery/save the world/etc.].” And some examples: “The player will be a witch or wizard who learns the craft of brewing complex potions to create unique pet monsters in the dark fantasy world of Monsturbia. Exploring the world to find ingredients provides a peaceful break between frantic potions-brewing sessions where the player must exhibit the speed and efficiency that will enable him/her to become the world's master monster-brewer, showered with wealth and fame.” Or, “The player, represented by an alpha wolf, will control him/herself and up to 7 subordinate wolves at a time in tactical combat, fighting his/her way from the humble beginning of the darkest forest of Wulfmoon to its capital city populated with the other most ambitious wolfpacks of the world. Combat alone can't get the player to the throne; only solving the puzzles in the ancient ruins of Paw's Mark, Broken Fang, and other such locations(dungeons) will allow the alpha to gain the wisdom and spiritual strength necessary to carry out the hero's true task: saving the world of Wulfmoon from itself.” Or, “The player will control the team of Wordy the Parrot and Arch the Cat as they bumble their way through a series of zany adventures, not-so-willingly helping the other animal denizens of Abcedaria solve their problems. Wordy and Arch must help each other navigate over obstacles and through mazes, as well as maze-like arguments with their stubborn neighbors. Even if this odd pair succeeds at bringing peace to their village, will they ever be able to stop arguing with each other?”
Thinking about selling a game before any of it has been programmed may feel like getting ahead of yourself. However, the intended sales method affects the design, and plans for earning and dividing income affect recruitment of other team members. Non-profit and/or opensource games also have legal differences with regard to what resources you can use to make the game or how large of a fee you have to pay to use them.
Distribution used to be more of an issue, but these days most indie games are sold entirely online and there's no need to worry about printing CDs, packaging them, and getting them to brick-and-mortar stores. If physical sales happen for an indie game at all they usually happen through a distributor who is already selling the game online, or instead of the game itself the distributor may sell cash cards and you may sign an agreement to add your game to the stable of games that the cash card works with. If you want to sell physical spin-off items like keychains, t-shirts, stuffed animals, etc. you can either do that yourself or you can do it through an online merchant that prints these items on demand and sells similar items for many games, comics, and other fandoms; they probably get cheaper bulk shipping rates than would be available to you.
Online distribution involves either providing downloads of the game, providing a server for the player to play the game on, or both. These services are available through different kinds of distributors, such as appstores and other online game distributors, social networking sites, and server farms; it's also possible to build a server room full of machines yourself, provided you can get a location with access to professional quality internet.
There are three main ways of getting payment from players: selling a game outright (optionally after giving the player a free trial), charging a monthly subscription fee (again there is often a free trial first), or making the whole game f2p (free to play) and instead earning income through a cash shop and/or ad revenue. For a singleplayer game, the one-time sale is the standard model, except for apps. Apps are applications for smartphones or devices like ipads, where the game is sold through an appstore which can be assumed to already have a billing account set up for the device owner. (Account set-up is a traditional hurdle for all online sales because people may decide they don't want a game badly enough to fill out a form and give their credit-card number to a company they aren't familiar with. Thus, avoiding the need to create an account can result in more sales.) Apps can use a traditional one-time sales model, or they can be freemium (free or ad-supported except for premium content) and can use a cash shop to sell the premium content (including the ability to remove in-game ads) even though the game otherwise has few or no online features. Ad-removal can also be sold as a subscription, often this is an annual subscription instead of a monthly one.
For an online multiplayer game the choice is usually whether to go with a cash shop or a subscription. Cash shops are generally more popular with younger (i.e. credit-card-less) and casual players (don't spend enough hours per week playing to feel that they could make full use of a subscription), while subscriptions are more popular with hardcore players (subscriptions can limit beggars and spammers, and more importantly ensure that the game is fair to all players, not pay-to-win).
So, how is the sales method relevant to design? For starters, if your game is going to have a free trial, you need to figure out what the limiting factor(s) of that trial will be, and how to notify the player when they are encountering one of these limits so they aren't confused by why they can't do something, without spamming them silly with constant notifications.
If you intend to have a cash shop you need to design items to sell in it. Items that won't be available within the game for normal currency, items that everyone playing the game wants, but that don't make the game so obnoxious for those who don't buy them that they quit. Cash shop item sales come from three overlapping categories: Consumables, Conveniences, and Customizations.
Consumables include things like energy refills, timer accelerators, and buff scrolls, especially ones of double XP or death penalty prevention. Many of these are also conveniences. Some MMOs also require a consumable “megaphone” to be spent to speak in the world chat channel. Conveniences include anything that spares the player time, deaths and other losses, or annoyance: a permanent inventory expansion, a version of an item that usually requires 30 or more levels to equip that is instead equippable by a level 1, packs of crafting ingredients, and mounts or mount upgrades that increase traveling speed. Mounts (and limited or premium pets) are also a major category of customization, along with clothing, dye, special haircuts, and other visual effects from fireworks and petal showers to neon username frames. And again, many of those are consumables.
So the point is, if you intend to have a cash shop you have to create lacks in your game, which the player can remedy with time and/or work, or can immediately fix with a cash item, and you also have to consider how cash shop pets fit into your breeding system, and what percent of your cool hair and clothing designs should be cash vs. what percent should be quest rewards or cost game currency. It's also ideal to get players used to using the cash shop by giving them a small amount of cash currency and a few quests to buy or use cash items.
If you have a subscription system you need to have some kind of scheduler to remind people to renew before their subscription runs out. Longer subscriptions often come with bonus items, and a method to transfer these to the player's account and, if the account has more than one character, a method to let the player choose what character to receive the item on.
And on top of all that, you need to know how much money you are willing to spend on developing your game, and you need to keep track of money you spend toward developing the game so you can know later when (if) the game breaks even by earning that money back. If you are promising team members future revenues from the game, you need to have a plan for how that will work, and if that payment will end after a certain amount of money or time. If you are paying team members up front you are probably going to need a paypal account. And if you are selling your game, cash items, or any spin-off merchandise up front you are going to need a merchant account to accept credit card transactions.
You should now add a sentence about how your game will be sold and distributed to your statement of purpose. If you intend to recruit a volunteer team you may want to specify whether the game will be for profit but wait and get their input on which specific sales method to use. If you plan to make a kickstarter or similar crowd-sourcing call for funds there are extensive how-tos on that topic by people who have a lot more experience with that than me. “I, [YourName], am putting up [X$] as a budget for developing this game. [If you plan to ask other people to donate money, who and how?] The priority for what to spend this budget on will be [1st, 2nd, if any is left]. [If you are planning to offer shares or royalties, how will that work or when will you decide how that will work? Will some go to monthly webhosting bills or other game maintenance? Will some go to paying back investors, including you?] The game will earn money through [cash shop, subscription, flat sale, ad revenue, and/or spin-off merchandise sale].” If you have any ideas for specific cash-shop items or a kickstarter plan, put them in an appendix for later.
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.
Online games typically have a more complex registration system than single-player games. (The major exception is ad-supported minigame archives, which typically have optional registration or no registration, since they do not need billing information for users.) Usually the player will have to state their birthday or that they are over the minimum age your game or a specific server of your game allows. Many games also require an email address. Optionally a game may allow one player to create several characters or locations, each of which needs their own name; in this case the player's name may either be used only by the forum and billing system, or may not be used within the game at all. Online games typically store most of the game's data in database entries. A player's true identity within the game may be their account number, with the player's username being only one of several pieces of data in the database entry for that account number. In some cases a game may be part of a larger network where the player already has an account, from which the game will import some of the player's data, and possibly share the player's achievements within the game back to that network. Typically a player is required to read the game's terms of service during the registration phase if they were not already required to do so during an installation phase. Many people don't actually read those things, so it can be helpful to also present the few major rules of the game in big red letters as part of the registration process.
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
- [Gameplay Genre(s)]
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]
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.
Time to add to your features list again:
- [Inventories]
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.]
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.
Direct exchange requires one player to click on the other's avatar or name. Some games limit direct exchange to those in the player's friends list, though I don't personally see the point of this. I suspect the idea is to discourage trade-scamming, but I don't think it actually works. Double approval is when both players add money and/or items to their side of the trade, commit to what they have put, then once both players have committed to their side, both must give their approval to finalize the trade. It's common for players to use their side of a trade to display a range of items they have available for sale, and even to show off items they have no intention of trading. For these uses it's important that they player not accidentally give away the items they are just showing. It's also common for players to add items and money to their sides in stages as they continue to chat and negotiate the trade, so it's good to allow this, and not make the trade window auto-close if the players are taking a while or the money portion be unable to handle simple addition and subtraction. Some trading interfaces include a mini 4-function calculator. The disadvantage of this type of trade is that it requires both people to be online, and some versions require the players to be standing next to each other. Also there is no way to automate offering the same trade to multiple people.
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.]
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]
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!
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.
Example color palette spreadsheet:
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?]
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 more structured game, tutorials aren't just about explaining how the game works to the player – they are also the first impression the game makes on the player, and everyone knows how important first impressions are. In the realm of fiction-writing people always talk about hooks and contracts with the reader; these things apply just as much if you substitute 'player' for 'reader'. A reader will start reading a book or a player playing a game because something external to the book/game has caught their attention – it may be that an acquaintance is playing the game, or a reviewer has reviewed the game, or the book/game has attractive cover art and a title that suggests the content is something the reader/player would enjoy. Once the audience gives the book/game that first minute of their attention, that's where the hook comes into play. The book/game needs to give the reader/player a feel for why its world is an interesting one to spend time in, give the reader/player a glimpse at some impressive things they could accomplish if they play a while, and then immediately give the player a task that gives them a taste of the gameplay and how that gameplay is interesting and satisfying. This taste of the gameplay is the contract with the reader(player). The rest of the game should be relatively consistent with this sample so the player doesn't feel like they've been the victim of a bait-and-switch.
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?]
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]
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]
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]
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.
3. Format – Copy your features list and paste it into your document, so you now have two. Remove all but the headings from one. If any of the headings seem confusing, clarify them. Congrats you just made a table of contents. Depending on what kind of word processor or other program you are using to make your game design document, you can go through and make each table of contents entry hyperlink to the appropriate feature.
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! ^_^
03 April 2013 Yay the category is finally right. Thank yous to both Michael Tanczos and Gaiiden for sorting this out!
Original Author's Note
This document, created by Mare Kuntz (sunandshadow) in 2012, is a free, public guide to making a design document for a pet-themed game, including example pet game design document sections intended for reuse in readers' own game design documents. A design document is not the only way to develop a game; some people favor the alternate method called agile development. But, this document is aimed mainly at people who have little design and development experience, and IMO agile development works better for more experienced people, or for people who are more interested in learning than in making a specific game. I am providing this document as a community service and releasing it to the public domain. It is freely usable by anyone for both noncommercial and commercial purposes. For example, an indie game developer could use this as the basis for a design document for their own pet game. Or anyone doing a school project or teaching a class where they needed an example design document could use this. I would enjoy hearing from people who find this document useful (sunandshadow@excite.com), but you are not required to notify me if you make use of it. I am available as a consultant for game-design-related projects, but I do charge for that kind of service.
Table Of Contents
0. Introduction: What is a game design document, why should you make one, and how do you use this guide to make one?
1. Genres: What kind of pet games are there, how are they different from each other?
2. Theme: Story, Setting, Playable Character(s), And How These Should Interrelate With Gameplay.
3. Distribution and Monetization: Getting the game to the player and the player's money to you.
4. Player Registration and Account Creation, Data Storage Within The Game
5. Avatar Creation: Human vs. Pet, Clothing Systems, The Avatar's Role(s) Within The Game, Avatar Equipment Slots, Stats, and Abilities.
6. Inventory Systems: Types Of Items And How Each Type Functions Within The Game, How The User Interacts With Storage, Storage Limitations And Expansion As Gameplay.
7. Gathering and Crafting: Climbing the Tech Tree, Recipes, Skills, Building Up Infrastructure, and Crafting Gameplay.
8. Trading, Shops and the Marketplace
9. Forums, Messaging, Chatting
10. Pets In More Detail: Functionality Within The Game, Capturing, Breeding and Genetic Systems
11. Tutorials, Quests, Reputation, and Levels
12. Combat
13. Minigames, Puzzles, And Other Combat Alternatives
14. GUIs and Controls, Game Modes and Context-Sensitive Behavior
X. Finale: An overview of the game development process and how the design document is used during this process.
0. Introduction: Game Design Document – What? Why? How?
A game design document is a written description of proposed game. In this guide I am assuming you, the reader, want to create a game. This makes you the game designer. (Or a co-designer if you want to team up with someone who will also contribute ideas.) Design is just another word for plan: a game designer plans out a game. In order to create a game you must decide what kind of game you want to create. I am also assuming you are going to outsource some or all of the programming and art of your game to other people. The main purpose of a game design document is to paint a clear picture of a proposed game. The document describes what game parts (otherwise known as features) will be in the game, and how they will fit together. The process of creating a document helps a designer clarify their creative vision for a game and make sure there aren't any inconsistent or missing pieces. The finished document is a record of all the design decisions that have been made. It can be given to others, in whole or in part, as a quick clear way of communicating the designer's vision. It can also be used as a checklist to track which pieces of code, art, and other assets have been created, until everything is checked off and the game is done!
What? So, what is actually in a game design document? A game design document usually includes:
1. A statement of the designer (you) or design team's purpose that they want the game to accomplish. You can write this as a serious statement of philosophy if you really want to, but it doesn't have to be anything complicated; instead you can just say "This game will be awesomely fun to play because..." Optionally you can mention a favorite game that you want yours to be similar to, or what genre it will be, or what type of player will really like it. Typically this part will be 1-3 paragraphs long.
2. A list of features you want the game to have (this does double duty as your table of contents).
3. A description of each feature (these are the sections listed in the table of contents, the "meat" of your design document).
4. Appendixes listing all the characters, location, items, puzzles, monsters, etc. needed to complete the game. (These lists are often added later, after the main design document is done. So really there are only 3 main parts – nice and simple. But, if, in the middle of making your design document, you happen to decide something like: "There are going to be six classes of pets in my game: Sun, Moon, Star, Shadow, Plaid, and Rutabaga." then an appendix is where you file that kind of information so you know where to find it later.)
Why? What good is a game design document? How do you use it to help develop your game? As soon as you write a feature description it becomes useful because you can refer back to it when designing a related feature, so you don't forget what you decided. An in-progress design document is like a journal, but more organized because you will be showing it to other people as well as referring back to it yourself. If you are in a team, the design document serves as a record of what has been firmly decided and should not be squabbled over or changed without an important reason. The design document can also be a fast way to orient a new team member to what is going on.
Most importantly, when you have finished writing your design document the feature descriptions you have written are used as a guideline in the development process when programming a feature, creating graphics or sound files for that feature, and playtesting that feature. How? When hiring a programmer or an artist the design document is both a checklist of all the tasks that need to be done to make the game, as well as a source of bite-size "assignments" that your employee(s) can do one at a time. You can do this by copying and pasting from your design document in to an email or forum post to a team member or employee, or by simply showing them your whole design document. The same applies to tasks you are going to do yourself – if you get around to creating something a month after you initially designed it, re-reading what you wrote reminds you exactly what you decided to do and why.
A game design document is also helpful as an organizational tool for your whole development process; it can be used as a plan you can then follow step-by-step to develop your game. You can even check off within the game design document which tasks have already been completed by you and others. As these parts of the game are created, they form the alpha version of your game! And finally, material from a design document's statement of purpose and story section are often reused when creating promotional materials or a webpage for a game project or completed game, while material from the appendixes is often reused in item flavor text, NPC dialogue, and other places throughout the game.
How? Okay, so how do you make a game design document? You follow this guide! I will describe the various genres of pet game so you can identify which one you want to make. I will describe the various features commonly found in each genre so you will have a starting list of features your game should have. Because this document is public domain (copyright-free) you are welcome to copy and paste as much of it as you can use directly into your own design document. You can also modify it however you want if you want features different than described here. When there are two or three alternative versions of a feature I will try to describe the differences between them and which is better in what context, so you can pick which version you want to use, or you can use this as background knowledge when designing your own version of a feature. You will still need to create some of the material yourself, such as your statement of purpose, your story, names of characters and places, and all the parts where your own creativity is the essential ingredient. But following this guide should be much faster and easier than creating your own design document from scratch, and hopefully the list of example features I'll describe here will make the guide flexible enough to help people design a wide variety of games.
1. Pet Game Genres: What Is Your Game's Primary Activity And Overall Goal?
The first thing to realize is that there are different genres (kinds) of pet games, which have different feature sets. It's very helpful to any game designer to have played a variety of games so they remember experiencing a variety of features and can pick from that “mental toolbox” which features they want their own game to have. If you have only ever played one kind of pet game, you would have difficulty trying to make anything other than that same type of pet game. If you want to make that kind of game, that's fine, though background knowledge of a variety of games would help you avoid designing a game that's just a rehash of something that already exists. So, I encourage all designers to play a variety of games, the same way writers should read a variety of fiction and artists should look at a variety of art. But it's ok if you already have a specific type of pet game in mind because you want to make a game similar to your favorite, or combining features of two or three of your favorites. It's also ok if you just know that you want to make a pet game, but not know exactly what kind yet. Figuring out which kind you want your game to be is the first step in creating your own game design document!
There are different kinds of genres. “Pet Game” is itself a genre, specifically a theme or motif genre. Fantasy, science-fiction, and sports are also theme genres. There are art genres, like 2D vs. 3D and anime style vs. western comic style. There are story genres, like horror games and romance games. Then there are gameplay genres, which is what people usually mean when they talk about genre: RPGs (role playing games), sims (simulations), MMOs (massively multiplayer online games), and others less commonly seen in the realm of pet games, such as adventure games, FPSes (first person shooters), and RTSes (real-time strategy games). The overall point of this section is for you to start writing your design document by listing what genres of different kinds apply to your game. The idea is that a person can pick up your game design document and in the first few sentences you will give them a concise and clear description of your proposed game.
Specifically you are going to fill in the blanks in this sentence: “[NameOfGame] will be a [2D or 3D or ?D] [optionally name the art style, e.g. anime] [singleplayer or multiplayer] [VPS/RPG/SIM/etc.] game where the player has [a small number or a large number] of [type of pet if you know it already] which which they do [combat or other main activity of the game].” Sorry if that looks confusing. Once you plug all the information in it will look like something sane, e.g. “Sunandshadow's Fish Game will be a 2D realistic-art singleplayer RPG/sim where the player has many fish which they use to battle and capture more fish, breed in a fishtank, and craft into fishscale armor, weapons, and potions.” Or, “Sunandshadow's Dragonrider Game will be a 2D anime singleplayer interactive story game where the player has 6 dragons they can attempt to befriend and partner with in dragonrider training class until one of the dragons agrees to permanently bond with the player and accept him/her as their rider.” Or “Sunandshadow's Virtual Pet Site will be a 3D Spore-style multiplayer VPS where the player starts with one pet of the most basic type and, using it to explore and breed, collects all possible pet variants.”
The Name Of The Game
You might happen to have a name in mind already; if so, cool. If you don't have an idea for your game's name yet, that's also fine. This section is not about brainstorming an awesome title which elegantly expresses the project's identity and grabs the attention of the project's target audience. Actually, names are often changed as a creative project develops, and are often one of the last things to be decided. It's almost impossible to think of a great name at the beginning, when you don't fully know yet what the project will be. No, what we want here is a functional working title. Something simple and handy you can use to name the file, discuss the project with others, and later use a search and replace to automatically put the game's real name in all the right places. I recommend something like Jane's Pet Game or Dragon Breeder Game or Pokemon Clone. So just pick something and fill in that first blank. Also, create a new document, name it Jane's Pet Game Design Document or whatever, then copy and paste that bolded sentence into it so you can fill in the blanks there. Unless you prefer to use a pen and paper, that's fine too.
What Are You Doing With Those Pets?
Pet games (or pet monster games, monster capturing games, monster breeding games, livestock ranching games, horse riding games, etc.) are characterized by the player's enthusiasm for some kind of creature. They don't have to be literally animals, but instead anything that can be presented as animal-like, including plants, robots, alien creatures, magical beings, or virtual creatures. Pet games could be divided into those where the player interacts a lot with one or a small number of creatures vs. where the player collects or breeds a large number of creatures, selling unneeded ones, or even slaughtering livestock to harvest crafting resources. Which of those are you more interested in creating? Approaching the question from a different angle, pet games could be divided into games where the pets' main role in the game is combat-related vs. those where it is something other than combat. Does one of these two types sound more like what you want to make? When you combine these you get four of the most common kinds of pet games:
1. A game where you own one or a few companion pets (or you are an animal or small group of animals) and you fight alongside or through them.
2. A game where you fight to build up a collection of pets which become your army or workforce (units in your combat squad, cards in a deck, or part of your home base producing stuff for you).
3. A game where you care for one or a few pets and compete with them.
4. A game where you have a farm or ranch where you raise many pets to sell, compete with, or build up to a complete collection.
Is one of those what you want to make? If not, here are a few less common options, and of course it is possible to mix and match:
5. An interactive story game where you talk to creature-characters, trying to befriend them or solve problems related to them.
6. A game where each pet is a challenge because they need to be healed or tamed before they can be passed on to a permanent owner.
7. A babysitting game where you must take care of the needs of several pets as fast as you can to keep them happy.
8. A world simulation where you experimentally create creatures and see how they survive in the wild.
9. Add your own!
2D vs. 3D
Art type is a challenging topic in game development because it is 1/3 personal preference, 1/3 dependent on what resources you have available because artists and game engines alike tend to only be good with one kind of art of the other, and 1/3 functionality because while some gameplay works fine with both approaches, a few kinds of gameplay work much better with one or the other. Since those thirds are like apples, oranges, and, plums, it's quite difficult to balance them against each other if they conflict. All you can do is try to figure out if some factors are more relevant than others. For example if you, the designer, really hate one of the two styles and don't want to put time and effort into developing a game that will have that type of art, that probably overrules any other issues. Or if you intend to be the primary artist and are only good at one of the two types, or you intend to be the primary programmer and already own a license for a game engine that is focused on one of the two types, that's also a strong argument for which you should go with. Or, if you have a strong idea of some gameplay you want your game to have which is incompatible with one of the two types, that's another strong argument. It's convenient to the development process to decide early which type of art a game will use, but if you really are stuck between the two options it can be postponed until more data is available to reevaluate the choice. There are also a few less common options like 2 ½ D that you might want to research if the two straightforward options aren't working for you. Fortunately the question of art style (as in things like realism, anime, western comic, gothic...) is a simpler issue because it has basically no functional difference, just personal taste and what your available artists have experience with.
Singleplayer vs. Multiplayer
Two main categories of computer games are online multiplayer games, and offline singleplayer games. The big difference between these two types is that in singleplayer games the game's primary activity is always something the player does against computer-generated opponents, whether these are monsters or something more abstract like a time limit. In multiplayer games, on the other hand, competition against other players or cooperation with other players is a significant part of the game (even though the majority of the player's time within the game may still be spent of single-player activities). A few games have a limited online component, such as phone and Facebook apps where the only things the player can do online are buy cash shop items and send presents to neighbors; these have mainly singleplayer gameplay so I will include them in the singleplayer category. Do you know whether you want to make a multiplayer or singleplayer game?
Multiplayer Game Genres:
Virtual Pet Sites – Pet Sites are characterized by having their primary multiplayer activities include forum posting and trading items or pets with other players. Some VPS games include a breeding system, and if they do it is commonly possible to use other players' pets as breeding stock. Some games encourage the player to collect pets or other collectibles. Some VPS games include a minigame arcade; if they do this is typically the main source of player income within the game, and players may compete for high scores at the games. Some VPSes include a clothing system, either for pets or human avatars. VPSes are the pet-themed version of social gaming sites, which are usually built around a forum with a customizable avatar and clothing system. This system is intended to facilitate player socialization by allowing players to present a carefully-chosen visual representation of themselves to others, and regularly update this visual representation to reflect holidays and other social events.
Minigame Arcades – Minigames are games which take a short time to play. They consist mainly of speedpuzzle games (Tetris, Frozenbubble, Pouyopouyo), solitaires (cards, Mahjongg, Minesweeper, Hangman, boardgames against a computer opponent), and arcade games (beat-'em-ups, shoot-'em-ups, bullet hells, pinball). In many some cases it is possible but rare to win; in other cases it is impossible to win, instead the player is scored on how long they survived or how many targets they shot or bonuses they collected before losing. A minigame does not have to have a forum or other social component; sometimes they are purely ad-supported and have no cash shop or membership. If a minigame arcade is combined with a social forum such as VPS the arcade is usually the method by which players can earn a daily income of game currency to spend on pets, clothing, or similar items. Minigames may not be terribly memorable or artistic, but they are convenient from a site maintainer's perspective because if one breaks or is disliked by player it is not related to the others and doesn't spoil the players' enjoyment of them. Arcades are also easy to expand by adding new minigames, as opposed to larger games where new content must be integrated and balanced with existing content.
PvP Pet Competition Games – PvP (player vs. player) games are those where the main multiplayer activity is dueling other players; possibly in combat but non-violent activities like racing, show jumping, agility, dressage, or beauty contests are also popular. One of the main goals is to earn a high rank in the competitive league of all players. Another goal may be to have the highest personal score on a particular course compared to your friends or other players who attempted that course during the current week or month. These games come in two flavors, fast-paced for those who crave adrenaline, and slow-paced for those who prefer strategy and patient persistence. The fast-paced kind has a main activity of driving the pet at high speeds while avoiding obstacles with quick reflexes (Or more rarely, fast-paced RTS combat between the armies belonging to two players.) The slow-paced kind is a sim or RPG where the main activity is increasing pet stats through training, breeding, or interacting repeatedly with an individual pet; in these slower-paced PvP games the competitive activity is either automated or turn-based instead of real-time. Both flavors of PvP game may have a singleplayer campaign or series of quests which teach the player how to play and may allow the player to earn higher levels and increased stats for individual pets or for the player's infrastructure. (Infrastructure is the property, tools, and abilities the player uses to produce competing animals: their ranch or other property, appliances and outbuildings for storing and breeding pets, training pets, or crafting useful items, their ability to breed higher-potential or rare baby pets, and their ability to modify pets.)
MMORPGs – MMOs are games where hundreds or thousands of people interact within an explorable virtual world. Whether the game uses 2D or 3D graphics the key element is that friends can, in realtime, see each other doing stuff within the world. RPGs are fighting-focused games where the fighting is strongly effected by stats; the main activity of the game is increasing these stats through leveling up and getting better gear. Progress through the game is typically guided by NPCs (non-player characters) offering quests, but the player is usually free to wander anywhere they don't immediately get killed by higher-level monsters. The most common type of combat is realtime involving spellbars and cooldowns, but many other types of combat are compatible with this type of game, from simple turn-based to turn-based tactical to realtime 3/4 overhead to realtime sidescroller/arcade/platformer, and even racing combat where racers can attack each other during the race. Please see the combat section for more details. Some MMOs are almost completely focused on PvE (player vs. Environment, where environment usually = monsters) combat. Normal difficulty monsters are found by single players or pairs of players in the main game world, while instanced dungeons are populated with elite (high-difficulty) monsters and bosses that require teams players to work together. Other MMOs have a focus on PvP, whether between individuals or in teams of 5 or more. Singleplayer PvP involves dueling other players for personal gain; group PvP can be simple team duels where the last player alive determines which team wins, or can be a more complicated activity of territorial capture by either NPC factions that players join or player-created clans/guilds. However PvP is structured, each player earns a PvP rank by their performance, and improving this rank is a goal and a source of pride. Both PvE and PvP are the main source of player income in games featuring them.
FPSes – I have not actually seen a pet-themed FPS, so I'll speculate on what one might be like. One possibility is that different pets might correspond to different types of guns, or perhaps biological armored suits that happen to include guns, or animal forms the player could shapeshift into which would happen to include distance attacks. The player would have the ability to bond with (or equip) one animal at a time, and which animal was equipped could affect range, firing speed, power, special effects like poison or freeze rays, and maybe things not directly related to shooting like the player's size, running speed, armor, healing speed, max health, jumping ability, etc. There are single-player FPSes, usually those are very similar to either an RPG or a fast-paced PvE racing game. Multiplayer FPS games are more different from MMOs and fast-paced PvP competition games because of the emphasis on short, intense interactions between 4-12 people and their environment (because the environment typically contains weapons, ammo, and healing items that the players have to scrabble for while avoiding being shot). Some FPS games have battle royale rules, meaning all players are against each other and the last one alive wins. Other FPS games have team play, often inspired by capture the flag, with death being a temporary setback from which players respawn until other one team or the other captures the flag (or destroys the other team's base, or whatever the specific goal is).
RTSes – Real-time Strategy Games typically have BOTH a singleplayer campaign and a multiplayer system for allowing 2-4 players to duel. The closest an RTS gets to a pet game is probably where the units are all creatures, and the buildings are either also creatures or are designed to feed or breed creatures. SimAnt is a fairly clear example, while the Zerg race in Starcraft may require a bit of squinting to see as an army of the player's pets. RTSes are all about building up infrastructure and climbing a tech tree, as described in the entry on sims. But in an RTS the play has to do it as fast as possible while being attacked by enemies, and the goal of PvP duels and most singleplayer missions is to exterminate the enemy from the map. Sims on the other hand are generally slower-paced, and instead of extermination sims are usually about becoming the best pet-breeder or similar profession, and earning a lot of money this way.
Singleplayer Game Genres:
RPGs – Single-player RPGs typically lack the focus on character appearance customization that MMORPGs often have. Instead single-player RPGs come in two flavors: J and W. J stands for Japanese and W for Western, but that was a historical division that is no longer accurate. These days both types of RPG can be made anywhere. Instead it's best to think of jRPGs as those which have a strong story and pre-created characters and quests, while wRPGs are those in which the player creates the playable characters and the game can generate semi-randomized quests, maps, and/or NPCs to make the game extensible and replayable. In jRPGs the player's progress through the game's story and world is regulated mainly by quests and puzzles which must be solved to unlock the player's ability to move to a new physical are of the game. In wRPGs the game is usually less linear, with the player free to wander anywhere they can stay alive. Both games have a focus on 1-10 playable characters and their use in combat, which can come in all the varieties listed under MMORPG. Singleplayer RPGs by definition cannot have PvP, so all play is PvE, unless the game has limited multiplayer functionality which allows dueling outside the main context of the game. But the main activity of the game is fighting monsters and bosses. The overall goal of this activity is to become the best fighter in the world and beat the biggest bad guy in the world.
PvE Pet Competition Games – These are singleplayer versions of PvP Pet Competition Games. As with singleplayer versions of strategy games, singleplayer competition games are often organized in the form of a campaign, a sequence of increasingly complex and difficult competitions which will eventually result in becoming the world-wide winner of whatever the particular competitive activity is. Like the PvP version the PvE version is split into fast-paced activities like racing and flying games and slow-paced activities like pet shows of the beauty contest variety. This genre is the one that most commonly tends to be confused about whether it is a game or a toy, though VPSes and sims may also suffer from this confusion. This causes problems both during development and for players of the finished game. See the entry below about Virtual Toys for info about avoiding this mistake.
Babysitting Game or Time Management Game – Other pet games often include a babysitting segment for raising young pets or breeding pets. Babysitting games can also be minigames. Technically they are a hybrid between a speedpuzzle game and a sim. A time management game is the non-combat version of an RTS, though in most time management games you control one unit rather than an army of units. What happens in a babysitting game is that the pets have happiness, health, cleanliness, sleepiness, or similar gauges. And these meters will get lower until the pet is very unhappy or dies, if the player does not intervene. Either the player can select the pet to see all of its gauges, or the pet will emote any need that crosses into the danger zone, or both. Emoting can be done by an emoticon symbolizing the pet's need appearing above their head in a thought or speech bubble, or it can be done by the pet's facial expression and/or body language changing to express their need, along with other visual effects like “stink lines” rising off a dirty pet. In some cases pets do not have health gauges; Lemmings is a classic example. The pets move of their own volition and often encounter fatal obstacles. The player must use some pets to solve the level's puzzle while keeping enough pets alive to lead them through the final gate to safety and satisfy the level's victory condition. When babysitting is the main activity of a standalone game the game is typically organized into a campaign, and each level of mission has a time limit. Time management games have a similar dynamic where the player runs around as fast as they can trying to fulfill a variety of needs. These goal of the game is not to maintain happiness though, it's probably to grow, breed, or craft something which can be sold for money, as in a Tycoon game.
Sims and Tycoons – Some Pet Competition games and RPGs overlap with sims, in that they can all include breeding, collecting, and training pets, and amassing wealth, levels, and/or stats and special abilities tied to level. Sims and RPGs may also both include crafting and building up an infrastructure by climbing a tech tree. Where RPGs have an overall goal of becoming the best fighter in the world, sims and tycoons usually replace this with a goal of becoming the best farmer or breeder or collector or crafter in the world. As the player gains experience they usually unlock new resources and special abilities related to this profession. Tycoons are a subgenre of sims; there's no real difference between the two except that tycoons have more of an emphasis on making money via selling the results of your sim-labor, while non-tycoon sims sometimes don't even have a currency system. Sim games usually have tech trees. A tech tree is a structure where the player puts effort into unlocking or mastering low level abilities, which are prerequisites to unlocking or mastering higher level abilities. For more details see the crafting section below.
Adventure Games and Interactive Story Games – Adventure and interactive story are actually two different genres, I'm just combining them here because they are so often seen together. Both of them typically lack combat, though they can be hybridized with a kind of game that has combat (for example the Zelda series are action-adventure hybrids). Both of them are typically singleplayer because, like sim gameplay, puzzle-solving gameplay is very difficult to make multiplayer without interfering with what makes it fun. The difference between these two genres is: Adventure games have physical puzzles that the player solves by flipping switches, turning knobs, sliding things along tracks, using pipes to move fluids around, igniting fires, and that sort of thing. Interactive story games mostly involve talking to other NPCs in a form of interaction called a dialogue puzzle, where the player can choose from a list of options what to say or do, and the choice made affects how the NPC decides to act, which in turn sends the plot of the game in one of a few different directions. In fact an interactive story game as a whole can be seen as one big puzzle where the player tries to carry out the right steps in the right order to get the best possible ending; many interactive story games expect the player to play through the game more than once the same way adventure games expect the player to need to restart puzzles if their first attempt at solving the puzzle turns out to be the wrong strategy. So both genres are about solving puzzles, the difference is just whether the puzzle pieces are physical objects or people. And it's common for games to have puzzle pieces of both types, thus making the game a combination of the two genres. Where do pets come in? Well, pets can be puzzle pieces, such as in a game about herding sheep through mazes. Animal-forms or summons can be puzzle solving techniques, such as a game where the player changes into a spider or summons a spider to weave a giant spiderweb that acts as a net to solve a puzzle, or the player changes into a bull or summons a bull to push a heavy object that they otherwise couldn't move. Or the player could be responsible for a space ark full of animal characters and have to matchmake between the animals so they are ready to produce lots of baby animals when they land on their target alien planet. There are all sorts of ways a game could be about solving complex puzzles involving animals.
Virtual Toys – Virtual Toys resemble games, but they generally have no goals or victory conditions. “Pet games” which are actually toys include the software portions of Tamagotchis, Furbys, and HexBugs, as well as various desktop pets and virtual fishtanks/fishponds. In the realm of non-pet games, Minecraft is the most notable example of a virtual toy in the past few years, though it has grown more game-like features (such as deadly monsters) since it was first created as a virtual lego-like toy. As a designer it's important to be aware of whether you want to make a game or a toy, since players who expect one will be disappointed if they get the other. Games and toys are both fun but not really in the same way, and software which has half game features and half toy features can be confusing and frustrating to the player – in other words, they can fail to be either kind of fun.
2. Theme: Story, Setting, Playable Character(s), And How These Should Interrelate With Gameplay.
A game is a piece of multimedia entertainment where the writing has to work as a partner with the gameplay (which is programming underneath) and the art. Well, not all games have stories, and virtual toys may have story but don't have goals. But this section is aimed at games that have a medium or high amount of story.
The word in the section heading that it's most likely readers will be confused by is theme. So let's talk about theme first. Above, we've talked about games which are focused on combat or competition, exploring at a relaxed pace or being super-efficient, solving puzzles or building up a small empire. I've mentioned that games also come in flavors like funny, cute, scary, magical, high-tech, and many others. All of these are theme, though they don't get at the heart of theme. Theme is the statement your game makes about what the (game) world is like and what the player's role is within that world. Who the player should be and what they should do to be declared the winner of (virtual) life. All forms of fiction, including games, are interpreted by the player's or reader's brain as life experience from which they may learn something about the real world and real life. This is why fiction is referred to as “the lie which tells a truth”.
The details are all made up, but characters act in ways that express truths of human nature, because they are based on the author's experience of themselves and others. The characters must behave in ways the audience finds psychologically and sociologically plausible, otherwise the characters will feel fake and the audience won't be able to suspend their disbelief and get immersed in that piece of fiction. Similarly, fictional worlds, though they can have magic or gameplay conventions that don't match the real world, are based on the creator's experience of the world. They must behave like something in the real world, though it's common to substitute something simpler for something too complicated, random, or slow to be quick fun. For example growing plants in a game is usually much faster and less prone to random disasters than growing plants in real life. And a difficult skill like picking a lock with several tumblers may be substituted for with a simpler locking mechanism like a sliding block puzzle. Fictional worlds must be internally consistent so that players feel satisfied because they are learning to master an interesting new environment, and don't feel like the game is “cheating” or “AI stupid”.
(AI stupid refers to a game being unable to recognize what the player is trying to do or refusing to accept a solution that seems logical and realistic from the player's point of view but the game has not been programmed to understand. For example, say a player must combine a string and a stick in their inventory to make a bow. If using the string on the stick works correctly but using the stick on the string results in an error, that's a classic example of AI stupidity.)
What kinds of themes do games commonly express? A game where the player spends all their time fighting, for example, can't help but promote the idea that the way one wins at life is by being the best warrior. Most of us aren't fighters in real life but the message still comes across that traits which are important to winning fights, like toughness, are important to cultivate in oneself. Also that the problems we encounter in life can be thought of as battles, with enemies we ought to attack and vanquish. An adventure game which has puzzles instead of combat has totally different messages: awareness of one's surroundings, creativity in using tools, and manipulative finesse when dealing with other people are connected with success, while straightforwardly attacking an enemy with a weapon as unsophisticated as a sword seems unlikely to work and unwise. Strategy games are about using one's intelligence and awareness of surroundings to directly and forcefully overwhelm an opponent. A time management game where you have to be efficient and fast to survive can make you reflect that you should be acting more industrious and efficient in your real life, and avoid activities that are inefficient or not obviously productive.
Now, games and stories are not about preaching or brainwashing and don't have a strong effect on most people's beliefs. Usually audiences already have their own beliefs about what kind of role they want to play in what kind of world, and will seek out games that deliver a message they are already familiar with because everyone likes some positive reinforcement, and wants to hear more stories of kinds they already know they enjoy hearing. So as a designer the idea isn't really to say what you think people ought to hear, but instead to analyze the games whose stories you love, and why you love them, and how you can create a game world and cast of characters who will be as much fun for your players. As an added bonus you and your team members will be more motivated on writing bits of story and creating pieces of art to illustrate fun ideas.
So, a simple way to get started brainstorming story ideas for your game is to make a list of game stories you have really enjoyed. Novels, anime, movies, and folktales are all good source material too. Who would you want to be in a game, that your players might enjoy being in your game? What kind of game world would you like to spend time in, that your players might also enjoy spending time in? Since this is a pet game, and you've already decided whether you want one or many pets to be used in a combat or non-combat situation, let's get more specific about that! What should they look like and how would you enjoy interacting with these creatures? No need to limit yourself to story ideas if any gameplay ideas are occurring to you too. Scribble all your ideas down, because it's much easier to work with ideas you can see in front of you than ones floating nebulously around in your head.
If you already have a strong idea of what kind of experience you want your game to be for your players, you can cross out things you like but aren't compatible with this particular project. You can always use them in another project in the future! For example, I think breeding systems are awesome, but a breeding system doesn't fit very well with a game where you want the player to only own and use one or a few pets. So if I wanted to make a game which was about a player bonding with one pet, I'd save my elaborate breeding system ideas for a different game design. Or, if I wanted to make a game about the player as an individual becoming the best warrior ever, I would consider making the player a shapeshifter or animal who fights opponents alone, instead of a human who fights with pet companions. And if there are any other player-controlled animals in the game they could be the civilians who make up the player's home base, the pack/herd/flock the player fights to protect and helps to grow by bringing home the spoils of victory.
I can't talk about every possible case here, or even go into detail about different brainstorming techniques. You can use whatever techniques work for you. I personally like starting with a list of everything that occurs to me, then crossing off irrelevant things, adding new relevant ones, grouping these things into compatible clumps, ordering those clumps in order from ones I like most to ones I like least, then trying to the best or second-best and combine the best parts of the others into it, so that I end up with one big clump of compatible ideas that contains most of my favorites. But some people love mind-mapping/webbing/bubble diagrams, and some people like to analyze 1-3 examples of similar games in detail rather than pull ideas from many sources, and some people prefer to do their brainstorming in a conversation with one or more other people... there are lots of ways to brainstorm that work for different people, or the same person at different times. But the end goal here is to add a description of your game's playable character, world, and thematic appeal to your statement of purpose.
Here's another fill-in-the-blank for you: “The player will control/be [number and type of playable character(s)] who will be [profession] who [game's main activity such as fighting, questing, solving puzzles, or crafting] in the [description of game world] world of [world's name]. [Other important activities] will also allow the player to satisfy their urges to [explore/become wealthy and famous/play mad scientist/help someone/be clever/build something/investigate a mystery/save the world/etc.].” And some examples: “The player will be a witch or wizard who learns the craft of brewing complex potions to create unique pet monsters in the dark fantasy world of Monsturbia. Exploring the world to find ingredients provides a peaceful break between frantic potions-brewing sessions where the player must exhibit the speed and efficiency that will enable him/her to become the world's master monster-brewer, showered with wealth and fame.” Or, “The player, represented by an alpha wolf, will control him/herself and up to 7 subordinate wolves at a time in tactical combat, fighting his/her way from the humble beginning of the darkest forest of Wulfmoon to its capital city populated with the other most ambitious wolfpacks of the world. Combat alone can't get the player to the throne; only solving the puzzles in the ancient ruins of Paw's Mark, Broken Fang, and other such locations(dungeons) will allow the alpha to gain the wisdom and spiritual strength necessary to carry out the hero's true task: saving the world of Wulfmoon from itself.” Or, “The player will control the team of Wordy the Parrot and Arch the Cat as they bumble their way through a series of zany adventures, not-so-willingly helping the other animal denizens of Abcedaria solve their problems. Wordy and Arch must help each other navigate over obstacles and through mazes, as well as maze-like arguments with their stubborn neighbors. Even if this odd pair succeeds at bringing peace to their village, will they ever be able to stop arguing with each other?”
3. Distribution and Monetization: Getting the game to the player and the player's money to you.
Thinking about selling a game before any of it has been programmed may feel like getting ahead of yourself. However, the intended sales method affects the design, and plans for earning and dividing income affect recruitment of other team members. Non-profit and/or opensource games also have legal differences with regard to what resources you can use to make the game or how large of a fee you have to pay to use them.
Distribution used to be more of an issue, but these days most indie games are sold entirely online and there's no need to worry about printing CDs, packaging them, and getting them to brick-and-mortar stores. If physical sales happen for an indie game at all they usually happen through a distributor who is already selling the game online, or instead of the game itself the distributor may sell cash cards and you may sign an agreement to add your game to the stable of games that the cash card works with. If you want to sell physical spin-off items like keychains, t-shirts, stuffed animals, etc. you can either do that yourself or you can do it through an online merchant that prints these items on demand and sells similar items for many games, comics, and other fandoms; they probably get cheaper bulk shipping rates than would be available to you.
Online distribution involves either providing downloads of the game, providing a server for the player to play the game on, or both. These services are available through different kinds of distributors, such as appstores and other online game distributors, social networking sites, and server farms; it's also possible to build a server room full of machines yourself, provided you can get a location with access to professional quality internet.
There are three main ways of getting payment from players: selling a game outright (optionally after giving the player a free trial), charging a monthly subscription fee (again there is often a free trial first), or making the whole game f2p (free to play) and instead earning income through a cash shop and/or ad revenue. For a singleplayer game, the one-time sale is the standard model, except for apps. Apps are applications for smartphones or devices like ipads, where the game is sold through an appstore which can be assumed to already have a billing account set up for the device owner. (Account set-up is a traditional hurdle for all online sales because people may decide they don't want a game badly enough to fill out a form and give their credit-card number to a company they aren't familiar with. Thus, avoiding the need to create an account can result in more sales.) Apps can use a traditional one-time sales model, or they can be freemium (free or ad-supported except for premium content) and can use a cash shop to sell the premium content (including the ability to remove in-game ads) even though the game otherwise has few or no online features. Ad-removal can also be sold as a subscription, often this is an annual subscription instead of a monthly one.
For an online multiplayer game the choice is usually whether to go with a cash shop or a subscription. Cash shops are generally more popular with younger (i.e. credit-card-less) and casual players (don't spend enough hours per week playing to feel that they could make full use of a subscription), while subscriptions are more popular with hardcore players (subscriptions can limit beggars and spammers, and more importantly ensure that the game is fair to all players, not pay-to-win).
So, how is the sales method relevant to design? For starters, if your game is going to have a free trial, you need to figure out what the limiting factor(s) of that trial will be, and how to notify the player when they are encountering one of these limits so they aren't confused by why they can't do something, without spamming them silly with constant notifications.
If you intend to have a cash shop you need to design items to sell in it. Items that won't be available within the game for normal currency, items that everyone playing the game wants, but that don't make the game so obnoxious for those who don't buy them that they quit. Cash shop item sales come from three overlapping categories: Consumables, Conveniences, and Customizations.
Consumables include things like energy refills, timer accelerators, and buff scrolls, especially ones of double XP or death penalty prevention. Many of these are also conveniences. Some MMOs also require a consumable “megaphone” to be spent to speak in the world chat channel. Conveniences include anything that spares the player time, deaths and other losses, or annoyance: a permanent inventory expansion, a version of an item that usually requires 30 or more levels to equip that is instead equippable by a level 1, packs of crafting ingredients, and mounts or mount upgrades that increase traveling speed. Mounts (and limited or premium pets) are also a major category of customization, along with clothing, dye, special haircuts, and other visual effects from fireworks and petal showers to neon username frames. And again, many of those are consumables.
So the point is, if you intend to have a cash shop you have to create lacks in your game, which the player can remedy with time and/or work, or can immediately fix with a cash item, and you also have to consider how cash shop pets fit into your breeding system, and what percent of your cool hair and clothing designs should be cash vs. what percent should be quest rewards or cost game currency. It's also ideal to get players used to using the cash shop by giving them a small amount of cash currency and a few quests to buy or use cash items.
If you have a subscription system you need to have some kind of scheduler to remind people to renew before their subscription runs out. Longer subscriptions often come with bonus items, and a method to transfer these to the player's account and, if the account has more than one character, a method to let the player choose what character to receive the item on.
And on top of all that, you need to know how much money you are willing to spend on developing your game, and you need to keep track of money you spend toward developing the game so you can know later when (if) the game breaks even by earning that money back. If you are promising team members future revenues from the game, you need to have a plan for how that will work, and if that payment will end after a certain amount of money or time. If you are paying team members up front you are probably going to need a paypal account. And if you are selling your game, cash items, or any spin-off merchandise up front you are going to need a merchant account to accept credit card transactions.
You should now add a sentence about how your game will be sold and distributed to your statement of purpose. If you intend to recruit a volunteer team you may want to specify whether the game will be for profit but wait and get their input on which specific sales method to use. If you plan to make a kickstarter or similar crowd-sourcing call for funds there are extensive how-tos on that topic by people who have a lot more experience with that than me. “I, [YourName], am putting up [X$] as a budget for developing this game. [If you plan to ask other people to donate money, who and how?] The priority for what to spend this budget on will be [1st, 2nd, if any is left]. [If you are planning to offer shares or royalties, how will that work or when will you decide how that will work? Will some go to monthly webhosting bills or other game maintenance? Will some go to paying back investors, including you?] The game will earn money through [cash shop, subscription, flat sale, ad revenue, and/or spin-off merchandise sale].” If you have any ideas for specific cash-shop items or a kickstarter plan, put them in an appendix for later.
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.
Online games typically have a more complex registration system than single-player games. (The major exception is ad-supported minigame archives, which typically have optional registration or no registration, since they do not need billing information for users.) Usually the player will have to state their birthday or that they are over the minimum age your game or a specific server of your game allows. Many games also require an email address. Optionally a game may allow one player to create several characters or locations, each of which needs their own name; in this case the player's name may either be used only by the forum and billing system, or may not be used within the game at all. Online games typically store most of the game's data in database entries. A player's true identity within the game may be their account number, with the player's username being only one of several pieces of data in the database entry for that account number. In some cases a game may be part of a larger network where the player already has an account, from which the game will import some of the player's data, and possibly share the player's achievements within the game back to that network. Typically a player is required to read the game's terms of service during the registration phase if they were not already required to do so during an installation phase. Many people don't actually read those things, so it can be helpful to also present the few major rules of the game in big red letters as part of the registration process.
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.
Time to add to your features list again:
- [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.
Direct exchange requires one player to click on the other's avatar or name. Some games limit direct exchange to those in the player's friends list, though I don't personally see the point of this. I suspect the idea is to discourage trade-scamming, but I don't think it actually works. Double approval is when both players add money and/or items to their side of the trade, commit to what they have put, then once both players have committed to their side, both must give their approval to finalize the trade. It's common for players to use their side of a trade to display a range of items they have available for sale, and even to show off items they have no intention of trading. For these uses it's important that they player not accidentally give away the items they are just showing. It's also common for players to add items and money to their sides in stages as they continue to chat and negotiate the trade, so it's good to allow this, and not make the trade window auto-close if the players are taking a while or the money portion be unable to handle simple addition and subtraction. Some trading interfaces include a mini 4-function calculator. The disadvantage of this type of trade is that it requires both people to be online, and some versions require the players to be standing next to each other. Also there is no way to automate offering the same trade to multiple people.
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.]
- Trading System [Skip this if your game has no trading system. This is only trades between two players].- [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.
More About Genetic Systems:
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.
Example color palette spreadsheet:
| 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 more structured game, tutorials aren't just about explaining how the game works to the player – they are also the first impression the game makes on the player, and everyone knows how important first impressions are. In the realm of fiction-writing people always talk about hooks and contracts with the reader; these things apply just as much if you substitute 'player' for 'reader'. A reader will start reading a book or a player playing a game because something external to the book/game has caught their attention – it may be that an acquaintance is playing the game, or a reviewer has reviewed the game, or the book/game has attractive cover art and a title that suggests the content is something the reader/player would enjoy. Once the audience gives the book/game that first minute of their attention, that's where the hook comes into play. The book/game needs to give the reader/player a feel for why its world is an interesting one to spend time in, give the reader/player a glimpse at some impressive things they could accomplish if they play a while, and then immediately give the player a task that gives them a taste of the gameplay and how that gameplay is interesting and satisfying. This taste of the gameplay is the contract with the reader(player). The rest of the game should be relatively consistent with this sample so the player doesn't feel like they've been the victim of a bait-and-switch.
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.
3. Format – Copy your features list and paste it into your document, so you now have two. Remove all but the headings from one. If any of the headings seem confusing, clarify them. Congrats you just made a table of contents. Depending on what kind of word processor or other program you are using to make your game design document, you can go through and make each table of contents entry hyperlink to the appropriate feature.
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!