Professional Documents
Culture Documents
Controlling Project Size For Student/Hobby Videogame Development
Controlling Project Size For Student/Hobby Videogame Development
1997-2001
Chris DeLeon
Programmer/Designer
Readers Top 10
Unrealistic Scope Failure to control scope Unwillingness to cut Scope Schedule Drags Out Leadership Indecision
1970s Complexity
->
1980s Complexity
->
1990s Complexity
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
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
No one reads a 25 (or 5) page design document Everything changes once its in play anyway
What would a
demo/Lite
version need?
Make that your full games plan. Just enough to prove it works!
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
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
4. Finishing
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
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!
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?