Simulation Engines TDA571|DIT030 Software Engineering Tommaso - - PowerPoint PPT Presentation

Simulation Engines TDA571|DIT030 Software Engineering

Tommaso Piazza

1

IDC | Interaction Design Collegium

Administrative Stuff

• Any new arrivals?
• Have you booked your first supervision?

Today is the last day!

• Do you know in which group you are in?
• Did you get a hold on everybody in your

group?

• Have you started looking at Ogre3D?
• Fist individual presentation this week!

2

IDC | Interaction Design Collegium

Administrative Stuff

R Extensions!

By the way... simEngines-g#-YouName-Extension

≠

simEngines-gV-... or -YourName-Multimedia

Rename your documents no need to re-share

• Ex. SimEngines-g7-TommasoPiazza-Extension

3

IDC | Interaction Design Collegium

Today’s Lecture in short

• Discuss some of the problems related to

software engineering in game development

• Their solutions
• The most helpful techniques and how to

apply them

4

IDC | Interaction Design Collegium

Introduction

• Developer teams often move directly from

game idea to coding

• Success or failure depends almost entirely on the

skill and experience of the developers

• How do we remove the factor of uncertainty

from this?

5

IDC | Interaction Design Collegium

Definitions

• Definition. [Software Engineering]
• A systematic approach to the analysis, design,

implementation and maintenance of software. There are various models of the software lifecycle, and many methodologies for the different phases

• Definition. [Software Engineer]
• A person who designs and writes and tests

computer programs

• Keywords are “systematic approach” and

“methodologies”

6

IDC | Interaction Design Collegium

Why software engineering?

• Programming in itself is a skill which can relatively easily

be learned. Why do we need software engineering?

• No need for software engineering in a team consisting of
• nly one person
• Modern systems have multiple developers
• Need for software engineering
• Software engineering
• A collection of best-practice methodologies for developing

large software systems in a systematic, deterministic and robust way.

• Separates professionals from beginners

7

IDC | Interaction Design Collegium

Why in games?

• David Braben created Elite and

Elite 2 by himself in the early 80s

• Today, a typical small

development team consists of

• 12-18 members in total
• 4-6 of them are programmers
• Obvious need for methodologies

and software engineering

• Too expensive not to be

methodological

8

IDC | Interaction Design Collegium

Why not just hack it together?

• The hacker, a hero?
• Games programming has a tendency to

attract hackers

• The games development industry is seen as

more laid back than other engineering industries

• Many believe games development is some

kind of “black art”

9

IDC | Interaction Design Collegium

Characteristics of a hacker

• Proficient
• Hackers have a very high technical expertise
• Productive
• Hackers are often highly motivated when facing a technical challenge
• Intelligent
• Hackers are smart and learn new technical skills quickly
• Independent
• Hackers often prefer working alone on a project and dislike outside intervention
• Individualistic
• Hackers have a very strong “prima donna” frame of mind
• NIH syndrome
• Hackers dislike working with products that where “not invented here” or by themselves
• Arrogant
• Hackers are almost always sure that they are right and do not acknowledge outside
• pinions
• Stubborn
• Hackers are often very set in their ways and can be hard to change

10

IDC | Interaction Design Collegium

Hackers and software engineers

• Games programming is not a black art
• Imposing software engineering practices on a

game project will not disrupt the creative process

• Hackerdom has no place in modern large

scale games development

• Team work is more important than technical

wizardry

• A software engineer is ideally the previously

mentioned hacker minus the bad parts

11

IDC | Interaction Design Collegium

How to deal with the hacker

• Make use of the following in your project groups
• Social contract
• A set of rules which determines what to do if

someone is not in time for meetings, how often you have meetings, how to resolve disputes etc.

• Coding standard
• Naming conventions, code layout, idioms,

source code structure etc.

12

IDC | Interaction Design Collegium

Game development aspects according to Gold

• Open-ended design
• Games have an unprecedented control over the feature set
• Heuristic content
• Game content (mainly playability) has to empirically be adapted to the

intended user

• Artistic content
• Games outstrip all other kinds of software when it comes to the amount of

artistic content

• Control methodology
• Most games have a control system that is radically different from other

software applications

• Complexity reduction
• The great diversity of the platforms that games must target imposes

considerable technical challenges in complexity reduction for the programmer

13

IDC | Interaction Design Collegium

The game development process

• We will not try to define yet another three-letter acronym process
• We assume a skeleton process with the following distinct

phases

• Pre-study and requirements
• Identify the goals and target audience of your project, establish the

functional and non-functional requirements, specify the use-cases. Artifacts: Pre-study document, requirement analysis

• Analysis
• Build a conceptual model of the program in the domain, identify the

concepts and their associations and define the functionality of the system as a set of system operations with contracts. Artifacts: Conceptual model, system sequence diagrams...

Tip: a functional requirement defines a function of a software system or its component

14

IDC | Interaction Design Collegium

The game development process

• Design
• Derive the classes and dynamic interaction between

classes for all system operations, employ design patterns, build class architecture. Artifacts: Interaction diagrams, class diagrams, component diagram

• Implementation
• Implement the system operations and use-cases, fulfilling

the contracts, unit test each component. Artifacts: Source code, source documentation

• Testing
• Perform system testing, document and fix any bugs.

Artifacts: Test protocols

15

• Unified Modeling Language
• Tool for object oriented analysis and design
• Introduced in 1997
• International standard
• Object management group, www.omg.org
• Current version is 2.0, but 1.5 still used a lot

(don’t)

• Independent of which development process you

use

• Only rudimentary knowledge in this course

IDC | Interaction Design Collegium

UML

16

IDC | Interaction Design Collegium

UML diagram types

• Class diagram
• The “vanilla” UML diagram type, used for showing the static class

structure in a software system or component

• Use Case Diagram
• Use Case diagrams identify the functionality provided by the

system (use cases), the users who interact with the system (actors), and the association between the users and the functionality.

• Communication diagram
• Collaboration diagrams show the dynamic execution of a system,
• ften based on the system operations that define a use case.

Involved classes are shown as well as their method invocations.

17

IDC | Interaction Design Collegium

Class diagram

• Simple class hierarchy
• Abstract classes
• Methods
• Associations

18

IDC | Interaction Design Collegium

Use Case Diagram

• Example showing the use case diagram for

an ATM-machine

19

IDC | Interaction Design Collegium

Communication diagram

• Example of a simple authentication module
• Sequenced operations show the dynamic

execution of the module and the relations of each class

20

IDC | Interaction Design Collegium

UML diagram types

• Sequence diagram
• Similar to a collaboration diagram, the sequence

diagram shows the dynamic execution of a number of collaborating classes, including their lifecycles

• Component diagram
• Shows the higher-level architecture of a system,

primarily based on components (packages) and their dependencies and associations

• State Machine diagram
• Shows the dynamic behavior of the system, this one

based on conventional state diagrams.

21

IDC | Interaction Design Collegium

Sequence Diagram

• Document the interactions between classes to

achieve a result, such as a use case.

• The sequence diagram lists objects horizontally, and

time vertically, and models messages over time.

22

IDC | Interaction Design Collegium

Component Diagram

• A Component Diagram, is used to describe

the dependencies between various software components such as the dependency between executable files and source files.

23

IDC | Interaction Design Collegium

State Machine Diagram

• Here is an example State Diagram that models that status of a

user's account in a Bug Tracker system

24

IDC | Interaction Design Collegium

UML and Unified Process

• The creators of UML (The Three Amigos)
• Jim Rumbaugh, Object Management Techniquey
• Grady Booch, Booch Method
• Ivar Jacobson, Objector
• Unified their three process models
• The result, UP
• Commercial version called RUP

(www.rational.com)

• UP is aimed at medium to large sized software

teams

25

IDC | Interaction Design Collegium

More on UML (a.k.a. where I picked from)

• UML is huge
• Only rudimentary skills are necessary in this course
• Learn more...
• The course “System development”
• www.uml.org
• http://dn.codegear.com/article/31863
• http://www.sparxsystems.com/uml-tutorial.html
• http://www.dotnetcoders.com/web/learning/uml/

default.aspx

• Books
• Unified Modeling Language User Guide
• UML Distilled by M. Fowler, K. Scott

26

IDC | Interaction Design Collegium

Break!

15 minutes

27

IDC | Interaction Design Collegium

http://www.dilbert.com

Break!

28

IDC | Interaction Design Collegium

What should I present as a software engineers?

• Overview of Software Engineering
• what, why,where,how
• Have a conceptual diagram of your game engine
• extension interaction, dependency separation, general
• rganization
• not required but recommended
• Some details about your plans for the game engine
• Your should come with greater details later on in the

development

• Generally it’s a good idea to come with some slides ( 5 to 10)
• The famous simEngines-g#-YourName-Presentation

document your should have shared with me

29

IDC | Interaction Design Collegium

Game engines as Software Frameworks

• There are three classes of software (Gamma, et.

Al 1995)

• Application programs
• Computer program with a specific purpose geared

towards an end-user

• Toolkits
• A set of related and reusable classes designed to

provide useful, general-purpose functionality

• Frameworks
• A set of cooperating classes that make up a reusable

design for a specific class of software

• Game engines tend to be frameworks

30

IDC | Interaction Design Collegium

Software frameworks

• Definition: Software framework
• A software framework is a set of cooperating classes that

make up a reusable design for a specific class of software

• Typically used to create application programs
• Customized by creating application-specific subclasses of

abstract classes from the framework

• Dictates the architecture of an application, including the
• verall structure, class hierarchy, responsibilities,

collaboration, and thread of control

• Emphasizes design reuse over code reuse by capturing

design decisions common to the application domain

• Often retains control of the thread of execution and calls the

user's code

31

IDC | Interaction Design Collegium

Framework development complexity

32

IDC | Interaction Design Collegium

Monolithic design

• A big danger for simulation engines
• Characteristics of a monolithic design
• Tight coupling
• Classes/subsystems/objects are highly dependent on

each other

• Low cohesion
• Classes/subsystems in the engine have vague and

badly defined responsibilities

• They both work against what we strive for
• Flexibility and reusability!

33

IDC | Interaction Design Collegium

Avoiding monolithic design

• Two major problems
• Too few components have too large responsibilities (low cohesion)
• Dependencies between components are too strong (tight coupling)
• How to remedy
• Refactor!
• Redistribute responsibilities
• Add new classes and modify existing things so that each class has

high cohesion

• Manage dependencies
• Minimize dependencies to external classes and remove

unnecessary associations. Make use of design patterns such as Singleton, Bridge and Mediator.

34

IDC | Interaction Design Collegium

Refactoring

• Refactoring is about improving the design of

existing code

• Alter internally without changing the behavior
• Consider changing everything from variable

names to algorithms

• Ongoing process
• Revisit your code
• Thread carefully
• Do not dig a too deep hole for yourself

35

IDC | Interaction Design Collegium

Dependencies

• “The curse of Hades” according to Gold
• Dependencies force the usage of more components than are

actually needed

• Design your engine so that it is general enough to allow for

using only select parts of it whenever possible

• Remember that dependencies with C++ are transitive
• 1. A → B
• 2. It is not the case that B → A
• 3. B → C

Then the functional dependency A → C is a transitive dependency.

36

IDC | Interaction Design Collegium

A Visual Example

Which one should your code resemble to?

37

IDC | Interaction Design Collegium

Dependencies

• Localize the problem
• Encapsulate the dependencies in toolkits or plugins
• Use design patterns Shield, Bridge, Mediator, etc
• General communication
• Message passing
• Events
• Ogre3D uses plugins
• Easy to extend functionality
• Not necessary to rewrite Ogre3D itself
• Read in Gold 3.3 for more information on handling

dependencies

38

IDC | Interaction Design Collegium

Design patterns

• Design patterns
• Reusable solutions for known software engineering problems
• Antipatterns
• Examples of bad design solutions and how they can be refactored
• The Blob (Antipattern)
• Procedural-style design leads to one object with numerous

responsibilities and most other objects only holding data. A common symptom of this is that you have a single class that seems to do everything in your code.

• Solution
• Refactor the design to distribute responsibilities more uniformly and

isolate the effect of changes.

• http://www.antipatterns.com/dev_cat.htm

39

IDC | Interaction Design Collegium

Reusability

• The main difference between the hacker and

the software engineer

• Reuse code written by yourself and others
• Develop software that encourages future

reusability

• Not a problem in most other industries, but

sadly, in the software engineering industry tools are often rewritten from scratch at the beginning of each project

40

IDC | Interaction Design Collegium

Classes of reuse

• Functional reuse
• Creating subroutines of often-used code and repeatedly calling the routine
• Vertical reuse
• Reuse within current and future projects (i.e. in a specific period of time) (long lifespan)
• Horizontal reuse
• Reuse within a number of concurrently developed projects (short lifespan)
• General reuse
• Combination of horizontally and vertically reusable software, i.e. possibly a game

engine

• Framework reuse
• High-level software framework that provides a software structure based on a specific

paradigm

• Component reuse
• Encapsulated, independent piece of code that can be used in new systems with a

minimum of integration

• Copy-and-paste reuse
• Self explanatory

41

IDC | Interaction Design Collegium

Reusability

• Reusability is a key focus in this course
• Other people should be able to use your engines
• Good way of testing
• Continuously write small demos that use the

engine

• “We never put anything into the technology that

we're not actually going to use. If it's not suitable for one of our games, we're not going to put it in because it can't be torture-tested.” - Mark Rein,

Epic Games

42

IDC | Interaction Design Collegium

RenderWare

43

IDC | Interaction Design Collegium

RenderWare

• Computer game middleware platform
• Developed by Criterion Software
• Game component framework
• Reusable and interchangeable software

components

• Does not impose a strict architecture and

structure (unlike genre-directed engines such as the Quake or Unreal engines)

44

IDC | Interaction Design Collegium

RenderWare

• Original success came from allowing developers

easy access to the PS2 (sometimes referred to as “Sony's DirectX”)

• Contains
• RenderWare platform
• The game development middleware consisting of an

integrated technology suite for graphics, physics, AI and audio

• RenderWare studio
• An integrated game development framework that provides

world editor, database management and a game build pipeline for additional support constructing a game

45

IDC | Interaction Design Collegium

RenderWare

• Has produced more than 500 titles worldwide
• At one time, one in four new console games

used RenderWare

• Used with the Grand Theft Auto and Tony Hawk

games

• Available for use on Windows, Mac OS X,

GameCube, Wii, Xbox, Xbox360, PlayStation 2, Playstation 3, and PlayStation Portable

46

IDC | Interaction Design Collegium

RenderWare

• The RenderWare team worked in accordance to many
• f the software engineering principles described in

this lecture

• Why?
• Huge team
• 230 people spread across 6 cities
• Genericity
• The framework needs to be able to used with any kind of title
• Continuity
• Constantly developed and improved
• Platform support
• The design needs to run on an extreme amount of different platforms

47

IDC | Interaction Design Collegium

RenderWare

• The RenderWare platform contains
• RenderWare graphics
• Cross-platform 3D graphics support with platform-specific
• ptimizations
• RenderWare physics
• Fast physics modeling
• RenderWare AI
• Multi-platform AI middleware
• RenderWare audio
• Real-time audio for multi-platform titles
• Components can be exchanged

48

IDC | Interaction Design Collegium

RenderWare

• RenderWare Studio contains
• FPS Genre design pack
• Example how to use RenderWare to create a FPS. (Genre packs is an interesting

concept)

• Core design tools
• Game object editors for attributes, animations, etc
• Game build process
• Game production pipeline for asset management
• Level building & editing
• Custom level editors for RenderWare
• Structured game database
• Hierarchical game resource database (remember the initial quote for this lecture?)
• Asset management
• Asset management using Alienbrain (a multi-user file management software

system optimized for media content)

• Game framework
• C++ framework for use as a skeleton for a game

49

IDC | Interaction Design Collegium

RenderWare

50

IDC | Interaction Design Collegium

RenderWare

51

IDC | Interaction Design Collegium

Summary

• Game engines are frameworks
• Frameworks are large and require a lot of effort to

develop

• Software frameworks in general and game

engines in particular have a nasty habit to become monolithic

• We avoid monolithic systems by careful

responsibility and dependency management

• A well designed game engine framework with clear

responsibilities and controlled dependencies is easy to reuse

52

IDC | Interaction Design Collegium

Remember!

• Software Engineering will this next week!
• Have you booked you supervision for this

week? Today is the last day!

53