 |
|
|
| |
Quest For The Perfect Design Tool
by Urbain Bruno on 02/02/10 01:04:00 pm
 
|
|
| |
|
Posted 02/02/10 01:04:00 pm
|
| |
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.
|
| |
|
|
What I see as "the" tool is a cross between Basecamp Writeboards and Google Wave that is not presentation oriented but rather keeps its contents in a malleable, readable form that can be exported to say Word, XML, HTML, etc. I've contrived a system that leverages the revision and permission systems of Writeboards, and the authorship and collaborative systems of Google Wave. Assuming that such systems are implemented and can be leveraged, then I see the system as follows:
System Overview => http://www.box.net/shared/pmj253u7p8
Looking at the overview image we can see how projects consist of several document elements, which consist of several section elements, which consist of several text block elements. Each element can be moved freely within the element hierarchy and can contain tag, authorship and attribute information. Tags are a similar concept used in blogging and practically anything Web 2.0 where each element can be accessible/filtered by its tags. Authorship is similar to authors in Google Wave where an element knows who has modified or added to its content. Attributes are something new and I mostly envision these being used in the export process. There may be a "title" attribute for a section or document, or possibly styling information used to render the element in the application. Basically attributes are used to provide export hints for the exporter to export to Word documents, XML, etc.
To support embedding media such as images/video etc, we could introduce a new "Media" element, which would have its own tags, authors and attributes like all other elements, and since media would be just another element it could be moved through out the element hierarchy.
It's an ostensibly "coder-oriented" tool but is useful for many writing tasks simply because you can take a document, slice it up into subnodes, rearrange them, and clone them elsewhere in the outline as needed. No nasty synchronization issues. This allows you to make multiple variations of a document that reuse the same content or create a "living history" of changes and updates. It really opens up tons of options and makes organization-heavy tasks way easier.
It's also highly extensible via Python(it's a Python-native app) and open-source so data portability options are plentiful.
But it's not as good at the collaborative elements, I'm afraid. It can play nicely with version control(nodes can be associated inside files, and then you simply check in the file), and that ability also lets you use Leo in tandem with e.g. HTML editors or IDEs, but it doesn't address real-time multiuser edits. I haven't used it in a team environment yet, but I suspect it could be adapted to one with some effort.
Like I said in the introduction we're not fan of writing tons of pages and I prefer a good talk with programmers or artists and trust me as the studio manager of my own company I know what it is to have design convictions on my projects :)
However it doesn't correspond quite well to the day to day issues you have when managing a game (especially redundant tasks) (unless you have a very talented team which is SUPER autonomous and self creative, then in this case, why a designer is needed in such a team?).
A small example, when you changed for the 100th times the combo system of your game and your manager ask why you took such decisions? Are you able to explain in details what happened in the process. Of course you can always say: "Oh you know it is so much better now" (doesn’t work).
The idea is to find an automatic way, process or tool to keep track of such things and focus more on communication and creative part of our jobs.
@Darren: I didn't know about this one, we're going to check it. Thanks.
@Terry: I think at a certain stage the issues are the same as in the Wiki (maintenance).
@Ethan: MindManager is really a good tool especially in terms of how you navigate within available information.
@Timothy We're not talking about difficulties in communicating our ideas but more about what comes after that. Since Fishing Cactus isn’t a *big* company (we’re 10), a designer is in charge of several projects (design+management) at once while working to produce new game pitches and presentations.
@Darren:You're right, the productivity issues go well beyond the simple document editing process. Exporting the data to formats is a useful feature but still often requires quite a lot of work to have final documents that are usable and malleable. All the features you describe would fit nicely into what we consider the "ultimate tool". More so, we also try to see all the design data as a set of text, tags, authors and other relevant data. What about a tool that could pull all the data automatically. For example, search for the “main menu” tag and the tool pulls out all the relevant design documents and related asset lists, implementation tasks and so on...!
@Ethan: Mind Manager is a great piece of software and it could fit perfectly into what I’m saying about. You could arrange all you data and subdata easily and visually (it’s always better to work on fun to use tools)!
Arranging data and subdata easily and visually sounds like invitation to check Canvas for One Note:
http://www.officelabs.com/projects/canvasforonenote/Pages/default.aspx
Still imperfect as it's Research and Development project, but inspiring if that's the direction you want to take.
- 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)"
Google sites (and other google tools as google docs) bring good answers to lot of elements of your list of needs.
But for me, google sites is just a good wiki tool so maintenance comes quickly crazy.
By the way, I think a tool takes all its value when it's associated to a set of "best practices". Moreover, this synergy can be improved adding some little home made tools built on the API of Google Tools.
@Mickaël You're right on all topics and Google certainly tries to centralize all its services in a practical way And that's why maybe we're disappointed with Wave...we hoped that it could act as a "centralizing client".
What we should expect of a designer's dedicated tool though, is the ability to automate or streamline the best practices you're talking about.
@ Mickael: On google site, the issue might be to swap from one application to another. Also you cannot automate data mining.
Best practices are always something to do.
The game is visualized in Gliffy (gliffy.com) which is basically a visio style flow chart program. Usefull cos you can colour boxes with your own styles for simple recognition (we use red boxes to denote that this needs more work for example). Ideally I would be able to click on a box and have a editable page pop up, where you can add anything about that box. Text pics videos whatevr. Gliffy doesnt do that, BUT... the text field associated with each box can be a link, so I simply created a Wiki, and each box links to a wiki page.
It would obviosly be better if it was all one application. I would like to be able to freely make a flow chart, and it automatically make a page for each box.
Can Mind Manager do this? I dont want a mind map... Anyway, its too expensive for me... I need er.. a free tool... ok stick some ads round the side, or charge me 50 bucks, but not 500 bucks... then I will stick to a wiki ha ha ha!!
1. Consider the need for a collaborative technology platform rather that an application or tool.
2. As applications become more social, realtime and collaborative, I believe they will inter-operate and be user extensible too.
3. Design time at run time, Develop In Situ.
This is what I've thought about:
A "whiteboard OS". where rich media applications can be built upon and which run collaboratively.
Common whiteboards now are just a scribble boards in my view. What I'm talking about is full GUI, windowing/MDI with full rich media types.
By having a complete set of GUI elements, the whiteboard real estate can be very organized and virtually unlimited in size.
Assets can be dragged and dropped from the desktop right onto the whiteboard. These assets could be programs too.
What I've be able to realize: http://www.colabry.com
I'm currently using Confluence wiki engine. It is the 4th game company I've been working in to use it, and in all my experience, it works quite well. My team also uses Mantis for task-tracking - it does it's job, and it's free and simple (and I also keep high-level plan in MS Project 2010), and I use excel 2010 for tables (it got a lot of unique tools for game designers).
MindManager is good for brainstorming and working on concepts, and I use Visio for schemes and interface design. Default windows elements that are already built into one of its templates help a lot. I'd like to use Xara for this, as I have a great experience with this editor - but my company currently buys only office. Occasionally I also use Paint.Net for screenshot editing and rough designs.