26 January 2013

Game Architecture and Design - part 2 and 3: Management and Architecture

Game Architecture and Design - parts 2: Management and 3: Architecture, by Rollings and Morris, 2004

Ch9 - Current methods of team management

Several developer stereotypes pose problems.

  • Mavericks are skilled and trust no one else.
  • Prima donnas know they are the best and consider others as threats.
  • Shy guys are ... shy, so they don't always say everything, which reduces the project visibility.
  • Sleepers appear nice to their boss, but actually attack the management in their back.
  • Jacks of all trades are overconfident and sell themselves too well. They can get overwhelmed.

Ch16 - Current development methods

Two quotes in this chapter exemplify the two main concerns I have with this book:

  • Games are less original that they used to be. The authors explain further down that in a dozen years, graphics have improved a lot, but gameplay not as much. I disagree: with the blooming indie scene, and more and more games being made every year, this sentence sounds more like nostalgic bitterness than a constructive remark.
  • C++ was considered too slow to be useful for game programming. The authors refer to Michael Abrash and his Assembly skills with so much awe that it gets a bit awkward. I think mentioning Assembly optimizations is worthless, and maybe even detrimental, to a 21st-century introductory book about video games. We have engines and high-level languages now!

Ch17 - Initial design

Tokens are elements of the game directly or indirectly manipulated by the player. Tokenization is the process between game design and implementation. Start with the token interactions and basic state machines, then the token-property interactions, and finally the property-property interactions. Example for Pacman:

Token interactions
Pacman death X X
Ghost eaten X X

And the state machine for the ghosts.

Token-property interactions
Token Properties Hungry Strong Eddible Weak
Hungry X Pacman death Score++ Ghost eaten
Strong Pacman death X X X
Weak Ghost eaten X X X
Eddible X Score++ X X

Ch18 - Use of technology

Game reviewers do not have time, so they give good reviews to the shallowest aspects of games: the graphics, not the mechanics.

Research and development is risky. Why not teaming up with a local university?

Ch19 - Building blocks

A bunch of design patterns useful for game programming. Here's chain of responsibility.


Below is State:


And finally, Template:

Ch21 - Development

  • Plan for reuse
  • Document
  • Design then develop
  • Schedule ad communicate
  • Catch mistakes as you go
  • Limit R&D
  • Know when it is good enough
  • Team ownership/"invisible" management
  • No feature creep
  • Team solidarity

22 January 2013

Game Architecture and Design - part 1: Design

Game Architecture and Design - part 1: Design, by Rollings and Morris, 2004

Ch1 - First concept

Originality can come from the gameplay, story, setting, characters, interface, or technology. It can also come from unexpected combinations. For example, a vampire living on a foggy island must fight against invading pirates. Present it through Indonesian shadow puppets, or Dia de los Muertos, or The Terror in France. It helps to think of movies, books, or music related to the theme.

Ch2 - Core design

Player goals can range from collecting something, gaining territory, racing, removing obstacles (finding keys to open doors), discovering (eg puzzles), or beating/killing other players. Provide means for these goals, and think about the feelings conveyed.

Emergence can be defined as complexity arising from simple rules. That is, rules interacting with rules or the environment. Populous preachers provide an interesting example of emergence. Preachers can convert warriors to their side unless those warriors are already in battle. Thus the first wave of enemy warriors will be converted by the preachers, but the second wave of warriors will fight with the converted warriors instead of being converted. These two simple rules force the player to regularly check her defenses.

Trivial choices are choices the players will always or never take. They should be avoided or left for the computer/AI to perform for the player. For example, when an ennemy unit is in sight, the player's units should shoot.

Ch3 - Gameplay

Synergies (also from slides by Claypool)
of scale of scope
Economy The more of one unit, the cheaper/better/stronger. Ex: making more knights reduces their shadow cost per unit. The more of a set, the better. Ex: trident + net, healer + tank + DPS.
Diseconomy Benefits decrease with quantity. Ex: mixed troops go as fast as their slowest member.

An interesting decision has an upside, a downside, and the payoff depends on circumstances (eg other players, environment, or self). For example, a Starcraft Terran player can choose to upgrade his Marine's attack range or attack rate. If the opponent plays Zergs, upgrading the attack rate is a very good choice. If the opponent plays Protoss, Marines are generally not the way to go (unless for surprise effect in a Marine-Vulture rush).

The shadow cost of a unit is any requirement the player had to pay before buying that unit. For example, knights require the cavalry technology ($100) and stables ($200). Knights can be purchased at the stables for $50. Thus making the first knight has a direct cost of $50 and a total shadow cost of $100 + $200 = $300. So overall, the knight costs $350. Making a second knight still costs $50, but reduces the shadow cost per knight to $300/2 = $150. Overall, making 2 knights costs $50 + $150 = $200 per knight. The tenth knight still costs $50, but decreases the shadow cost per knight to $30. At that point, the overall cost of a knight is $50 + $30 = $80.

Supporting investments are remotely related to the player's goal. For example, one needs to build farms to produce food to feed knights. Farms are a 2-degree supporting investment (farm - food - knights). Upgrading the damage of knights is a 1-degree supporting investment (upgrade - knights).

Costs (whether normal costs, supporting investments, or shadow costs) also depend on the environment. In Age of Empires, a unit costs 40 woods and takes 40 seconds to build. In the early game, things start slowly, so the expensive part is the 40 woods. Mid-game, events happen quickly, so the expensive part is 40 seconds. End-game, wood is depleted, so 40 woods is expensive again.

Strategic (ie long-term) choices will later impact tactical (short-term) choices.

Impermanence is an interesting choice: should I receive armor+100 for 30 seconds, or armor+5 forever?

Versatile choices are good for beginners. In an RTS, speed makes units more versatile.

Ch5 - Balance

Rewards = gameplay payoffs + graphics eye-candy.

Component balance = comparing unit A to unit B.

Attribute balance = comparing attack range to attack power (in a small map, attack range is not as important as attack power).

Ch6 - Look and feel

A list of storytelling techniques.

Obstacles: the player has to decipher/fight/think about the events to make the plot progress

Foreshadowing: prepare for the plot by giving a hint/preview. Ex: in an RTS, a couple clubmen attack my settlement. They were only scouts of a larger army ...

Personalization: saving the world is cliche and bad. Instead, the sexy princess asks ME to save her. Saving the world is a side-effect. The player identifies with his avatar during gameplay AND cutscenes. If the avatar has 2 hours to find a cure for himself, the player cares.

Resonance: The most subtle consists of repeated images that defy instant critical analysis. More direct: visual symbols that directly express the subtext.

Resistance: elements that delay the unfolding of the story. Helps suspend disbelief. The best way to involve the hero in a crazy story is by having him refuse at first. Ex: "please save the president" - "no, i'm retired" (this surprises the audience) - the bad guy kidnaps his daughter - "OK I'll do it"

Plot point: confound expectations or change the story's direction. 3 types: reversal (traitor!), discovery (a change from ignorance to knowledge, usually most effective when paired with reversals), and calamity (Gandalf dies at the beginning of the journey!). Ideally, each level begins and ends with a plot point, ideally during gameplay rather than during a cutscene. Early plot points deepen the story, later plot points clear u[ mysteries. Small plot points every 30 mins, big plot points every 3h.

Suspense: fear and expectation.

Dialogue: not needed if images can convey the idea better. Can give more colorful details.

Theme: Do not answer the questions you ask. Ex in Matrix: What is reality? How powerful is love?

Resolution: should be hard-won (satisfaction from effort), not obvious, satisfying (morally or aesthetically), consistent (with what happened so far), and achieve closure (solve problems of the story). Could use self-sacrifice at the end: when the avatar dies, the story naturally ends for the player.

Change: Change in the status quo causes the action. At the end, the hero must have changed in some ways (he learned or failed to learn something, grew up, ...).