1. Games Development 2 Entity / 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