[Literature] Fundamentals of Game Design, ch 10: Mechanics

The mechanics are the data and algorithms that define the rules. Mechanics implement the internal economy inside the game engine and present challenges to the UI perspective. Mechanics are also in charge of the NPC AI, mode switching, and links to story engine. The mechanics define how resources can be created/deleted/exchanged, the state or attributes of entities, and the relationships between entities.

Economy

Quantifiable entities are produced by sources at spawn points (health pack in FPS or gold mine in RTS), consumed in drains (shooting consumes ammo, units cost resources), and exchanged through traders (exchange A against B, both A and B exist) or converters (A is consumed, B is produced). Players do not mind getting money for free, but they want to know why they lose some. Explain the drains. A resource is tangible if it takes physical space (space- and weight-limited inventory in Baldur's Gate vs potion stacking in RO vs limitless inventory in JRPG).

If the player has no way to get into a feedback loop, there is a deadlock. Example: when player has no money in Monopoly, she can't buy properties, and can not get money.
Mutual dependency happens when two production mechanisms require each each other's output as their input.
Equilibriums relieve pressure from the player: she can just sit and watch what happens. Therefore, there should be a mechanism to break the equilibrium or require player's intervention (e.g. farms in Age of Empires produce food automatically but expire after 3 harvests). Static equilibrium happens when offer = demand. Players can see their impact instantly in static equilibrium. Dynamic equilibrium happens when the same production cycle repeats itself over time (offer and demand follow patterns). Players may have to wait to know if their actions disrupted the equilibrium.

Mechanics and gameplay

Passive challenges do not require the mechanics to operate (e.g. climbing over a wall). Active challenges (solving a puzzle) have the player progress between states to reach the solution state. However, the player often has the same actions to solve all challenges (jumping, shooting, running).

Guidelines for designing mechanics

• Strive for simplicity: do not make more mechanics than necessary. Occam's razor.
• Do not try to get it perfect on paper. Playtest instead.
• Give enough details to programmers, but do not waste your time going too deep. Minor bugs and misconceptions can be fixed at tuning time.
• From higher-level game design documents, detail what the player is going to do, the flowboard of the game's modes, outline of the story, level ideas and progression, and victory and loss conditions.
• Do your entities: store resources? Are affected by processes? Have state and transitions? Have relationships with others? interact with or by the player (and how)? Also, find verbs these entities will enact.
• Resources: detail how sources, drains, and conversions work.

Debugging tip: always use the same seed in random number generators.

[Literature] Fundamentals of Game Design, ch 9: Gameplay

What makes a game fun

50% from quality assets, UI, and code. 35% tuning and polishing. 10% imaginative level design. 5% innovation. A pinch of luck.
Guidelines

• Gameplay before story and graphics
• get a feature right or leave it out
• player-centric, know your audience
• abstract or automate the boring parts
• be true to your vision, do not add stuff for marketing or in hope of getting more players
• aesthetics matter

Challenges

Gameplay is in the challenges.

Challenge hierarchy: to complete the game, the player has to complete chapters, levels, missions, and atomic challenges. Atomic challenges are what player focuses on at the moment. The game victory condition should be explicit, as well as the atomic challenges. Intermediary challenges can and should be implicit: the fun comes from figuring out how to use the atomic tools to reach the end goal. That's why the player should be rewarded whatever path she took or means she used.

Many simultaneous atomic challenges put stress on the player (e.g. Impossible Super Mario levels). Difficulty = intrinsic skill + stress. Intrinsic skill = level of skill required to overcome a challenge without any time limit. Sudoku is pure skill. Stress = perception of time pressure for a given skill level. Tetris is pure stress. Therefore, to make the game easier, give more time to complete skill-based challenges.

Commonly used atomic challenges:

• Physical coordination (hand-eye): speed, accuracy, timing and rhythm.
• Logic and maths: challenges solved by reasoning power alone. Rubik's cube, puzzles
• Race: time pressure reduces strategic thinking.
• Factual knowledge: Trivial Pursuit, quizzes
• Memory: French Tarot
• Pattern recognition
• Exploration: spatial awareness, locked doors, traps, mazes, teleporters. Should still have challenges, otherwise it's sightseeing.
• Conflict: strategy, tactics, logistics, defend weak units, stealth. Checkers, chess, Heroes of Might and Magic.
• Economic: accumulate resources (RTS), balance a complex economy (SimCity), care for living things (Black and White)
• Lateral thinking: there is no obvious solution.

Actions

Actions are IG events directly and immediately influenced by player's input. Player spends most of her time using actions to overcome atomic challenges. Therefore, particular attention should be given to how actions can overcome basic challenges.

Some actions do not overcome challenges, but provide hooks for unstructured play (honking in a racing game), creation/expression (customizing your avatar), socialization (emotes), and story participation. There are also meta-actions: loading, saving, configurations, exit, ...

Saving

Save files are good for testing and debugging. In general, saving harms immersion and story flow/discovery (player can see different branches by reloading and taking different choices). Always allow the player to save and reload the game. Saving can be implemented through:

• level passwords (levels of Lucky Luke for Gameboy),
• save slots (player can keep copies of his progression and try different things, Doom),
• quick save when pushing a key (Baldur's Gate 2),
• automatic save/checkpoints (mid-level checkpoints in Mario platformer series).

Impact of updates on retention

It does not matter if WoW has around 12 million subscribers. What matters is how many users connect monthly to the game. As shown in my paper, half of the 40% of players who stop playing the game for more than 6 months never freeze their subscription (ie they keep paying but never login). Since they pay, some would consider them active.

Who are those inactive people? It is hard to guess. Therefore, let's flip the question: what are the patterns of (in)activity for various player demographics? By player demographics, I do not mean achievers, explorers, etc. from Bartle or any psychologically-based categorization of players. I would rather focus on the extent to which people play in relation to the game updates, in WoW raiding more particularly.

Category	Ratio of total player pop. (estimate)	Behavior
Pro gamers	<0.05%	Intensive play on PTR right before update deliveries. After four to six weeks, all heroic-mode bosses have been downed by their guild (with eventually some world firsts). Then they stop until the next update.
Dedicated raiders	<10%	This category could be called hardcore, but hardcore is an umbrella term that does not mean much. Those players eventually try out new bosses on PTR. Server-firsts are their goal. They raid three to seven times a week, and spend a considerable time looking for strategies or theorycraft data. Once active guild members have received most of the top-ilevel gear, the raiding activity decreases, and people log in less often. They take a break after 3 to 6 months depending on how dedicated and skilled their guild members are.
Amateur Raiders	>90%	Continuous raiding. They take their time to raid (once to three times a week), and their raids look more like spontaneous pick-up groups than organized expert guilds. Every body complains about the few who really do not pay enough attention and supposedly cause the wipes. Only patient officers spend time reading strategy guides and coach their guild members. These players have content at least until the next update.

Since amateur raiders make up the bulk of the WoW player population, this slow release cycle does not apparently harm the WoW player base so much. However, it seems to me that a diverse range of players (dedicated + amateur, for instance) gives more stability to the player base. Therefore, it might be worth it trying to retain dedicated raiders longer (say, a year's worth of content for each biyearly expansion).
Below, a totally fake graph to show how all this would look like.

Limitations

These qualitative categories may not be the most accurate, but they reflect trends observable in the game, in the few informal player interviews I conducted, and in quantitative studies.

The speed of updates may affect the retention rate of particular player demographics. Blizzard is known for taking its time to release well-polished updates every other year. SOE, on the other hand, has been releasing extensions for EverQuest three times faster: every 8 months on average. What does that mean for retention?

Each player category is affected differently by the gameplay (PvP vs PvE vs PvPvE vs sandbox vs ...). In this article I focused on PvE, but maintaining a top position in the PvP ladder on one's server takes dedication. Another example: the number of EVE Online players has been increasing steadily up to 350k subscriptions, possibly because fans of this kind of gameplay have to be very dedicated. Can these players be considered loyal, though?

Hardcore/casual misconceptions

There are a few well-known gamer stereotypes out there. Let's review the misconceptions about those types and see which useful parts remain.

Hardcore

Dedicated, competitive, and often tech-savvy. Hardcore gamers are also social: they are in charge of their guild, debate on forums, and, more generally, want to be in. They do not only play the game, they also play the metagame. If they have a console, they may buy the latest console FPS or RPG, or at least try it out, and talk about it. If they only play MMOG, they watch for and try out betas, compare game designs, and complain about the lack of innovation. There might be console-fighting-game-only, MMO-only, FPS-only, and other types of hardcore players. Hardcore is an umbrella term for many and diverse player segments. A hardcore niche only makes sense with respect to a particular genre (e.g. FPS), game (StarCraft), or even gameplay mode (auction house golden boys of WoW). In a Marvel vs Capcom 3 tournament, the audience consists mostly of hardcore fighting-game players, not RTS hardcore players.

Pro gamer

Pro gamers are not hardcore gamers. First, they have a manager and are financially sponsored by a brand or a big game studio. Second, they do not share their strategies until they have applied them in tournaments. Lastly, although training is a key part of their success, they may actually play less than hardcore gamers because the metagame is often more important than the game itself. In WoW, for instance, the metagame for pro gamers involves tracking forum posts from game developers or playing only with the basic UI, as tournaments forbid UI addons. Pro gamer teams also track each other's stats.

Casual

Looking at online dictionaries, casual can have different meanings. For gamers, there's at least two distinct categories within the casual umbrella: occasional gamers, or unconcerned gamers.

MMO players who can play for a couple hours every other week are occasional gamers. They may be very focused and play really well during those few others, though. Post-hardcore gamers, who used to consider themselves as hardcore but have found a partner, just got a child, etc. have become occasional gamers. Others like to play games, but have little time to spend in them, and/or do not want to spend too much money in them. This last category of players is referred to as mid-core or softcore.

Unconcerned gamers do not play seriously. They know it's just a game, and the magic circle is often quite thin. As far as time is concerned, 1-minute games while waiting at the bus stop, in the doctor's office, during the commercial breaks, etc. may add up to hours of play per day. Of course, an addiction to Angry Birds does not sound as bad as neglecting one's kids to play Aion 18 hours per day. Short, easy (dumb?), and kawaii-graphics games spread out thanks to smart phone and Facebook apps. Some of those games eventually have a social component (e.g. trading resources in Farmville to complete quests), but it's not what makes them played.

Once again, many do not see the difference between midcore/softcore, post-hardcore, and unconcerned gamers. Casual is a large umbrella term containing many player types. So-called casual games such as Plants versus Zombies sometimes hide intricate mechanics (easy to understand, hard to master). A game like Mario Party 4 could be played very differently by four friends at a party: one could play nonchalantly because she's bored, another competitively because he rocked at the first Mario Party for N64, etc.

Conclusions

• The casual/hardcore distinction is not deep enough (and sometimes inaccurate). Models such as Yee's motivations of play in online games or Bateman's player patterns seem more relevant.
• I suggest the use of personas to conceptualize a typical player. Personas follow a player-centric approach based on qualitative assumptions. When market surveys and large datasets can be expensive, personas are cheap, and everyone in the team, from marketing to design or graphics can benefit from them.
• All players are social. The difference relies in how they are being social.

[Literature] Fundamentals of Game Design, ch 8: User Experience

Rules: be consistent, give good feedback, player should always be in control, few steps to do an action, easy undo/redo, minimize physical stress, no recall, group controls and feedback elements together when they are related, provide shortcuts. No more than 2 clicks between the start/loading screen and actual play.

At all times, the player must be able to answer:

Player question	In-game solution(s)
Where am I?	Minimap, ambient environment sounds
What am I doing right now?	Visual and audio feedback cues
What challenges am I facing?	Quest or mission log
Did my action succeed/fail?	Visual cues
Am I in danger of losing the game?	HP, gauges
What should I do next?	Quest helper

First, define gameplay modes: camera perspective, interaction model (= mapping player input to game actions), and gameplay (= challenges and actions). Then, figure out which visual elements and controls are needed for each UI mode.

Interaction models can be avatar-based (FPS), omnipresent (RTS), party-based (RPG), desktop-like, or contestant (TV game shows).

Solutions for complicated game elements

Solution	Description	Example
Abstraction	Replace a detailed feature by a less accurate one, or aggregate it with another.	Fuel is never seen in racing games
Automation	Let the computer handle the annoying or repetitive parts of a process.	Path finding in RTS is handled by the AI.
Choice of automation	Let the player decide if a feature should be automated or not.	Racing games: manually switching gears is often more efficient than automatic gear.

Broad interface: all buttons are directly on the screen. It takes time to learn and remember where each of them are. Example: plane cockpit.
Deep interface: the information is categorized in hierarchies, menus, and options.
Consoles usually have deep interfaces with menus because there's no mouse pointer and few buttons given to the player. A keyboard, on the other hand, gives a lot of breadth.

The interface should be context-sensitive. Only show the possible actions and buttons in a given situation. Give also visual cues of the consequences. Example: When pointing the cursor to a tree, the pointer should change into an axe.

[Literature] NetGames 2002

Summary of selected papers about MMOG architecture from the NetGames 2002 conference.

Aarhus et al., Generalized Two-Tier Relevance Filtering of Computer Game Update Events.

• Two-tiered means network communication is limited to a dedicated concentrator layer
• TCP
• Consistency within the server layer requires to pass the world state between servers.
• Clients connect to concentrators based on network topology, not their position in the game world.
• The concentrators are constructed to be application independent
• Dead-reckoning schemes
• Clients connect to a concentrator, not to the server logic. Hence, client connection is never lost if a game server crashes.

---

Bharambe et al., Mercury: A Scalable Publish-Subscribe System for Internet Games.

• distributed content-based publish-subscribe system
• subscription language expressive enough to allow game-specific subscriptions (eg x in [10,20] && y <= [40,50], or team == "MyTeam"). In the subscription {x in [10,20] && y >0}, a hub for x is more efficient at relaying an event than a hub for y.
• routing mechanism based on a circle of modular software hubs, each hub storing subscriptions.
• Evaluation: network topology simulator in which nodes are randomly assigned as hubs [unrealistic]
• Metrics:
  • Number of publications routed by a node. All nodes end up having the same routing load (ie scalability achieved).
  • Number of subscriptions stored by a node. Virtual world is a square, hence the central zone receives more players and subscriptions than peripheral zones.
  • Delay for a publication to reach the interested subscribers. Increases linearly with the number of nodes [not scalable!]

---

Cronin et al., An Efficient Synchronization Mechanism for Mirrored Game Architectures.

• Trailing State Synchronization (TSS)
• Optimistic algorithm: execute commands as they are received and rollback when late messages are received.
• TSS runs a delayed "trailing" copy of the live game state. Trailing copy is able to re-order messages and execute them in chronological order.
• It's cheaper to execute a command multiple times than to make snapshots of the game state
• Preserving random events was hard

---

Farber, Network game traffic modelling.

• Traffic modeling from logs of a 36 hour LAN. Matches of 8 to 30 players.
• Server sends 16kbps to each client
• Each client sends 1 kbps to the server
• Both client and server receive 20-25 packets/sec.
• Packet size varies a lot.
• Probability density function of client-server and server-client packet size and latency modeled by Extreme Value distribution: F(x) = exp(-exp(-(x-a)/b)). (long-tail behavior)

---

Fiedler et al., A Communication Architecture for Massive Multiplayer Games.

• World cut in rectangle or hexagon tiles.
• Players subscribe to current and tiles adjacent to closest current tile corner.
• Each tile contains an environment and an interaction channel.
• Environment channel for static data. Static objects generate bandwidth only when someone interacts with them, not by themselves. A static object does not interact with other static objects. Consumes low bandwidth. Uses TCP.
• Interaction channel for active objects. Active objects interact with static and active objects.
• Tiles are managed by one or more servers (n to n relationship). Server only provides constant data such as terrain and objects within the map. Server only cares about the environment channel. Collision detection on clients. Scales with the number of tiles, not the number of clients.
• Authoritative objects are on the machine that instantiates them. Other clients have duplicates/"proxies". Collision detection and other object-object interactions are calculated on clients. Affected object instances publish their updates on the interaction channel of the object's current tile.

---

Griwodz et al., State replication for multiplayer games

• Player-to-player interactions require low latency (= high urgency).
• In case of congestion, less urgent events may be dropped. Results in a game of lower quality, but still running.
• Rare player-to-environment actions require high reliability
• Game designers define when they build the game which actions are urgent and which are relevant.
• Clients connect to a nearby proxy. Proxies are interconnected.
• Participants belong to target groups. Each target group can be contacted through a channel.
• Overlay network of proxies distribute events to target group members.

---

Henderson, Observations on game server discovery mechanisms.

• Analyzing network traffic to know how FPS servers work.
• Game servers register to server directories. Client gets server list from directory using UDP. Same structure as Napster.
• Method: 3 Half-Life US server directories were queried four times a day for a month.
• Problem of directories: single points of failure, stale information (70% of servers not active anymore), redundant info (90% of servers register to all directories), and no congestion control

---

Mauve et al, A Generic Proxy System for Networked Computer Games.

• Move intelligence and server functionality to the border of the network
• Some server functionality can be delegated to the proxies.
• Proxies located close to the players (need ISP support). Therefore, they could execute client code as well (anti-cheat).
• Proxies can reduce the server load in doing packet processing and filtering.
• Overlay network enables traffic rerouting around congested areas, network fault detection and node-failure recovery.