Introduction. How are games similar/different from other software engineering projects? Common software engineering models & game development

Transcription

1 SOFTWARE TECHNIQUES

2 Introduction How are games similar/different from other software engineering projects? Game Design & Art Common software engineering models & game development Waterfall, spiral, etc. Agile software engineering models Extreme programming, Scrum Practical advice Development speed and ease Code quality Modularity and reuse Cross platform development

3 What makes games different? Economics of game development follow entertainment, not software Publisher/industry/consumer pressures are huge, and shift randomly Fixed cost, packaged goods vs service model Content & design components of project They behave differently from a requirements and scheduling standpoint Sometimes you can't tell if it's right 'till it's done Fun is particularly hard to pin down Add large content integration phase missing from other types of projects Don't fit into narrow classifications Part embedded system, part real-time multimedia, part database

4 What makes games similar? It's software! (Duh) The general phases of development are the same Most of the problems are the same Bad estimates Changing requirements Fluctuating teams Games tend to be like regular software projects on steroids We can screw up in 6 months to a degree that would take someone years if they were writing an operating system or a word processor

5 Code, Game Design and Art A game is really three projects running in parallel Cross dependencies can be large, but you need to work to minimise them Designers and artists shouldn't need code work to get new content into game Given unlimited time, they needn't be done in parallel Having solid design, before starting anything else is great Never happens, but at least having enough of an idea of what's going on to start tech and art is usually doable. Having solid technology before even beginning content creation This does actually happen sometimes, when companies have lots of time and resources, or purchase tech.

6 Standard software models: The waterfall model Waterfall model Requirements -> Design -> Code -> Integrate -> Ship Pros : Simple, in all software engineering textbooks Big up front design makes it look like you know what you are doing Cons : Doesn't work Particularly for games Content is too different from code, can't late integrate Need working game sooner than end Publishers want milestones Gameplay must be tested

7 Standard software models: Iterative models Prototype driven and iterative models work better for game development You need a prototype To satisfy publishers To give designers something to work with To show demos for promotional purposes Publisher and design pressures will cause requirements to change, so you will need to iterate anyway Can integrate content and code in each cycle Less risky than large integration

8 Standard software models : spiral model Spiral model Requirements -> Risk Assessment -> Prototype -> Evaluate -> Repeat Needed to add content integration phase at end of each prototype phase Would work great in theory, but often falls down in practice Some big up-front design generally required by management / publisher Risk assessment is a good idea, but hard in practice, no one seems to understand it for games (design in particular) External pressures often shorten/remove subsequent evaluation, requirements and risk assessment phases

9 Standard software models: prototyping Default model for games If you don't plan at all, you will be using coral growth prototyping as your primary software engineering technique Throwaway prototyping Use the first prototype as a test-bed for ideas. Once issues have been resolved, chuck it and start over with your new knowledge Need to be careful to try and solve real issues Need to be even more careful about really throwing it away Evolutionary prototyping Like throwaway, but you plan to keep you prototype (instead of accidentally keeping it) Need to refactor a lot

10 Standard software models : hybrids Radical's process is a hybrid model Lots of design up front, like waterfall Some of this is really necessary Some is just to satisfy the publisher Now that we are owned by a publisher, we do less snow job documentation Shift into evolutionary prototyping mode once development starts Sometimes there is a throwaway prototype as well We tend to base our throwaway prototypes on existing games

11 Agile software engineering methods New class of solutions aimed at brittleness of standard techniques Iterative models, taken even further Pioneered by extreme Programming (XP) Scrum, Rational Unified Process, are also popular technique Lots of game developers will look at the techniques and say Hey, we're already doing that

12 Key features of agile techniques Short milestones, frequent integration Very little up front design Systems are designed closer to when they are implemented Feature oriented XP User Stories, Scrum Feature Backlog Focus on tight communication Pair programming, scrum meetings Test driven design Shift power to the production personnel We recommend that you follow some variation of these techniques

13 Practical advice Development speed and ease Source control Testbed / sandbox environments Iteration is key Replicability Demo / journalling Maintaining code quality Code reviews Refactor judiciously Functional tests Defensive programming (asserts) asserts are often better than robustness too many asserts can slow down development if failure can in practice be recovered from

14 Practical advice Modularity and reuse Make interfaces to systems as narrow as possible Minimize entry points to big systems Reduce dependencies Don't have pointers into other systems internal data Don't get too clever Never rewrite COM when cut and paste will do Premature optimisation/pessimisation Cross platform development Build on multiple platforms from day one Abstract in the right places To much abstraction can be just as bad a too little Beware the lowest common denominator

15 Conclusion Keep in mind how games are different from standard software Code, design, art distinction Pick and choose techniques from a variety of methodologies Prototyping is a key technique Helps conquer the it is fun on paper problem With your assignment schedule, an agile development process would be very beneficial Read these three books: The Mythical Man Month Frederick Brooks Code Complete and Rapid Development Steve McConnell

16