booting it out the door or just getting the thing finished jan svarovsky kuju entertainment
TRANSCRIPT
Booting It Out The Dooror
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
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
Definitions
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!
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
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
Issues that face you
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
Current status
• Code
• Gameplay– or “everything else”– mechanics
• eg “you can double-jump” and “there are 3 species”
– content• levels, storyline
• even custom puzzles
Current Status - code
• Slow
• Too much memory
• Applies to CPU, GPU, sound
• Buggy
• Not finished
• Wrong platform
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?
Current Status
• Not a problem!– Of course it’s not finished, slow, buggy– It didn’t exist at all to begin with!
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
Final Status
• Feature creep
• Feature removal
• The pipeline is part of your product– There’s a code pipeline too
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
Solutions
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
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
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(…);
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
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
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
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
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
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
Prevention
• It’s never too late
• So this overlaps with “fixes”
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
Code Pipeline
• Compile times– header files, precompiled headers– “Thing.h”
• Extract out system dependency– You’ll be changing that lots at the end
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
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
Issue avoidance
• “it’ll all be ok in the end”
• Make the game complete earlier– Vertical slice– Gameplay shouldn’t rely on final art
