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

Conclusion

• We all have to end projects

• Hope this helps

• Thanks and questions

jan.svarovsky@kuju.com