As designers we are always looking for the best tool to communicate our ideas. At Fishing Cactus we always try to come up with collaborative solutions and we try to keep the following motto: "not make a 100 pages design document". Instead we try to find solutions to keep the design document light and readable for different audiences. Managers want to have an overview of the game in order to evaluate scope. Programmers want to have a clear understanding of the mechanic they have to implement and game designers want to know how a mechanic works with another. Most of the time all these people are looking for either a very detailed aspect of the game or a big overview.

All design documents are living pieces, changes in scope and gameplay mechanics occur more than once in the lifespan of a game project. Also there are different types of design documents: game concept, game treatment, one pager, game design document, game backlog (if you are using SCRUM). Also, a variety of production documents is generated as the design undergoes implementation (asset lists for one, localization texts list and so on...).

For a designer, managing those different aspects quickly becomes tidy work and is bound to require a great amount of time. Ultimately, we spend literally days and weeks maintaining the documentation. But that's not the only problem we spotted. Here is a list of elements we think can be improved:

- Maintenance (time cost and ease of use)
- History (versioning)
- Rich text editing (often needs using code tags) with embeddable content
- Collaborative tool (invite other designers or even other persons to join the discussion)
- Moderating (content supervision)
- Search / Indexation issues
- File organization
- Dedicated sections for dedicated usages (Brainstorm meeting, Sprint review)
- Profiling of game design elements (who worked on what)
- Structured overview of the above information
- Relation between causes and effects (a brainstorm meeting changed that X mechanic on the game)
- Data mining for lists (sound, localization, animations, art assets)
- Scalability of the document (regarding the reader, scope)
- Define the granularity of information (regarding scope and so on)
- Keeping track of outdated content (reminder)
- Keeping the team informed of the meaningful changes in real time (regarding what they implemented previously)

This is why we started here a small discussion around a dedicated designer tool to remove some hurdles from our daily work.

It is also worth noting that we're discussing a tool that would be used internally and would not be suited for producing presentation documents for clients and business partners (but an export feature could allow for raw content to be reorganized and on which you can add extra eye candy to make the documents more sexy).

Let's talk about it!

We're starting this thread hoping to have some constructive input about what designers always dreamed of for their work tools. So let's share some info and not forget that sizes and configuration of a game developer company can vary widely. Not to mention project scope.

Leave your thoughts in the comments and feel free to point out relevant discussions that could bring new data to our analysis. A lot of industry people talk about this constantly on several sites, forums, conversations, but it seems to us that no existing or non-existing tool to rule them all has emerged.

What we're asking here is to think about what you'd love to see in the ultimate design tool and to what problematics it should bring answers to. And talk about it :)

What we think about:

Google Wave

Google Wave has arrived (in an ever-evolving beta form) and as usual, public opinion is fairly divided about it. But how does Google Wave fare as a game design tool?

We started using Google Wave as soon as beta invitations were sent out and we started thinking about ways to put it to good use. Below is a list of Wave features and their relevance to our design process.

Creating/Removing Waves: Anyone can create a Wave and share it, but removing is impossible. When a Wave is removed from a Wave client, other followers still have access to it. It is like having an old outdated document lying around and just waiting to mess things up. This leads to a bigger issues, the need for some form of content moderation and data structuring: you know, creating folders to put specifics waves in, moving Waves around to organize them. Presently, these operations only affect the precise client that triggered the change, leaving the other follower clients unchanged.

Graphic interface: Wave's interface is far from perfect (and surely far from final) but it's still fairly easy to add/edit content. As soon as a Wave gets longer though, content gets hard to find and structuring information becomes almost impossible (you can't move blips, Wave's contents, once they are created).

Ease of sharing and collaborating: It is extremely easy to invite and share content with other Wave users. Being able to edit all the content and following discussions or when you have an idea or suggestion is undoubtedly a great feature. On the contrary, having no way (at present at least) to remove people from a Wave can really be a problem for those company paying a lot of attention to secrecy. The case we have here is that some people left the company and still have access to some confidential content and although we trust our guys, we can see this being a huge problem.

Changes history (playback button): This is a great feature that lets you playback all the changes that have been made to a Wave. It's really useful to track/review changes as a whole but also acts as a major "undo" function.

Real-time messaging: This is advertised as a world-changing feature but we fail to see how this feature serves us (we are already using IM systems). More so, this has zero relevance in our work context. Next!

Embeddable media and gadgets: This feature isn't used often (embedding images and textual content in document is a feature we've come to expect as standard) but we had a case when embedding YouTube videos was nice. We had to provide a quick list of small "high concepts" for a potential partner and each people on the design team could add theirs. Embedding videos was a nice, quick way of proving the concept by showing similar games or visual inspirations (and video work better than pictures which work better than text). This allowed us to spend less time trying to understand the concepts and reviewing them and going directly to the selection process.

Document uploading: We thought this was great. Always having the latest document version up on the wave for everyone to have access to. Unfortunately this leads to the usual maintenance chores as someone needs to keep track of all the document revision/changes. Also, the document being not directly editable this means that people have to download the document, modify it and upload it back. Not very efficient. And Google Docs integration is terribly poor at the moment (even with the iFrame gadget).

Conclusions:

While Google Wave has some nice features, we don't see it as a long-lasting tool for game designers. It proves useful to keep track of ideas, sum up brainstorms, share information and references not to get lost.

Unfortunately, as soon as things get serious (as in "the game is actually being produced, wohooo!"), Wave usage is limited (at best) to keep track of ideas a little more easily and flexibly that with a forum or a wiki.

Feel free to comment.

Article written by Andrea Distefano and Bruno Urbain.