Flash Hack: Introduction to Rapid Prototyping

A Research Project? No thanks.

Have you ever been in a college class and noticed that everyone was either sleeping, using Facebook, or playing video games?

Of course you have.  We’ve all been there.  No matter how important the information may be, students simply lose interest in the subject matter and become disinterested, disengaged, and bored.

Well, such an event recently occurred in a game design class at SMU's Guildhall.  The students were assigned UDK research topics to prepare them for an upcoming team group project.  Professors divided the students into teams and assigned them research topics such as character creation, weapon functionality, Kismet, etc.

As a future production student on two of their TGP (team group project) teams, I knew that these students were going to fall flat on their faces if they didn’t learn the knowledge contained in the research project.  Having done the research project myself, however, I knew that the projects were boring as hell and didn’t teach my cohort much about UDK.  On top of this, students were already showing up to class and playing games until it was time for them to leave.  The class simply wasn’t productive at all.

Myself, a fellow production student (producer for two of the other teams in the cohort), and our professor sat down and thought of ways we could resolve the situation.  These were extremely talented students, but they lacked motivation.  How could we engage, motivate, and teach them the information they needed to learn in less than a week?

Our answer:

“We walk into their class tomorrow morning and tell them to make an 8-player deathmatch in 2 hours.  That’s how.”

Trial by Fire

My fellow production student had worked with this particular cohort on their first TGP at the Guildhall.  Because of this, he could offer insight to their personalities, work ethic and skill level.  With this knowledge in mind, my production friend arranged the students into nine teams -- eight teams of five and one team of four. 

The team breakups were slightly different from team to team, but most of them consisted of two level designers, one programmer, and two artists.  The team of four, while down one member from the rest of the teams, was comprised of extremely skilled members of the cohort.  This team was a control group to determine whether our restrictions were too aggressive.

 Of course, my friend, being the clever person that he is, arranged the teams with certain personalities in mind.  Amongst many other things, this would show us producers how these students would work under pressure, their ability to work together, and reveal team dynamics that would otherwise go unnoticed until their TGPs were already underway.

We assembled the deliverables based on their proof of tech milestone requirements.  Defining a list that closely resembled what they would do in their TGP would show us where the most technical obstacles were taking place and allow us to prepare for production accordingly.

Here’s the full list of requirements:

**Students may not use pre-existing UDK assets

The Outcome

Overall, the exercise was a huge success.  There were definitely some wide-eyed stares accompanied by some dropped jaws when I went to the front of the room and told the entire class to make an eight-player death match in two and a half hours.  The students learned a great deal about making a game in UDK.  Moreover, they learned how much they have to learn about the editor.  They also learned that working together is more important than individual skill.  That being said, a talented individual can enlighten an entire room if they are provided the proper communication channels. 

As on looking producers during this exercise, we learned about their team dynamics in real-time.  This isn’t the ‘best behavior’ you get in an interview.  People respond different when they’re actually in the action.  Some people were lost at sea, some became the anchors, some helped others and some closed up.  This exercise, which is now known at our school as the ‘flash hack,’ taught the students more about UDK in two hours than a research project did in two weeks. 

As producers, it revealed team dynamics that would usually only emerge during production.  With this knew knowledge, the production student and I were able to optimize team formations for this cohort’s TGP.  I’m pleased to say that in only two weeks of pre-production, these five TGP teams have surpassed their proof of tech requirements two weeks ahead of schedule.  This cohort has officially set a new record in development speed and quality for TGP2 at the Guildhall at SMU.