Games Development 2 Entity / Architecture Review

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

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.

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

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

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

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

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

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

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

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