Photo by JD Hancock on Flickr. Used under Creative Commons Attribution license.
Category Archives: ETC
In preparation for a new project this Fall, I have been reading through the ETC project postmortems from Spring 2012 and looking for common themes that I can implement into my next effort to make it successful. This is my own summary lens on 14 postmortems. I believe the postmortems are internal to ETC so I won’t be linking to them or giving out too many details, but the general lessons may be valuable.
A few points get hammered home over and over again when you read postmortems on student projects. Our professors remind us of these all the time and they seem so obvious, but in the heat of a 15-week development cycle it’s easy to get them wrong.
Limit your scope
Somebody – could be anybody – will ask for more than you can give. So estimate your work right away, and be very clear about how much you can do and why. This is hard, and certainly deserves its own book, but there are a few key principles that will help:
- Accept that estimates are imperfect – it takes the pressure off. Round to days or half-days.
- Involve everyone in estimation – they will be more invested, and you will get more accurate estimates.
- Estimate frequently – you will get better at it.
- Build in buffer time – you will need it.
Almost every team celebrated limiting their scope, and no team wished they had taken on more work.
Teams that get past talk and design and make something the fastest, seem to have the most success, while those that don’t always wish they had started earlier… probably because this is a prerequisite for the next couple of points, iteration and playtesting.
For tips on making this happen, see “Gold spike” below and Kyle Gabler on rapid prototyping.
The results are 100% consistent: Every team either says “We’re so glad we iterated so much,” or “We wish we had iterated more.” Build it, try it, discuss it, rinse and repeat. Of course, this goes hand-in-hand with the next point:
The most successful teams were consistently the ones that did lots of playtesting. Those that start playtesting earliest and do the most over the course of the semester always have a more polished, more impressive product in the end.
Of particular note, one team mentioned that they did a lot of playtesting but they didn’t reap the benefits because they didn’t take the time to discuss their playtest results and update their direction accordingly. So, don’t forget the do something about it step. I’m hoping our whole team can meet after each playtest to talk about the feedback and plan changes together.
Then there are good habits that only some of the teams get – usually the successful ones.
Very successful teams do a good job of specializing, with clear distinctions between roles for team members. “A lead for every task and every task has its lead.” This has a number of benefits – team members who feel solely responsible for an aspect of the project will be more invested and relish in their creative freedom. It helps keep aspects of the project from being overlooked. It looks good in presentations too, when for any given topic the team can point to their expert.
The flipside of specialization is interdependence and duplication of knowledge. Some teams reported that their members were so independent that they were not always on the same page. So while you have a lead on every task, you should also have at least two brains on every feature. It will build a team mindset, help team members get each other ‘unstuck’, and when crunch time hits you won’t have put the whole weight of the project on the shoulders of that lone programmer that knows how to deploy to the staging server.
You have a brand-new team that’s never worked together before and you need to get started, but your client is out of reach and your design is up in the air. Early prototyping seems impossible. What to do? Why not make a tiny game together to get everybody rolling? The “gold spike” task (doesn’t even have to be a game) can be an icebreaker, lets the team get an early read on their group work style, and can be a first step in establishing your asset pipeline. I’m considering starting this semester with a quick “Asteroids” remake.
Low Latency Communication
A number of teams reported a new understanding of the value of face-to-face conversation when working through problems. It is tempting for some (like me) to write a long, detailed breakdown of a problem and its solution, and sometimes that is important. But drawings and diagrams are much more efficient than writing to communicate with a group, and if you can just walk over to someone and tell them about it, that is even faster. Documentation is an important tool, but it’s a slow one. Turn to better tools to communicate quickly within your team.
A Physical Task Board
A number of teams attempted to use Scrum or a related agile development style this last semester. Every single mention of Scrum in the postmortems said (paraphrased) “we started the semester using a digital task board, but it just fell apart. When we finally switched to a physical task board everything came together!” I’ve had the same experience on at least two different teams.
Above and Beyond
Then there are those outlier cases – times when a team did something different, and it really worked!
How to Pitch
One team told a great story about trying to help their client pick an idea. They had gone in with a number of good ideas, and explained the technical merits of each, but they were not getting the positive response they needed. So they sought assistance from the faculty, who recommended that they pitch just one or two ideas very well. They needed to show more excitement about the ideas they were pitching so that they could really sell them. They also needed to make the technical merit of the ideas secondary to an emotional hook. The team landed with their next pitch, and the project had a clear direction from then on.
On my own team I learned a lot about how important it is to be pitching your idea all the time. Even when the client comes to you with an idea, you have to ‘pitch’ it back to them with enough passion to make them your partners in the work. And practice makes… well, you know.
Unifying the Team
One team mentioned that they used improv games to get to know one another throughout the semester, and reported great camaraderie and unity as a result. That team worked some very long hours in order to produce a polished, finished product, and they credit their ability to cooperate at 3AM to how they developed their relationships early on.
Humor me… some other things I want to try after reading the postmortems, though they weren’t directly mentioned.
It’s easy to get lost in the details when working on a project. Some of the strongest interactive works exhibit a unity of vision that can be hard to create with a team. I wonder, what would happen if, as soon as we had our vision hook/design pillars/theme song figured out, we repeated that as a group every day? It could take as little as one minute of a stand-up meeting. Would it help us create a more unified experience?
Try putting one team member in charge of the “juiciness” of the experience. This is one of those easy-to-forget things that has a big impact. Ideally a game designer is looking at this, but programmers have a huge impact on it too.
A Shared Vocabulary
I wonder if it wouldn’t be helpful to continue building a shared foundation of words and ideas within the team, via common reading. You could even make this a role, and put someone in charge of the “book” club, but you share articles and videos. We kind of do this naturally, so it might be real overkill – or it might be interesting to collect all shared theory.
The Legend of Zelda: The Wind Waker
A critical comparison demonstrating the usefulness
of Janet Murray’s pleasures of digital interactive media.
Bradley C. Buchanan
ETC Fundamentals: Video Game Report
November 4, 2011
A “down the rabbit hole” tabletop adventure for three players. Created for my game design course – My first experience creating, playing or running a tabletop RPG.
A print-and-play race to build the pyramids! My second dice game, created for my game design course.
A parlor-style dice game for two to four players. Created for my game design course.
Yesterday, I ran my first tabletop RPG.
My only previous experience with tabletop storygames was one abstract GM-less game (like Polaris) that was fun, but nontraditional. Now in my game design class I’ve been assigned to create and run an adventure module using light, D&Dish rules. The goal is to tell a strong interactive story with a good interest curve. Remember, I’ve never played D&D before, much less run it.
I’d say the session was a surprising success!
I’ll upload my full postmortem when it’s complete. For now I’ll summarize by saying that things started slow but picked up well, and the best moments were when the players surprised me with their ingenuity. At one point they devised a plot worthy of any TV show that I hadn’t planned for at all. Thanks to Dave, Kai and Jimmy for playing!
“There and Back Again: A Hopscotch Tale” is a cooperative hopscotch game themed around Lord of the Rings. It is designed for nine players, but has handicap scenarios for less. The game is extremely difficult, and designed so that some players must fail for the others to succeed.
In playtesting the game was met with enthusiasm. The high difficulty was confirmed (which I attempted to tone down each iteration) but the result was exactly what I wanted – people were highly engaged with one another, encouraging each other and strategizing together to overcome the very difficult game.
I count this a success. We’ll see what grade I receive.
On the south side of Pittsburgh, between the Monongahela River and I-376, stands a fairly unassuming office building. From a distance, one might have a hard time telling it apart from its neighbors. From the outside, there’s nothing to suggest that this is the place we affectionately call “The Dream Factory.”
Once you step inside, though, all doubts melt away.
In the latest episode of the Brainy Gamer podcast, Michael Abbot interviews Matthew Burns, producer on Halo 3 and Halo Reach. When asked about how to get into the games industry in 2011 (in the last 10 minutes of the episode), Burns mentions that university game design programs are a great way to go these days, and specifically mentions the ETC at Carnegie Mellon. He and Abbot then have a short conversation about game design schools, with Abbot citing an interview with Jesse Schell for the latest issue of Kill Screen Magazine. Burns says that large studios are happily hiring graduates of game design programs, and that the graduates are well-trained and competitive in the industry.
Awesome. Nice to feel like I’m a little ahead of the curve – I start at ETC in two days!