480 likes | 679 Views
Gameplay systems. Mark Nelson mjas@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
E N D
Gameplay systems • Mark Nelson • mjas@itu.dk 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.
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?
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
Composition/aggregation ISa GUI window a rectangle? classWindow : Rectangle {}; Or does a GUI window HAVE a rectangle? classWindow { Rectangle *rectangle; };
Converting is-a to has-a Isolate features into independent classes (components) Components shouldbe as decoupled as possible GameObject as hub, ratherthanancestor
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?