Mark Nelson mjas@itu.dk

Gameplay systems

Fall 2013 www.itu.dk

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.

Chunks

Game flow

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

World elements

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)

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

Class hierarchies

Class hierarchies

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

Multiple inheritance

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?

Multiple inheritance alternatives

Mix-ins

Composition

Component-based design

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

Mix-in classes

Composition/aggregation

IS a GUI window a rectangle?class Window : Rectangle {};

Or does a GUI window HAVE a rectangle?class Window{

Rectangle *rectangle;};

Pacman example again

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

if (m_pRigidBody == null), object isn’t affected by the physics system

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

Game scripting language examples

Custom: QuakeC UnrealScript

General-purpose: Javascript Python Lua

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)

Miscellaneous issues

How to interact with native game objects? How much of the semantics to abstract/expose?

Events Can objects send events? Can objects receive events? Are events broadcasts? Can scripts define new kinds of events?

Multithreading?