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. 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