Sponsored By

Guildhall Production track - Revisiting TGP1

A Production student at the SMU Guildhall reviews the post mortem of his TGP1 game, FrankenFrenzy.

Dustin Davis, Blogger

September 17, 2012

5 Min Read

            Time moves strangely at the Guildhall.  We’re off in Plano Texas, miles away from the SMU campus proper, in our own little video game world.  Not that we’ve learned much about Plano.  I’m familiar with the two streets between my house and the Guildhall.

            Generally, a quarter of your coursework is intended to be dedicated to team game projects (TGP).  But as you might imagine, when you give a group of gamers the chance to work on their (usually) first group video game to completion, the effort they're willing to put in is sometimes beyond the project requirements.   Our schedule is almost universally considered relentless, but a lot of it is a self-imposed workload.  I played a lot more video games before I was in video game school.

            About five months ago, my first team game project (TGP1), FrankenFrenzy ended.  In less than a month, I’ll be tasked as the producer for three new TGP1 projects in the newest group of Guildhall students.  The Producer specialization track is new to Guildhall, and my class of producers will be the first group to revisit TGP1 in a changed role.  

            As such, it’s come time for me to look back at FrankenFrenzy.  I get to pretend to give sage Yoda-like wisdom as someone who’s a whole semester ahead of the newest Guildhall class.  Honestly, read this as, “I still have no idea what I’m doing, but here’s what I’ve got.” 

            At Guildhall, TGP1 is a 7-8 week 2D game project for 4-5 cross-discipline students, making up a quarter of their class schedule.  The content of the game is limited only by reasonable subject and scope.  For FrankenFrenzy, we used Garage Games’ Torque 2D.  The new students will use GuildEd, the Guildhall’s new internal engine.  FrankenFrenzy is a bare bones real time strategy game reminiscent of Plants vs. Zombies.  The player acts as Dr. Frankenstein by building monsters, deploying them, and giving them custom upgrades made out of the body parts of attacking villagers. 

            FrankenFrenzy’s development was a humbling, frenetic, learning to doggy-paddle experience that I really enjoyed.  The whole team ended up happy with their experience, and the result.  I may be as excited to do TGP1 again as I am to move on to our Capstone game (TP3).  

            So now I’ll run by a few bullet points of my FrankenFrenzy postmortem, with comments.

What went right:

  • Kept well-defined roles.

True enough, in retrospect.  My team started out with an artist, a level designer, a programmer, and myself, a producer (A second programmer joined our team during development).  I say that we kept our roles, but even in the real industry, a producer’s role isn’t always well-defined.  In this tiny project, the producer role meant I did whatever extra work was there, wherever we were a bit behind.  On FrankenFrenzy I’d guess my time was about a quarter management, a quarter test and balance, and a half artist.   Generally, FrankenFrenzy’s art schedule was overloaded and I was comfortable enough with 2D drawing to help.  

  • SCRUM kept us productive

I’m a believer.  I find SCRUM to be simple, intuitive, and useful – for visibility, for accountability, adaptability, as a dependable line of help.  Guildhall teaches SCRUM early, so I’ve not experienced many alternative formal methods.  At first, it was almost natural to dismiss SCRUM as a mild inconvenience, and some of the TGP teams honestly didn’t bother.  My team practiced SCRUM regularly, even if half-jokingly at first.  It didn’t take long for my appreciation to sink in.  I can’t say definitively that the SCRUMming teams benefited over those that didn’t, but it seemed evident, even on projects that small.

  • Team stayed motivated; high attendance and productivity

  • Clear product vision and priorities

  • Ease and speed of conflict resolution

I’ll not air out ever-so-slightly-dirty laundry, other than to say at one point I stepped on some toes, was kindly told I was wrong, so apologized and stopped the toe-stepping.  Nothing special about any of that, except that it all happened in a 48-hour period without drama.  I still privately contend that I was only mostly wrong.

What went wrong:

  • Changing scope during development, and

  • Scope required work outside scheduled hours

It was inevitable.  As first time developers, our eyes were bigger than our stomachs.  Oh sure, it will be easy to start out with a modest ten monster abilities, three bad guys, and five different pieces of equipment.  Wait, how long did that animation take?  Wait, how many icon variations does that mean?  You mean we have to do a five minute task for each permutation of xyz?  It adds up.

  • Didn’t keep up with quality control regularly enough, and

  • Unstable build during open Beta

We had precious few testing hours scheduled, and even fewer completed.  We can’t say we weren’t warned.  Testing often, testing early, it’s drilled into us.  It’s really more valuable than I realized, even when I’ve been taught the lesson before, even when I’ve learned it firsthand and promise myself I’ll test more next time.  It’s hard to imagine ever saying that I tested a game too much.    So when we had a big day set aside with dozens of testers available, and our build crashed before the players could win in five games out of ten, we had to make the best of it.

What I learned:

  • Make vision/direction/quality requirements clear early

  • Test often.  No, more often than you’re thinking.

  • Individuals need spheres of responsibility

  • Respond to small issues quickly before they grow, personal and technical

  • Set the pace and work ethic for the team


So there you have it, my first blog post.  Thanks for reading.  I meet my new TGP1 teams tomorrow, so wish me luck.

Read more about:


About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like