Booting It Out The Door or Just Getting the Thing Finished

1. Booting It Out The DoororJust Getting the Thing Finished Jan Svarovsky Kuju Entertainment

2. Introduction • Scope of talk and definitions • So how do you finish a game • Issues that face you • Solutions to get your to your goal • Prevention - making it easier next time • Conclusion and questions

3. Definitions - Audience • Programming • But decision-makers • Yet not programming • Code is the glue that holds art / design together • With power comes responsibility • Therefore talk strays into management

4. Definitions

5. Definitions - “Endgame” • Deliberately woolly definition • Alpha / beta vary from game to game • Especially small projects may not have them • It’s more a state of mind • Finishing not adding features • Deadlines looming • Starting to realise it’s going to be tough • Me!

6. Definitions - “Finished” • Everything is negotiable • TRC / TCR / … • PC / Mobile can have patches • Version 2 • Often it’s in everyone’s interest to pass milestone • Feature creep

7. Definitions - “Finished” • There are stages • Alpha / beta / milestones / publishers • Of varying importance • Ultimate deadline is gold master • Still negotiable, may never have been set • Something that someone might want to buy • Always should have this one in mind

8. Issues that face you

9. Issues • Current status • Existing problems • Final status • Defining what you need to achieve • Getting from one to the other • what will get in your way

10. Current status • Code • Gameplay • or “everything else” • mechanics • eg “you can double-jump” and “there are 3 species” • content • levels, storyline • even custom puzzles

11. Current Status - code • Slow • Too much memory • Applies to CPU, GPU, sound • Buggy • Not finished • Wrong platform

12. Current Status - Gameplay • Mechanics • We have control over this, have to implement it • Not finished • Is it fun? • Content • We have to provide a smooth pipeline • Employ twice as many artists on half-speed pipe?

13. Current Status • Not a problem! • Of course it’s not finished, slow, buggy • It didn’t exist at all to begin with!

14. What is the current status? • Overall game • Chances are no-one’s played the game • Most people looking after their own section • Completeness < perceived completeness • Code • No-one’s sure what’s complete • Or how buggy it is

15. Final Status • Feature creep • Feature removal • The pipeline is part of your product • There’s a code pipeline too

16. Getting from one to the other • Code and data rot • Personnel coming and going • Fixing bugs rather than leaving them • Things that slow you down • header files • too much interconnectedness

17. Solutions

18. Solutions • Mostly it’s about people and the process • First section will be specific code fixes • Afterwards “the rest” • I’ll imagine I’ve just turned up on your project

19. Specific code fixes • Consoles have duplicated data • Go back to “legacy” level load system for PC • Memory / Size • Often large easy fixes available • Overload operator new() to tag memory • and similar for textures / sounds • Number of allocations just as bad as size

20. Operator new void *all_blocks; void *operator new(size_t Size, const TCHAR *tag) { void *retval = malloc(Size + 8); // create memory with extra space if (!retval) return NULL; *(void **)retval = all_blocks; // link all blocks together *all_blocks = retval; ((const TCHAR **)retval)[1] = tag; // label the memory return retval; } CTexture *tex = new(“Frontend”) CTexture(…);

21. Optimisation • Vtune / Aprobe / SN Tuner / etc • Always bigger optimisations at higher level • Do you need that many line checks? • Do you need poly/poly collision far away? • Bigger optimisations at even higher level • Do you need collision at all? • Do you need that many objects • Look outside programming

22. General fixes • Believe TRC / TCR’s / etc • And that they’re there to help you • Multiplayer game for feature testing • The AI behaviour emerges from humans • Game doesn’t need to be so complete

23. People • Work hard! • Why? Because it’s their game • Keep hassling people • Force people to play the game • Testers don’t mean you can avoid your job • Think outside your bit • True of everyone not just leads

24. People - task lists • You need to give people something to do • But they have to see the forest for the trees • Civilians’ voices example • Everyone’s just typing typing typing

25. People - overlapping • To start with, easily definable tasks • Towards the end, things overlap • “it crashes” - who’s to fix? • Why is this not true on a building site? • All code can affect all other code • Why is this not as true in bank systems? • Efficiency over tidiness

26. People - nerves • Make big changes • It’s never too late • actually, I do have an example where it might be • People err on the side of not changing • Tiptoeing round increasingly unstable system

27. Prevention • It’s never too late • So this overlaps with “fixes”

28. Pipeline • Time from change being made to tested • Load times • Easy to optimise • Resource creation • resource machine becomes the bottleneck • Towards the end, this becomes painful • Things are more set in stone • Optimisations to loading may slow down resource generation

29. Code Pipeline • Compile times • header files, precompiled headers • “Thing.h” • Extract out system dependency • You’ll be changing that lots at the end

30. Pipeline • Avoid rot with error testing code • Sensible defaults (eg green texture, flashing) • “Human-readable” errors • Errors as near as possible to their fix • Animation editor example • People must care about it

31. Scalability • Especially on PC, but true on consoles • LOD based on distance • Not just of gfx, but of gameplay if you can • You’re always pushing the engine • You don’t commit to spec until later

32. Issue avoidance • “it’ll all be ok in the end” • Make the game complete earlier • Vertical slice • Gameplay shouldn’t rely on final art

33. Conclusion • We all have to end projects • Hope this helps • Thanks and questions jan.svarovsky@kuju.com