mark nelson [email protected] gameplay systems fall 2013
TRANSCRIPT
Gameplay systems
Layer that interfaces engine tech and gameplay
Levels, goals, objects, behavior, scripting, AI, etc.
Gameplay segmentation
Major organizing concept is segmentation
Gameplay is usually segmented, sometimes hierarchically Levels Rooms Missions Waves Campaigns Combat / dialog
Gameplay segmentation
Temporal and/or spatial segmentation
One common approach: Chunks: segments of a level, of medium size Game flow graphs: graph of gameplay objectives and chunks
See also: José P. Zagal, Clara Fernández-Vara, Michael Mateas (2008).
Rounds, levels, and waves: The early evolution of gameplay segmentation. Games and Culture 3(2): 175-198.
Gameplay segmentation
How/why to segment?
Gameplay reasons
Technical reasons (usually memory)
Content-pipeline reasons
Segments in each case could but don’t have to be the same
Static elements
Commonly: Terrain Buildings Roads Bridges
Does not include purely graphical elements (e.g. skybox) Objects in the world that interact with gameplay but don’t
move themselves (much)
Dynamic elements
Commonly: Player character NPCs Vehicles Items Projectiles
Most game mechanics are concentrated in the dynamic elements
Static v. dynamic continuum
Not necessarily a hard boundary
Common to have semi-dynamic static objects Destructible terrain: often implemented as sort-of static, swapping between
three static objects for ”undestroyed” / ”half-destroyed” / ”destroyed”
Where to draw the line? Efficiency: static objects can skip some kinds of updates Gameplay: static objects are assumed to be inert by default
Static v. dynamic continuum
One guideline: ”Staticness” means not participating in some gameplay systems
Example: Buildings are treated as ”static” by the physics system, instead of as objects
with very large mass and velocity 0.0.
Can have fine levels of static/dynamic granularity per gameplay system, but usually group into a smaller number
Game object models
What is in your game world, and its attributes/behaviors
Pac-Man Four ghosts, each w/ different AI Level 1’s layout/walls Some fruit Some pellets (some already eaten)
Game object models
Object-oriented object models: Types of objects in the game (Pac-Man, ghost, pellet) Instances of objects actually in the world (1 Pac-Man, 4 ghosts, 50 pellets) Attributes of objects: defined per-type, values set per-instance Behaviors of objects: member functions / methods
Often extensible via inheritance Blinky inherits ghost type but overrides some behavior
Code-driven engines
Early games were mostly code-driven Instantiate game objects via hard-coded C++ instantiation Change levels/objects/behavior by changing code
Computationally efficient, simple, but doesn’t scale to larger teams
Engineers become content bottleneck
Data-driven engines
Engine provides framework, game data loaded from files Levels, models, scripted behaviors, etc.
Game data can be edited by artists/designers using external editors, without engineering in the pipeline
Different levels of data-drivenness E.g. Are object types externally extensible?
Game-world editors
Chunk creation/management Game world visualization Object placement/attributes Navigation meshes Attach behaviors to objects
Engine-specific
Tool-side versus runtime object models
Tool-side object models not always the same Editor might not have the same concept of OO hierarchy Single game object in the editor might instantiate as multiple runtime objects
in the engine Tool-side object models can be very simple: object ID with associated data
and resources
Balance of ease of use (on both sides) and ease of mapping
Midpoint summary
Games (usually) need a game object model Data-driven engines have tool-side models, externally
editable, that are loaded into runtime game objects
Games are segmented into chunks/levels/etc.
Often a split between static and dynamic objects
Dynamic game object model
Spawn and destroy game objects Link to low-level subsystems Real-time simulation of object behaviors Object management (queries, IDs, etc.) Scriptability (finite state machines, embedded scripting) Network replication Saving games (object persistence)
Object model architectures
Object-centric Object is represented by a class Or, a small collection of interconnected instances Class encapsulates attributes and behavior
Property-centric Object is represented by only a unique ID Properties of an object distributed among tables Behavior implicitly defined (by collection of properties)
Object-centric example (Hydro)
Only a few object types Boats (player-controlled, AI-controlled) Floating boost powerups (blue, red) Ambient animations (animals on trackside) Water surface Ramps Waterfalls Particle effects Track sectors Static geometry (buildings, terrain) 2d HUD
Deep + wide hierarchies
Temptation to do philosophy instead of game design Classify all possible entities taxonomically
More practically Difficult to understand behaviors deep in a hierarchy – too many levels of
inherited/overridden behavior ”bubble-up effect” – base classes have to make sense for everything derived
Multiple inheritance troubles
Widely considered problematic, at least in C++ Collisions between members with same names Complex resolution rules Many companies’ in-house C++ coding standards prohibit it
But still conceptually needed What do we do about amphibious vehicles?
Mix-in classes
Some kinds of classes are ”enhancement-only” (mix-in), not real standalone object types
Use multiple inheritance, but every object has only one ”real” parent, plus any number of mix-ins
Mix-ins add properties/behavior
Composition/aggregation
IS a GUI window a rectangle?class Window : Rectangle {};
Or does a GUI window HAVE a rectangle?class Window{
Rectangle *rectangle;};
Converting is-a to has-a
Isolate features into independent classes (components) Components should be as decoupled as possible GameObject as hub, rather than ancestor
Component-based modeling
GameObject aggregates specific types of components
if (component==null) instance does not have that specific type of component
Behavior managers look for and act on objects’ non-null components
Component-based modeling
Component-based models can be more or less pure
Less pure: Still have an inheritance hierarchy, but use components to simplify it
More pure: Objects are nothing but aggregations of optional components New kinds of objects are just new kinds of aggregations
Property-based modeling
Limit case of component-based models Objects are just IDs that index properties, like in a DB
Pros: Memory efficient Emergent behavior
Cons: Objects are just bags of properties, don’t ”really” exist Emergent behavior
Scripting
Object model captures some dynamic behavior Spawning/removal ”Normal” motion and interactions
Sometimes want to factor out complex or special-case behavior into bundles of code When player steps on this button, [run code] Attach script to button, instead of defining a one-time-use button subclass Often, easier to externally edit also
Runtime versus data-definition
Of the externally editable languages, usually two types
Data-definition languages JSON XML
Runtime scripting Python Lua Javascript
Programming languages axes
Interpreted versus compiled?
Imperative, declarative, functional?
Object-oriented?
Reflective?
Game scripting languages
Typically: Interpreted Lightweight interpreter Support for rapid iteration Convenience and ease of use Goal is often halfway between ”real programming” and no programming
UnrealScript
Custom UDK scripting language Tightly integrated into engine/toolchain
C++ style syntax Allows extending the UDK class hierarchy Latent functions (execution divided across frames) Data members linked to UnrealEd Network replication for multiplayer games
Lua
Common choice for embedding third-party language
Free embeddable interpreter Used in lots of products (WoW, Photoshop Lightroom) Good performance Cross-platform Documentation exists Someone else maintains/bugfixes
Architectures for scripting
Scripted callbacks Extending game object with script Scripted components or properties Script-driven engine system Script-driven game (engine is more of a library)