Sponsored By

Game Dev Collaboration: Google Docs Style

Unsure if Google Docs is the right way to manage online collaboration with your video game team? This article takes a hard look at its strengths and weaknesses, offering examples, praise, and criticism.

Chris Oltyan, Blogger

September 2, 2010

12 Min Read
Game Developer logo in a gray background | Game Developer

[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.

Enter the Google

So what does Google do that tickles my fancy so? It makes everything incredibly easy, and destroys any barrier -- and thus any excuse -- for someone not to update a doc. When it started out, sure, it had issues all over the place, but one thing stood out that instantly made it my hero: multi-user collaboration in a single doc.

This was my Holy Grail. I didn't have to worry who else was editing a doc; I could see them doing it, and I could work while they did their thing. I cried during my first experience with this. It was magical.

And oh my God, the spreadsheets! They sang like the stars to me, with automatic showing of which cells other people were editing, in perfectly color coded symmetry. The power of seeing who was editing the doc, and who edited it last, provided further incentive for people to pop in and check it out. It had a strange chat room feeling to it, which actually encouraged people to participate.

Another obstacle Google docs surmount is the annoyance of markup languages. Even with minimal tags, marking up text adds just enough extra time to what you are doing to discourage use of the formatting we are all used to. With Google docs, I could now merrily WYSIWYG my way down the lane, add bullets, and even style formats to my heart's content without ever touching the "<>" keys.

There is something to be said for a document that is pleasant to look at, both in terms of readability and ease of access for the information you need. This helps keep the documents alive and up to date.

Lastly, the things are online, so whenever I need them, whereever I am, I can quickly and easily get into the docs, update them, and be on my way. This is particularly important as in today's production environment, you are often required to be away from your desk to talk things over. A meeting room computer anywhere in the world now has access to the latest docs, and changes discussed can be instantly added.

Every Rose Has Its Thorn

It's not all fun and games, though, and Google is a rabbit hole of dependencies and commitments. First and foremost, if you are not using Google Applications, you are not using Google Docs. By signing up your entire company to the service, your emails, users, and docs all come together perfectly. Balk at that commitment, and you lose bucketloads of features and functionality. This is a non-trivial commitment, so it's wise to look at all the legalease around Google Apps before taking the dive.

An example of how partial commitment will only cause you pain is the directory sharing option. With Google Apps, you can share a single directory with users in the domain quickly and easily, thus insuring that everyone has access to the needed docs.

Without, it quickly becomes a painful process of setting up various specific user access invitations, or creating giant gaping security holes that others can exploit. So if you're going to go Google, you need to be prepared to go all the way.

That, of course, brings up other security issues, as there are a few odd loopholes in Google Docs structures. Essentially, if you insert a picture into a Google doc, it's theoretically possible for someone to access that picture from a URL. It is almost impossible for a hacker to accomplish this feat, but life on the cloud means that for better or for worse, a single failure in your security can result in all your documents being accessible by others.

Note that you will not lose this data (well, see below for more on that) but in our world of confidential releases and announcements it could cause substantial embarrassment if the wrong people gain access to your entire document library.

Remember me oohing and ahhing about online access? Well, the flipside is a bitch, as when the internet goes down, so does your entire company's document repository. On the slight bonus side, Google Gears allows you to continue working offline, but then you start facing the same merging problems that plague other non-Google systems -- as well as the danger of stomping on someone else's changes. Essentially, if you have a poor or slow internet connection, Google will cause you great pain in the speed of its responsiveness.

Lastly, as new features are implemented, and things get broken, you always run the risk of shooting yourself in the foot. For instance, using the new "easier and improved" share feature, I just managed to lock myself out of this document, and was forced to copy and paste it into a new one. It's important to note that a software suite that is always evolving can sometimes turn into a monster.

So I've Sold my Soul, Now What?

Okay, so you decide to take the plunge of the advice of this article and that strange cult of people chanting "do no evil" in the corner. How powerful is this collaboration?

As part of this article, I've done several things. First and foremost, this article itself is a Google doc, and I've now shared it with the world for viewing via this link. I could just as easily make it so you all could edit it, but for this purpose I figure the link is enough.

Now, you all can take that link, and share it around with whomever you like. I could also set the link to only work with people from a specific domain, with specific emails, and I can make it so that it requires a Google account login (or not) depending on my whim or need for security. All that would took about two seconds to set up, and sharing with a domain of people would be just as easy.

So, rather than just stop at sharing a single doc, let's assume we have a bunch of stuff we want to share inside a project. Well, shared folders are your friend here.

Take a gander at this link. You'll notice that the article is listed in this directory, and also requires no login, but now, I don't have to worry about sharing each doc individually. All I have to do when I create a doc that I want all of you to view is drop it into that folder, and voila! Instant access.

But wait! There's more!

Let's talk about spreadsheets, because I love them, and Google has done a wonderful job of ripping off everything I love about Excel and little of what I hate. For the record, I consider myself an expert at Excel. I have spreadsheets that reference spreadsheets that reference spreadsheets. Sadly, I cannot do that sheet-referencing-a-sheet trick in Google Docs, but I can still do a lot. Just view this sheet, and appreciate the use of names, complex functions, and other whiz-bang doodads that are available to you.

Now, for the fun and sheer terror of it, I have also made a public (and publicly editable) Google drawing for this article. It shows the basic features and doc types available through Google Apps. In internal office testing, it took approximately 10 minutes from "Test drawing, Try it out!" posted in a chat room to having lolcats slapped all over it.

It's important to let people know the purpose of a drawing before allowing access, so all that I ask is people keep it appropriate and do not delete the original information. It's worth noting that Google Drawings does not currently save revision history, so I have placed a non-collaborate copy of the drawing in the same directory to let people see where we started.

You can also create PowerPoint-like presentations, but that tool is low on features. There are many more compelling solutions out there, and I see no reason to struggle with Google's halfhearted attempt at this. If someone wants to prove me wrong, and demonstrate the power of Google Presentations, feel free to contact me and I'll add yours to the presentation directory. Until then, I'd advise sticking to whatever tools you are using.

Now, let's say I want to know your thoughts on this article, and I want to know how many people are looking at my docs. Well, this handy survey will let me solicit opinions to my heart's content, and while I normally wouldn't share the results with the world, I see no reason to hold back now. I have also shared the results in the Collaboration directory so you can check them out there.

Lastly, remember me mentioning wanting to know how many people are looking at my docs in the paragraph above? Well, while I can't share this easily with you all without some Perl/Python acrobatics (using a script to take the results of my Google Analytics account and then publishing them to a shared Google Spreadsheet) rest assured I am watching everyone who is going to my survey, and all docs associated with this article. A well-made walkthrough on how to track net traffic using Google Analytics can be found here.

Conclusion

Google Applications gives me, hands down, the easiest way to share documents across an organization that I've ever seen. It owns my soul for now, but Live Office and other collaborative apps are on the way. Once those technologies develop some, they may offer a challenge to the ease of working with the Google stack. But that day, I believe, is still distant, and no one else is close to causing me to convert.

Other Resources

Try these other awesome collaborative tools too!

Great Whiteboard - http://www.scriblink.com

Decent Photoshop alternative on the go - http://www.splashup.com/

Read more about:

Features

About the Author

Chris Oltyan

Blogger

Chris Oltyan, currently the Director of Product Development and Operations at ZeeGee Games, has been working in the video games and serious games industries for the past 10 years. From running his own studio producing PS2 titles, to lobbying congress for more game based training, he has had experience in a wide variety of interactive spaces. He helped create one of the first social networking apps for the Nintendo DS and has been involved in the creation of numerous virtual worlds. With over 20 shipped titles across 8 different platforms, he has faced, and overcome, a wide range of production problems, and looks forward to solving more.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like