Ad Lib Game Development Society
Zero Lodge
Session 2 (Sunday May 30, 1 day, 6 participants)
Project: Meat My Baby
Participants:
Clare,
Ken,
Lucas,
Shawn,
Squirrel,
Wyeth
Downloads:
Synopsis:
Ken walks in and starts telling us this story about some review he
read in which the reviewer criticizes a certain game by likening
its controls to "guiding a baby through a minefield" (paraphrased).
BOOM. Babies in minefields. But wait... you don't control the
babies directly -- you have to motivate them by launching loud
fireworks to scare them away from dangerous landmines, or by
launching pretty sparklers to attract and steer them towards
their ultimate destination... a meatgrinder. Thus was born:
"Meat" My Baby.
Yeah, we know it's terrible. But oh so funny.
Unfinished business:
Lots. Several things worked: babies crawl around and animate, landmines
animate, babies take damage and perish, however... the fireworks
system never came online in time, so ultimately the game was
left remarkably unfinished.
Postmortem notes
What went right
- Overall concept was very original and funny.
- Interesting high-level design ideas.
- Kickass name.
- Art and animations were a perfect fit -- hilarious and excellent.
- Lots of initial excitement and buy-in; we didn't even consider another idea.
- Programming tasks were enumerated and broken down well.
- Discovered that Art and Code accomplishments can each serve as inspiration for the other ("ooh, cool meat grinder anim, I wanna get that into the game" or "ooh, cool, baby AI is working; I'm gonna go finish up that baby anim").
What went wrong
- Too ambitious: the least-finished project so far as of this writing. We failed to get even basic gameplay up and running, probably because there was nothing "basic" about the gameplay in the design.
- Stayed high-level too long: we should have defined immediate, concrete goals, both short and long-term.
- Setup was disorganized: we wasted a lot of time setting up computers, installing software, cutting network cables, setting up source control, getting and eating lunch, etc. Plus, more than half of the participants showed up quite late.
- Started late: as a group, we didn't actually become productive until almost 2pm.
- Undefined roles: both programmers and artists sort of floated and flitted between poorly defined roles; nobody had a clear picture of exactly what they were supposed to be doing.
- The project lacked a simple, clear direction.
- Shot way too high with the fireworks system; instead of trying to implement a totally generic, data-driven way of specifying firework effects and game mechanics, we probably should have just hardcoded 3 or 5 effects quickly.
- Put too much emphasis on cosmetic functionality (like firework effects and animation) rather than implementing gameplay as quickly as possible.
- Code ramp-up was more costly than expected; bringing other programmers up to speed and helping with usage questions caused the programmer most familiar with the engine to be the least productive.
- Artists couldn't create assets early on as most of the file format decisions and systems hadn't yet been designed.
- Large turnout caused us to grossly underestimate team management complexity and overhead due to coordination and communication.
- Adding more people exponentially exacerbated an already chaotic situation.
- Gaps in the engine forced coders to spend time writing basic foundational systems (text parsing, animation, etc.) instead of concentrating on gameplay systems and game code.
- Artists had to do a lot of "shit work" - how can we make this more fun and engaging for them?
- Tried to keep moving forward with parallel half-implementations rather than serial, iterative first-things-first gameplay steps or tiers.
- Art and design tasks weren't enumerated and broken down like the programming tasks were.
- Artists didn't have a clear picture of what assets to make or what direction to head.
ALGDS and page content are Copyright 2004 Brian
"Squirrel" Eiserloh. Note that neither Brian Eiserloh nor the ALGDS
makes any claims of ownership, expressed or implied, of content
generated by ALGDS Lodge members. All code and content created
in Lodge sessions is owned solely by its individual creators
and governed entirely by the decisions thereof. We do, however,
reserve the right to freely release and redistribute any code,
assets, or games submitted to the ALGDS by their rightful owners
for that purpose.