In this post I want to bring up one of the highlights of my time in the industry and how it enhanced our company, teams and processes.  While I know some of you are hoping it will involve camping, drinking and embarrassment of colleagues you may know, this was not your typical team building event.  For Mini Game week, the studio was divided up into 18 teams of 7-8 people each.  On Monday morning we were given the teams, assigned to an area, and our task was simple: deliver a game on Friday morning.  There would be prizes and bragging rights.  Everyone was involved: executives, programmers, artists, designers, admin, and managers.  There were no restrictions on theme, platform, or technology.  And there was no time to waste!

Our team comprised 3 programmers, 2 artists, 1 animator and 1 designer.  Our first two tasks were to come up with an idea, and settle on the tech we wanted to use.  We brainstormed until lunch and it involved lots of whiteboard discussion, diving into ideas, and ranking different designs.  Our main considerations were ensuring we weren’t overscoping ourselves, that we were playing to our strengths, and that we weren’t complicating things.  On Friday we’d be presenting our game to the studio in the form of a science-fair-type walkaround, so we had to draw people in without losing them with an elaborate explanation of concept or controls.  We did up a simple paragraph describing the game, and while the designer and artists brainstormed deeper into that, the programmers experimented with tech.  Each of us took an engine and tried to create a prototype by the end of the day, and argue for that platform.  I took XNA, and the other two considerations were Unreal and Flash.  An hour later, I had taken one of the XNA samples and modified it into the beginnings of what would be our final game.  The Flash SE struggled with how to handle controller input, while the Unreal demo struggled with sheer overhead of building assets and an over-qualified toolset.  By the end of the first day we had our design, our tech, and had made our first version control checkin!

The rest of the week was a blur of quick decision making and implementing.  Because we were using XNA and our artists and designers didn’t have Visual Studio, we ended up with a simple method of getting our content into our game.  The SEs would work in Perforce, and when we deemed enough changes or fixes were complete, we’d push a build to the network for the rest of the team.  Due to the way XNA loads content, they could edit XML files, drop art assets into the build directory and be able to load them into the game without programmer intervention.  This made for a fairly efficient workflow, and shielded them from our inevitable breakages early on.  Once they were happy with the art they’d check it in and we’d sync to make sure nothing went wrong.  We worked this way throughout the week.  Through an organic process, team members found their roles.  People stepped out of their comfort zone to take on tasks that needed doing, and even the rote tasks were snapped up, as the adrenalin rush of quick iteration and results motivated us.  By Thursday morning we had essentially an “alpha” version of our game, and breathed a bit lighter, knowing we could tune and fix bugs for the rest of the day and not push risky work into demo day.  As the deadline loomed, rumours were abound.  Throughout the week people had been keeping ideas to themselves, but nearing the end it became less likely someone would steal a design.  During the week, we felt confident our game would hold up to the competition, but in the end, we underestimated the talent and ideas brewing in the rest of the studio.

Demo Day was probably the best day I’ve ever had as a professional game developer.  Late Thursday night people were at the office into the evening, fine tuning their games, making signs, coming up with props, and the next morning the studio was transformed.  The energy in the air was crackling, as people wandered from room to room playing the other 17 games that had emerged from the chaos.  I think there was general amazement at what had been accomplished in 4 days.  No team worked an insane amount of OT, and almost everything was done from scratch.  So to see network multiplayer, complex 3D models, intricate levels, and amazing designs, was remarkable.  Some highlights were the use of the Rock Band drums to control fighting apes, the use of voice pitch to control the player, and a fully polished game that eventually won best overall game that was written in plain C/DirectX.  There were games done in XNA, Flash, Phyre Engine, PopCap, and plain old C/C++.  There were PC games, 360 games, and PS3 games.  It was a diverse collection of ideas and decisions that was birthed from groups of people who may have only worked together for the first time at the start of the week.

So what was the point?  Was this just a week off from the grind; a chance to slack off and work on a pet project?  I believe the value of this week cannot be underestimated.  As an individual team we learned many things:

  • quick iteration is possible, and beneficial.  This was apparent early on when I had the XNA demo up and running before Unreal was even done cooking assets for the first time!  Don’t settle for a bad process, as it can make all the difference.
  • decision making under pressure.  Sometimes decisions just HAVE TO BE MADE.  During this week, there was no alternative, and some of our best ideas came late in the day when a little bit of panic was bubbling.  Put creative people together, give them a deadline and a goal, and they’ll come up with great things.  A choice doesn’t have to be analyzed for months to be right.
  • scaffolding is essential for prototyping.  There were many systems we hacked in, but they worked.  If we ended up shipping our game we could easily replace them, but getting systems built up quickly to support the end result was the only way to do things.
  • technology isn’t the focus of games.  Programmers obsess on technology and will debate their language of choice to the death, and rightly so, as it is our job for the short and long term health of the studio.  We’ll play competitors’ games and analyze the anti-aliasing, physics system, and network performance.  Don’t get me wrong, bad technology can kill a game and a studio.  But, at the end of the day, design and gameplay rules.  Of the 18 games, the technology didn’t give any one an advantage over another.  XNA didn’t make our game more fun.  We set aside those glasses for the day and looked purely at mechanics, and what made the games fun, and it felt good!

From a studio point of view, there were also benefits:

  • camaraderie.  Our studio was growing, so at the start of the week there were many introductions to be made. By the end of demo day, the 7 of us had formed bonds that would help us down the road when working together.  The importance of team composition cannot be underestimated, and I think if anything the week showed that we had hired the right people at our studio.  There were no reports of ego trips, slackers, or major conflicts.  People were having fun, taking on different roles, and working well as teams.
  • the importance of prototyping.  Why don’t we do this every time we create a new project?  Why do we restrict this decision making to a small group of people?  It was clear that everyone had good ideas.  With polish, I think we could have easily shipped three or four of the demos.  It was only a week, and we generated more ideas and pushed them to some level of completion than we could’ve any other way.
  • evaluation of technology.  Sure, this goes against my last point above, but while technology didn’t impact the final games, there were pros and cons everyone ran into.  The team that tried PhyreEngine was the first group in the studio to evaluate it, and I think they learned more during this week than they could have with a more formal evaluation of the product.  I hadn’t written any C# before this week, and while the code I wrote was fairly horrible, I learned what was easy to do and what was difficult to do in a short amount of time.
  • expansion of skill sets.  We had designers using Photoshop, world modelers tuning animations, and production coordinators designing the UI.  This sort of activity can prevent a studio from stagnating.
  • everyone saw every stage of game development.  For some of the greener employees, they saw how ideas were generated, how people interacted, and how to “final” something.  While it was very compressed and obviously doesn’t represent a true cycle, it was nonetheless valuable experience.

So overall, it was a fabulous exercise, relevant to our studio, and a whole lot of fun.  We never did it again, but if I ran my own studio, I’d do it every year.  I know it is difficult to find a point where essentially shutting down studio operations for week wouldn’t negatively impact a game team, but perhaps a smaller scale operation done by a single game team post-finaling, for example, might work.  What do you think?  Do you see the benefit of such a thing?  What other events have other studios done that felt beneficial?