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