Controlling Project Size for Student/Hobby Videogame Development

Controlling Project Size Chris DeLeon Sept 9, 2011

1997-2001

Vision by Proxy Chris DeLeon Second EdiQon Programmer/Designer 2 million plays / 5 wk Game Dev blog, 10k-‐30k readers/month Technical Game Designer 200+ Experimental Gameplay Projects Establishing member of start-‐up recently Featured 11/2009 acquired by PopCap For “What’s Hot” Reader’s Top 10 2010 Finalist Summer at Will Wright’s Cofounded in 2004, 5+ games/semester

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 DieUnrealistic ScopeFailure to control scopeUnwillingness to cut ScopeSchedule Drags OutLeadership Indecision

One approach: Decades Progression 1970’s 1980’s 1990’s -> ->Complexity Complexity Complexity

Arcade-Style Requires Less Content than Console or home PC StyleArcade often took place all on one screenArcade can vary gameplay by Tweaking stageparameters rather than adding more bosses, etc.Arcade games get away with shorter play sessions

Even mid-80’s Arcade Gets TrickyDon’t underestimatethe work that goesinto art, audio, andcode for an 80’sarcade-style game.This is actually aconsiderable amountof time and work ->Even if you alreadyknow exactly What youAre making… Which is aLuxury we don’t haveFor original concepts!

1. Picking a Foundation

Why Use a LibraryYou should not be re-inventing code to: Load and use image/audio formats Detect real-time input draw lines render textYou need to be at a higher level of abstraction! 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!

Engine Use Can Mess Up (!) Your Gameincreases content quality expectations (esp. if 3d)Digging into API Docs instead of coding the gamePacks Your Design with Implicit Assumptions

But use Some sort of LibraryLibraries: XNA/DirectX, SFML, Allegro, SDL, FlashPunkPart Library, Part Engine: FlixelPossible Exception to the Engine Rule: UnityFlash/ActionScript3 is inherently part-engine: isquirky to work with, but far easier to distribute

2. Starting on the Right Track

Mock-Up Screenshot and 1-page DocNo one reads a 25 (or 5) page design documentEverything 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.

SchedulingThink in terms of min / max / avgPlan from both ends, meet in the middleSpreadsheet with rows as roles, columns as FridaysBottlenecks! prioritize work that enables other work

On Team SizeSmaller teams can be faster Less misunderstanding Less internal documentation Less disagreementAdding more programmers will not get the game donefaster nor make it bigger, but it *will* increase yourchances of never finishing it.(But Some tasks parallel better, e.g. audio, art)

Genre ChoiceVehicles just slide and rotateAbstract puzzle/action is always an optionAnimated human bodies are a big undertakingLazy 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

Can’t decide between equal ways to move forward? Just pick one and go with it! Always have a plan to completionWishy-Washy burns time and effort, confuses teamBegin with a clear (but tentative) weekly planIf you’re changing plans as you, revisit that planto 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 QuestionsWhat questions need answers? At the very least: “what can I do now/next?”Beware of design by committee: prepare proposalsoutside of meetings, then present and DISCUSS!

Tangible Weekly Results Per MemberExpect 1-2 nights/week per developer, more if lead1 coherent contribution from each member weekly Not: I’ll do “More art” / ”More code” this weekIf 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 seriouslyit’s only practice? Then don’t practice not finishingMake a list of what’s left. only let that list shrink! <- not a boat

Bang-for-your-buck tradeoffsPut your effort where it’s going to show90/10 rule: 90% of player focus on 10% of contentNear the end of a project? Hack.“If youre willing to restrictthe flexibility of yourapproach, you can almostalways do something better.” -John Carmack

Cut Scope Aggressively ThroughoutPlan projects with modularity for wiggle roomAlways have a fallback planTriage: 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 onadditional work. Or making the game worse!wrap it up, let it go, learn from it, and move on

Questions? Chris DeLeonHobbyGameDev@gmail.com www.HobbyGameDev.com

Controlling Project Size for Student/Hobby Videogame Development

by Chris DeLeon on Jan 22, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 20

Statistics

Controlling Project Size for Student/Hobby Videogame Development — Presentation Transcript

http://us-w1.rockmelt.com	10
http://a0.twimg.com	10