1. Booting It Out The Door or Just 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. 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