46 1. Introduction
that I’ll call the gameplay foundations layer (for lack of a standardized name).
Shown in Figure 1.29, this layer provides a suite of core facilities, upon which
game-specifi c logic can be implemented conveniently.1.6.15.1. Game Worlds and Object Models
The gameplay foundations layer introduces the notion of a game world, con-
taining both static and dynamic elements. The contents of the world are usu-
ally modeled in an object-oriented manner (oft en, but not always, using an
object-oriented programming language). In this book, the collection of object
types that make up a game is called the game object model. The game object
model provides a real-time simulation of a heterogeneous collection of objects
in the virtual game world.
Typical types of game objects include
z static background geometry, like buildings, roads, terrain (oft en a spe-
cial case), etc.;
z dynamic rigid bodies, such as rocks, soda cans, chairs, etc.;
z player characters (PC);
z non-player characters (NPC);
z weapons;
z projectiles;
z vehicles;
z lights (which may be present in the dynamic scene at run time, or only
used for static lighting offl ine);
z cameras;
z and the list goes on.
The game world model is intimately tied to a soft ware object model, and
this model can end up pervading the entire engine. The term soft ware object
model refers to the set of language features, policies, and conventions used to
implement a piece of object-oriented soft ware. In the context of game engines,
the soft ware object model answers questions, such as:
z Is your game engine designed in an object-oriented manner?
z What language will you use? C? C++? Java? OCaml?
z How will the static class hierarchy be organized? One giant monolithic
hierarchy? Lots of loosely coupled components?
z Will you use templates and policy-based design, or traditional polymor-
phism?
z How are objects referenced? Straight old pointers? Smart pointers?
Handles?