# 9. Forums, Messaging, Chatting

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

 White L. Brown L. Orange L. Red L. Purple L. Blue L. Green L. Yellow Gray Brown Orange Red Purple Blue Green Yellow Black Dk. Brown Dk. Orange Dk. Red Dk. Purple Dk. Blue Dk. Green Dk. Yellow
The top, middle, or bottom row is determined by a brightness gene which can be A, B, or C. Assuming the system does not have dominance and recessiveness, the inheritance algorithm could look like this: A + B = 50% A, 50% B B + C = 50% B, 50% C A + C = 25% A, 50% B, 25% C The color inheritance rules would be a bit more complex: Orange + Red = 50% Orange, 50% Red OR 25% Orange, 50% Brown, 25% Red Orange + Purple = 25% Orange, 50% Red, 25% Purple OR 25% Orange, 25% Red, 25% Brown, 25% Purple OR 100% Brown Orange + Blue = 30% Orange, 30% Blue, 10% each other color excluding brown and gray OR 25% Orange, 50% Gray, 25% Blue OR 100% Gray Brown + Brown = 40% Brown, 10% Each other color excluding gray OR 100% Brown There are many, many other ways this could be done. For an utterly different but still monoploid genetic system you could google a walkthrough of Plant Tycoon, and there are other walkthroughs and wikis which explain the breeding systems in various games. I just wanted to give an example of what genetic algorithms might look like. Now lets finish up with your features' list entry for this section: - [For the primary type of pet in your game, which category(ies) do they belong to?] [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]

# Article Update Log

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

Report Article

## User Feedback

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

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

##### Share on other sites

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

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

##### Share on other sites

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

##### Share on other sites

Thank you very much for sharing this in depth information

##### Share on other sites

I've gotten to 3 so far,

The following is a complement, despite how it may sound:

In all my years of forums, research, schooling, game development, writing, etc. I have never looked at a document, and seriously thought TLDR, before I posted  until now. (I do intend to go back)

That might be hard to believe, if you don't know me, and even if you do, I have to say, I was a little put off by the attitude portrayed in the Classified AD, that linked me here. But never the less, from what I've read so far, sounds like there's quite a lot of experience behind this.

I can't help but think this is some how a pitch to inspire some one help make a game with you, and I have a small gripe with the definition of "Designer" employed here.

This kind of format and advice will work, if and only if, the people who wrote and collaborated on the original GDD are the ones making the game. (or there is a solid promise of payment down the road)

By that, I mean, the most critical issue I've seen in GDDs is it's too detailed.

If the fellow  team members or new recruits had no say in what utimatelly went into the GDD, why should they care for fancy theoretical math that details how  a mechanic is meant to be theoretically implemented?

It's too much, now, if you leave some of these things open, they will be able to get invested in your vision. In reading a GDD, the reader should be taken on  a journey, in whihc they see the overall plan of the entire project, if you want specific values and how those will be implemented, than save it for the TDD.

In reading a GDD, i should have an appreciated of what has been done and discussed before, and where we are going. Not Mired in the in a present of what  specific feature's values are in incredible detail.

As the person in charge of writing & updating our GDD since Summer of 2011, It's been a constant process of how best to structure and present it. What goes in, what is best saved fpr a separate checklist? Why is this section here not there?  How do I write it so it appeals to all types of creative types, and not one over the other? What size font should each heading be, and the general text, so it looks and flows well?

And on and on.....

Shouold we have highlights for showing who came up with which concepts?

(I did our 1st draft  back in Dec 2012, by memory, in an airport. And by Rev 9, I had credited everyone by memory as well. Each version back then was signed of by the core, at it was very long, and not as clean as the one we have now. The reason was because we tried to put too much into it.)

Your GDD will be the most concrete and most important  thing about your game, more then the game itself, at times, since that is the guiding file that governs all else.

The content of it should not be changed, by any one person alone, even if that person is project lead.As you get a core team, it will be signed off by all of them, since they are the ones making it happen.

It will only be finished once you ship the last version yall intend to do, and it will bind and liberate everyone.

Make it clear where it needs to be, vague where it should,  and inspiring at every turn.

I made a conscious choice to not include any images in it, despite some asking for it. The reason being that you can never neat a person's imagination of what can be, the gab between what can be, and what is, is where inspiration, creativity, and passion live.

Foster that in your GDD, and it will work, but leave no room for that, then you at best get parroting oand copies of what you already have.

A GDD should say, we can do better, and here is what it could be like.

Sigh,

right then,

rant over.

##### Share on other sites

I've gotten to 3 so far,

The following is a complement, despite how it may sound:

In all my years of forums, research, schooling, game development, writing, etc. I have never looked at a document, and seriously thought TLDR, before I posted until now. (I do intend to go back)

That might be hard to believe, if you don't know me, and even if you do, I have to say, I was a little put off by the attitude portrayed in the Classified AD, that linked me here. But never the less, from what I've read so far, sounds like there's quite a lot of experience behind this.

I can't help but think this is somehow a pitch to inspire someone help make a game with you, and I have a small gripe with the definition of "Designer" employed here.

This kind of format and advice will work, if and only if, the people who wrote and collaborated on the original GDD are the ones making the game. (or there is a solid promise of payment down the road)

By that, I mean, the most critical issue I've seen in GDDs is it's too detailed.

If the fellow team members or new recruits had no say in what ultimately goes into the GDD, why should they care for fancy theoretical math that details how a mechanic is meant to be theoretically implemented?

It's too much, now, if you leave some of these things open, they will be able to get invested in your vision. In reading a GDD, the reader should be taken on a journey, in which they see the overall plan of the entire project, if you want specific values and how those will be implemented, then save it for the TDD.

In reading a GDD, I should have an appreciation of what has been done and discussed before, and where we are going. Not Mired in a present of what specific feature's values are in incredible detail. Details will always change, the vision should be consistent.

As the person in charge of writing & updating our GDD since Summer of 2011, It's been a constant process of how best to structure and present it. What goes in, what is best saved for a separate checklist? Why is this section here not there?  How do I write it so it appeals to all types of creative types, and not one over the other? What size font should each heading be, and the general text, so it looks and flows well? Is this feature impactful enough, and deserve to be in this document?

And on and on.....

Should we have highlights for showing who came up with which concepts?

(I did our 1st draft back in Dec 2012, by memory, in an airport. And by Rev 9, I had credited everyone by memory as well. Each version back then was signed off by the core, and it was very long, and not as clean as the one we have now. The reason was because we tried to put too much into it.)

Your GDD will be the most concrete and most important thing about your game, more than the game itself, at times, since that is the guiding file that governs all else.

The content of it should not be changed, by any one person alone, even if that person is project lead. (who somehow became me after all this time) As you get a core team, it will be signed off by all of them, since they are the ones making it happen.

It will only be finished once you ship the last version all intend to do, and it will bind and liberate everyone.

Make it clear where it needs to be, vague where it should, and inspiring at every turn.

I made a conscious choice to not include any images in ours, despite some asking for it. The reason being that you can never neat a person's imagination of what can be, the gap between what can be, and what is, is where inspiration, creativity, and passion live.

Foster that in your GDD, and it will work, but leave no room for that, then you at best get parroting and copies of what you already have.

A GDD should say, we can do better, and here is what it could be like.

Sigh,

right then,

## Create an account

Register a new account

• 0
• 0
• 1
• 1
• 3

• 9
• 21
• 13
• 9
• 17