Games Development 2 Entity / Architecture Review CO3301 Week 7 - 2

Generalising Game Code This semester, we have looked at a range of related entity-based techniques: Use of templates and entities Entity update and rendering Entity UIDs & messaging Resource Management Text-based data for games – XML Scripting for high-level game logic – Python, Lua All shift away from hard-coded game data / logic Towards more generalised game code Rapid iterations, "offline" changes, reusable code etc.

What happened to the Mesh? In year one we introduced the concept of a mesh: The constant geometry of a scene element Create models from a mesh to populate the scene Only need to load the mesh once Many models can share the mesh data There is other invariant data for scene elements: Concrete features: mesh, animations, sounds Constant game stats, e.g. max HP, top speed etc. Scripts: behaviour, interface Store this common data in an entity template The mesh is now just part of the template data

And the Model? A model was introduced as a mesh instance: A positionable object in the scene Only encapsulated the renderable aspects Only relevant to graphics Scene elements also need to Maintain their own game state (e.g. HP, velocity) Send / receive communication Have behaviours / AI Introduced the entity to capture all these aspects The model is now just part of the data stored by an entity

Names / UIDs vs Pointers Used interface pointers for meshes and models With the move to entities and templates we have added other means of identification Templates and entities are named Entities also have unique identifier (UIDs) An entity manager can map names / UIDs to pointers when necessary UIDs are more efficient (hash-maps) This allows for more abstract game logic: Messaging and scripts using names / UIDs Safer and sometimes easier than using pointers

Entity Update / Messaging The behaviour and interaction of models generally used global functions / data: SceneUpdate Global arrays of data Entities have individual update functions Read messages, update state, perform behaviour SceneUpdate calls entity updates, little global code Use entity class data, little need for global data Entities interact by sending messages Promotes loose coupling: entities don't need to know about each other's operation

Scripted Behaviour / Logic Entity update functions can be written in a scripted language for several benefits: Scripts can be simple yet powerful Rapid iterations, good for testing / tweaking Can be altered at run-time or after release Entities still need to store some data / interface functions But much of their functionality can be scripted Does imply an interface between entity and script [Or maybe not – entire entity system could be in script] Must be careful with performance Scripts are slow to interpret But high-level game logic often not time-critical

Data-Driven Scene Setup SceneSetup has previously been hand-coded: Load each mesh in turn Create and position each model Also set up cameras and lights This is just setting up of a database This code is better replaced by data We could even store entities in a simple database at runtime Now using XML to capture initial game state Entities and templates are created as they are parsed out of an XML file Replacing hand-coded SceneSetup

Component-based Entities Alternative approach for entity architecture Allows functionality to be added / removed from an entity piece-by-piece Great flexibility, works well with text-based data Possible performance problems: Much more messaging Easy to over-architect for the purist – must be practical Requires very careful planning of: Component types needed Interaction between components Can be too flexible and hence difficult to control

Summary Have moved away from programming a game, towards programming a game engine Our game code is much more abstract now The game content and logic can captured using text-based data, scripts and assets Flexible and extensible Only a little game-specific code needed: A few specialised entity classes / components Some overall game control, e.g. user interface Just a flavour of possible game architectures No hard and fast rules here – adapt and innovate