1 / 33

Booting It Out The Door or Just Getting the Thing Finished

Booting It Out The Door or Just Getting the Thing Finished. Jan Svarovsky Kuju Entertainment. 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.

meira
Download Presentation

Booting It Out The Door or Just Getting the Thing Finished

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related