<style box background>This mini-lecture will present an overview of the major components of a computer game (i.e. the major subsystems; the main loop; the key role of time; game state; subsystem communication; game entities or objects).</style>

<style center> Today's goal:
to become familiar with the overall internal structure of a game. </style>

Technically, videogames are interactive real-time simulations with graphical displays and audio.

• Ideally, we want the major subsystems to be as modular (decoupled) as possible
  • Each system should view other systems as a black box, regardless of how complicated they are internally
  • Communication should occur through narrow, well-defined interfaces
• All the systems are collaborating on updating, or presenting the evolving state of the game
• Designing this game state in which many systems are interested while maintaining modularity is the fundamental architectural challenge designing a game engine

Video games are have a fairly natural decomposition into subcomponents

• Major systems should have well defined boundaries and communication paths
• They are probably going to be implemented by different people
• Need to manage the complexity

What does a game do?

• Takes user, and maybe network inputs and generates a displayed frame, and some sound effects
• This involves the co-ordination of dozens of major subsystems, hundreds of minor subsystems, and thousands of entities

“Outer loop” of a game, handles:

• Setup/shutdown of the application
• Managing the high-level game state
  • Front-end, in-game, paused, etc.
• Controlling overall game flow (order-of-operations)
• Updating the major subsystems

The “game kernel” can be structured in various ways:

• VERY expensive w.r.t. resources.
• screen gets updated 24 times per second (every second)
• use the video card (!)
• 3 parts of the graphics system:
  • object level
  • geometric level
  • rasterization level

• [color=green]mostly still playing diegetic & non-diegetic sounds.[/color]?diegesis
  
• can be sounds played from clip or something more sophisticated (synthesis)

• Asset Management / Loading / Pipelining
• Script

• primary driver/controller
• must work in real time - using resources left over after graphics
• includes
  • Physics engines
  • object location
  • world / environment states
  • NPC control
  • status control

• only part of the system players see
• [color=green]Front-end[/color]
  
• [color=green]H.U.D.[/color]

One of the most important aspects of game architecture is time.

• How time is handled should be designed into the architecture from day one.
• Inconsistent handling of time throughout the game will create difficult to fix bugs, and frustrating game-play.
• Be clear as to the units of time used in variable names and function calls.

• Rule of time: Game time is constant regardless of frame rate.
  • “Game time” must always be aligned to “real time”.
• A car traveling at 100 km/h must travel the same distance when the game is updating at 60 fps as it is when the game is updating at 20 fps.
  • Not 33 km/h at 20 fps!
  • In some situations “game time” may run at a different speed
• In sports games, clock is often accelerated
• When game is paused, “game time” doesn’t change
  • Old PC games often got this wrong.

• The collection of information that represents a snapshot of the game universe at a particular time
  • Position, orientation, velocity of all dynamic entities
  • Behaviour and intentions of AI controlled characters
  • Dynamic, and static attributes of all gameplay entities
• Scores, health, powerups, damage levels, etc.
• All sub-systems in the game are interested in some aspect of the game state.
  • Renderer, Physics, Networking, and Sound systems need to know positions of objects
  • Many systems need to know when a new entity comes into or goes out of existence
  • AI system knows when player is about to be attacked – sound system should play ominous music when this happens

• How is the game state made available to subsystems?
  • Global state
  • Push/Pull (client server) based models
  • Managers
  • Broadcast-listener
  • Database
  • Shared entities
• Can also use different systems for different types of state

• Many different ways to structure the entity system
  • Single rooted inheritance hierarchy
  • Multiple inheritance
  • Ownership based
  • Component based
• A modern game must manage of dozens-to-thousands of independent entities.
  • e.g. A unit of an RTS game: Position, orientation, health, current orders, animation frame

Intro to Game Architecture Annotated Power Point slides by Jeff Ward ( Associate Programmer, Bethesda Game Studios). Last Update Feb. 2007; Jeff Ward was involved in the development of Oblivion.

Game Architecture A somewhat elderly article by Richard Bartle, well known for his work with virtual worlds.

Project Darkstar Game Architecture A few notes on the overall architecture of Sun's Darkstar Project.

Designer's Notebook: The Role of Architecture in Videogames (The Primary Function of Architecture in Games) By Ernest Adams, October 9, 2002 http://www.gamasutra.com/features/20021009/adams_02.htm

Designing and Integrating Puzzles in Action-Adventure Games By Pascal Luban, December 6 2002 http://www.gamasutra.com/view/feature/2917/designing_and_integrating_puzzles_.php

The Elder Scrolls IV: Oblivion (2005) [PC, Xbox 360] Developed by Bethesda, Published by Microsoft

Crawford, C. The Art of Computer Game Design, 1982. http://www.vancouver.wsu.edu/fac/peabody/game-book/Coverpage.html

Parker, J. R. (2005). Start Your Engines: Developing Racing and Driving Games. Scotsdale, AZ: Paraglyph Press. http://www.paraglyphpress.com/startyourengines/ ; http://www.ucalgary.ca/~jparker/racinggames.html