Controlling Project Size for Student/Hobby Videogame Development
3 likes719 views
Chris Deleon's document discusses key strategies for managing small game development projects, emphasizing the importance of controlling project scope and scheduling. It highlights common pitfalls leading to project failure, such as unrealistic expectations and leadership indecision, while advocating for focused planning and the use of libraries to streamline development. The text also underscores the necessity of finishing projects to ensure they are taken seriously by players.
![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 ! !;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!](https://image.slidesharecdn.com/cdeleon-scope-control-120122215407-phpapp01/85/Controlling-Project-Size-for-Student-Hobby-Videogame-Development-12-320.jpg)
Controlling Project Size for Student/Hobby Videogame Development
- 1. Controlling Project Size Chris DeLeon Sept 9, 2011
- 2. 1997-2001
- 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. Game Creation Society Projects
- 5. Don’t Be This Guy
- 6. Confession: I’ve made ‘art games’ …But Not in VGDev, and after I made conventional games
- 7. Why Small Team Projects Die Unrealistic Scope Failure to control scope Unwillingness to cut Scope Schedule Drags Out Leadership Indecision
- 8. One approach: Decades Progression 1970’s 1980’s 1990’s -> -> Complexity Complexity Complexity
- 9. 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
- 10. 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!
- 11. 1. Picking a Foundation
- 12. 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 ! !;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. 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
- 14. 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
- 15. 2. Starting on the Right Track
- 16. 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
- 17. Prev. page mock-up -> real Screenshot
- 18. The Sequel’s mock-up “Screenshot”
- 19. real Screenshot of the Sequel
- 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. 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
- 22. 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)
- 23. 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
- 24. 3. Staying on Track
- 25. Can’t decide between equal ways to move forward? Just pick one and go with it! 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
- 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. 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!
- 28. 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…
- 29. 4. Finishing
- 30. 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
- 31. 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
- 32. 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!
- 33. 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
- 34. Questions? Chris DeLeon HobbyGameDev@gmail.com www.HobbyGameDev.com