Gambit Week Seven Observation, by Jeremy Kang (Academic Staff at Republic Polytechnic, Singapore)

Coming back to the Gambit MIT after a good three years definitely brings back lots of good memories of my 2008 Gambit Summer Internship - and personally, everything is almost exactly the way I remembered it to be. The only exception is that this time around, I'm on the other side of the fence, now in the shoes of a mentor and playing the role of an observer, while the student-interns are caught in the midst of the warzone that is Week 7.

The highlight of the week definitely had to be the open playtest session that occurred on Thursday night, where the teams had to showcase their games to a throng of outsiders, and other interns alike, to get first-hand feedback on their games. Naturally, I took part in the playtesting as well, and have to say that I personally came away really impressed with Team Fabulous' game from a design standpoint, with the metaphors cleverly applied in their game design. I was also suitably impressed with what Team Planterra was trying to do in their game with the AI (Artificial Intelligence), and will definitely keep my eyes peeled for how that would turn out.

So much so that I sat into a team meeting with Team Planterra the next day, curious to listen to the feedback they had collated, and more importantly, to watch the proceedings of how the team would go about addressing the issues that were brought up in the playtests. In an organized and systematic manner, the team tackled the issues in order of priority and settled on some major improvements to work on for the remaining week of production and polish.

The heat is definitely on in the Gambit Lab, and I'm sure all the teams are firing on all cylinders now, while I eagerly anticipated the final products. Going by what I've seen in the past however, I'm sure that most of them are going to be great. Keeping my fingers crossed till then.

Week Seven by Douglas Finnigan (Temasek Polytechnic)

With the (mild) panic of Open House over, there's an atmosphere of intense concentration in the labs. I get the feeling that nobody wants to talk, unless it's about the work. Even the free food is ignored (for a surprising few minutes, anyway). The Open House feedback has been analysed in depth, and now the teams know what they have to do - with only five more days to get it done. They don't feel like students anymore. Some subtle transformation has occurred, and I'm still trying to figure out what it is.

It's fascinating to watch the teams grapple with their research questions. Some say that it confines them too much, but no one questions their relevance. A group of high school students on a summer program at Tufts is currently visiting the lab, and they're play-testing as I write. I felt the sense of relief in Lex, QA for Team Fabulous, when one of the testers wondered at the end if perhaps the character was gay. Mission accomplished, at least for now. And it's a tough mission, making sure that the games are fun to play, technically sound, and also address The Research (capital letters).

The students perhaps don't see themselves as anything more than designers, artists, programmers, composers and testers, but I feel like an observer of some complex experiment. (And it may be that I'm also, unknowingly, one of the test subjects.) As an educator, my interest is not so much in the games, but in how students adapt to and ultimately thrive in this new environment. The games are a testament to the students' creativity and hard work, but the students themselves are a testament to whatever it is that the Gambit lab and the people here have invented.

I'll still be looking for answers when I get back to Singapore. Thank goodness.

Week Seven by Mark Gossage (Singapore Polytechnic)

As a software developer, I understand quality assurance (QA), but having seen it here in GAMBIT and comparing it to how it runs in my previous company as well as in school its totally different.

1. Dedicated QA role & QA room. It makes really good sense when I see what people are using it for, which I will get onto next. I also really liked the posters that are scattered around the room as they explain a lot of what QA is really about. I also spoke to one of the QA's who was busy imaging OS's on the machines and how they will test using different versions of flash, different browsers and different OS's. Sometimes they will test with many applications running in the background (Skype, audio players, etc) to check for incompatibility.

2. Not just play the game. This is obvious & I think that is what many students think it's all about, but there is a lot more to that than just this.

3. Testing paper prototype as well as testing the daily builds. I arrived too late to see the paper prototype, but based upon my discussions with QA, this is a great thing that QA can do at the start of the process. Forcing the daily build also ensures QA has work to do ☺, but it also makes sure that things are continually integrated and updated.

4. QA as Build engineer. Not all teams have a QA as build engineer, but just about all the QA's have software engineering knowledge and so they can fulfill this roll. Having the QA as build is also a handy way to make sure that all the code/assets is being committed into the version control and that there are no PC specific hacks anywhere. It also helps free up the developers from having to check this.

5. QA job is to find the bugs, identify and surface the bugs to the team, but NOT to fix or ensure the bugs are fixed. This one surprised me at first, but it became more apparent when I saw the vast number of issues that were being spotted. It's the owner/producer that makes the call on how serious the bugs are and prioritizing them.

6. The focus tests when the public comes in and plays the game are a great idea. Even the early prototypes of the game. It forces the team to get stuff ready. Stressful? Probably. Useful? Very.

So what does the QA do? (If you haven't read the posters in the QA room, read them!)

1. Technical testing: Take that daily build and look for the bugs. Usually the daily build is up by 3, so 3-5 the QA can look for bugs and report back by the next day. This has the standard:
• Regression test (check no old features are lost)
• Build test (make sure all the new features which were marked as completed today are actually in the daily and are verified to work)
• Random tests (all those crazy things you do to try to break it, putting symbols in to input boxes, clicking on the wrong order, etc)
• Text/writing (all in game text & punctuation, manuals/help files, build instructions)

2. Usability testing: is this game fun? Is it easy to use? Remember your QA should have played your game more than any other person. Do you want to know what your game is like? Ask QA. Serious usability issues should be spotted and reported back to the team. Remember it owner/producer's call on how serious it is and whether to fix it. Another part of usability testing can be checking the writing/tutorials/help-files (even before they are coded into the game to make sure its clear)

3. Focus testing: go and get the public to play this game. GAMBIT already has the schedule planned for the focus testing, so the team must work to match that. The QA needs to prepare feedback forms, decide how to conduct the test, and conduct. In GAMBIT, the public is arranged; normally it would be QA's role to attract people to a focus testing session.

4. Team testing: This one is not found on the posters in the QA lab, but it seems important. One-two times per week (3pm-5pm), all the QA's from all teams gather in the room and test all the games. Each game gets a focused 20-30 minutes with all eyes on the game, except the games QA, who will be observing, answering questions, collecting feedback. As well as being lots of fun (from my perspective as a mentor who got to play all the games at the same time), it formed a great way for QA's to work together & learn from each other. Senior QA would keep it focused and keep dropping reminders to us all ('headphones on, remember checking the sound as well'), and was able to assist when some of the QA's got too stressed with all the issues being found in their game.

Last comment: reporting of Bugs. Some teams use FogBugz (a web bug reporting tool), some use notepad. I think all are probably verbally communicated to producer/programmers. But I have observed that each team works differently and it seems that the producers & directors are ok with different styles of work depending upon the team.