Team Communication

01/01/2010 by T.J. Martin

Team Communication

Hi, I'm T.J. Martin, a game programmer at Hidden Path on the team that
created Defense Grid: The Awakening.  We've just finished the final
polish stages of the product, and it feels great.  I think we've got a
challenging, addictive game that's fun to play and beautiful to look at.


When I think back to what the key things were that allowed us to get to
this stage, I focus on two things:  1 - allowing the designers to have
the ability to efficiently experiment with design concepts, and 2 - the
excellent communication and problem solving techniques the team used.



The tower defense format provides a simple, but rigid, system of rules.
Since this system established the basic game play, we used this rule set
as a canvas to explore more subtle design ideas and play with game
balance.  We wanted our designers to be able to work as freely as
possible, so we thought about content creation from the very beginning
of Defense Grid.  One of my main tasks was to allow the designers to
create levels that were completely playable without any programmer or
artist intervention. The result was a level editor that actually
generated geometry for testing purposes.  Only after the level design
was nailed down would the artists would go through and make it look
beautiful. Since Tower Defense is a genre that is largely about
optimization and efficiency, it was important to be able to tweak every
little detail to make every level, monster and tower as fun as possible.
We made an effort to ensure that any number or setting could be
modified by a designer without having to wait for someone to change
code.

One of the things I like most about Hidden Path is the rapid flow of
information. We work in open environments where everyone is free to
bounce ideas around. No one hides in an office and creates features in
isolation. Any feature has probably been thought about and discussed by
multiple people from art, programming and design. This low communication
barrier also allows programmers to better empower designers. We don't
simply read a document and then make it happen. We work with the designers. If we have a question or suggestion, we can bring it to
them directly instead of waiting for an open slot on their Outlook
calendar. This lets us make sure that our game stays fun and that we all
love the final product.

One of the most interesting design areas has been assigning roles to
individual towers. I have always felt that, in any game, different
pieces of your arsenal should be fundamentally and functionally
different. Just changing numbers and adding a new visual effect is not
enough! Anytime we felt that two towers were becoming too similar, we
addressed it. At one point, we had a tower that wasn't really working
out. Instead of just cutting it or letting it go unaddressed, we got
around a whiteboard and discussed what made the tower unique and how we
could keep that element. At the end, we had completely redesigned two
towers. No meetings were scheduled. No formal change requests were
written. We exchanged ideas collaboratively until we arrived at the
right answer, and we made it happen.

This kind of cooperation and these thought processes are what enable us
to create games we are proud of.  I knew we were on the road to
achieving this goal with Defense Grid when we all started competing with
each other for better scores and breaking down strategy on a whiteboard
to be better at our own game.  The team dynamics have really helped build a great game experience.

Posted in Defense Grid | Keywords: Defense Grid