Controlling Project Size

Chris DeLeon Sept 9, 2011

1997-2001

Chris DeLeon
Programmer/Designer

Vision by Proxy Second EdiQon

2 million plays / 5 wk Game Dev blog, 10k-30k readers/month

Technical Game Designer

200+ Experimental Gameplay Projects

Readers Top 10

Featured 11/2009 For Whats Hot 2010 Finalist

Establishing member of start-up recently acquired by PopCap

Summer at Will Wrights

Cofounded in 2004, 5+ games/semester

Game Creation Society Projects

Dont Be This Guy

Confession: Ive 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

1970s Complexity

->

1980s Complexity

->

1990s 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-80s Arcade Gets Tricky

Dont underestimate the work that goes into art, audio, and code for an 80s 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 dont have For original concepts!

1. Picking a Foundation

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

!;row 51 (320 * 50)! !;column 161! !;loop counter!

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 its in play anyway

Prev. page mock-up -> real Screenshot

The Sequels mock-up Screenshot

real Screenshot of the Sequel

What would a

demo/Lite

version need?

Make that your full games 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

Cant decide between equal ways to move forward?

Always have a plan to completion

Just pick one and go with it!

Wishy-Washy burns time and effort, confuses team Begin with a clear (but tentative) weekly plan

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

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: Ill do More art / More code this week If work isnt getting done, try to find a resolution. If no resolution, they may need to be let go (or active members get frustrated) It usually isnt news to that person. Sometimes people even want to quit, But dont 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 its only practice? Then dont practice not finishing Make a list of whats left. only let that list shrink!

<- not a boat

Bang-for-your-buck tradeoffs

Put your effort where its 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 youre 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