Controlling Project Size

Chris DeLeon Sept 9, 2011

1997-2001

Chris DeLeon Programmer/Designer

Reader’s  Top  10  

Featured  11/2009  For  “What’s  Hot”  

Summer  at  Will  Wright’s  

Technical  Game  Designer  

200+  Experimental  Gameplay  Projects  

Cofounded  in  2004,  5+  games/semester  

Establishing  member  of  start-­‐up  recently  acquired  by  PopCap  

Vision  by  Proxy  Second  EdiQon  2  million  plays  /  5  wk   Game  Dev  blog,  10k-­‐30k  readers/month  

2010  Finalist  

Game Creation Society Projects

Don’t Be This Guy

Confession: I’ve made ‘art games’

…But Not in VGDev, and after I made conventional games

Why Small Team Projects Die

Unrealistic Scope

Failure to control scope

Unwillingness to cut Scope

Schedule Drags Out

Leadership Indecision

One approach: Decades Progression

1970’s Complexity

1980’s Complexity

1990’s Complexity

-> ->

Arcade-Style Requires Less Content than Console or home PC Style

Arcade often took place all on one screen

Arcade can vary gameplay by Tweaking stage parameters rather than adding more bosses, etc.

Arcade games get away with shorter play sessions

Even mid-80’s Arcade Gets Tricky

Don’t underestimate the work that goes into art, audio, and code for an 80’s arcade-style game. This is actually a considerable amount of time and work -> Even if you already know exactly What you Are making… Which is a Luxury we don’t have For original concepts!

1. Picking a Foundation

horiz:! mov es, startaddr ! !;put segment address in es! mov di, 32000 ! !;row 101 (320 * 100)! add di, 75 ! ! !;column 76! mov al,colour ! !;cannot do mem-mem copy so use reg! mov cx, 160! ! !;loop counter! hplot:! mov es:[di],al ! !;set pixel to colour! inc di ! ! !;move to next pixel! loop hplot! vert:! mov di, 16000 ! !;row 51 (320 * 50)! add di, 160! ! !;column 161! mov cx, 100! ! !;loop counter!

Why Use a Library

You should not be re-inventing code to:

Load and use image/audio formats

Detect real-time input

draw lines

render text

You need to be at a higher level of abstraction!

Engine Use Can Mess Up (!) Your Game

increases content quality expectations (esp. if 3d)

Digging into API Docs instead of coding the game

Packs Your Design with Implicit Assumptions

But use Some sort of Library

Libraries: XNA/DirectX, SFML, Allegro, SDL, FlashPunk Part Library, Part Engine: Flixel

Possible Exception to the Engine Rule: Unity

Flash/ActionScript3 is inherently part-engine: is quirky to work with, but far easier to distribute

2. Starting on the Right Track

Mock-Up Screenshot and 1-page Doc

No one reads a 25 (or 5) page design document

Everything changes once it’s in play anyway

Prev. page mock-up -> real Screenshot

The Sequel’s mock-up “Screenshot”

real Screenshot of the Sequel

What would a demo/Lite version need?

Make that your full game’s plan. Just enough to prove it works!

12 item/enemy/car/Level types? No! 3. If it comes out well, do a sequel.

Scheduling

Think in terms of min / max / avg Plan from both ends, meet in the middle

Spreadsheet with rows as roles, columns as Fridays

Bottlenecks! prioritize work that enables other work

On Team Size

Smaller teams can be faster Less misunderstanding Less internal documentation Less disagreement

Adding more programmers will not get the game done faster nor make it bigger, but it *will* increase your chances of never finishing it. (But Some tasks parallel better, e.g. audio, art)

Genre Choice

Vehicles just slide and rotate

Abstract puzzle/action is always an option

Animated human bodies are a big undertaking

Lazy environments: Space, Ocean, Sky, snow fields

(also avoids many path-finding complications)

Nice: Games where level design is number tuning, instead of architected layouts

3. Staying on Track

Always have a plan to completion

Wishy-Washy burns time and effort, confuses team

Begin with a clear (but tentative) weekly plan

If you’re changing plans as you, revisit that plan to figure out what has to be cut to make room

Can’t decide between equal ways to move forward?

Just pick one and go with it!

What New Ideas to Accept?

Does it eliminate previously scheduled, undone work?

WHAT A GREAT IDEA! Does it add new work, or waste finished work?

Save it for the sequel.

Have Meetings to Answer Questions

What questions need answers? At the very least:

“what can I do now/next?”

Beware of design by committee: prepare proposals outside of meetings, then present and DISCUSS!

Tangible Weekly Results Per Member

Expect 1-2 nights/week per developer, more if lead

1 coherent contribution from each member weekly

Not: I’ll do “More art” / ”More code” this week

If work isn’t getting done, try to find a resolution. If no resolution, they may need to be let go (…or active members get frustrated)

It usually isn’t news to that person.

Sometimes people even want to quit,

But don’t know how! Help them out…

4. Finishing

Finishing Matters a Lot

“Almost done” games are really less than 40%

No one will play it or take it seriously

it’s only practice? Then don’t practice not finishing

Make a list of what’s left. only let that list shrink!

<- not a boat

Bang-for-your-buck tradeoffs

Put your effort where it’s going to show

90/10 rule: 90% of player focus on 10% of content

Near the end of a project? Hack.

“If you're willing to restrict the flexibility of your approach, you can almost always do something better.”

-John Carmack

Cut Scope Aggressively Throughout

Plan projects with modularity for wiggle room

Always have a fallback plan

Triage: Forget the first plan, what have we got?

players will never know what you cut!

a Lamborghini is not a polished Yugo

At some point you’re getting diminishing returns on additional work. Or making the game worse!

wrap it up, let it go, learn from it, and move on

+ ≠

Questions?

Chris DeLeon

HobbyGameDev@gmail.com

www.HobbyGameDev.com