Entries in this blog

Spectrum Of Design a blog series by sunandshadow aka Mare Kuntz
Blog #3: Does This Rollercoaster Have Sand? (Themeparks, Sandboxes, and Sandparks)
Themeparks and Sandboxes represent two different philosophies about what a gameplay experience should be like. Themeparks are concerned with giving players a well-paced, story-rich experience. This means guiding players along a somewhat linear path, and preventing them from changing the gameworld except in certain planned ways (combat and quests) or personal locations (instanced housing or inside minigames), to prevent players from damaging the experience for future players, or taking actions that the story can't react appropriately to, damaging the players' immersion. World of Warcraft is probably the most widely-known and played themepark game, though there are many, many others.
Sandboxes are concerned with creating a highly-interactive, sim-like world where players can do whatever they want within the world's physical capabilities. NPCs and pre-created locations don't usually have a place in a sandbox game, whether because they are regarded as irrelevant and not worth putting development effort (and budget) into, or whether they are seen as a taint on the pure player-shapable sand of the world. Sandbox play often focuses on gathering, crafting, and building, whether this is an end in itself or in support of combat. Some sandboxes focus more on trading and traveling. Eve Online and Wurm Online are two of the most widely-known sandboxes. Wurn Online, in fact, has a web page devoted to talking about the nature of sandbox games and why they feel it is important that their game is an exemplary sandbox.
Sandparks are any hybrid between themeparks and sandboxes. It's still an open question which features will become characteristic of this genre, or whether it will split into two or more distinct types of sandpark. Personally I think that customizability will turn out to be a central trait of sandpark games. Themeparks and sandboxes both consider customizability a virtue, though they normally focus on different types of customizability: character appearances and mounts for themeparks, crafting and housing customzability for sandboxes. Players who are requesting sandpark MMOs often seem to be looking for a game that has all types of customizability, rather than neglecting some as both themeparks and sandboxes tend to do. Ryzom could be considered an existing example of a sandpark, but it's not a complete, well-developed example of the genre, which is why it has had such financial problems over the course of its existence. There's a fuzzy line between "grinders" and sandparks. Grinders are like themeparks which are somewhat sandbox-like in that they mostly lack questing and instead have really high level caps reached mainly by killing monsters. Arguably, they combine the worst features of themeparks and sandboxes, though their design goal of using a limited budget to create a world players can spend years playing in without running out of game might be considered noble.
One way of combining the best (though possibly most expensive) features of sandboxes and themeparks is geographically: the themepark locations are NPC towns where quests and story are delivered, while all land outside the borders of NPC towns is sandbox-like, allowing players to build and grow crops on it, as well as the usual monster hunting. In some cases the land outside towns may be divided into two different bands - suburbs for player housing, which don't have monsters or gathering nodes, and wilderness with monsters and gatherables. A designer might prefer to have housing separated from wilderness because if wilderness areas are not landscapable or constructable the terrain data for them is simpler and requires less bandwidth and load times for players. Similarly, if monsters can't roam around housing areas and attack, the monster AI doesn't have to know how to navigate around houses and housing/monster interactions don't need to be tested for bugs and exploits. On the other hand, a designer might want players to be able to reshape the whole world, or to have territory control gameplay focused on gathering nodes. One other possibility is putting the player housing into the NPC city, but this is really a themepark approach, because usually this type of housing can't be customized on the outside, only on the inside (which may be in an instance). And as I was saying above, limiting customizability seems to run counter to the purpose of having sandparks rather than being content with either a sandbox or a themepark.
A different way of combining sandpark and themepark elements might be having quests and narration be delivered through the menu system, rather than having NPCs exist at particular locations in the world. Or, if NPCs existed in a physical location, it might be that each player had a copy of the full set of NPCs on their personal property, and these NPCs could communicate with the player regardless of where the player was or what they were doing. A system like this can be seen in games where the player has a cell phone or other personal communicator through which NPCs call the player; Grand Theft Auto V is one example. A slightly different version can be seen in games lke Castleville - the player gets a copy of each NPC who wanders around like a pet, but all the actual missions and story are delivered through the menu system. This approach is probably descended from the single-player campaigns of games like Warcraft III and StarCraft/StarCraft II; in these games stories and missions are delivered through the menu system, but the main characters of the story are often playable hero units in the mission levels.
A third attempt at trying to combine sandpark and themepark elements might follow the approach of a game like Vindictus - this type of game doesn't have a main world, but instead allows players to run the dungeon of their choice from a menu. If a game of this type were to add either instanced player housing, menu-accessed gathering and crafting areas, or both, it could become sandpark-like. Wouldn't be too different from existing themeparks that use an expansion to add instanced player housing with sandbox-like play such as growing crops possible only within the housing. Runes of Magic and Wizard 101 are two examples of themepark MMOs which have added sandbox elements via an instanced housing system.
Themeparks, Sandboxes, and Sandparks aren't the only kind of MMO. Myst Online: Uru Live Again is the most well-known examples of an MMO adventure game (MMOA or MMOAG). There are several MMO strategy games (or PBBG, Persistent Browser-Based Game). Examples include Travian, Grepolis, Ikariam, Evony, Stronghold Kingdoms, and many more. There are also several not-quite-MMO online CCGs, games which are basically lobby games where players duel each other at a Collectible Card Game. These include games from Magic The Gathering Online and Hearthstone through PoxNora and a wide variety of free-to-play single-player RPG-like games where the player uses cards to fight a series of increasingly difficult AI opponents, combined with online lobby-based duelling against other players. Wizard 101 is also an interesting example of a themepark MMO which has CCG-style combat. Tactical MMOs usually fit into one of the themepark/sandbox/sandpark categories, but I feel they are worth mentioning in case any of you have not yet encountered the unique experience of an MMO where combat is turn-based and generally occurs on a checkerboard-like field and use of terrain is an important elements of combat. Dofus and Atlantica Online are two examples of tactical MMOs.
So, why might you, as a designer, choose to create a themepark or a sandbox, or something else entirely? It really depends on the type of experience you want to create for your players. In previous blogs we've already covered whether to give players a precreated character, an avatar which is a blank slate for the player to customize, or a team of adventurers, athletes, soldiers, or pets. We've also covered whether to focus on players who want to play in groups or players who want to play solo. Now we can add: players who like to experience precreated stories, players who like to customize the world around them, players who like to have clear goals and be rewarded and recognized by the game for achieving these goals, players who dislike having a game try to guide them somewhere and set their goals for them, and also players who like to spend almost all their play time on combat vs. players who like to spend half or more of their play time on non-combat activities like crafting, trading, or exploring.
What kind of experience do you want to give players? What kind do you as a player want to experience? Let me know in the comments! ^_^

Spectrum Of Design a blog series by sunandshadow aka Mare Kuntz
Blog #2: Fishing For Grouper Or Sole? (Designing For Group Play Or Solo Play)
In the previous blog I talked about solo adventurers, adventuring parties where each character is controlled by one player, and adventuring parties (or sports teams or armies) where all the characters or units are controlled by one player. These differences in gameplay structure result in differences in gameplay experience, and most MMO players have a strong preference for what type of gameplay experience they want from an MMO. In this case, the specific issue is whether they want to play as a team with other players or play by themselves with only occasional casual interactions with other players. One of the major factors underlying this preference is the fact that some people are extroverts and some people are introverts.
Extroversion and introversion are naturally occurring personality types, which are at least influenced by genetics, if not completely determined by them, and it's visible from toddlerhood whether someone is inclined to be one or the other. What are these personality types? What's so different between the two of them? Extroverts are people who like people - socializing makes them feel energized, while being alone makes them feel depressed. Introverts are people who find it draining and stressful to interact too closely with other people; they find being alone restful and great for being able to hear themselves think or work contentedly on a project. Very few people want to socialize all the time or none of the time though - it's more about whether you are more often in the mood to socialize or more often in the mood to be by yourself. Neither extroversion nor introversion is better than the other, and neither is capable of changing into the other; it's quite damaging to pressure someone to act counter to their personality type. (If you want to learn more about introversion, extroversion, and other personality types, I recommend taking the Keirsey Temperament Test, of which there are several versions available online. Or if you want an actual book, I recommend Please Understand Me II by David Keirsey.)
In general, humans are approximately 60% extroverts and 40% introverts. But, extroverts tend to be less interested in anything computery than introverts, so computer and video gamers have a reversed ratio, more like 40% extroverts and 60% introverts. On the other hand, extroverted gamers gravitate more toward multiplayer games than single-player games, so MMO players are somewhere around 50% extroverts. This even divide has actually proved problematic, especially for AAA MMOs. 50% is not a big enough piece of the audience for an AAA situation where the company does not want to make a niche game. In real life introverts and extroverts are often friends with each other. Most workplaces employ both types of people because they are good at different types of jobs, and most business need both types of job done. But introverts and extroverts tend to have different hobbies and interests.
MMOs can only afford to provide a narrow selection of interactive experiences for players, and few possible experiences appeal strongly to both introverts and extroverts. A game that is aimed only at one personality type can provide the widest range of options for that type of player, but will not retain players of the other type. Designing for both types is like trying to walk in two directions at the same time - you don't have enough bodies to go both directions, so you're going to fall on your face. Any game development project that tries to do too much with too little ends up with a shallow game that has a limited number of hours of gameplay any given player will like. (Spore, while not an MMO, is a really clear example of this type of error in going for a broad but shallow game.) When an MMO's design fails to take personality type into account, content that one type of gamer would like may be gated behind content that this type of gamer doesn't like. So either they are unhappy while playing through the mis-targeted content, or they quit before the get to the content they would have liked. Meanwhile players that liked the first type of content will not be interested in the second kind, and won't consider it a good reward or replacement for finishing the first kind.
What if you want both types of players?
In an ideal situation where an MMO had an infinitely large budget, would it be the best choice to have content for group players and solo players in the same game. Well... maybe not. Games are a form of fiction. According to one of my favorite fiction theorists, Simon Lesser, one of the purposes of fiction is to present to the audience "a world free of distracting irrelevancies" and the purpose of play a game or reading a novel is "to learn about ourselves" by "testing ourselves against the contents of this fictional world, which have meaning in direct proportion to their relevance to our own concerns". If a virtual world contains elements "relevant to the concerns" of a solo player, are they "distracing irrelevancies" to a group player, and vice-versa? Yes, at least some of the time they are. (I'll talk about this further when I get to the topic of crafting in MMOs in a future blog entry.)
Moreover, even in an enormous high-budget MMO you wouldn't see parallel group-focused and solo-focused methods for doing the same activity; redundant gameplay is just never going to be a priority for any developer. Which means that any activity developed as solo gameplay is an activity that won't be available as group gameplay, and vice-versa. So in any compromize game intended to have activites for both group and solo players, opportunities are going to be lost from both groups' points of view. For an AA or indie MMO with a limited budget the answer becomes even clearer: pick group players or solo players to design for. Experienced MMO gamers of all kinds are tired of playing games that aren't really aimed at them, and desperate for a game that will allow them to be who they want to be and act how they want to act in a virtual world that caters to their niche. Playing a game that feels like a badly-fitting piece of clothing is one of those irritations that builds up until the prospect of facting that annoyance one more time outweighs your desire to go back and play for another day, and is a reason why many otherwise-loyal players leave games even though they have a fairly high level character in that game. May the next decade be the era of niche games, where every player can find a truly comfortable fit!
However, perhaps there are some of you whose dream is to make a game for everyone. Maybe you will even make one that proves me wrong, because both group and solo players will prefer it to more nice games; maybe the introverts and extroverts who are friends or relatives in real live will be really happy they can play your game together, while being free to not really play 'together'. So, for those determined to make a game for both solo players and group players, here are my recommendations:
Scalable Dungeons! The number one way that any average themepark MMO could be more solo-friendly is by giving each dungeon a solo mode.
Gathering, Crafting and sim-activities like growing crops. If killing monsters in the main game world is the solo player's "meat", gathering and crafting are the potatoes. Don't undercut your solo players by making gear droppable; have crafting mats for that gear or enhancement consumables for that gear drop instead! In any game which has a serious crafting system, the best gear for every level should be craftable, though it may require drops from dungeon bosses to craft, or high faction reputations to get the recipes. Also, standard gathering, where you stand at a node and wait, just plain sucks. It is inarguably crappy gameplay. If you want gathering to be one of your main types of solo gameplay, make it actual gameplay, where the player has to play some kind of minigame, which must be an actual fun way to spend time, to gather their materials.
Low-level dungeons! Going the other direction, players who prefer grouping tend to hate games where the first dungeon, the first place that really requires a group, doesn't appear until level 20. Non-combat group tasks, like giving your newbie level and NPC fortress where two players must stand on tiles at the same time to open the gate for 30 seconds, could also add some easy group content that even people who haven't really mastered combat yet can do. Ideally, you could also place and NPC there who will come stand on one of the tiles if asked to by a player. Then it's more friendly to soloers and people who happen to be playing when the game is underpopulated.
Low-level PvP! Group PvP is the other favorite activity of players that prefer grouping; yet some games have either no PvP or 1v1 dueling only for low-level players. Games which have multiplayer mount racing, a CCG, or other multiplayer 'PvP minigames' also tend to have ridiculously high level or money requirements to be able to participate and not be utterly left in the dust by higher level players. Handicap systems where players are automatically up-leveled, down-leveled, or allowed to use a game-provided mount/card deck/whatever are essential for getting low level players into grouping activities and enabling group play between players of diverse levels. If you are particularly interested in focusing on PvP, a leveless game might even be the answer, because level disparities are so disruptive and limiting to PvP.
Raids tend be considered PvE endgame content. While raids are undoubtedly the form of PvE which requires the most experience at playing the game, and they are easier to balance for a group of max-level players than for a group of players with more diverse levels, like all group play they will generally be avoided by solo players, and if they are the only PvE endgame content an MMO has, and solo players who made it to the top level are going to feel pretty neglected and abandoned by the designers at this point. If raids are an important part of your game, make sure you have alternate high-level solo PvE content.
Collecting is a hobby that both introverts and extroverts like, but it tends to be somewhat more popular with introverts. Extroverts are more interested in collecting if it is supported by a system for showing off your collection to other players, though. Very few MMOs have done much with collecting ad using galleries or mannequins and weapon stands to display collections, which is sad because it's a relatively easy thing to implement, especially if you already have player housing or an ability for players to look at each others' equipped gear.
NPC interactability - this is something that could improve an MMO experience for group players and solo players alike. NPCs which can be interacted with more like a real person would be more pleasing to extroverts who don't like wasting time not interacting with other players, and introverts would have a guaranteed positive experience interacting with NPCs, as opposed to other players who might feel like handing out insults, criticism, and harrassment to anyone they happen to meet. Also, collectible NPCs are an idea whose time has come - I want that harem of NPCs to go with my houseful of pets PLZKTHX.
Focusing On Soloers
Before I get into the meat of this section, I think I need to soapbox a bit. YES, it is a completely valid idea to design an MMO focused on solo players. I have occassionally run into some extroverts who don't understand why introverts might enjoy solo MMO play and find it uniquely different and/or better than playing a single-player game. Or worse, occassionally I encounter someone who feels that MMOs as a genre are the collective property of extroverts, and introverts should GTFO becuase they're bringing down the property values in the neighborhood. That is nothing but bigotry. A genre of games is huge. The realm of MMOs is big enough to contain several games for every type of player. Players who prefer to solo in MMOs, as opposed to either grouping in MMOs or playing a single-player game, have real and valid reasons for this preference. All gamers deserve games that cater to their preferred type of play. Solo players don't deserve to be treated like second class citizens, either by other gamers or by games that try to draw in both group and solo players, but quietly give preferential treatment to group players. They don't deserve games that drop group play requirements unexpectedly on players' heads several levels into the game, or games that forget about solo content about halfway through the game, trying to force solo players into grouped high-level and endgame content. Group players also deserve games that focus on and support grouping; I'll get to that a few paragraphs further down. Meanwhile, that's enough ranting from me.
For people who are genuinely confused about why someone would enjoy soloing in an MMO, let's look at what a solo player actually does in a game. Whether you prefer to group or solo, the presence of other players in an MMO's world is one of the things that makes an MMO's world feel real in a way that a single-player game world, even one with great story and graphics, can't manage. Forums and public chat channels are great for introverts and people with social anxiety because they allow users to communicate at their own pace, communicate without committing to guild or faction membership, and provide opportunities to see what existing communitiy members are saying before trying to join the discussion. (On the other hand, verbal-only chat systems are pretty horrible for introverts, though extroverts generally like them.)
An auctionhouse or marketplace is another great way that MMOs allow players to interact with each other with a bit of a safety buffer in between them. Economic gameplay with other players is much more interesting than simulated economic play in a single-player game because interacting with other people is more unpredictable, and not in a way that's uselessly random, but in a fascinating way where you can see one pattern emerging here, a different pattern emerging there, and the patterns change each week or month.
As mentioned above, gathering, crafting, and sim gameplay such as growing crops or breeding animals are a staple of solo gameplay. Unfortunately a lot of games tend to 'sabotage' these types of gameplay by inserting group requirements, even when the game as a whole isn't heavily group focused. A Tale In The Desert has some types of gathering that require 4 or more people, and due to the lack of an auctionhouse it is impractical to aboid that type of gathering by trading for the material instead. (Though on the other hand, the fact that A Tale In The Desert expects every single player to craft their own house and generally has a focus on crafting items for oneself rather than to sell or to grind crafting XP, is really great for soloers. In fact, restrictions on selling or trading craftable items and breedable pets could be a really good thing for a solo-focused game, because you want each player to have the pleasure of climbing the tech tree on their own, you don't want them to get leapfrogged over interesting content due to the accomplishments of earlier players.) Wizard 101 has a system where breeding pets requires two players who each have a pet; a player cannot breed two pets they own. Breeding dragoturkey mounts in Dofus requires ownership of a paddock, and property ownership is restricted to guilds and in limited supply per server; additionally it's extremely difficult to capture wild dragoturkeys in solo combat; for some classes it's merely hard, but for others it's all but impossible.
Finally, minigames are popular content among solo players. Introverts tend to be more interested than extroverts in puzzles and beating their own previous high scores or score requirements for a special prize from the game, both common elements of minigames. Minigames which are based on breeding pets or mounts, or collecting cards, tie in well with other solo-player interests. Even multiplayer minigames are fairly good for solo players because players are often too busy to interact much during the game, and it is easy to leave between rounds if one feels oversocialized or discovers that a player one dislikes is already playing the minigame.
In general, if you are designing for solo players, beware of mechanics you are copying from other MMOs, as those other MMOs were probably not solo-focused and might contain elements that, while interesting designwork, might undermine your game's solo focus.
Focusing On Groupers
Group players too deserve to have MMOs which support group play and community interaction. There doesn't seem to be a lot of prejudice against group play in MMOs, so I don't feel the need to repeat my rant in reverse for this section. Group interaction in MMOs tends to take a few common forms: Dungeons, Raids, Team PvP, and Large Scale PvP. More innovative forms include inducements to group during monster-hunting in the main world, group property ownership, and group puzzles.
Dungeon runs usually feature a group of 3 to 8 players entering an instanced dungeon where they first have to avoid aggroing too many lower level mobs at once, then must cooperate with coordinated timing to kill one or more bosses. This is the type of play where the triad of combat roles - tank, healer, and DPS (damage per second) - has gained most of its fame. Vindictus is an example of an MMO that has chosen to focus on dungeon runs to the extreme of not really having a virtual world outside the dungeons.
A larger version of a dungeon run, raids feature large groups of 20 to 100 players, usually fighting a world boss, though in some cases they are fighting an invasion of a whole army, which may culminate in a boss. Within a raid players are often divided into multiple dungeon-style groups using the tank-healer-DPS system. Raids are found in WoW and most WoW-alike MMOs, mainly at higher levels of the game. "Endgame progression", if that term isn't paradoxical, tends to involve farming gear from either raids or by earning PvP tokens to spend in a PvP shop. Though farming reputation is also a notable endgame activity in WoW-alikes.
Team PvP pits one group of 3 to 8 players against another, either in an arena system or in a guild territory system or faction territory system. Territory systems are pvp systems in which the victorious side on a battlefield temporarily gains control of some territory within the game; generally the faction members or guild members of the faction or guild controlling the territory get some kind of bonuses or buffs as long as they keep control. In some games PvP has an entirely different set of gear than PvE, which means that people who want to take part in both of these activities are kept busy farming 2 different sets of gear. MOBAs (multiplayer online battle arenas) are a recent experiment in online games intended to focus entirely on group play. In my personal opinion MOBAs aren't technically MMOs, but they are still worthwhile for MMO designers to look at, along with other not-quite-MMOs like virtual pet sites and online casinos and arcades. MOBAs evolved from a hybridization of team PvP in MMOs and offline multiplayer battle arenas descended from the Bomberman series, various racing games including Mario Kart, and FPS games with a multiplayer mode like GoldenEye 007.
Large-scale PvP features large groups of players fighting each other; in some cases there are NPC characters mixed in among the players to provide story context for the battle or explain strategic objectives that are different from one battle to another. In a battleground system the two sides are generally factions on the same server. In an RvR (realm vs. realm) system the two sides are generally players from two different servers. Some games have large-scale guild vs. guild combat, but the percentage of guilds per server which can field more than 10 fighters at any given time isn't very high, so this version of large-scale PvP has somewhat fallen out of favor among designers.
Many MMOs treat battling normal monsters in the game's main world as a solo activity or one where people can group in pairs or trios, but might be fighting in separate neighboring battles rather than actually fighting in the same battle. Some games will even automatically group any two players fighting nearby, unless they have set some options to prevent this. Other MMOs try to bribe or force players to group in the main world. Even players who prefer grouping don't necessarily like being subjected to these lures and pushes, so if you are a designer who wants to encourage players to group, please keep in mind that methods should be tested to see how off-putting they are to players, or how much unpleasant drama they create. Various techniques for promoting grouping in main-world monster hunting include: Monsters marked as appropriate for a certain level of player are either difficult enough to require a few players of that level to successfully fight them or tend to come in groups of monsters which require a few players of that level to successfully fight them. Final Fantasy XI is an example of a game where soloing in a level-appropriate area was discouraged through difficulty, as the mobs were scaled to be fought by groups. Some games give an XP or loot bonus to monster kills made while in-group with other players (who are physically in the same area and not idle). Maplestory is an example of a game that gives an XP bonus to anyone in a group.
Some games, for example Dofus, have instanced battles so it is very easy for that kind of game to tell how many players of what levels are actually involved in the battle. Dofus has certain rare drops which will simply not be dropped at all if there are too few players in a battle. Wizard 101 is another game with instanced battles where the game can tell how many players are in a battle - in this case the game will call nearby monsters to join a battle where a group of players have aggroed a smaller group of monsters.
Several games require property to be owned by a guild rather than an individual, or require several players to sign on as initial members before a new guild can be created. Collectively-owned property and collectively-stored assets are a big source of drama and accusations of various crimes between players; if you want to avoid this kind of drama, even in a group-focued game, you may want to avoid group ownership of property and assets, or implement a system that publicly tracks what individuals give to a group property and what they are permitted to take from it or change within it.
Maplestory and Dofus both contain examples of group puzzles: generally 3 or more players need to either stand in the correct spots at the same time or activate levers in the correct order.
One problem that group-focused games face is conveying story. For a player who wants to play in a group as much as possible, they are afraid of seeming slow and annoying other group members if they take the time to read text while in a dungeon or talking to an NPC, and will 'spoil' dungeons for themselves by reading about them online beforehand so they don't annoy other group members by being oncompetent. They also get blocked in their attempts to group if they have a quest where only other players who are on the same step of the quest can group with them - FFXIV A Realm Reborn has had a lot of players expressing frustration with the interleaving of quest chains and boss fights. I don't know of a clear solution to this problem. Putting text into a journal or library of lore books where the player can read it later can help a little, but it's not anywhere near enough to really solve this problem. Having NPCs in dungeons deliver spoken dialogue in a timed gap before a battle such that players can't do anything else while listening is another possibility, but would surely get annoying for people running the dungeon for a 3rd or 4th time. And dungeon replayability is more important for group-focused games than single-player games. Some MMOs, particularly sandbox MMOs, don't really need a lot of story, but it's too important to RPGs to consider leaving the story out to be a solution. (Plus, as a writer, saying that would be practically a crime; they might even revoke my poetic license. ^_~ ) Sorry I don't have a more useful suggestion for this one.
As I said above for solo-focused games, if you want to design a group-focused game, beware of copying mechanics from other games which may not have been group-focused, as you could accidentally undermine the group-focus of your game.
No matter whether you want to design an MMO focused on grouping, soloing, or both, I hope this blog entry has given you some ideas for what kind of features will support your design goal, and what kind might be counter-productive. Last but not least, questions for all of you! Do you prefer to be in an MMO that has both group and solo players, or do you prefer to be in a game which focuses on the type of player you are? Want to give an example of an MMO you think does the best job at pleasing both kind of player? And MMO that does the best job focusing on group play? An MMO that does the best job focusing on solo play? I hesitate to ask this last question, but do you think I did a fair job describing both solo play and group play? I know a lot more about the one I prefer than the one I don't like, but I tried hard to do a good job for both. ^_^;

Spectrum of Design 0, 1, and 2 were originally published on MMOsite.com
MMO: Spectrum Of Design a blog series by sunandshadow aka Mare Kuntz
Blog #0: Introduction Welcome! This series will look at the many choices involved in designing a game, and how these choices result in the wide spectrum of MMOs there are today, and possibly some new hybrids we might see in the future.
I've been involved with hobby and indie game design for over 15 years now. I've been very excited to see that in the past few years it has become easier than ever for gamers to get into game content creation. Some of you have supported the development of games to fit your tastes through Kickstarter. Some of you have modded games for the enjoyment of other players, or supported modders with donations or other help. Some of you bought the recent Humble Bundle of game development tools, or have supported various open-source projects from freeing Ryzom's server and client code to game-related art tools like Blender, Gimp, and Inkscape. Not to mention open-source games like The Mana World, where player voting affects how the game is developed. And many of you might be looking forward to the new crop of MMOs where player-created content will be the meat of the game, like Shards and Project Sansar, the planned 'spiritual sequel' to Second Life. You as game players will, more and more, have the chance to participate in creating the games you and I will play!
This series of blogs is for you - anyone interested in some free and easy education about how game design works, to help you get started doing your own game design and development. Whether your ambition is designing your own dream MMO, building a small location within a game that allows player content creation, joining someone else's game development project as an assistant designer or content creator, or going to school to learn about game design and development, this blog series should be able to give you a foundation of knowledge. Specifically, I'm going to talk about what types of MMOs there are, and how a few small decisions made when starting to design a new game result in the many different genres and subgenres of MMOs that exist. Chances are, you love some of these types of games and hate others - why? What type of player are you, and how do games please, or displease, the type of player you are? What other types of players are there, and why do they like different types of games? I'm also going to talk about how contradictory design decisions can result in something that annoys everyone. ^_~
The first interesting design decision I'd like to take a look at with you is the decision to make an MMO game. It's actually the second design decision made - the first is to make a game at all. But the decision to make a game is usually a tangled, impossible-to-verbalize mix of loving games, being frustrated with games, feeling the urge to experience a particular story or a particular type of gameplay, wanting to be part of a creative team, and wanting to see others reacting to one's creation. Like other artistic callings, either you want to create games or you don't. But assuming that you do, let's talk about why you might feel compelled to help design or develop an MMO, rather than some other kind of game.
MMOs hold the dubious honor of being the genre of game that people are most likely to discourage each other from making. Why? Well, MMOs are inarguably one of the most difficult types of games to bring from a concept to something playable. There are some exceptions - a text-based MMO would be less difficult than a 3D single-player RPG - but most MMOs start with a game genre that's already complex in a single-player version and then 'level up' the complexity by adding issues of player interaction and networking functionality. Massively, Multiplayer, Online - the defining traits of the genre are the ones that make it difficult to develop. It's a general rule of game design that the simpler the concept, the higher the chances of a playable beta ever existing. Coming at this question from the opposite direction, MMOs account for a large and growing percentage of hours spent gaming among teens and young adults; the same ages when people are likely to first decide they want to design a game, and also likely to want to design something similar to what they are playing. Coincidentally, the age when people are the most ambitious because life's failures haven't yet beaten into them the lesson to 'aim small'.
Personally I love MMOs, and I have fun working on MMO designs even though I know I don't have the drive to lead a game development project or a funding campaign; in my humble opinion, armchair game design is a perfectly good hobby. Maybe someday I'll find a motivated leader who wants me to help design their game, or maybe I won't; either way I have at least as much fun making up game designs that probably won't become actual games as I would painting along with Bob Ross and the hanging the painting on my wall where hardly anyone but me will ever see it.
But anyway, and more importantly, MMOs are AWESOME. Why? Because they have the potential to include every other genre of game. Because they have the potential to be entire worlds that players can more-or-less live inside. They are 'real' worlds because you interact with real people in them. This virtual world aspect is one of the things that inspires the most genre loyalty from MMO gamers, and what motivates many of us to want to create our own piece of virtual world, whether within a game by doing some landscaping and house building, or out here in reality by participating in envisioning a new game or modding an existing one. So, now that I've briefly defined MMOs and why we might enjoy trying to design an MMO or a small part of one, tune in next time to figure out what kinds of MMOs there are for you to make!
Now, for your first chance to participate! If you have a request for what game design choices you would like to hear about in future blogs in this series, please comment! (For example, future topics might include avatar-focused games vs. non-avatar-focused games, sandboxes vs. themeparks, PvE vs. PvP, solo-focused vs. group-focused, or combat types and combatless MMOs. What do you want to hear about? What interesting possibilities aren't listed here?)

MMO: Spectrum Of Design a blog series by sunandshadow aka Mare Kuntz
Blog #1: To Avatar Or Not To Avatar? (No, not that movie with the blue cat-aliens.)
One of the most basic divides among game types is one of the least talked about, because it's one of the few that doesn't provoke much controversy among players. Arguments about group play vs. solo play, PvP focus vs. PvE focus, permadeath, and many other topics sweep through MMO gamer communities like seasonal forest fires. But I think the only time I've heard the topic of whether a game is avatar-focused come up is in the context of EVE Online. Player A was recommending that Player B try EVE Online, and Player B replied rather calmly that they just can't get into games where their role in the game is a ship or a nation rather than a specific character running around the world doing stuff.
That specific character, assuming we are talking about a player-chosen or customizable character, is called an avatar. The design question of whether to make an avatar-focused game or not is actually closely related to the issue of whether and how to design a game to enable and support roleplaying. Roleplaying is, in fact, one of those often-argued topics, but I think a lot of people don't understand what avatars have to do with it. Probably because some games are so good at giving a player character-developing things to do with their avatar while other games are so terrible at this, that the average player's experience of avatars is quite mixed. Either way, focusing a game on an avatar is one of the biggest silent distinguishing factors of an MMORPG, as opposed to either single-player RPGs or other types of MMO. Please note, I'm not saying MMORPGs must be avatar focused. Rather, I think it's interesting how many single-player RPGs are not avatar focused, yet this type of RPG has been largely ignored in MMO design. On the other hand, there are a notable number of non-avatar-focused MMOs, but for some reason hardly any of those are MMORPGs. Is this a coincidence, a result of history, or is there some reason non-avatar-focused RPGs don't work as MMOS? Let's investigate! ^_^
Type 1: Mouse or Man(y)? There are three types of non-avatar focused game. The first type doesn't usually include RPGs, but rather strategy games, puzzle games, SIMs, and adventure games; these are the non-avatar-focused games most heavily represented among MMOs, though many compromize by adding a still-image avatar, as described below. In these types of games the player is generally represented by the mouse cursor (sometimes in the shape of a hand) and the player's body is not shown on the screen or simply does not exist. Though in strategy games the player may regard themselves as having multiple bodies, in the form of the units of their faction, none of them are customizable, and even hero units do not count as avatars. The closest you get to a non-RPG with an avatar focus is a game like Minecraft or the Harvest Moon series where the player character is what you use to run around building and tending plants.
Let's look at some history. Single-player RPGs of the 80s and 90s were rarely avatar-focused because they faced technological limitations that discouraged designers from choosing to give the player a customizable avatar-type character. Changable character appearances had a high development cost, a high game storage size cost, and often resulted in overall poorer-quality character graphics. Linear stories where the player could not make any meaningful choices also won out in terms of cost-effectiveness against interactive story games where the player could customize their character's personality. We'll get to interactive story in a later blog entry though. So, there were several reasons for single-player RPGs to avoid giving players customizable avatars, unless the avatar could be limited to a cheaper system like non-animated portraits. Even this was pretty much only possible in games where the player's character neither walked around the world nor participated directly in combat; so basically, mostly non-RPGs or strategy-RPG hybrids, where combat occurs by means of a card game or moving units around a chessboard-like tactical battlefield. Still-image avatars were common in the earliest networked graphical games, which were mainly card and board games converted to computer games. The use of the term avatar to apply to user-chosen still images in web forums and other social media descends from this type of minimal avatar. (Check out the comments below this blog entry for some examples! ^_^ )
Type 2: Found This Cool Character Just Lying Around But back to single-player RPGs of the 80s and 90s. When they did give the player control of a single character, because of the high cost of enabling the player to customize anything, instead of an avatar the game usually gave the player the predefined main character of the game's story. This is the second type of non-avatar-focused game. A predefined playable character is great for storytelling, as long as the story doesn't need to be interactive at all. Predefined main characters are a characteristic trait of jRPGs. (Japanese-style RPGs) It's actually quite difficult for a writer to tell a good story when they can't dictate the main character's personality and actions. If you took a survey to find out which single-player games of all time are felt to have the best stories, most of the winners would be linear RPGs with predefined main characters. Though there would be some adventure games in there too.
However, predefined main characters can interfere with one of the main appeals of games as a medium, which is that the player can take action rather than just reading or watching. Players can find it frustrating or uncomfortable to be put in control of a character who is taking actions the player wouldn't choose or saying things the player wouldn't say. So, in an effort to avoid imposing a personality on the player's character which might be contradictory to the player's own personality, some games try to compromize between avatar and non-avatar playable characters by having a main character whose appearance is pre-created but whose personality and dialogue are left blank. This is a 'silent protagonist', a character who is given no lines of dialogue. In the Zelda series in particular, the main character Link is not only silent but almost uncharacterized, because the designers of this series wanted Link to be more of a silhouette that the player could step into than a character of his own. Amnesiac main characters were also a common way to try to give players a character who is a blank slate personality-wise, and as clueless about a fantasy or science fiction game world as a new player is.
Type 3: I Am Large, I Contain Multitudes (Walt Whitman) The third type of non-avatar-focused game is any game where the player in put in control of a whole group of characters. (In terms of gamer psychology, these are quite interesting because players make statements like "I'm the red team." or "I'm Cloud, Vincent, and Tifa right now." showing that players are capable of putting themselves into roles that don't correspond at all to their real existence as a lone human being.) The group of characters under the player's control can be an army or a sports team, but in RPGs it is most commonly 'an adventuring party'. They also often include compromizes where a more avatar-like silent and/or amnesiac protagonist is in an 'adventuring party' with vivid precreated characters - Final Fantasy VII is a well-known example. The sheer popularity of adventuring party RPGs is most likely due to J. R. R. Tolkien. (Though he in turn was probably inspired by the tales of the Knights of the Round Table and Robin Hood, among other sources.) Video games didn't exist when Tolkien was writing, of course, but his books were a major influence behind the creation of the first tabletop roleplaying games in the 1970s. However, from the beginning it was standard for each tabletop player to control only one character, usually a self-created, customizable avatar. That's the tradition that went on to spawn MUDs in the 80s (MUD stands for multi-user dungeon, and a MUD is a text-based online RPG), and MUDs are what evolved into the first MMORPGs in the 90s.
Some single-player RPGs, mainly wRPGs (western-style RPGs), did try to stick with the tabletop model of avatar-style characters, despite the development costs. Roguelikes were lone-adventurer dungeon-crawlers which commonly had simulated dice which the player 'rolled' to randomly generate the main character. The player was generally able to choose a gender, race, class, and name. Some wRPGs adventuring party games allowed the player to recruit party members from randomly generated characters (usually found in taverns); this was sometimes combined with allowing the player to create one custom character as the party leader. As hardware evolved, and storage space became cheap, especially on personal computer platforms, the virtual paper doll system was invented. This system used image layering to allow a player to combine an avatar base (a blank body, usually with a choice of gender and skin color) with customizing elements like hair styles, clothes, and weapon. (As a personal note, the single largest solo game-related art project I have carried out was creating a virtual paper doll system.) In its basic form this system only generates a still image, not an animated sprite. But when 2D MMOs were created, the paper doll system was expanded to create a full animated sprite set including all the visual customizations. This is still the base of all 2D MMO avatar systems today, though technological advances like color-pickers, vector graphics, bone animations, and ragdoll physics have all modified the under-the-hood details of how 2D avatar systems work.
Forget TESO, I Still Want My Skyrim MMO It has only been in the past decade that we've really begun to see avatar-focused-games overcome all hardware limitations and some development cost issues to really show what they can do in single-player games. The Fable series and Skyrim are two of the major examples of recent developments in allowing players to control their character's appearance and to some extent interactively affect where the game's story goes. Usually MMO design lags behind single-player game design due to the extra-long development time of MMOs, which in turn is due to the greater complexity of enabling player interactivity. Giving players the ability to customize their characters has been one of the few areas where MMOs have consistently out-performed single player games; but Skyrim made such a big splash partly because it was clearly able to compete on equal footing with MMOs in the area of visual character customization, and surpass them in terms of story interactivity. AAA games aside, even indie games can do great things with customization now because it has become possible to buy whole 3rd party avatar systems, both 3D and 2D.
So, have advances in gaming tech and the availability of 3rd party game development resources created a situation where avatar-focused games have won out over non-avatar-focused games? Well, not really. What we've got is an increased ability to combine avatar-focused gameplay and non-avatar-focused gameplay into the same game. For example, imagine that Starcraft 3 comes out, and it's still all about networked strategy battles, but now it has a customizable avatar for which you can earn hats via in-game achievements? And from the other direction, we're seeing avatar-focused MMOs that have increasing amounts of minigame play where the player's avatar is irrelevant or would even get in the way of the player controlling their units, cards, or puzzle pieces. Though avatars can be integrated beneficially into some minigames, like racing and fishing.
This tendency to combine the two approaches does not make the question of whether to focus on avatars irrelevant. Cost and development time are still an issue, especially for anyone trying to make their first MMO, and there are always going to be benefits of either trimming off less-useful features (like an avatar system in a strategy game) or planning to add those features in the 2nd or 3rd update, after the game has a steady income. The issue of avatars can also help identify under-exploited areas of the MMO market - there are very few MMOs where the player can control an adventuring party or small army in turn-based combat, and the few that do exist are well-loved by their players, so to me that looks like an opportunity for a few more of these games to be made. Avatar appearance customizations are often totally wasted in the character creation phase of current MMOs, when they could be a lot more valuable if incorporated as earnable rewards within the game. Ugly avatar systems can severely interfere with players' ability to get immersed in a game or feel motivated to earn or by appearance customization items. Gender-locked classes are a big design no-no that we still see cropping up in new games like Crowfall because the developers apparently don't understand the problem with them. Understanding how avatars and precreated characters interact with roleplaying, storytelling, and interactivity are also very important for designers, especially of RPGs. Perhaps in the future we'll even see a game innovative enough to offer players a choice between a pre-created character with a scripted jRPG like story and an avatar character with less story and more freedom to explore, appealing to both people who like story and people who like the freedom to explore (or perhaps the freedom to avoid reading). ^_~
Finally, some questions for all of you! Are your favorite single-player RPGs avatar-focused or not? How about your favorite MMOs? Would you prefer to make or help make an avatar-focused or non-avatar-focused MMO? Topic suggestions for future blogs are still welcome too.

Fill-in-the-blank description of game's genre and other basic properties from my guide:

[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].

WildWright will be an MMORPSIM game where you fight to build up a collection of pets which become both your army and your workforce, and you can even use one as a mount. Sim elements of the game include your estate, where you tend your pets to produce crafting resources, and which you upgrade to increase your crafting and pet breeding abilities. RPG elements of this game include combat [tactical or real-time?], interactively building your reputation with NPC factions, and building friendly or romantic relationships with specific NPCs. WildWright will take place in a 3D world, beautifully illustrated with 2D anime/fantasy-style sprites. [Full 3D would also be acceptable if creatures can be modeled to look like they have lots of personality.]

More templates and fill-in-the-blanks from my guide:

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

Other templates used from part 1. of the guide (only the ones I actually used are copied&pasted here):

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). 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. 5. An interactive story game where you talk to [s]creature[/s]-characters, trying to befriend them or solve problems related to them.

You will create a humanoid avatar who will begin as a member of the WildWright race, just about to reach adulthood. WildWrights are a race of life spirits or fertility nymphs [Call them what exactly?] who have an affinity with life in all its forms, and can develop the ability to command monsters in battle, magically engineer new organisms, and change their own bodies to have more anthropomorphic appearances if they desire. The setting of WildWright is a fantasy universe composed of flat-earth islands floating in a "space" filled with breathable air, which can be crossed on the back of a flying mount or by a magic-powered flying ship. [Possible names for this universe: shardlands, fragments, isles, shattered lands, scattered lands, splintered lands, the wilds, etc.] WildWright will be a ton of fun and highly immersive because it will give you the opportunity to: explore a unique fantasy universe, play mad scientist, help NPCs with their problems and investigate mysteries(questing), fix up dilapidated areas, be a clever combat strategist quick-witted minigame player and mount-racer, collect an assortment of items including pet monsters, clothing, plushies, and NPCs (by building up a relationship with them until they want to come live with you), build and craft creatively and display your creations and collections to other players, play the game's market, and become rich and famous among the game's NPC population (ultimately, players can become god-like).

Since yesterday I have been working on developing a new game idea. Well, a few fragments of this concept existed already, as can be seen in this thread from 2011 and another from 2012: https://www.gamedev.net/topic/602667-story-concept-for-a-breedereatersim-game/ https://www.gamedev.net/topic/627379-so-whats-your-rpg-story/#entry4955487

I could probably go back even farther and point out things this idea has in common with my octopus/starfish MMO concept and my Becoming MMO concept. Nothing arises out of a vacuum, every "new" idea has roots in previous ones. But this concept was never developed to any significant degree, and I'm reworking what little there was in response to what I learned playing Skyrim, among other recent experiences.

Some people have also asked me for an example design document to go with my guide to developing a pet game design via writing a design document. All the pieces of this guide are available in this journal, or you can get it all at once as an article: https://www.gamedev.net/page/resources/_/creative/game-design/developing-your-game-concept-by-making-a-design-document-r3004

So, I started by going through the first step of my guide, "Statement of Purpose", for this game concept. This is an overly-wordy rough draft, because the first step guide is about producing a "brain dump", not worrying about polishing anything up. Still, I'd be happy for any feedback on this game concept. So finally, the actual content of this journal entry:

A statement of the designer's purpose that they want the game to accomplish:

My goal in designing WildWright is to create a gameplay experience which feels like the player has entered an interactive novel.

What kind of novel? Specifically a fantasy romance novel, or at least a fantasy novel with optional romance content. The 'heroine' of this novel is a problem solver who helps NPCs, heals wounded areas of the universe, and investigates mysteries. Thematically the novel should be about personal evolution, and a player's personal technology and magical abilities as part of their self-identity. The ultimate goal of such personal evolution is apotheosis (becoming god-like, as represented in the game by having wealth, safety, and the ability to do practically anything you want). So to support this theme that you win the game by becoming god-like, I think the players should start as "baby gods" or more precisely "life nymphs" or "fertility spirits" who are just reaching adulthood. After finishing the game's tutorial content they will be ready to set off into the universe with the goals of developing their life-related magic and establishing their own estates/tribes. An estate is a piece of territory where the player can build buildings or sculptures, breed pets, grow crops, display collections and outfits, and bring NPCs they have successfully courted to live as part of the player's new tribe. Your tribe is all the NPCs and pets who belong to you. Your estate is just as important a part of your identity within the game world as your avatar's body, clothing, and mount are. The middle or "meat" of the game is the player's journey to mystical understanding of the universe/nature/animals/and how "people" (the nymph species) fit into this universe, as well as what role the player wants to take as an adult in nymph society.

What about the "interactive story" part? The game must react in ways that recognize the player's choices and accomplishments. The way Joe Player and Jane Player can both start Skyrim or Fable in the same place and end up with quite different worlds shaped by their individual actions, with the world treating one like a villain and one like a hero, that is AWESOME. I want WildWright to do that in an MMO structure. So WildWright should provide an online world which encourages (but never forces!) players to interact with each other, especially admiring each others' buildingd, collections, and other accomplishments. At the same time the game needs to provide protection from interferance for players' personal SIM-gameplay projects, and also provide the story-rich structure and pacing of a jRPG. (Not a disgoranized sandboxy experience of questionable meaningfulness. Yuck.)

I want WildWright to give players an immersive fantasy world where they feel free to do any of a rich variety of fun things at any time. Activity options should include quests, combat, crafting, minigames, interacting with NPCs and pets/crops, customization, and art. I want this game to allow players to easily view and comment on the accomplishments of other players, from architecture and sculpture to appearance/gear/mount customization and collections to pet breeding to combat performance.

A ranching game is a pet game where the player owns property and infrastructure which are used to produce pets. It is a close relative to farming games where the player owns property and infrastructure to produce crops; the well-known game series Harvest Moon combines these two types of games.

By my estimate, ranching games are the second most popular type of single-player pet game, after catch-em-all monster battling games. Both of these types of games work in some multiplayer contexts too. Again, some games combine ranching and monster battling, and farming can be combined with both. A hybrid genre isn't necessarily a better or worse design choice than a pure genre. But, pure genres are easier to study and if you want to hybridize two genres it's important to have a thorough understanding of both pure genres before so you can decide which features of both to combine and which to discard or replace with something from the other. Thus, this piece of writing is a little study on ranching games, and will not include combat or crop-growing.

What are some ranching games we can examine? Plant Tycoon is my personal favorite ranching game, despite the fact that the 'pets' being bred are plants rather than animals. The equivalence of these plants to pets is easily demonstrated by looking at Fish Tycoon, which is an earlier and extremely similar game from the same game development company; the only reason I'm analyzing Plant Tycoon instead of Fish Tycoon is that Plant Tycoon is the same game but improved by some added features. I'm going to refer to the plants in plant tycoon as pets throughout this piece of writing, which should hopefully make it easy for readers to see Plant Tycoon's design as applicable to whatever their preferred type of pet is.

Viva Pinata is another ranching game, and makes an interesting contrast to Plant Tycoon because the two are quite different. Both games are about the core concept of using property to breed pets to earn money (to improve that property to breed more 'picky' pets to earn more money...) Both are also realtime games which can be paused. Both include the ability to buy new pet types and other items from an NPC shop, and sell pets to NPCs. Both include some kind of sickness that the player can cure and a water meter where water level falls over time which the player must use a watering can to keep in the 'goldilocks zone' (not too dry, not too wet). Anyone who has played any version of the Sims should immediately recognize this as a standard type of pet care. (Yes, sims count as pets; the series is not technically a ranching game though because you can't sell the sims themselves, nor is breeding them core gameplay, it's more like a half-implemented 'icing' feature.

But Viva Pinata and Plant Tycoon have some big differences. The surface differences start with the fact that VP is 3D and PT is 2D. VP takes place outdoors with the player's property being literally a piece of land, while PT takes place mainly indoors with the player's property being a greenhouse full of flower pots plus a plant nursery where the player sells their plants to customers. The two have a somewhat similar story where you are recapturing some lost past glory - this should be familiar to all Harvest Moon fans because it is their storyline too. In the case of VP you are trying to match the achievements of the previous best pinata breeder, Jardiniero; in Harvest Moon style this begins with the task of removing junk from fallow fields. In the case of PT the story ties in with their other games which all share a story that there used to be an Eden-like island named Isola. This island was destroyed (ala Atlantis myths) but in PT your job is to propagate the rare plant species that originated on the island as well as recovering the extinct species that were lost with the island by 'back breeding'. This is the technique by which the heck horse, a 'reconstruction' of the tarpan horse was created - by breeding individuals who each had some tarpan characteristics.

The deeper differences between VP and PT start with the fact that VP has an XP/leveling/achievement system which is such a big feature of the game that it occasionally overwhelms the player's breeding and sim activities. The way in which the leveling system seems overwhelming is that leveling up is the only way to earn shovel improvements and land expansions, and leveling up often causes a cinematic sequence to play, interrupting whatever the player was doing. PT on the other hand has no levels or achievements (arguably the game's second-largest flaw after it's severe lack of storage space). Progress in PT is controlled by the simple mechanism that every upgrade costs money, so the player can only progress in obtaining all the upgrades whenever they have earned enough money to do so. This works, but it's not very motivating to the player. IMHO the game ought to have had an achievement for breeding every plant, and sub achievements for breeding all of each sub-type; that could have been a happy medium between VP's slightly excessive level restrictions and interruptions and PT's lack of achievements (other than the main goal of discovering the 6 magical plants and the side goal of collecting all the bugs). VP does have a good standard set of achievements for each pinata type: it visited you, it became a resident, you bred one.

The other major difference is that a large percentage of VP's play is about creating and maintaining an environment to attract pinatas and enable them to become activated to breedablility. This can be quite laborious; to be activated, shown by a pink heart over their head, often requires each pinata to eat another pinata lower down the food chain. This activation must be done for both prospective parents, and it gets used up be breeding and must then be done again for each offspring. In some cases the pinatas will decide on their own to attack and possibly eat another pinata, which the player cannot effectively separate from each other (at least for flying ones), so part of the player's perpetual task of managing the habitat involves keeping an eye on these fights - breeding replacements and deciding whether to kill off or heal injured pinatas.

The only vaguely similar thing PT has is the bug collection; the plants you are currently growing count as an environment in that they determine which bugs appear for you to catch. The first bug of each type is automatically collected, while the rest are worth small amounts of cash, and are the mechanism by which the player can rescue themself from accidentally running out of money and healthy plants to sell. There's a cash reward for completing the collection too. The fact that VP's pinatas can take aggressive actions without the player's consent, along with the much greater complexity of the environment in VP, is responsible for the major difference in feeling between the two games: in PT the player is in control, in VP they can't maintain control, they can only hang on and recover when things go pear-shaped.

Finally, let's talk about the breeding systems of these two games. This is the one way in which I think PT really outshines VP. Viva Pinata's pet breeding only occurs between two identical pets to produce another of the same exact thing. The gameplay focus is instead on developing the environment to attract new types of pets. Plant Tycoon is the opposite; only minimal upgrades are possible to the plant-growing environment (upgrading soil and water), and this allows higher-level plants to survive better without direct, expensive intervention by the player, but the gameplay focus is on the experimental breeding. Any plant that makes it to adulthood produces an infinite supply of pollen that can be used to fertilize any number of other plants. Each plant can only become 'pregnant' once, and produces 3-5 identical seeds which will often be different than both parent plants. Parents which both have the same stem shape will always produce offspring with that stem shape, and parents which have the same type of flower or fruit will always produce offspring with that trait, but otherwise the results of breeding are often surprising and add up to a complex intellectual puzzle; there are a huge number of possible stem/flower combinations too, more than 300. This is only possible because the genetic system is non-Mendelian. My positive experience with Plant Tycoon's breeding system (and Fish Tycoon's, which is almost the same) is the major motive behind my opposition to realistic genetics as a design choice for pet games; this is just plain more fun.

So, I think I've covered all the major features of the two games. Anyone see anything I missed? Anyone want to suggest a third similar game for further comparison? Any general comments or questions about ranching games?

These are three older entries copied (with a bit of editing) from my equivalent of this developer journal over on the Virtual Pet List forum. I'm copying them here because I wanted to follow up with the new one I just wrote, and they probably should have been copied here in the first place because they're about game design. I make no guarantee that they aren't redundant with the multi-part guide that comprised the previous 16(?) entries in this journal. If anyone wants to comment on these, you're welcome to, regardless of the fact that they are kind of old.

Subgenres Of Pet Game I Like

I have for quite a while wanted to join a pet game project that is getting started as a co-designer. So, I thought I would make describe the different types of pet games I would be interested in creating.

1. Single Player Breeder Tycoon Sims (ranching games) 2. Single Player RPG where the player uses a deck of pet cards or a small army of pet units on a tactical battlefield to fight 3. MMO games where all of the monsters in the game are captureable, and pet breeding is a crafting-like activity which involves playing minigames.

In all of these cases I'm generally interested in a breed-em-all dynamic with fantasy pets (e.g. breed a lion and an eagle to get a griffin). I am imagining a system with somewhere between 200 and 1000 types of pets (eg. pink fox would be one type and purple fox a different type, so it's not as many as it sounds like). I also have a strong preference for humorous, cheerful, cute or beautiful games, and the story optionally could include romance. I'm not really interested in anything where the world is supposed to be dark and bloody and constant fighting.

1. Single Player Breeder Tycoon Sims - Here I am talking about a flash or PC game like Celebrity Pedigree, Fish Tycoon, Plant Tycoon, or a similar game but with combat added. In addition to the CCG (collectible card game) and tactical (army on a chessboard) types of combat mentioned above, one other type of combat that could combine nicely with a breeder tycoon game is tower defense, particularly like that seen in Plants vs. Zombies.

A game of this type would have two main screens: a breeding screen and a combat screen. In the breeding screen the player builds and upgrades nests, hatches eggs, takes care of babies which emote their needs, and unlocks new types of pets for combat use by raising one to adulthood. In the combat screen the player uses the units they have unlocked so far to fight increasingly high level monsters; when killed these monsters drop crafting resources used to build and upgrade nests, consumable items used to raise babies, some sort of currency or resource spent to breed pets and possibly to buy more upgrades and consumables from a shop, and rare eggs or consumable items used to mutate adults. So the player alternates between the two modes until they have unlocked all possible kinds of pets (become the master pet breeder of the world). This achievement should unlock a boss fight, basically the end of the game.

2. Single Player RPG where the player uses a deck of pet cards or a small army of pet units on a tactical battlefield to fight. - Some examples of this type of game include PS1 games like Eternal Eyes or, although not a pet game, Disgaea is a great example of a modern tactical RPG. For a CCG RPG the old Magic the Gathering Game Shandalar for the PC was a great example of an RPG where the player collects cards and builds an increasingly good deck with which to defeat increasingly high level opponents.

In either a tactical or CCG context it again makes a lot of sense to give the player a goal of unlocking all units or collecting all cards. For a typical RPG the player would be given one new unit or card as a reward for completing each sub area (optionally they would have to breed the subtypes from this and their other owned units/cards) and completing this collection would coincide with having explored the whole map and unlocked the final boss battle. The main difference between a single player RPG and a tycoon SIM is that the RPG has a lot more NPCs and story, while the SIM has more sim gameplay such as monitoring the needs of maturing eggs and babies.

3. MMO games where all of the monsters in the game are captureable, and pet breeding is a crafting-like activity which involves playing minigames. - This type of game is impractically large to develop unless someone has a few thousand dollars to invest. But since I play a lot of MMOs I enjoy thinking about how I would design one, including a pet system which is an improvement on those in the MMOs I have played. Personally I'd be more interested in an MMOSIM (like A Tale In The Desert plus combat) than in a standard MMORPG or a forum+minigames arrangement like NeoPets or Gaia Online.

I could see doing either a 2D MMO with anime/cartoon style graphics, or a 3D MMO with fantasy graphics (Perfect World is a fairly nice example). I could see doing either a level-based progression or a level-less game which would be more PvP friendly - if everyone is the same level it's a lot easier to find opponents with whom you are fairly matched. I could see either making the main combat system tactical, like that of Dofus, or making two parallel combat systems - a realtime one for human avatars and a tactical one for pets.

I mention A Tale In The Desert because I would like to have a similar system where players do a lot of gathering and crafting of personal items like custom houses, storage chests, and appliances which are used for further kinds of crafting. I'd be quite interested in including a dating-sim like system where players could court the NPCs, as well as a non-romantic larger-scale version of the same system where players built reputation with various factions to unlock access to special mounts, clothing, etc.

A New Pet Game Type: Time Management Pet Crafting

I don't know if this idea is new in general, or just new to me and someone else already thought of it. But I love time management games (such as Ranch Rush), which are like the non-combat version of a real-time strategy game (such as Warcraft/Starcraft). I also like speedpuzzle minigames ranging from Freaky Factory to Vasebreaker. The two share a structure where each level is a mission with its own goal or multiple goals, and within each mission the player may gather resources, build up infrastructure or defensive structure, and there is either a time limit or other loss condition. The excitement of the game comes from the need to think fast; even grindy resource gathering is more interesting when you have to figure out which resource you need this mission and grab it as quickly and efficiently as possible. This kind of constructive gameplay (as opposed to destructively slaughtering opponents) tends to appeal to the same audience segment who like building up a collection of pets and/or raising an individual pet to have great stats and abilities.

But, what the heck does this speedy gameplay have to do with pet games? Well, In general I think of breeding and raising pets as a crafting activity. Crafting activities are generally about gathering up all the resources to fulfill a recipe, which might require pre-crafting such as growing a tree to get a needed type of fruit from it, or pre-processing such as squishing the fruit into juice, which in turn might require infrastructure build up such as crafting a juicer first, and resource gathering such as gathering water to water the tree, etc. So, for each pet there could be a recipe, and gathering all the materials to fulfill the recipe would be one mission. That would be a basic low-level pet, but higher level pets might require several missions to fulfill sub-recipes.

I think this could be really successful because obtaining each pet is more time consuming yet also more interesting that wading through random combat to find that one pet you want to capture. I can imagine a player spending several hours to get an epic pet and not being bored during the process, provided care was taken to make the goals within each recipe not be too repetitious and the recipes have varied requirements so the player isn't gathering the same resource for every pet.

Recently I played the game Dragon City (on facebook) and one thing I particularly liked about the game is the mechanism for making the pets progress from baby to adult. You feed them to make them grow up, but it's not one of those annoying systems where you have to feed the pet every X amount of time to prevent it from getting sick or dying. Instead you can feed any pet whenever you want, because food functions as the pet's experience points. I think this would be awesomely compatible with a minigame, for example pinball, Tetris, or a solitaire card game. The game could pay out in pet food (plus rare bonus items or small amounts of money). The player can then distribute the food to level up whichever creatures they want to work on that day. This could give players a use for playing the minigame several times a day, without flooding the economy with the game's currency.

X. Finale: 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! ^_^

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] [indent=1]- [List game mode(s) with the primary control scheme] [indent=2]- [Describe the control scheme, both info displayed to the player and input giveable by the player.] [indent=1]- [List each group of game modes with an additional control scheme] [indent=2]- [Describe the control scheme, ditto.]

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:

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] [indent=1]- [What is tended/babysat, how does this activity work?] [indent=1]- [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] [indent=1]- [What kind of dexterity/timing activity is it, how does it work?] [indent=1]- [If there are multiple activities of this type within the game, describe each additional one.] - [Puzzles, if the game includes this type of activity] [indent=1]- [What kind of puzzle is it, how does it work?] [indent=1]- [If there are multiple activities of this type within the game, describe each additional one.]

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] [indent=1]- [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?] [indent=1]- [What unit(s) is the player controlling in the fight and what can the player do with them, including movement and types of attacks?] [indent=1]- [Are there AI allies of some kind?] [indent=1]- [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...?] [indent=1]- [What is the battlefield like and in what ways can it effect combat?] [indent=1]- [Can items be used in combat, and if so, how?] [indent=1]- [What is the typical number of enemies fought at once, as well as the minimum and maximum number?] [indent=1]- [Are enemies typically different in stats or other capabilities from player-controlled units?] [indent=1]- [What is typical enemy behavior and common variants on that?] [indent=1]- [What are the typical rewards of combat?]

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?] [indent=1]- [Describe how the major activities in this game create this type of experience.] [indent=1]- [Describe your game's tutorials and how they teach basics] [indent=1]- [Describe how content near the beginning of your game acts as a teaser/contract with the player.] [indent=1]- [Describe your game's quests &etc. if any] [indent=1]- [Describe your game's individual NPC reputation system, if any.] [indent=1]- [Describe your game's factions and their reputation system, of any.] [indent=1]- [Describe your game's leveling system, if any, and what type of things it rewards.]

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.

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

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?] [indent=1]- [Describe how the pet's functions within game fit primary category.] [indent=1]- [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?] [indent=1]- [Describe how the pet's functions within game fit primary category.] [indent=1]- [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] [indent=1]- [If there is stat inheritance, how does it work?] [indent=1]- [If there is appearance inheritance, how does it work?] [indent=2]- [2D bitmap/raster, vector, or 3D] [indent=2]- [set forms or mix-and-match body parts] [indent=2]- [set colors per form or body part, standard palette of colors, numerical]

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] [indent=1]- [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.] [indent=1]- [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] [indent=1]- [Is this done using the forum software, trade interface, an external network, or something else?] [indent=1]- [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] [indent=1]- 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.] [indent=1]- Voice Chat [If you are providing this, describe what you want to provide.]

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.] [indent=1]- [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?] [indent=1]- [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.] [indent=1]- [Describe the shop use method and GUI.] [indent=1]- [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]. [indent=1]- [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]. [indent=1]- [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.] [indent=1]- 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?] [indent=1]- 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?] [indent=1]- 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.] [indent=1]- 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.] [indent=1]- 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.] [indent=1]- Delivering items to buyers and returning unsold items to sellers. [How does it work?] [indent=1]- [If there are multiple marketplaces that actually sell different stuff or work differently, describe each.]

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.] [indent=1]- [Describe your game's (primary) crafting system: what are you crafting out of what, by what sort of gameplay?] [indent=2]- [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.] [indent=1]- [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.] [indent=1]- [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?]

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] [indent=1]- [For the first inventory, describe its location, the kinds of things it can contain, and starting size] [indent=2]- [For each inventory, describe how it can be upgraded if this is possible.] [indent=1]- [Repeat for each additional inventory] [indent=2]- [Ditto] - [Item types] [indent=1]- [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.] [indent=2]- [What properties or statistics, if any, do items of this type have?] [indent=1]- [Repeat for each additional item type] [indent=2]- [Ditto]

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] [indent=1]- [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.]

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 [indent=1]- [Offline saved game file/Online database/Mainly offline with minimal online friends network or cash shop or ad serving] - Account Creation and Registration [indent=1]- [If online, are you handling account creation yourself or is a store or stable handling it for you?] [indent=1]- [What data do you want to collect from each player?] [indent=1]- [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.] [indent=1]- [Do you require email confirmation, credit card confirmation, or age verification? What can't the player do before they are confirmed?] [indent=1]- [If you intend to have multiple servers, what differentiates them?] - [Graphics Type] - [Gameplay Genre(s)] [indent=1]- [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) [indent=1]- [Linear or Interactive] [indent=1]- [Story Genres(s) E.g. Horror, Fantasy, Humor, Romance, Adventure, Mystery] [indent=1]- [Theme(s)] [indent=1]- 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.] [indent=1]- Notes: [Any story ideas you have had so far] - [Number and Type of Playable Characters] [indent=1]- [Continue to section 5 for the rest! :) ]

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.

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?"

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: [indent=1] 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:

[indent=1]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 1/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.

Wow, I haven't used this journal in a while. The reason I am using it now is that one of the other forums I hang out at is specific to pet games, and there are a lot of newbies over there who want to make a pet game without having much clue what game design is, or what a design document is. I remarked that maybe I should make a guide explaining what a game design document is and how to design a pet game via making a design document for it. The forum owner and a few other people encouraged me to do so, so I am. But, there doesn't seem to be anyone at that forum with the knowledge or inclination to give constructive criticism on my guide. Not even typo-finding, apparently... And then by coincidence I saw two people in the design forum here saying that they didn't really know how to design, so I guess there must be more newbies here than I thought. They are probably not making pet games, but they might get something out of the guide anyway. So! I'm posting the guide here in pieces, asking for constructive criticism, and also to make it available here as a reference like my older writings in this Journal.

This document, created by Mare Kuntz (sunandshadow) in 2012, is a free, public guide to making a design document for a pet-themed game, including example pet game design document sections intended for reuse in readers' own game design documents. A design document is not the only way to develop a game; some people favor the alternate method called agile development. But, this document is aimed mainly at people who have little design and development experience, and IMO agile development works better for more experienced people, or for people who are more interested in learning than in making a specific game. I am providing this document as a community service and releasing it to the public domain. It is freely usable by anyone for both noncommercial and commercial purposes. For example, an indie game developer could use this as the basis for a design document for their own pet game. Or anyone doing a school project or teaching a class where they needed an example design document could use this. I would enjoy hearing from people who find this document useful (sunandshadow@excite.com), but you are not required to notify me if you make use of it. I am available as a consultant for game-design-related projects, but I do charge for that kind of service.

[indent=1]Table Of Contents [indent=1] 0. Introduction: What is a game design document, why should you make one, and how do you use this guide to make one? 1. Genres: What kind of pet games are there, how are they different from each other? 2. Theme: Story, Setting, Playable Character(s), And How These Should Interrelate With Gameplay. 3. Distribution and Monetization: Getting the game to the player and the player's money to you. 4. Player Registration and Account Creation, Data Storage Within The Game 5. Avatar Creation: Human vs. Pet, Clothing Systems, The Avatar's Role(s) Within The Game, Avatar Equipment Slots, Stats, and Abilities. 6. Inventory Systems: Types Of Items And How Each Type Functions Within The Game, How The User Interacts With Storage, Storage Limitations And Expansion As Gameplay. 7. Pets: Storage, Functionality Within The Game, Capturing, Breeding and Genetic Systems 8. Crafting 9. Trading, Shops and the Marketplace 10. Forums and Messaging 11. Tutorials, Quests, Reputation, and Levels 12. Combat 13. Minigames, Puzzles, And Other Combat Alternatives [indent=1]14. GUIs and Controls, Game Modes and Context-Sensitive Behavior X. Finale: An overview of the game development process and how the design document is used during this process.

0. Introduction: Game Design Document - What? Why? How?

A game design document is a written description of proposed game. In this guide I am assuming you, the reader, want to create a game. This makes you the game designer. (Or a co-designer if you want to team up with someone who will also contribute ideas.) In order to create a game you must decide what kind of game you want to create. I am also assuming you are going to outsource some or all of the programming and art of your game to other people. The main purpose of a game design document is to paint a clear picture of a proposed game. The document describes what game parts (otherwise known as features) will be in the game, and how they will fit together. The process of creating a document helps a designer clarify their creative vision for a game and make sure there aren't any inconsistent or missing pieces. The finished document is a record of all the design decisions that have been made. It can be given to others, in whole or in part, as a quick clear way of communicating the designer's vision. It can also be used as a checklist to track which pieces of code, art, and other assets have been created, until everything is checked off and the game is done!

What? So, what is actually in a game design document? A game design document usually includes:

[indent=1]1. A statement of the designer (you) or design team's purpose that they want the game to accomplish. You can write this as a serious statement of philosophy if you really want to, but it doesn't have to be anything complicated; instead you can just say "This game will be awesomely fun to play because..." Optionally you can mention a favorite game that you want yours to be similar to, or what genre it will be, or what type of player will really like it. Typically this part will be 1-3 paragraphs long.

[indent=1]2. A list of features you want the game to have (this does double duty as your table of contents).

[indent=1]3. A description of each feature (these are the sections listed in the table of contents, the "meat" of your design document).

[indent=1]4. Appendixes listing all the characters, location, items, puzzles, monsters, etc. needed to complete the game. (These lists are often added later, after the main design document is done. So really there are only 3 main parts - nice and simple. But, if, in the middle of making your design document, you happen to decide something like: "There are going to be six classes of pets in my game: Sun, Moon, Star, Shadow, Plaid, and Rutabaga." then an appendix is where you file that kind of information so you know where to find it later.)

Why? What good is a game design document? How do you use it to help develop your game? As soon as you write a feature description it becomes useful because you can refer back to it when designing a related feature, so you don't forget what you decided. An in-progress design document is like a journal, but more organized because you will be showing it to other people as well as referring back to it yourself. If you are in a team, the design document serves as a record of what has been firmly decided and should not be squabbled over or changed without an important reason. The design document can also be a fast way to orient a new team member to what is going on.

Most importantly, when you have finished writing your design document the feature descriptions you have written are used as a guideline in the development process when programming a feature, creating graphics or sound files for that feature, and playtesting that feature. How? When hiring a programmer or an artist the design document is both a checklist of all the tasks that need to be done to make the game, as well as a source of bite-size "assignments" that your employee(s) can do one at a time. You can do this by copying and pasting from your design document in to an email or forum post to a team member or employee, or by simply showing them your whole design document. The same applies to tasks you are going to do yourself - if you get around to creating something a month after you initially designed it, re-reading what you wrote reminds you exactly what you decided to do and why.

A game design document is also helpful as an organizational tool for your whole development process; it can be used as a plan you can then follow step-by-step to develop your game. You can even check off within the game design document which tasks have already been completed by you and others. As these parts of the game are created, they form the alpha version of your game! And finally, material from a design document's statement of purpose and story section are often reused when creating promotional materials or a webpage for a game project or completed game, while material from the appendixes is often reused in item flavor text, NPC dialogue, and other places throughout the game.

How? Okay, so how do you make a game design document? You follow this guide! I will describe the various genres of pet game so you can identify which one you want to make. I will describe the various features commonly found in each genre so you will have a starting list of features your game should have. Because this document is public domain (copyright-free) you are welcome to copy and paste as much of it as you can use directly into your own design document. You can also modify it however you want if you want features different than described here. When there are two or three alternative versions of a feature I will try to describe the differences between them and which is better in what context, so you can pick which version you want to use, or you can use this as background knowledge when designing your own version of a feature. You will still need to create some of the material yourself, such as your statement of purpose, your story, names of characters and places, and all the parts where your own creativity is the essential ingredient. But following this guide should be much faster and easier than creating your own design document from scratch, and hopefully the list of example features I'll describe here will make the guide flexible enough to help people design a wide variety of games.

I was trying to describe my experiences giving online lectures and workshops about writing topics to someone, but I realized I had no easy way to look at a list of the lectures and workshops I've given here. Thus I'm going to collect the links to them in this journal entry.