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

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

Observer:

Below is State:

Strategy:

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

The aesthetics of gameplay: a lexical approach

The aesthetics of gameplay: a lexical approach
Zagal and Tomuro
MindTrek'10

See the PDF or the ACM page.

Primary Elements of Gameplay Aesthetics

Aesthetics cluster	Words in cluster	Description
Pacing	fast, stressful, dull, tedious	The perception of how often game events occur.
Scope	endless, vast, immense, minimal	The size of the possibility space afforded by a game.
Complexity	simple, short, complex, uncomplicated	The measure, or sense, of the number of parts in a system and how they are interrelated.
Demands	hardcore, experienced, retro, demanding	The requirements imposed upon the player by the gameplay
Cognitive Accessibility	deep, unusual, twisted, intricate,	The measure, or sense, of the opacity of a system and the challenges it poses in understanding it.
Impact	addictive, boring, overwhelming, visceral	What we feel games “do to us” when we play them, and how they make us feel.

• Analyzed nearly 400k user reviews posted before April 2009 on gamespot.com. 8k games covered by reviews from 112k users.
• 40% of user reviews contain the word gameplay
• Method: Stanford Parser to perform part-of-speech tagging. Matrix of (723 adjectives total that precede and modify the word gameplay) x (5000 most frequent words that occur before or after the adjective, ie context words, ie words that give a context to the adjective). Cells of the matrix contain number of occurrence of an adjective with a context word. Run kmeans on the matrix to obtain k=30 adjective clusters. (Compared to k=10 or 20, k=30 generated better-looking clusters). Two adjectives are similar (and put in the same cluster) if their context word distributions are similar. Then, give a name to each cluster based on the adjectives it contains.
• Only 2 clusters about narrative elements. Therefore, players have no difficulties separating the formal or mechanical aspects (game mechanics) from their narrative interpretations (representation).
• AI does not emerge as a cluster. Possible reasons: no language to describe game AI, or games AI are not sophisticated enough, or a too recently marketed topic to feature in reviews.
• Genre does not emerge as a cluster.
• Limitations: Gamespot population = 95% males, lots of colloquial words disappeared in cleaning phases.

My remarks

• A group like "fast FPS gameplay" may have been considered as "fast gameplay" because FPS is not an English adjective, and the Stanford parser only looks at English adjectives. Since genre adjectives are not English but rather specific of gamer communities (e.g. "FPS", "RTS", "JRPG", etc.), genre did not appear in clusters.
• It'd be interesting to know which game names occurred most often next to gameplay. For instance, "gameplay like Civilization" may be quite rare, but very meaningful when talking about a niche genre.
• If genre is a label of the dataset, then it could be interesting to cluster a matrix like adjectives x genre. Goal = see which adjectives are explaining most a genre.

Fundamentals of Game Design, ch 14: Strategy Games

Strategy = planning series of actions against the opponent(s). There's usually a large variety of potential actions. Analysis paralysis happens when players have to wait for the other to be done thinking about his next move. In RTS, decisions have to be taken quickly. The basic mechanics of strategy games involve units and the factories that produce them. There can be diplomacy if the scenario is long enough. The attributes of units can be: (max) health, (max) armor, atk, ammo, aspd, area of effect, range, and others ...

Melee unit's value (eg footman) = max HP * shot power * aspd * accuracy * range * walk speed
Ranged static unit's value (eg tower) = max HP * shot power * aspd * accuracy * range^2/2. Squared because the area defended increases quadratically. Halved because units can generally only cover one side/half, the one side towards the enemy.

Most RTS make little use of line of sight and terrain realism; a unit on top of a hill could see further, a unit behind a hill could be hidden from those behind it, units have atk/def/... bonus when they are in their favorite terrain.

Gold is too important for war for mines to be spread out randomly. Spreading randomly means randomly-chosen players get a random advantage from the start, which is unfair. Mines randomly spread also means that players will hunt for mines instead of fighting strategically against each other. Large mines should be positioned symmetrically if they are decisive. Random mines should be smaller and not be decisive for winning.

Lanchester's laws: 1- In melee combat, army strength is proportional to number of units because each fighter can engage only one enemy at once. 2- In ranged combat, units can concentrate their power on a single enemy. When 1 unit is attacked by 3 archers, its life decreases 3 times faster, and it can only attack one of them, ie 1/3 of the enemies. Therefore, 3 ranged units are 3*3=9 times stronger than a single unit (whether ranged or not).

Imagine the tight and strong negative feedback loop: "wounded units attack weaker". Then players have to play sub-efficiently all the time, and they're going to wage attrition skirmishes, not big epic battles.

Do not block or forbid certain units or skills in a particular level. Instead, make the level so that this unit or skill is very inappropriate. Ex: to prevent the player to use air units, give the opponent lots of anti-air missiles. To prevent the use of iron, set the victory condition to "collect lots of iron".

Upgrades

Upgrades can apply to a single unit (veteran units have +1 dmg), all units of a particular kind (grunts get +2 atk), all units of all kinds (Iron Age = +2 def to everyone), or even the whole mechanics (production speed divided by 2). Upgrades can be unlocked by spending resources, time, achievement, ... The tech tree can be:

• totally open: player spends point in any tree she wants, like in WoW
• constrained: finish one branch to start another
• fixed: once player starts in a tree, only this tree is available for the rest of the game

Production and distribution

Production process should be concrete and visible, while the distribution process should be abstracted. Ex: plant farms for food = concrete food production. No supply lines as long as there are roads = abstract supply distribution. There are different shades and techniques for supply lines: troop caravans between cities in Heroes of Might and Magic IV, trade caravans between cities in Civilization series or Age of Empires, or Armored Personnel Carrier that transports troops and fuel in Advance Wars. Another approach is to have cities within a zone of influence to be supplied: cf the influence zone mechanics of Populous (you can only build in your area of influence), Civilization, and Black and White (you can only exert your god powers within your zone of influence).

AI techniques

• Game tree search, as used in games where there is a finite number of possible moves, such as Chess or Checkers. Problem: the search space increases exponentially, which is a problem for games like Go which have too many possible moves.
• Neural networks: patterns are identified after repeated exposure. Problem: training takes time, the system can hardly be tweaked, and adding new patterns means re-training the whole system.
• FSM: units transition from one state (walking) to another (shooting) because of events (enemy appeared in sight). Problem: the unit can only be in one state at once.
• Hierarchical FSM: FSM of the commander gives orders such as "take this hill" to captains. Captains have an FSM that gives orders to soldiers in the squad, such as "cover fire" or "make diversion". Each soldier has its own FSM as well: "if I see an enemy, run for cover". hFSM can create emergent behavior.