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

Simulation Engines TDA571|DIT030 Software Engineering Tommaso Piazza 1

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! IDC | Interaction Design Collegium 2

Administrative Stuff By the way... simEngines-g#-YouName-Extension ≠ simEngines-gV-... or -YourName-Multimedia Rename your documents no need to re-share Ex. SimEngines-g 7 -TommasoPiazza- Extension R Extensions! IDC | Interaction Design Collegium 3

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 IDC | Interaction Design Collegium 4

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? IDC | Interaction Design Collegium 5

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 ” IDC | Interaction Design Collegium 6

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 only 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 IDC | Interaction Design Collegium 7

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 IDC | Interaction Design Collegium 8

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” IDC | Interaction Design Collegium 9

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 opinions  Stubborn ‣ Hackers are often very set in their ways and can be hard to change IDC | Interaction Design Collegium 10

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 IDC | Interaction Design Collegium 11

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. IDC | Interaction Design Collegium 12

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 IDC | Interaction Design Collegium 13

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 IDC | Interaction Design Collegium 14

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 IDC | Interaction Design Collegium 15

UML  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 16

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, often based on the system operations that define a use case. Involved classes are shown as well as their method invocations. IDC | Interaction Design Collegium 17

Class diagram  Simple class hierarchy  Abstract classes  Methods  Associations IDC | Interaction Design Collegium 18

Use Case Diagram  Example showing the use case diagram for an ATM-machine IDC | Interaction Design Collegium 19

Communication diagram  Example of a simple authentication module  Sequenced operations show the dynamic execution of the module and the relations of each class IDC | Interaction Design Collegium 20

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. IDC | Interaction Design Collegium 21

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. IDC | Interaction Design Collegium 22

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. IDC | Interaction Design Collegium 23

State Machine Diagram Here is an example State Diagram that models that status of a  user's account in a Bug Tracker system IDC | Interaction Design Collegium 24

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 IDC | Interaction Design Collegium 25