Simulation Engines TDA571 DIT030 Architecture and design. Tommaso Piazza

Transcription

1 Simulation Engines TDA571 DIT030 Architecture and design Tommaso Piazza

2 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?

3 First, some fun!

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

5 Definition: Architecture Another attempt at a definition from ANSI/IEEE Std Definition: Architecture is defined by the recommended practice as the fundamental organization 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

6 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

7 Example: 3dwm - Chalmers

8 Example: Crystal Space Abstraction Layers for component that build and rely on each other

9 Example: Ogre3D

10 Architecture and design Creating the architecture is part of the design process Architecture is the high-level structural design 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

11 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

12 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?

13 How to create an architecture Responsibility Does every component have a clear responsibility that does not interfere another component? Orthogonality Avoid redundancy and make sure that responsibilities are orthogonal and adequate Associations How will information flow between different components? What is the cardinality of different components?

14 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

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

16 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

17 List of Design Patterns The initial 23 design patterns

18 Pattern: Singleton

19 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 cause pollution to the global namespace. Implementation In C++ (like in Java), we implement the Singleton design pattern using static member functions and variables.

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

21 Pattern: Bridge

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

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

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

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

26 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 on the design level of software systems. For more information, read Analysis Patterns Reusable object models by Martin Fowler

27 Architectural patterns Definition An architectural pattern expresses a fundamental structural organization 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

28 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

29 OSI-7

30 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 View Core functionality and data (application-specific) 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

31 Pattern: Model-view-controller

32 Break!

33 Game programming Design Patterns Design patterns for game programming are generally categorized in the three core patterns of the MVC architectural pattern Model = Game World Maintains world object state View = Renderer Draws models Controller = Process Changes model state based on circumstance

34 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

35 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

36 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

37 Pattern: Type Database Intent Store information which is common to model types Motivation There is often a lot of common information concerning objects (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 subclass Often implemented as an independent relational database indexed by type number or type name

38 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

39 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

40 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

41 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

42 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

43 Game patterns: Overview

44 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

45 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

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

47 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

48 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; };

49 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... };

50 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

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

52 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(); }

53 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

54 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

55 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 other states Managing_Game_States_with_OGRE

56 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