March 22, 2006
This Gamasutra article highlights some intriguing real world experiences in rapid prototyping:
The project started in Spring 2005 with the goal of discovering and rapidly prototyping as many new forms of gameplay as possible. A team of four grad students, we locked ourselves in a room for a semester with three rules:
- Each game must be made in less than seven days,
- Each game must be made by exactly one person,
- Each game must be based around a common theme i.e. "gravity", "vegetation", "swarms", etc.
As the project progressed, we were amazed and thrilled with the onslaught of web traffic, with the attention from gaming magazines, and with industry professionals and academics all asking the same questions, "How are you making these games so quickly?" and "How can we do it too?"
We lay it all out here. Through the following tips, tricks, and examples, we will discuss the methods that worked and those that didn't. We will show you how to slip into a rapid prototyping state of mind, how to set up an effective team, and where to start if you've thought about making something new, but weren't sure how. We hope these well-tested guidelines come in useful for you and your next project, big or small!
Few of us have the luxury of protyping games, but the principles they outline (embrace failure, use short cycles, etc) are broadly applicable to all software development.
Posted by Jeff Atwood
I wouldn't say creating game prototypes so swiftly is a "luxury" :P Gamedev is about as fun as normal dev, just prettier.
Thought this quote was intersting:
"Once we hit development, we found each other to be more of a distraction than anything else – as each person was fully immersed in their own efforts."
Sort of goes against a main tenet of XP. I must admit; pair programming just "ain't" for me either. I think the solitude of being alone with one's thoughts during development is critical. I think "selective" pairing is fine to troubleshoot and brainstorm, but not as a primary way of coding. IIRC Jeff, McConnell touches upon this in Code Complete somewhere no? Or maybe I'm thinking of Maguire's Debugging the Development Environment...
I think the solitude of being alone with one's thoughts during development is critical. I think "selective" pairing is fine to troubleshoot and brainstorm, but not as a primary way of coding
Yeah, that quote intrigued me too, as did the graph showing the "value of working together" was of most use at the beginning and end of the cycle. I want on-demand, low-friction pairing rather than mandatory pairing!
I liked the "formal brainstorming has a 0% success rate" anecdote as well.
I think the solitude of being alone with one's thoughts during development is critical.
the aggressive lack of this facility in Corporate CubeLands goes a long way to explaining why such software generally sucks. OTOH, M$ (up to a few years ago anyway) was reknowned for giving every developer an office. I recall that went from all singles to some doubles; but never CubeLand. wonder whether that's still true?
"...was reknowned for giving every developer an office."
In Steve MacGuire's "Debugging the Development Environment", he mentions that. He also talks about email strategies like only reading email in the AM, noon and late PM. Pretty much what current productivity guru's like David Allen recommend. MacGuire also talks about an MS policy (back then anyhow) about all communication being via email and that phones call were reserved for absolutely critical issues. It might be an "older" book, but it still rings very true for me personally anyhow. I guess I'm just not one of those developers that can listen to music blarring in a war room watching my buddy work on my pc while my teammates discuss requirements. No wonder refactoring is so important in XP. ;-)
nice. I really appreciate it.