A few weeks back, I attended Austin Game Developer's Conference.  I enjoy going to these conferences, learning from others and getting a sense of what changes are afoot in our industry.  Any given talk may be hit or miss but there are always a few gems of information to be found in almost any presentation.

Here are my notes from a few sessions I found particularly enlightening or interesting.  Please be warned these are mostly stream of consciousness to capture the "flow" of the discussion -- salient points, key figures, and so on.  It certainly isn't intended to be a transcript.

World of Warcraft Operations: http://xemu.blogharbor.com/blog/_archives/2009/9/17/4324361.html

This was probably my single favorite talk of the show, despite it's somewhat dry nature compared to the usual World of Warcraft fare of loot, monsters, and the like.  I'm a huge process & tools geek, so it was very nice to get a peek behind the curtain.  Building and maintaining a large organization like this is a huge challenge, one that I think many people don't even realize exists.  The sheer scale of their operations is astonishing and only adds to the amazing accomplishments of the game.  

Laralyn McWilliams on Free Realms Design: http://xemu.blogharbor.com/blog/_archives/2009/9/18/4325350.html

One of the things I found most interesting about this talk was how alien the design process was to me.  I don't mean that in a bad way, rather the reverse: it was fascinating to see such a qualitative and analytical approach to game design decisions that traditionally come from the "gut", and I learned a great deal from it.  Game development is an intense fusion of science and art, but rarely have I seen the science part applied as deeply to the non-technical parts of the game.  This is an area I think we may see more of in the future as the audiences our games reach grow more broadly than the tastes & creative background of the people making them.

Sebastian de Halleux - Playfish: http://xemu.blogharbor.com/blog/_archives/2009/9/18/4325286.html

This talk was probably the most in tune with what I would describe as the "vibe" of the conference.  Namely, that alternative business models (micro-transactions, free-to-play, etc.) are becoming very relevant to modern game business.  It has been something on my radar for the success in Asian markets for a few years, but seeing it actually come to Western markets with dramatic numbers is a new development.  I'm not quite sure I buy into all the hype yet, but it is clear that this next phase of market evolution is only just beginning.  I'm excited by the idea that we may be moving past the "one size fits all" level of involvement between gamers and the people who make the games that they love.

Hi, I’m Rob “Xemu” Fermier, the lead Code-Bot (ie, programmer) on one of our game projects here at Robot.  While a lot of my day-to-day job involves actually writing code, fixing bugs, and the like, the most important responsibility I have is just fostering communication – both within the programmers on the project but also among the various people on the team and in the company as a whole.  There are a million reasons why good communications are important, but one of the most basic is that we want to make sure we are all headed in the same direction in our day-to-day tasks.

One of our front-line tools in helping communications is the “morning sync”.  Every morning, each of the 4 “pods” at Robot gets together and has a quick discussion to cover where we are and where we’re going at a very specific level of detail.  Each person quickly hits what they got done yesterday and what they’re doing today.   Simple, but effective.

Of course the last thing most developers want to have on their schedule is another meeting; much less one scheduled every single day.  So there are a few things we do to make sure it has a positive impact rather than a negative one:

• Short:  Each person has to be short and to the point, and the whole thing usually takes 10 to 15 minutes.  It’s never allowed to go over 15 minutes, period.  Discussions that crop up as a result of the morning sync are usually resolved in ad hoc meetings immediately afterwards.
• Easy: We sync right in the same pod where we are working, so there’s very little organization required.  Everyone has a good sense of what they are doing and never has to “prepare” anything.  One advantage of a daily meeting is that it can be pretty casual and folks fall into a routine with it easily.
• Reliable: The sync always starts on time, regardless of who is there.  People can plan on it and it doesn’t drag on by starting late or hanging around.
• Open: Anyone is welcome to listen in on the sync meetings.  But they don’t talk, since the meeting is focused on the people doing the work.  By having them out in a common space, it promotes the idea that we want to share information to anyone who wants it.

What is most important, of course, is the communication benefit that it brings us.  While there are rarely surprises there, it keeps everyone abreast of the latest things going into the code base or changes that are imminent.   Frequently some other programmer than the one doing the task will have some relevant knowledge or experience to share, and this gives a very convenient platform for doing so.  When the process is operating smoothly there aren’t a lot of surprises, but it still helps kick off the day and keep people focused on how what they do fits into the big picture along with the work of all the other ‘bots.

This is a modified part of a larger process called “Scrum”.  We don’t adhere formally to the Scrum process, but we have hijacked bits and pieces of it that work well for our rapid pace of development and iteration.   It is an important “meta process” that each of our processes needs to be open to change and evolution as we use it and see how it does (or doesn’t) work in practice. 

We’re lucky here at Robot to have a team of very experienced folks who have all worked together extensively in the past.  This means we are starting from a great base of communication to begin with, but without constant attention it is easy for those lines of communication to shut down.  Experience has shown that the worst problems almost always start as a breakdown in communication – so anything we can do to keep those from even happening in the first place is a huge win for the project and the team.