Here is a postmortem by Sara Verrilli about the challenges and successes of the "embedded staff" role in our project workflow:

Every summer, GAMBIT runs an eight week game development program for undergraduate students, primarily from Singaporean universities and polytechnics. This year about fifty interns joined us, forty of them from Singapore and the rest from local colleges and universities in the Boston area. This was the third summer for GAMBIT's program, but it changes a bit each year, and 2009 was no exception. For the first time, each team had its own audio designer, rather than sharing the efforts of a three person audio team. Secondly, three of the teams had a grad student from our CMS program join them. And, finally, each of the teams was given an embedded staff member from the GAMBIT staff.

What exactly is an "embedded staff member?" Well, according to our summer planning paperwork, the embedded staff member serves as a team mentor, role model for the producer, overall team advisor, and the primary channel of feedback and criticism from the GAMBIT staff and product owners to the team. The embedded staff's job (or ES, as GAMBIT abbreviated the title) is explicitly not to run the team, provide game design, or make decisions for the team. Unless, of course, one of those things became Necessary, and what conditions constituted Necessary were heavily theorized but never actually specified. And so, with a clear mandate but fuzzy responsibilities, the summer began.
My team was Team 5 - Poof Productions. Their research goal: provide two versions of the same educational game, one with a strong narrative and one without. The product owner (the client for whom the team created the games) also required a fun educational game, one where the player would willingly play the game regardless of its educational impact. Waker and Woosh are Team 5's answer to this task.

What went right?

• Once the prototyping and initial game concept session started rolling, I got out of the way. I wanted to join in - playing around with new game ideas is fun. However, I didn't want to overshadow the team's ideas with my own; this was their game. Instead, I listened in on their prototypes, and tried to use my comments and questions to keep the team on track for their project goals. For example, how do you use a rhythm game to express displacement, velocity and acceleration? Graphically? When they couldn't answer that question, it was time to try an alternate approach.

• Demonstrating the development processes GAMBIT expected the team to use - and then giving the team time to use them, mis-use them, and finally get them working, in their own unique style. GAMBIT required the teams to use several agile development principles borrowed from Scrum - among them, the idea of a product owner, a task board, and daily stand ups. However, with only eight weeks of development and a group of inexperienced developers, GAMBIT also provided a schedule of development goals. So we were using elements of agile production on a waterfall schedule. I built the Scrum task board for them, and helped them define their tasks for the first milestone; I led the first couple of daily stand ups. By the middle of the program, it felt like the task board was useless, as team members frequently announced they'd worked on something completely different, and the task board stood unedited for days until the producer prompted the team to sort and re-arrange. Finally, for the last sprint, something clicked. The team members understood what needed to happen, divvied up the remaining tasks, prioritized them, and tasks flew across the board. I could actually tell where the team was on the project by looking at the board, and then looking at the game, as opposed to talking to each of the team members. It was also during those two weeks that the game really came together, as a good looking, fun to play game.

• Being there to channel the product owner, on the research goals and the specific tasks the product owner asked us to work on. Our product owner was very busy this summer, and while he met with us at the end of every milestone to review the game and give us feedback, he wasn't there for the day to day decisions. All too often, the team would be staring at two seemingly gargantuan tasks, both Necessary to the Well Being of the Project, and clearly both desired by our product owner. By checking our notes, and making sure that the producer and I got clearly prioritized requests during the review meetings, I was able to remind the team which task to tackle first - even if that meant the other task fell off the table, and rolled away. I was also able to reassure them that, yes, the team wasn't going to get everything done it had hoped for, and that was okay also. What we needed to do, instead, was insure that we got the most important tasks completed, and that those completed features worked together to make a good game. During any development period, especially a short one, there is only so much work that can get done. Experienced teams regularly over estimate their ability to accomplish tasks; inexperienced teams are even worse at it. Keeping priorities clear - and, more importantly, the product owner/client's priorities clear - means that at least the tasks that get dropped are the least important ones.

What could I have done better?

• Scoping the project - keeping it a manageable size. Before the students arrived, I knew what our research proposal was, and what our product owner wanted from the team. I was worried about the density of initial design challenges - three concept graphs, two alternate games, and a high quality narrative, but the team had an extra artist and a grad student to play utility infielder, so it seemed achievable. Then the product owner - after the team decided on a platform style game - asked for procedural levels. At the same time, thea bstract version of the game went from 'no story and no story specific art' to a version with a unique set of art and audio assets, including its own avatar. Alarm bells went off in my head, but the team wanted to do it all, so I let them try. I should have stepped up and said no procedural levels, and greatly minimized the abstract version's unique assets. Instead, we ended up chasing a procedural levels solution for about two weeks, while the artists did another round of concepting for abstract assets. Reality did set in, and the only remaining sign of procedural levels is the random placement of obstacles in medium and hard levels. The acceleration levels were also cut, because we just couldn't figure out how to accelerate the player on our small screen.

• Art asset scheduling - I waited too long to talk to the artists about getting art into game. The team of three artists developed elaborate plans for the visual look of the game... and then they kept developing them. With two full games to provide assets for, the team didn't have time to dally - but they did. They generated a set of placeholder assets for the game, so level creation and testing could go on, and then stalled on delivering production assets. Five weeks into the project, with three weeks to go and only one or two production assets in the game, the producer and I revised the art asset list, lined up estimates, and started counting hours. The artists, confronted with their list of desired assets and a very short time frame, buckled down and assets finally appeared. While we had three artists - generous for a summer project! - one of the artists ended up devoted almost entirely to Woosh, and another spent hours converting art from bitmap to vector to go into game. Final art didn't come into the game until the week before ship, and we were still adding new assets during gold certification. Because of that, there are several elements, especially in the story version, Waker, that are less polished than they could be. The team used polish time for final asset creation, rather than polish, and it shows in the level art, the game menus, avatar animations, and the player controls.

• For the narrative version, failing to get a better connection between the story and the game mechanics. The team came up with a compelling gameplay mechanic, and then a rich story. Bringing the two together, however, fell by the wayside as the artists worked on creating art to bring the world to life, the designers made levels, and the programmers and QA struggled to get everything working. When the story was first presented to the team, I was worried about the story's ability to be expressed in the gameplay, and I asked the team to get a better connection between the two. They never got around to it, and in the end we cobbled the story together with the help of a writer, working the story to match the elements that were in game. It worked, but the team had time, and the ability to do a better job. I should have pressured them to connect the game mechanics and fiction, and offered then better support in doing so. I made one or two suggestions, but didn't want to force my ideas on the team; I still wouldn't want to. I should have made them show me how their gameplay and their story interconnected much earlier in the project, when it was still possible to alter story, gameplay, and assets.

My goal for the summer was twofold: one, make sure our client, the product owner, got a successful, useful project. (He did: he told us so!) Secondly, I wanted everyone on the team to learn as much as possible about working on a team, especially when working with people whose skills are different from their own. I wanted them to learn how to make a game by stretching their own skills, and if possible, learn from their teammates about the other disciplines on the team. Finally, I wanted them to make mistakes and recognize them, recover from them, and gain the confidence to make yet more mistakes, and find solutions to them as well. In the end I tried to serve the team as the voice of experience, demonstrating successful techniques, giving advice when asked (and, sometimes, before being asked) and warning them about potential complications they might not expect. What I really didn't want to do was stop them from making the mistakes they would learn from - and therefore learning from them. We - as a team - certainly made lots of mistakes, but the games - Waker and Woosh - speak for themselves. Overall, I think that by serving as ES I helped the students learn; I certainly learned more about how to teach, and next summer I intend to do a better job.

Check back today for more content on Waker and Woosh