[Unsure if Google Docs is the right way to manage online collaboration with your video game team? Game industry veteran Chris Oltyan takes a hard look at its strengths and weaknesses, offering examples, praise, and criticism.]

It was 10 PM and my eyes were blurry. I was at home keeping company with a wracking cough and pounding headache, trying to give the team the information they needed to finish an essential milestone.

We had been keeping a wiki somewhat up to date, but now, when it mattered the most, there wasn't enough detail to knock out the final game systems. As I painfully slogged through updating and submitting HTML while talking the team through desired functionality on my cell, I screamed to the gods, "There must be a better way!"

Almost everyone I know who has been a producer in the industry has a story similar to the one above. wikis, design docs, or interpretive dances are made at the beginning of a project, and, by the second day of development, are hopelessly out of date.

Over the years I've dabbled in every bit of tech buzzwordery I could. At the end of it, I settled on online collaborative tools to help solve the pain and suffering that come from out-of-date docs of dubious freshness.

My Brief History of Collaborative Tools

When I started my own studio in 2002, we had a very process-oriented CTO. He insisted that, before we even finished forming the company, we establish some baseline norms. We had a file naming convention that insured proper versioning and easy sorting, and a directory structure for projects that we kept to meticulously.

We used Word for our docs -- everyone else did too -- and even had nifty document templates that allowed for easy identification and automatically noted who last updated them. All in all, it was probably the best document system I've ever been a part of. It lasted all of two weeks in production before it became impossible to identify the latest design doc.

The system was solid, but it just couldn't keep up with how quickly we moved. Soon, we just gave up, and tried to keep a running conversation on what was expected. While we were small enough for this to work most of the time (five people in the same 15-by-20 room makes it easy to know what other people are thinking.)

Of course, this broke down completely when we got more people involved, and specifically when we had to expand to two rooms. The second that the running conversation had to loop in additional people, we were unable to keep up with the shifting changes in the project.

The next time I was at a company and we had a chance to do something different, I offered up using SVN for design docs. After all, it worked great for code; it must work for docs, too! Those who have tried this method, go on and skip ahead. You don't need to relive the horror.

What is the horror, you may ask? I have one SVN command for you: "SVN lock". It allowed us to prevent collisions in files, and made sure the version we saw was up to date, but practically guaranteed that someone on vacation or offsite had left the file locked, requiring a new version with a different file name. After a few months of this, you'll be right back with me in 2002, saving out different file names for every doc, with half of them actually more up-to-date than what you are working on right now.

Another day, another company, and this time we were going to wiki the problem to death. A recent Gamasutra article on wikis tells us that these things can be useful, and work to make them even more relevant continues onward.

In the IGDA Production mailing list, there was a recent post about how wikis with the best intentions still fall out of date frighteningly fast. Regardless of the flavor of wiki you try, they are generally powerful, flexible, and impossible to manage -- unless you have someone who is an expert in house.

If you didn't have a good awareness of it before, you will amaze yourself at the power of your own entropic force when it comes to a wiki. With the information just a little out of date, you will create just enough incentive for your team to abandon the wiki and just move to a quick conversation on changes.