Simulation Engines TDA571|DIT030 Architecture and design Tommaso - - PowerPoint PPT Presentation

Simulation Engines TDA571|DIT030 Architecture and design

Tommaso Piazza

1

IDC | Interaction Design Collegium

Software architecture

• Today we will examine the subject of software

architecture

• Examples
• Patterns
• How do we split our game engine into systems

and subsystems?

• How does information flow in our system?
• How do we minimize dependencies?
• How do we maximize the cohesion?

2

IDC | Interaction Design Collegium

First, some fun!

http://www.youtube.com/watch?v=D_p58o6RJ88

3

IDC | Interaction Design Collegium

Definition: Architecture

• There is no universally accepted definition
• One attempt from “Software Architecture in

Practice” (Len Bass, Paul Clements, Rick Kazman)

• Definition: The software architecture of a program or

computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

• In short: Supports analysis and design while

still being simple enough to easily overview.

4

IDC | Interaction Design Collegium

Definition: Architecture

• Another attempt at a definition from “ANSI/IEEE

Std 1471-2000”

• Definition: Architecture is defined by the

recommended practice as the fundamental

• rganization of a system, embodied in its

components, their relationships to each other and the environment, and the principles governing its design and evolution.

• There are hundreds of definitions, but these two

cover the subject fairly well

5

IDC | Interaction Design Collegium

Example: Three tier architecture

• Common architecture for administrative

systems

• Dependencies only go to the right (no mutual

dependencies)

• Allows for the application server to be used with

many different clients (multiple platforms etc)

Client Server Database

presentation model storage

6

IDC | Interaction Design Collegium

Example: 3dwm - Chalmers

7

IDC | Interaction Design Collegium

Example: Crystal Space

8

IDC | Interaction Design Collegium

Example: Ogre3D

9

IDC | Interaction Design Collegium

Architecture and design

• Creating the architecture is part of the design

process

• Architecture is the high-level design on the

structure of the components in a software system

• Defines components involved in the system
• Defines interfaces between components
• Defines constraints in the system
• Does not define an implementation
• Leaves many low-level design decisions

unbounded

10

IDC | Interaction Design Collegium

How to create an architecture

• The easiest way is to already have experience

in building software architectures

• Trial and error!
• Study architecture of existing systems
• Few well-established methodologies
• Curiously non-engineering
• Architecture patterns

11

IDC | Interaction Design Collegium

How to create an architecture

• A few guidelines (a.k.a what do ask yourself)
• Visibility
• Which components need to know about which other

components?

• How do you make them accessible to each other?
• Do you solve component visibility with a global registry or

by sending around references to those that need it?

• Abstraction
• Can you classify your components into different

abstraction layers?

• Can you remove mutual dependencies between

components of different abstraction levels?

12

IDC | Interaction Design Collegium

How to create an architecture

• Responsibility
• Does every component have a clear responsibility that

does not encroach on another component?

• Orthogonality
• Avoid redundancy and make sure that responsibilities are
• rthogonal and adequate
• Associations
• How will information flow between different components?
• What is the cardinality of different components?

13

IDC | Interaction Design Collegium

Design patterns

• From “Pattern Language” (Christopher

Alexander), 1997

• Each pattern describes a problem which occurs over

and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

• Patterns are abstract descriptions of

common problems and effective solutions

14

IDC | Interaction Design Collegium

Design patterns

• Adopted by software engineering in the 90s
• “Design patterns: Elements of Reusable Object-
• riented software” (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) 1995
• Authors known as “The gang of four”
• Still the authorative source on design patterns
• Catalogue of 23 separate patterns
• Name
• Problem description
• Detailed solution
• Nowadays, hundreds of patterns

15

IDC | Interaction Design Collegium

Anatomy of a Design pattern

• Name
• Obviously important since it will be part of the common

terminology for all software engineers

• Problem
• A problem description which tells us when a particular pattern

is applicable (its context)

• Solution
• A description of the elements that make up the design of the

pattern solution, their relationships, responsibilities, and collaborations

• Consequences
• The results and tradeoffs of using the pattern

16

IDC | Interaction Design Collegium

List of Design Patterns

• The initial 23 design patterns

17

IDC | Interaction Design Collegium

Pattern: Singleton

• Problem
• Some classes only have one instance in an entire system. In

addition, this instance should be easily accessible.

• Solution
• Make the class itself responsible for keeping track of its sole
• instance. The class can ensure that no other instance can be

created and it can provide a way to access the instance.

• Consequences
• Controlled access to sole instance. Overuse can case pollution to

the global namespace.

• Implementation
• In C++ (like in Java), we implement the Singleton design pattern

using static member functions and variables.

18

IDC | Interaction Design Collegium

Pattern: Singleton

class PrinterSpooler { private: static PrinterSpooler *_instance; PrinterSpooler(); // private constructor ... public: static PrinterSpooler *instance() { if (_instance == NULL) _instance = new PrinterSpooler(); return _instance; } ...

• };

19

IDC | Interaction Design Collegium

Pattern: Bridge

• Problem
• Capturing different implementations of an abstraction through simple

interface inheritance leads to very rigid couplings between the abstraction interface and the implementations. This can result in major maintenance problems and cross-platform issues.

• Example
• In this example we have a class hierarchy for 3D meshes and

want to extend them with support for terrain meshes. There are different implementations for the OpenGL and DirectX versions.

20

IDC | Interaction Design Collegium

Pattern: Bridge

• We are inadvertently mixing abstractions with
• implementations. Adding a new mesh will also require

platform-specific versions.

• Solution
• If we separate the abstraction and implementations and create a

single bridge between the two, we can avoid these problems.

• Consequences
• Decouples interface and implementation, improves extensibility,

hides implementation details from clients.

21

IDC | Interaction Design Collegium

Patterns in general

• There are three categories of patterns
• Architectural patterns
• High-level patterns specifying the fundamental structure of

a software system.

• Design patterns
• Medium-level patterns to organize subsystem-level

functionality in a system.

• Idioms
• Low-level patterns solving implementation-specific

problems (often on a language level).

22

IDC | Interaction Design Collegium

Patterns in general

• Patterns can also be quantified over phases of

the development process

• Analysis patterns
• High-level solutions to commonly recurring problems on

the analysis level of software systems.

• Design patterns
• Medium-level solutions to commonly recurring problems
• n the design level of software systems.
• For more information, read “Analysis Patterns –

Reusable object models” by Martin Fowler

23

IDC | Interaction Design Collegium

Architectural patterns

• Definition
• An architectural pattern expresses a fundamental structural
• rganization schema for software systems. It provides a

set of pre-defined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

• Different kinds of architectural patterns
• Mud to Structure Layers, Pipes and Filters, Blackboard
• Distributed Systems

Broker, Pipes and Filters, Microkernel

• Interactive Systems

Model-View-Controller, Presentation- Abstraction-Control

• Adaptable Systems

Reflection, Microkernel

24

IDC | Interaction Design Collegium

Pattern: Layers (Layered system)

• Structure applications that can be decomposed

into groups of subtasks at specific levels of

• abstraction. Services of one layer build from

the services of the previous layer.

• Example
• OSI 7-layer network model, Crystal Space, VMs

Benefits Reuse of layers Support for standardization Dependencies are kept local Exchangeability Drawbacks Changing behavior Lower efficiency Unnecessary work Difficulty of establishing correct granularity

25

IDC | Interaction Design Collegium

OSI-7

26

IDC | Interaction Design Collegium

Pattern: Model-view-controller

• Structure applications in such a way that there is a clear distinction between the

visual views, the manipulative controls, and the domain model these two operate upon.

• Model
• Core functionality and data (application-specific)
• View
• User display of model
• Controller
• Handle user input for manipulating model and views
• Example
• Volume controls in Windows

Benefits Multiple & synchronized views Pluggable views and controllers Exchangeability of “look and feel” Framework potential (MFC, Swing, etc)

Drawbacks Increased complexity Tied to view & controller View & controller depend on model interface

27

IDC | Interaction Design Collegium

Pattern: Model-view-controller

28

IDC | Interaction Design Collegium

Break!

http://xkcd.com

29

IDC | Interaction Design Collegium

Game programming Design Patterns

• Design patterns for game programming are

generally categorized in the three core patterns

• f the MVC architectural pattern
• Model = Game World
• Maintains world object state
• View = Renderer
• Draws models
• Controller = Process
• Changes model state based on circumstance

30

IDC | Interaction Design Collegium

Game programming Design Patterns

• General rules
• Models are read-only by views; Views are

invisible to models

• Models are read-write by controllers
• Controllers are created by models, but otherwise

controllers are invisible to models

• Views and controllers are invisible to each other

31

IDC | Interaction Design Collegium

Pattern: Model

• Intent
• Store the state of a game object which exists in the game world
• Motivation
• Games consist of a variety of objects which interact
• Each object tracks its state over time as the game progresses
• Game rules define the transition of these states, and are often

implemented by the controller pattern

• Implementation
• Models are often implemented as polymorphic class hierarchies
• Each type of model is given its own class which extends a base class
• Subclasses often overload basic methods to implement a special trait
• Care is often given to optimizing models for quick access by the view

pattern

32

IDC | Interaction Design Collegium

Pattern: Spatial Index

• Intent
• Speed searches by position in a model database
• Motivation
• Almost all games need to search a model database quickly by

location or region

• Visibility culling
• Picking
• Collision detection
• Implementations
• Binary Space Partition (BSP)
• Quad trees
• X and Y hashes
• Portals

33

IDC | Interaction Design Collegium

Pattern: Type Database

• Intent
• Store information which is common to model types
• Motivation
• There is often a lot of common information concerning
• bjects (artwork, basic stats, etc)
• To avoid duplication and to simplify editing, these are

separated into a database

• Implementation
• Conceptually, static data associated with a model sub-

class

• Often implemented as an independent relational database

indexed by type number or type name

34

IDC | Interaction Design Collegium

Pattern: Type Database

• Examples of fields in a type database
• Prototype state (hit points, strength, etc)
• Size, extends, initial orientations
• Type categorization (offense, defense, etc)
• Execution scripts
• Artwork (meshes, textures, sprites)
• Sound effects
• It is a good idea to provide control of the type

not dependent on writing code

35

IDC | Interaction Design Collegium

Pattern: View

• Intent
• Render the visible models given a viewpoint in the game world
• Motivation
• Renderers are often the most custom part of any game
• Renderers often define the technology in a game and determine the envelope of

design

• Extreme optimizations are common at the expense of maintainability
• Implementation
• The view reads the model database through a spatial index but does not

modify either

• Model is read-only by view
• Spatial index is read-only by view
• View is invisible to model and spatial index
• Communication between a spatial index and a view is often the determining factor

i game performance and is given great attention

36

IDC | Interaction Design Collegium

Pattern: Controller

• Intent
• Update model state based on circumstance
• Motivation
• Controllers implement the rules of a game
• Controllers determine how objects behave given a circumstance and

isolate these rules from the objects themselves

• Makes both controllers and models more reusable and maintainable
• Implementation
• Models are read-writeable by controllers
• Controllers are created and destroyed by models but otherwise invisible
• Views are invisible to controllers and vice-versa
• Controllers are often implemented as processes in a mini cooperative

multi-tasking kernel, but are sometimes hard-wired

37

IDC | Interaction Design Collegium

Pattern: Mini-kernel

• Intent
• Provide each controller with a chance to execute once per game frame
• Motivation
• Without a mini-kernel, model objects are typically updated by a set of

hard-wired controller functions called from the main loop

• Example:

void updateWorld() { for(int i=0; i<numTanks; i++) { if(tanks[i]) { updateTankPhysics(tanks[i]); updateTankAI(tanks[i]); } } ... etc

• Reduces encapsulation and increases maintenance

38

IDC | Interaction Design Collegium

Pattern: Mini-kernel

• Implementation
• Create a base controller class
• A list of controller pointers is maintained
• Each game frame, the mini-kernel calls a virtual

update-method on controllers

• Good opportunity for threading...
• Make sure that update-calls are non-blocking
• Sometimes, the update order might require priority

assignments

• Input, etc

39

IDC | Interaction Design Collegium

Game patterns: Overview

40

IDC | Interaction Design Collegium

Keeping it flexible

• What if you want to change some of the

controllers to modify the models transformations?

• write new controllers
• or...
• use a component approach

41

IDC | Interaction Design Collegium

Component frameworks

• The best solution to avoid monolithic design in a

framework is to base it more or less around independent components

• Definition (from lecture 1)
• “A component is an independent unit of deployment with

contractually specified interfaces and with explicit context dependencies to other external components only.”

• Key points
• Independent – Few or no dependencies
• Unit of deployment – Must deploy the whole component
• Contractually specified interfaces – Clearly defined interfaces as

contracts of the capabilities of the component

• Explicit context dependencies – Any dependencies are explicitly

defined and only to other components

42

IDC | Interaction Design Collegium

Examples of Component frameworks

• CORBA
• OMG's platform-independent and language-agnostic

component model for distributed objects

• Microsoft DCOM/COM/COM+
• Microsoft's Component Object Model for the Windows

platform

• Microsoft .NET
• Microsoft's new model for web services (distributed

components)

• Java Beans
• Java's component architecture as specified by Sun. Allows

for portable Java-style components.

43

IDC | Interaction Design Collegium

Focus: SCF in CrystalSpace

• CrystalSpace is no longer used in this course,

but as it is a good example

• Uses a light-weight component mechanism

called Shared Class Facility

• Well suited for game engine design
• Separates the interface and implementations (called

plugins in SCF)

• Allows for replacing implementations with updated

versions

• Allows for using different implementations

depending on configuration/hardware/etc

44

IDC | Interaction Design Collegium

Interfaces

• Main concept of SCF, like most component frameworks, is

the interface

• Example

//idog.h struct iDog : public iBase { virtual bool IsAlive() = 0; virtual char const* GetName() = 0; virtual void SetName(char const *) = 0; virtual void Shout(int Volume) = 0; virtual void Run(int Speed, float Direction) = 0; virtual bool GetChildren(iObjVector *oBrood) = 0; };

45

IDC | Interaction Design Collegium

Implementations

• Example (note that there can be several implementations)

//mydog.h #include “idog.h” class MyDog : public iDog { private: // private member functions & variables char* Name; public: virtual bool IsAlive(); virtual char const* GetName(); virtual void SetName(char const *); virtual void Shout(char const *msg); virtual void Run(int Speed, float Direction); virtual bool GetChildren(iObjVector *oBrood); ... public member functions & variables ... };

46

IDC | Interaction Design Collegium

Plugins

• mydog.h and mydog.cpp are placed in a plugin, usually as a dynamically

linked library

• A factory method is added to the plugin

static iDog *MyDog_Create() { return new MyDog(); }

• The plugin is accessed with:

csLibraryHandle handle = csLoadLibary(“./libdog.so”); iDog (*iDog_Create)() = csGetLibrarySymbol(handle, “MyDog_Create”); iDog *dog = iDog_Create(); printf(“Doggy's name is %s\n”, dog->GetName()); dog->Shout(“bark”); ...

• Macros can make this easier

47

IDC | Interaction Design Collegium

Plugin meta-information

• The SCF system discovers plugins automatically and dynamically
• Some additional meta-information about each plugin is needed

<?xml version=”1.0”?> <plugin> <scf> <classes> <class> <name>crystalspace.mygame.mydoc</name> <implementation>MyDog</implementation> <description>My Dog Plugin</description> <requires> <class>crystalspace.graphics3d.</class> </requires> </class> </classes> </scf> </plugin>

48

IDC | Interaction Design Collegium

Using SCF and plugins

• When using the plugin, include the interface (idog.h) and not the implementation

// dogtest.cpp #include "cssysdef.h" #include "csutil/scf.h" #include "csutil/cfgfile.h" #include "idog.h" static void test_dog() { csRef<iDog> dog = SCF_CREATE_INSTANCE("MyDog", iDog); if (!dog) fprintf(stderr, "No csDog shared class!\n"); else { dog->SetName("Droopy"); dog->Walk(); dog->Shout("hello!"); printf("Dog's name is %s\n", dog->GetName()); } } int main (int argc, char const **argv) { scfInitialize(argc, argv); test_dog(); iSCF::SCF->Finish(); }

49

IDC | Interaction Design Collegium

Architecture for a Simulation Engine

• So, how do we construct an architecture for our

projects?

• Identify the various components and concepts

important for your engine

• 3D graphics
• Physics
• AI opponents
• ... etc
• Draw a simple diagram of your concepts
• Add associations between concepts
• Rework until you are happy

50

IDC | Interaction Design Collegium

Ogre3D

• Ogre3D is a rendering

engine, not a simulation engine

• The software

engineering can not be based on Ogre3D

• Develop an

architecture that includes Ogre3D as a rendering component

51

IDC | Interaction Design Collegium

Game states

• All kinds of games and simple simulations beyond simple

demos have multiple states

• Introductions
• Menus
• Playing
• The old-school way of doing this is with if-statements,

switches and loops

• Extremely cumbersome in the long run
• Use a game state machine instead
• Each state can be implemented separately without impact on
• ther states
• http://www.ogre3d.org/wiki/index.php/

Managing_Game_States_with_OGRE

52

IDC | Interaction Design Collegium

Summary

• Software architecture is part of the design process and

establishes the main structure of a system without binding low-level details

• Creating good architectures is difficult and is a skill that

requires experience

• Patterns can help us by providing us with previously

collected experience

• Design patterns provide us with solutions to tactical

problems on a medium abstraction level

• Architectural patterns provide strategies on the overall

structure of a software system and its subsystem

• Idioms are implementation-level patterns for solving

particular problems given a particular programming language

53