Controlling Project Size       Chris DeLeon        Sept 9, 2011
1997-2001
Vision	  by	  Proxy	  Chris DeLeon                                                     Second	  EdiQon	  Programmer/Design...
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...
One approach: Decades Progression  1970’s            1980’s            1990’s             ->                ->Complexity  ...
Arcade-Style Requires Less Content  than Console or home PC StyleArcade often took place all on one screenArcade can vary ...
Even mid-80’s Arcade Gets TrickyDon’t underestimatethe work that goesinto art, audio, andcode for an 80’sarcade-style game...
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 l...
Engine Use Can Mess Up (!) Your Gameincreases content quality expectations (esp. if 3d)Digging into API Docs instead of co...
But use Some sort of LibraryLibraries: XNA/DirectX, SFML, Allegro, SDL, FlashPunkPart Library, Part Engine: FlixelPossible...
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 it...
SchedulingThink in terms of min / max / avgPlan from both ends, meet in the middleSpreadsheet with rows as roles, columns ...
On Team SizeSmaller teams can be faster  Less misunderstanding  Less internal documentation  Less disagreementAdding more ...
Genre ChoiceVehicles just slide and rotateAbstract puzzle/action is always an optionAnimated human bodies are a big undert...
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-Was...
What New Ideas to Accept?Does it eliminate previously scheduled, undone work?WHAT A GREAT IDEA!Does it add new work, or wa...
Have Meetings to Answer QuestionsWhat questions need answers? At the very least:              “what can I do now/next?”Bew...
Tangible Weekly Results Per MemberExpect 1-2 nights/week per developer, more if lead1 coherent contribution from each memb...
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 pract...
Bang-for-your-buck tradeoffsPut your effort where it’s going to show90/10 rule: 90% of player focus on 10% of contentNear ...
Cut Scope Aggressively ThroughoutPlan projects with modularity for wiggle roomAlways have a fallback planTriage: Forget th...
a Lamborghini is not a polished Yugo                  +At some point you’re getting diminishing returns onadditional work....
Questions?     Chris DeLeonHobbyGameDev@gmail.com www.HobbyGameDev.com
Upcoming SlideShare
Loading in …5
×

Controlling Project Size for Student/Hobby Videogame Development

1,627 views

Published on

Brief introductory talk for the VGDev student videogame development club at Georgia Tech, highlighting basic concepts to help keep student/hobby-sized projects realistic and completable.

1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
1,627
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
15
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Controlling Project Size for Student/Hobby Videogame Development

  1. 1. Controlling Project Size Chris DeLeon Sept 9, 2011
  2. 2. 1997-2001
  3. 3. 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  
  4. 4. Game Creation Society Projects
  5. 5. Don’t Be This Guy
  6. 6. Confession: I’ve made ‘art games’…But Not in VGDev, and after I made conventional games
  7. 7. Why Small Team Projects DieUnrealistic ScopeFailure to control scopeUnwillingness to cut ScopeSchedule Drags OutLeadership Indecision
  8. 8. One approach: Decades Progression 1970’s 1980’s 1990’s -> ->Complexity Complexity Complexity
  9. 9. 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
  10. 10. 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!
  11. 11. 1. Picking a Foundation
  12. 12. 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!
  13. 13. 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
  14. 14. 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
  15. 15. 2. Starting on the Right Track
  16. 16. Mock-Up Screenshot and 1-page DocNo one reads a 25 (or 5) page design documentEverything changes once it’s in play anyway
  17. 17. Prev. page mock-up -> real Screenshot
  18. 18. The Sequel’s mock-up “Screenshot”
  19. 19. real Screenshot of the Sequel
  20. 20. 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.
  21. 21. 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
  22. 22. 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)
  23. 23. 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
  24. 24. 3. Staying on Track
  25. 25. 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
  26. 26. 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.
  27. 27. 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!
  28. 28. 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…
  29. 29. 4. Finishing
  30. 30. 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
  31. 31. 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
  32. 32. 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!
  33. 33. 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
  34. 34. Questions? Chris DeLeonHobbyGameDev@gmail.com www.HobbyGameDev.com

×