Introduction to and analysis of aggregation-based game models, featuring an assignment and demo with uFrame.

1. Game Programming
Component-Based Entity Systems
Nick Prühs

2. About Me
“Best Bachelor“ Computer Science
Kiel University, 2009
Master Games
HAW Hamburg, 2011
Lead Programmer
Daedalic Entertainment, 2011-2012
Co-Founder
slash games, 2013
Microsoft MVP
2015
2 / 79

3. Objectives
• To understand the disadvantages of inheritance-
based game models
• To learn how to build an aggregation-based game
model
• To understand the advantages and disadvantages of
aggregation-based game models
3 / 57

4. “Say you’re an engineer…
… set out to create a new Game Object System from scratch, and you’re going to ‘do it right the first time’. You
talk to your designer and say ‘What kind of content are we going to have in this game?’
They respond with ‘Oh lots of stuff, trees, and birds, and bushes, and keys and locks and … <trailing off>’
And your eyes glaze over as you start thinking of fancy C++ ways to solve the problem.
The object oriented programming sages tell you to try to determine Is-A relationships and abstract functionality
and all that other fun stuff. You go to the book store and buy a C++ book just to be sure, and it tells you to fire
up your $5000 UML editor. [...]”
- Scott Bilas
4 / 57

5. Entities
5 / 57

6. Entities
6 / 57

7. Entities
7 / 57

8. Entities
8 / 57

9. Entities
9 / 57

10. Entities
10 / 57

11. Entities
• object in your game world
• can (or cannot)…
• be visible
• move around
• attack
• explode
• be targeted
• become selected
• follow a path
• common across all genres
11 / 57

12. Entities
12 / 57

13. Approach #1: Inheritance
13 / 57

14. Approach #1: Inheritance
• Entity base class
• that class and its subclasses encapsulate the main
game logic
14 / 57

15. Example #1: Unreal Engine 3
• base class Actor
• rendering
• animation
• sound
• physics
• almost everything in Unreal is an Actor
• Pawn extends by taking damage
• Projectile extends by spawning impact effects
15 / 57

16. Drawbacks of inheritance-based game models
• Diamond of Death
16 / 57

17. Drawbacks of inheritance-based game models
• code added to the root of the inheritance tree
causes big overhead
• code added to the leafs of the tree tends to get
copied
• root and leaf classes tend to get very big
17 / 57

18. Where is Waldo?
public override void TakeDamage(int damage)
{
this.Health -= damage;
}
18 / 57

19. Where is Waldo?
public override void TakeDamage(int damage)
{
this.Health -= damage;
}
19 / 57

20. Where is Waldo?
public override void TakeDamage(int damage)
{
base.TakeDamage(damage);
this.Health -= damage;
}
20 / 57

21. Drawbacks of inheritance-based game models
• always need to understand all base classes along
the inheritance tree
• impossible to enforce calling base class functions
• Someone will forget it. Trust me.
• And you’re gonna spend your whole evening finding that one
missing base.Update().
• deep class hierarchies will more likely run into call
order issues
21 / 57

22. Inheritance-based game models are…
• … difficult to develop
• … difficult to maintain
• … difficult to extend
22 / 57

23. “There are probably hundreds of ways…
… you could decompose your systems and come up with a set of
classes […], and eventually, all of them are wrong. This isn’t to say
that they won’t work, but games are constantly changing,
constantly invalidating your carefully planned designs. [...]
So you hand off your new Game Object System and go work on
other things.
Then one day your designer says that they want a new type of
“alien” asteroid that acts just like a heat seeking missile, except it’s
still an asteroid.”
- Scott Bilas
23 / 57

24. “alien” asteroid
24 / 57

25. Approach #2: Aggregation
25 / 57

26. Approach #2: Aggregation
26 / 57

27. Approach #2: Aggregation
• popular since Gas Powered Games’ Dungeon Siege
• introduced long before
• entities are aggregations of components
• which in turn encapsulate independent functionality
• corresponds to recommendations by the Gang of Four
• “favor object composition over class inheritance”
• similar approach is used by the Unity3D game engine
• just for clarification: Unreal uses components as well, called
ActorComponent
27 / 57

28. Approach #2a
• create an Entity class
• add references to all available components
• has obvious disadvantages:
• many component references will be null pointers for
most entities
• big unnecessary memory overhead
• Entity class has to be updated each time a new
component is introduced
28 / 57

29. Approach #2b
• create an Entity class
• introduce a common base class for components
• entities hold a collection of Component objects
• reduced the memory overhead
• increased extensibility
• already gets close to an optimal solution
• easy to build, maintain and debug
• easy to implement new design ideas without breaking
existing code
29 / 57

30. However, we can do better.
30 / 57

31. Approach #2c: Entity Systems
31 / 57

32. Approach #2c: Entity Systems
32 / 57

33. Approach #2c: Entity Systems
• game entities are nothing more than just an id
• thus, no data or methods on entities
• no methods on components, either: all
functionality goes into what is called a system
• PhysicsSystem
• HealthSystem
• FightSystem
• entirely operate on their corresponding
components
33 / 57

34. “All the data goes into the Components.
All of it. Think you can take some “really common”
data, e. g. the x-/y-/z-coordinates of the in-game
object, and put it into the Entity itself? Nope. Don’t
go there. As soon as you start migrating data into the
Entity, you’ve lost. By definition the only valid place
for the data is inside the Component.”
- Adam Martin
34 / 57

35. Example #2: Simple Fight
35 / 57

36. Example #2: Simple Fight
36 / 57

37. Example #2: Simple Fight
37 / 57

38. Example #2: Simple Fight
38 / 57

39. Example #2: Simple Fight
39 / 57

40. Example #2: Simple Fight
40 / 57

41. Example #2: Simple Fight
41 / 57

42. Example #2: Simple Fight
42 / 57

43. Example #2: Simple Fight
43 / 57

44. Example #2: Simple Fight
44 / 57

45. Inter-System Communication
Systems communicate by the means of events, only.
• no coupling between systems
• easy to add or remove systems at any time
• great architectural advantage for general game features
• need multiplayer? just send the events over the network!
• need AI? just make it create events which are handled just
like player input is!
• need replays? just write all events with timestamps to a file!
45 / 57

46. Inter-System Communication
46 / 57

47. Advantages of Entity Systems
• update order is obvious
• components can easily be pooled and re-used
• independent systems can be updated by separate
threads
• data can easily be serialized and stored in a
database
47 / 57

48. uFrame ECS
48 / 12

49. uFrame ECS
DEMO
49 / 12

50. Assignment
1. Reduce Health of attacked entities.
2. Remove killed entities.
50 / 12

51. Assignment
1. Reduce Health of attacked entities.
2. Remove killed entities.
Hint
First, think about the components (data), systems
and events you might need!
51 / 12

52. Assignment
1. Reduce Health of attacked entities.
1. Add an AttackComponent with a Damage property.
2. Add a HealthComponent with a Health property.
3. Add groups for attacker and defender entities.
4. Add a DamageSystem modifying these components.
2. Remove killed entities.
52 / 12

53. Assignment
1. Reduce Health of attacked entities.
1. Add an AttackComponent with a Damage property.
2. Add a HealthComponent with a Health property.
3. Add groups for attacker and defender entities.
4. Add a DamageSystem modifying these components.
2. Remove killed entities.
1. Add a HealthChanged event.
2. Raise the HealthChanged event in the appropriate
system.
3. Add a DefeatSystem destroying defeated entities.
53 / 12

54. Assignment
3. Add a random value to the damage caused by
each attack.
4. Reduce damage taken by an Armor value of the
attacked entity.
5. Implement leveling up entities, increasing their
current Health and Damage.
54 / 12

55. Assignment Solution
Publicly available at
https://github.com/npruehs/teaching-ecs-uframe
55 / 12

56. Takeaway
• inheritance-based game models show a lot of
disadvantages
• entity systems are easy to maintain and debug
• provide great extensibility without the necessity of
modifying existing code
• show better performance characteristics for both
memory and CPU load
• easy to implement commonly used features
• scripting
• serialization
• logging
56 / 57

57. References
• Mick West. Evolve Your Hierarchy. http://cowboyprogramming.com/2007/01/05/evolve-your-
heirachy/, January 5, 2007.
• Levi Baker. Entity Systems Part 1: Entity and EntityManager.
http://blog.chronoclast.com/2010/12/entity-systems-part-1-entity-and.html, December 24,
2010.
• Kyle Wilson. Game Object Structure: Inheritance vs. Aggregation.
http://gamearchitect.net/Articles/GameObjects1.html, July 3, 2002.
• Adam Martin. Entity Systems are the future of MMOG development – Part 1. http://t-
machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-
1/, September 3, 2007.
• Adam Martin. Entity Systems: what makes good Components? good Entities? http://t-
machine.org/index.php/2012/03/16/entity-systems-what-makes-good-components-good-
entities/, March 16, 2012.
• Scott Bilas. A Data-Driven Game Object System.
http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides_with_notes.pdf, Slides,
GDC 2002.
• Scott Bilas. A Data-Driven Game Object System.
http://scottbilas.com/files/2002/gdc_san_jose/game_objects_paper.pdf, Paper, GDC 2002.
• Insomniac Games. A Dynamic Component Architecture for High Performance Gameplay.
http://www.insomniacgames.com/a-dynamic-component-architecture-for-high-performance-
gameplay/, June 1, 2010.
57 / 57

58. Thank you!
http://www.npruehs.de
https://github.com/npruehs
@npruehs
dev@npruehs.de