 |
 |
|
If you enjoy reading this site, you might also want to check out these Think Services sites:
 Game Career Guide (for student game developers.)
 Indie Games (for independent game players/developers.)
 Finger Gaming (news, reviews, and analysis on iPhone and iPod Touch games.)
 GamerBytes (for the latest console digital download news.)
 Worlds In Motion (discussing the business of online worlds.)
 Game Set Watch (the Group's alt.game weblog.) |
|
|
|
| |
Feature: 'Book Excerpt: Game Engine Architecture'
by Staff
|
|
| |
|
November 25, 2009
|
| |
In a new feature article, Gamasutra presents an excerpt from Naughty Dog programmer Jason Gregory's recently released book, Game Engine Architecture. The book contains a massive amount of data on the specifics to consider when developing a game engine.
This excerpt from Chapter 14 covers a typical approach to updating game objects -- but the full feature goes on to explain the flaws in this method:
"The simplest way to update the states of a collection of game objects is to iterate over the collection and call a virtual function, named something like Update(), on each object in turn. This is typically done once during each iteration of the main game loop (i.e., once per frame). Game object classes can provide custom implementations of the Update() function in order to perform whatever tasks are required to advance the state of that type of object to the next discrete time index. The time delta from the previous frame can be passed to the update function so that objects can take proper account of the passage of time. At its simplest, then, our Update() function's signature might look something like this:
"virtual void Update(float dt);
"For the purposes of the following discussions, we'll assume that our engine employs a monolithic object hierarchy, in which each game object is represented by a single instance of a single class. However, we can easily extend the ideas here to virtually any object-centric design. For example, to update a component-based object model, we could call Update() on every component that makes up each game object, or we could call Update() on the "hub" object and let it update its associated components as it sees fit. We can also extend these ideas to property-centric designs, by calling some sort of Update() function on each property instance every frame.
"They say that the devil is in the details, so let's investigate two important details here. First, how should we maintain the collection of all game objects? And second, what kinds of things should the Update() function be responsible for doing?"
The full feature goes on to detail the method of maintaining a collection of active objects, as well as the responsibilities of the update() function, but goes onto explain why these methods are not necessarily viable in a full-scale game engine.
Those details, as well as coverage of object and subsystem interdependencies, bucketed updates, object state inconsistencies, and more, are included in the full feature article, now available on Gamasutra.
|
| |
|
|
