Game Models - A Different Approach

58
Game Models A Different Approach Nick Prühs July 12, 2013

description

The design and rules of games constantly change during development, invalidating your carefully engineered software from day to day. Entity systems are a great approach for getting rid of the many drawbacks of inheritance-based game models like the “diamond of death”, moving on to a much more flexible aggregation-based model which has been popular since Gas Powered Games’ Dungeon Siege.

Transcript of Game Models - A Different Approach

Page 1: Game Models - A Different Approach

Game ModelsA Different Approach

Nick Prühs

July 12, 2013

Page 2: Game Models - A Different Approach

About Me

„Best Bachelor“ Computer ScienceKiel University, 2009

Master GamesHamburg University of Applied Sciences, 2011

Lead ProgrammerDaedalic Entertainment, 2011-2012

Co-Founderslash games, 2013

2 / 58

Page 3: Game Models - A Different Approach

PART I

ENTITY SYSTEMS

3 / 58

Page 4: Game Models - A Different Approach

Objectives

• To understand the disadvantages of inheritance-based game models

• To learn how to build an aggregation-based gamemodels

• To understand the advantages and disadvantages of aggregation-based game models

4 / 58

Page 5: Game Models - A Different Approach

“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’. Youtalk 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 functionalityand 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 fireup your $5000 UML editor. [...]”

- Scott Bilas

5 / 58

Page 6: Game Models - A Different Approach

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

6 / 58

Page 7: Game Models - A Different Approach

Entities

7 / 58

Page 8: Game Models - A Different Approach

Approach #1: Inheritance

• Entity base class

• that class and its subclasses encapsulate the main game logic

8 / 58

Page 9: Game Models - A Different Approach

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

9 / 58

Page 10: Game Models - A Different Approach

Drawbacks of inheritance-based game models

• Diamond of Death

10 / 58

Page 11: Game Models - A Different Approach

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

11 / 58

Page 12: Game Models - A Different Approach

Where is Waldo?

public override void Update(float dt)

{

this.SystemManager.Update(dt);

this.EventManager.ProcessEvents(dt);

}

12 / 58

Page 13: Game Models - A Different Approach

Where is Waldo?

public override void Update(float dt)

{

this.SystemManager.Update(dt);

this.EventManager.ProcessEvents(dt);

}

13 / 58

Page 14: Game Models - A Different Approach

Where is Waldo?

public override void Update(float dt)

{

base.Update(dt);

this.SystemManager.Update(dt);

this.EventManager.ProcessEvents(dt);

}

14 / 58

Page 15: Game Models - A Different Approach

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

15 / 58

Page 16: Game Models - A Different Approach

Inheritance-based game models are…

• … difficult to develop

• … difficult to maintain

• … difficult to extend

16 / 58

Page 17: Game Models - A Different Approach

“There are probably hundreds of ways…

… you could decompose your systems and come up with a set ofclasses […], and eventually, all of them are wrong. This isn’t to saythat 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 onother 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’sstill an asteroid.”

- Scott Bilas

17 / 58

Page 18: Game Models - A Different Approach

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

18 / 58

Page 19: Game Models - A Different Approach

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

19 / 58

Page 20: Game Models - A Different Approach

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

20 / 58

Page 21: Game Models - A Different Approach

However, we can do better.

21 / 58

Page 22: Game Models - A Different Approach

Approach #2c: Entity Systems

There is no Entity class at all.

22 / 58

Page 23: Game Models - A Different Approach

Approach #2c: Entity Systems

23 / 58

Page 24: Game Models - A Different Approach

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

24 / 58

Page 25: Game Models - A Different Approach

“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-gameobject, and put it into the Entity itself? Nope. Don’tgo there. As soon as you start migrating data into theEntity, you’ve lost. By definition the only valid placefor the data is inside the Component.”

- Adam Martin

25 / 58

Page 26: Game Models - A Different Approach

Example #2: Simple Fight

26 / 58

Page 27: Game Models - A Different Approach

Example #2: Simple Fight

27 / 58

Page 28: Game Models - A Different Approach

Example #2: Simple Fight

28 / 58

Page 29: Game Models - A Different Approach

Example #2: Simple Fight

29 / 58

Page 30: Game Models - A Different Approach

Example #2: Simple Fight

30 / 58

Page 31: Game Models - A Different Approach

Example #2: Simple Fight

31 / 58

Page 32: Game Models - A Different Approach

Example #2: Simple Fight

32 / 58

Page 33: Game Models - A Different Approach

Example #2: Simple Fight

33 / 58

Page 34: Game Models - A Different Approach

Example #2: Simple Fight

34 / 58

Page 35: Game Models - A Different Approach

Example #2: Simple Fight

35 / 58

Page 36: Game Models - A Different Approach

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!

36 / 58

Page 37: Game Models - A Different Approach

Entity Systems – Implementation

DEMO

37 / 58

Page 38: Game Models - A Different Approach

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

38 / 58

Page 39: Game Models - A Different Approach

Disadvantages of Entity Systems (?)

• lookups cause performance hit• resist the urge to add cross-component references – this

would make you lose all of the advantages mentioned before

• just don’t flood your system with unnecessary component types – just as you would always do

• misbelief that it takes longer to “get the job done”• used at the InnoGames Game Jam #3 for creating a

multi-platform multi-player real-time tactics game in just 48 hours – spending the little extra effort at the beginning pays off• Always.

39 / 58

Page 40: Game Models - A Different Approach

Conclusion

• 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

40 / 58

Page 41: Game Models - A Different Approach

PART II

ENTITY SYSTEMS & UNITY

41 / 58

Page 42: Game Models - A Different Approach

Objectives

• To learn how to write .NET libraries for Unity3D

• To learn how to use entity systems with Unity3D

42 / 58

Page 43: Game Models - A Different Approach

Entity Systems & Unity

43 / 58

Page 44: Game Models - A Different Approach

Entity Systems & Unity – Project Structure

• Source folder• Unity project

• Logic project

• Build project

• Unit Tests

• Vendor folder• third party libraries

44 / 58

Page 45: Game Models - A Different Approach

Entity Systems & Unity – Setup

1. Create Unity project as usual.

2. Create shared solution.1. Switch target framework to .NET 3.5.

2. Add Unity project to game solution.

3. Create Build project.1. Add reference to logic project.

2. Write batch file for copying .dlls to the Unity Plugins folder (see next slide).

3. Set post-build event.

45 / 58

Page 46: Game Models - A Different Approach

Entity Systems & Unity – Post-Build Script

REM Copies all libraries to the Unity Plugins folder.

SET PATH_TO_UNITY_PROJECT=%1

SET DLL_TARGET_DIR=%PATH_TO_UNITY_PROJECT%Assets\Plugins\

SET DLL_SOURCE_DIR=%2

XCOPY "%DLL_SOURCE_DIR%*.dll" "%DLL_TARGET_DIR%" /D /Y

Visual Studio Build Event:

$(ProjectDir)PostBuild.bat $(ProjectDir)..\Unity\ $(TargetDir)

46 / 58

Page 47: Game Models - A Different Approach

Entity Systems & Unity – Write Logic Base

• Game class

• GameSystem base class• virtual initialization method

• reference to type-casted game

• GameEvent enum

47 / 58

Page 48: Game Models - A Different Approach

Entity Systems & Unity – Link to Unity

1. Create GameBehaviour passing Unity Start and Update to the logic.

2. Create LogBehaviour passing all logic events to the Unity log.

3. Add game systems, components and events as desired.

4. Add entity-object-map to GameBehaviour.

5. Implement OnEntityCreated an OnEntityRemovedevent handler.

48 / 58

Page 49: Game Models - A Different Approach

Gotcha!

Don’t forget to rebuild the solution!

49 / 58

Page 50: Game Models - A Different Approach

Gotcha!

Don’t forget to add new game systems to your game class!

50 / 58

Page 51: Game Models - A Different Approach

Hint

Override ToString in event data classes for more useful log output!

51 / 58

Page 52: Game Models - A Different Approach

Entity Systems & Unity –Unit TestingAfter all, this is one of the reasons we did that, right?

1. Add the unit test framework of your choice to the Vendor folder (e.g. NUnit).

2. Add unit test project to the solution and add a reference to the framework.

3. Write unit tests as usual.

52 / 58

Page 53: Game Models - A Different Approach

Gotcha!

Don’t forget to initialize, start and update your game in unit tests!

53 / 58

Page 54: Game Models - A Different Approach

Entity Systems & Unity – Setup MonoDevelop

1. Ensure solution file has version 11:

Microsoft Visual Studio Solution File, Format Version 11.00

# Visual Studio 2008

2. Add „After Build“ Custom Command in PostBuildLibraries project options.

54 / 58

Page 55: Game Models - A Different Approach

Future Prospects

• Attribute Tables• store arbitrary key-value-pairs• used for initializing all components of an entity

• Blueprints• consist of a list of components and an attribute table• created with some kind of editor tool by designers• used for creating entites at run-time

• Hierarchical Attribute Tables• used for overloading blueprints with specific entity

attribute values• e.g. reduced initial health

55 / 58

Page 56: Game Models - A Different Approach

Future Prospects

• building physics system outside of Unity• requires own Vector2 and Vector3 data structures (and

conversions)

• position of Unity game objects should always reflect physics position

• converting PDBs to MDBs• provides more verbose debug output in Unity

56 / 58

Page 57: Game Models - A Different Approach

References

• Mick West. Evolve Your Hierarchy. http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/, January 2007.

• Levi Baker. Entity Systems Part 1: Entity and EntityManager.http://blog.chronoclast.com/2010/12/entity-systems-part-1-entity-and.html, December 2010.

• Kyle Wilson. Game Object Structure: Inheritance vs. Aggregation.http://gamearchitect.net/Articles/GameObjects1.html, July 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 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 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 2010.

57 / 58

Page 58: Game Models - A Different Approach

Thank you for your attention!

Contact

Mail

[email protected]

Blog

http://www.npruehs.de

Twitter

@npruehs

Github

https://github.com/npruehs

58 / 58