1 / 48

Gameplay systems

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

fauve
Télécharger la présentation

Gameplay systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Gameplay systems • Mark Nelson • mjas@itu.dk Fall 2013 www.itu.dk

  2. Gameplay systems Layer that interfaces engine tech and gameplay Levels, goals, objects, behavior, scripting, AI, etc.

  3. Gameplay segmentation Major organizing concept is segmentation Gameplay is usually segmented, sometimes hierarchically Levels Rooms Missions Waves Campaigns Combat / dialog

  4. 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.

  5. Chunks

  6. Game flow

  7. 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

  8. World elements

  9. 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)

  10. Dynamic elements Commonly: Player character NPCs Vehicles Items Projectiles Most game mechanics are concentrated in the dynamic elements

  11. 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

  12. 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

  13. 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)

  14. 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

  15. 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

  16. 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?

  17. Game-world editors Chunk creation/management Game world visualization Object placement/attributes Navigation meshes Attach behaviors to objects Engine-specific

  18. 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

  19. 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

  20. 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)

  21. 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)

  22. Object-centric example (Hydro)

  23. 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

  24. Class hierarchies

  25. Class hierarchies

  26. 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

  27. Multiple inheritance

  28. Multiple inheritance

  29. 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?

  30. Multiple inheritance alternatives Mix-ins Composition Component-based design

  31. 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

  32. Mix-in classes

  33. Composition/aggregation ISa GUI window a rectangle? classWindow : Rectangle {}; Or does a GUI window HAVE a rectangle? classWindow { Rectangle *rectangle; };

  34. Pacman example again

  35. Converting is-a to has-a Isolate features into independent classes (components) Components shouldbe as decoupled as possible GameObject as hub, ratherthanancestor

  36. 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

  37. Component-based modeling if (m_pRigidBody == null), object isn’t affected by the physics system

  38. 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

  39. 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

  40. 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

  41. Runtime versus data-definition Of the externally editable languages, usually two types Data-definition languages JSON XML Runtime scripting Python Lua Javascript

  42. Programming languages axes Interpreted versus compiled? Imperative, declarative, functional? Object-oriented? Reflective?

  43. 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

  44. Game scripting language examples Custom: QuakeC UnrealScript General-purpose: Javascript Python Lua

  45. 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

  46. 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

  47. 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)

  48. 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?

More Related