Jump to content

  • Log In with Google      Sign In   
  • Create Account

Designing: The Game and Its Content

Guide To Designing A Pet Game Part 13

Posted by , 27 December 2012 - - - - - - · 618 views
sunandshadow, guide, tutorial and 7 more...
13. Minigames, Puzzles, And Other Combat Alternatives

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Guide To Designing A Pet Game Part 12

Posted by , 25 December 2012 - - - - - - · 754 views
sunandshadow, guide, tutorial and 6 more...
12. Combat

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- [Combat Type]

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

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

- [Are there AI allies of some kind?]

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

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

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

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

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

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

- [What are the typical rewards of combat?]

Guide To Designing A Pet Game Part 11

Posted by , 24 December 2012 - - - - - - · 597 views

11. Tutorials, Quests, Reputation, and Levels

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

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

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

In a more structured game, tutorials aren't just about explaining how the game works to the player – they are also the first impression the game makes on the player, and everyone knows how important first impressions are. In the realm of fiction-writing people always talk about hooks and contracts with the reader; these things apply just as much if you substitute 'player' for 'reader'. A reader will start reading a book or a player playing a game because something external to the book/game has caught their attention – it may be that an acquaintance is playing the game, or a reviewer has reviewed the game, or the book/game has attractive cover art and a title that suggests the content is something the reader/player would enjoy. Once the audience gives the book/game that first minute of their attention, that's where the hook comes into play. The book/game needs to give the reader/player a feel for why its world is an interesting one to spend time in, give the reader/player a glimpse at some impressive things they could accomplish if they play a while, and then immediately give the player a task that gives them a taste of the gameplay and how that gameplay is interesting and satisfying. This taste of the gameplay is the contract with the reader(player). The rest of the game should be relatively consistent with this sample so the player doesn't feel like they've been the victim of a bait-and-switch.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Guide To Designing A Pet Game Part 10

Posted by , 23 December 2012 - - - - - - · 874 views

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! Posted Image

Some common kinds of pets:

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

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

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

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

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

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

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

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

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

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

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

More About Genetic Systems:

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

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

Appearance inheritance systems can be done in three ways:

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

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

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

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

Example color palette spreadsheet: [Ugh formatting fail, sorry, I'll have to figure out how fix this later...]

WhiteL. BrownL. OrangeL. RedL. PurpleL. BlueL. GreenL. Yellow
BlackDk. BrownDk. OrangeDk. RedDk. PurpleDk. BlueDk. GreenDk. Yellow

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

The color inheritance rules would be a bit more complex:
Orange + Red = 50% Orange, 50% Red
OR 25% Orange, 50% Brown, 25% Red
Orange + Purple = 25% Orange, 50% Red, 25% Purple
OR 25% Orange, 25% Red, 25% Brown, 25% Purple
OR 100% Brown
Orange + Blue = 30% Orange, 30% Blue, 10% each other color excluding brown and gray
OR 25% Orange, 50% Gray, 25% Blue
OR 100% Gray
Brown + Brown = 40% Brown, 10% Each other color excluding gray
OR 100% Brown

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

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

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

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

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

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

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

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

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

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

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

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

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

Guide To Designing A Pet Game Part 9

Posted by , 22 December 2012 - - - - - - · 815 views

9. Forums, Messaging, Chatting

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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