FRANKENFRENZY
Torque 2D
Windows PC

My Role as Game Designer/ Associate Producer

  • Served as Scrum Master
  • Developed and updated GDD
  • Led design meetings and kept core gameplay vision
  • Developed 2D art content including character concept art and HUD
  • Approved content and gameplay
  • Administered team Sprint Retrospectives and Sprint Planning

FrankenFrenzy Trailer

FrankenFrenzy Screenshot
     FrankenFrenzy was an eight-week project for five students.   FrankenFrenzy is a casual 2D PC strategy game built in Torque.  Players build, deploy and level up monsters as they assume the role of Dr. Victor Frankenstein defending his lab from marauding villagers. 
   
    Development of FrankenFrenzy was a labor of love for me, and I put my hand in every aspect of development: production, programming, art, audio, and design.  As Game Designer on my first team game project, I got to play with a favorite game concepts - strategy and customizable characters.  These concepts carried over into my Master's Thesis on balancing customizable units.

My FrankenFrenzy concept art
Picture
Mini-Postmortem 
on my role on

FrankenFrenzy
What Went Well
  • Team stayed motivated
For most of the team, FrankenFrenzy was the first opportunity each of us in video game development.  We were excited and optimistic throughout, and took our struggles in stride. 
  • Ease and speed of conflict resolution
With such a small group of developers, team dynamics were a significant potential risk.  However, due to the personalities of the team members, and partly due to our common goals, there were very few human work problems during FrankenFrenzy's development.  And whatever problems occurred were addressed as quickly as possible.  For example, when I overstepped my role into art assets, the issue was brought to me by our artist with professionalism and quickly resolved.
  • Clear product vision and priorities
I attribute much of the project visibility and clarity of priorities to the development processes at the Guildhall, which include a variation of Agile with SCRUM. When inevitable cuts needed to be made, we were clear enough on the product vision to know what content could be culled without losing the core of our game. 
What Went Wrong
  • Irregular quality control
We had precious few testing hours scheduled, and even fewer completed.  We can’t say we weren’t warned.  Testing often, testing early: even when you’ve learned it firsthand and promise yourself to test more next time, it's difficult to test enough.  So when we had an important playtest 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.
  • Roles and responsibilities conflict
In short, at one point I stepped on some toes, was kindly told I was wrong, so apologized and stopped the toe-stepping.  There wasn't much to it except to note that the problem arose and was addressed within 48 hours.  First, it was a lesson in establishing and maintaining spheres of responsibility. Second, it was a good example of how simple honesty and empathy can keep a team together and on track.
  • Overscope
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.
What Was Learned
  • Make vision/direction/quality requirements clear early and often
  • Let individuals have spheres of responsibility
  • Respond to small issues immediately before they grow
  • Set the pace and work ethic for the team