controlling project size for student/hobby videogame development
Post on 19-Oct-2014
1.500 views
DESCRIPTION
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.TRANSCRIPT
Controlling Project Size
Chris DeLeon Sept 9, 2011
1997-2001
Chris DeLeon Programmer/Designer
Reader’s Top 10
Featured 11/2009 For “What’s Hot”
Summer at Will Wright’s
Technical Game Designer
200+ Experimental Gameplay Projects
Cofounded in 2004, 5+ games/semester
Establishing member of start-‐up recently acquired by PopCap
Vision by Proxy Second EdiQon 2 million plays / 5 wk Game Dev blog, 10k-‐30k readers/month
2010 Finalist
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 Die
Unrealistic Scope
Failure to control scope
Unwillingness to cut Scope
Schedule Drags Out
Leadership Indecision
One approach: Decades Progression
1970’s Complexity
1980’s Complexity
1990’s 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-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!
1. Picking a Foundation
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!
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!
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 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.
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
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
Can’t decide between equal ways to move forward?
Just pick one and go with it!
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: 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…
4. Finishing
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
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
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 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
+ ≠