Tales from the Ebony Fortress

Archive for July, 2009

Pitfalls of using wikis for game design documents

by on Jul.26, 2009, under Uncategorized

I recently made a post on this issue over at Gamedev.net, and thought I’d clean it up a bit to post over here, as I think it’s worth talking about. Designers are often looking for new and better ways both to create and present their design documents, and rightfully so. Just as programmers may try different languages, techniques, tools, and IDEs, designers should be looking at better tools and methods to allow them to capture their ideas, organise and prioritise them in a sensible way, and to present them to a variety of audiences, perhaps the most important of which during the implementation phase of the project being the programming team.

Our team used a Wiki for the current project, and while this choice carried several benefits, it also had several shortcomings. The positives barely need expressing to anybody familiar with Wikis – they allow collaborative work, ad-hoc reorganisation, easy cross-referencing, automatic outlining and table-of-content generation, built-in version-control, etc. Therefore I will expand upon the negatives. None of these problems are fatal, but it’s easy to fall foul of them without realising it if you’ve not used one before. So here’s what I learned from my personal experience.

Every page should be categorised. Use sub-categories if they make sense. In this modern world of tagging things rather than grouping them into hierarchies, or following Google’s “search not sort” mentality, it’s easy to overlook  the categorisation. Don’t do this! Otherwise there can be parts of the design that nobody sees. Nobody is going to recursively click every single link in the document, nor is anybody going to exhaustively read every page that is returned for any given search term.

Instead there should be discrete categories and anybody who needs to understand a certain aspect or feature of the game should quickly be able to see a clearly marked subset of the document that is relevant to them. Following from this, if you have a design team who are collaborating on the document it is useful if individual designers take sole responsibility for certain categories, ideally the features they designed or primarily work with. Each category should stand alone as a fairly complete sub-document, with external links existing just for reference. Otherwise you end up needing to be familiar with the whole doc to get anything done, which means you’ve lost most of your benefits over a normal linear document.

Be prepared to produce hard copies of the categories. Obviously this is not really an issue if you work remotely. But if you share an office, being able to print off parts of the document conveniently is vital. A hard copy is much more convenient to use in meetings, for writing notes on, etc. Nobody wants to be pulled into a meeting about Feature X when there is no possible way you can bring all the specifications for Feature X with you to refer to. And if you can’t refer to the documents, you tend to end up designing in parallel to them.  If you can’t print off part of the document, you tend to find that people start designing features outside of the wiki for convenience purposes. And you don’t want that because suddenly your design becomes ephemeral and ethereal – an email here, a JIRA/Bugzilla comment there, a note on a pad somewhere else, because everybody was writing without direct reference to the original document.

Ensure that pages can be locked against edits, and are when appropriate. Programmers will follow the specification as closely as they can and will clear up ambiguities with the designers as needed. But the very nature of expressing s0ftware in natural language means that occasionally a designer will write something and the programmer will implement it in a way that fails to catch the spirit of what was written while nailing the syntax 100%. This is unfortunate but is essentially a problem that designers and programmers can work through, the designers learning to be more explicit and less ambiguous with their descriptions and the programmers learning to spot situations where this might be the case. A worse problem is when designers are free to work and rework their design during implementation. A collaborative document like a wiki makes this far too easy and tempting to do. Designers, wanting the best for the game and to provide the best service to the programmers, have a tendency to go back and ‘improve’ and ‘clarify’ their designs after you’ve already started or even finished implementing them. They think they’re being helpful or diligent, but actually they can cause a major discrepancy between design and implementation. Of course, in their head, the discrepancy was already there, but in the programmer’s head, the design has appeared to change significantly.  When this happens during implementation, it can be frustrating to the programmer and cause some work to be scrapped and rewritten. Worse is when it happens after implementation, and the first that the programmer hears of it is when the QA department find that discrepancy and file a bug against it, implicating the programmer for not following the design.

Once designs are given to the programmers to work on, lock the page, and force future amendments to go through an approval process. The history and revision control feature is not enough for this. QA are not going to rigorously compare the coder’s source control commit times to the designer’s wiki revision history when noting a discrepancy between ‘The Design’ and ‘The Implementation’. More than the others, this is a management issue rather than a technology issue. The same problem could conceivably happen with any design doc. However the wiki technology makes it much easier to make little adjustments here and there without anybody noticing until the damage is done.

Ensure that all pages have one owner. A good design is often a big design. In Wiki terms this can mean tens or hundreds of separate pages. As the project moves forward, some features grow, some shrink, some are removed or replaced entirely. Obviously all these changes should be signed off with the implementors as mentioned already, but then the document must remain up to date. On a regular basis coders and QA staff will use the wiki as a reference, sometimes going back to a page they’ve not used for weeks, or using the search functionality to uncover the relevant page. What is critical therefore is that what they find must be relevant and pertinent to what they’re working on. Otherwise their time is wasted: at best, they have to search again (and again), and at worst, they take some action based on this outdated design which wastes their time and potentially that of other people too.

For this reason, every wiki page should be owned by a person on the design team, and that someone should keep the page updated in sync with any changes made to the design so that the information is always correct. If you have the information categorised adequately then each category can have an owner and this becomes quite simple. But without someone being accountable, it’s assumed that someone else will keep it up to date, and this won’t happen because nobody will exhaustively check every page to see if any are out of date. If it’s not practical to have a single owner for a feature or category (as might be the case if it is being co-designed by 2 people, for example), designate one of them as having responsibility for the wiki pages.

Be disciplined regarding scratch-pad, discussion, or brainstorming pages. Wikis are a good middle ground for discussing and evolving a design. They are more convenient than email in terms of having all the information in front of you, and less time-consuming than meetings where all but one person is doing nothing but listening. Unfortunately this means that the game design document can end up with annotations, discussions, vague ideas, and other noise scattered in among the signal.  This can make it hard for programmers to see what is the agreed design and what was just discussion and ideas relating to the topic. Sometimes the problem is in the other direction and key design decisions are left stated in these discussions and not migrated to any clear specification area.

Use a separate namespace if your wiki provides such a thing to keep the normal searches free of this noise. The MediaWiki ‘Talk’ or ‘Discussion’ pages are a good way to handle this, leaving the main pages with the official docs. At the very least flag the page with a big disclaimer message or template that quickly tells programmers or QA that the content of this page is not gospel and is subject to change without notice. Designers should migrate authoritative information from these pages to the proper specification pages as appropriate.

Hopefully that is all useful to someone!

Related Posts:

Leave a Comment :, , more...

Playing time

by on Jul.20, 2009, under Uncategorized

Sorry for not updating recently; real-life has been a bit busier than usual and I’ve had little time to ruminate on game development of late. But then this was always going to be a sporadic endeavour rather than a regular column so have patience! I’ve plenty of posts drafted up, they just need editing and finishing off.

Until then, a note on the length of time required to enjoy or complete games today. Personally I love RPGs, and especially those permitting a large degree of freedom for exploration such as Oblivion or the Might and Magic series. Even with more linear games I tend to have a cautious play style, spending 30 minutes on Doom 2 levels that had a ‘par’ time of 2 minutes, spending 8 hours on Thief 2 levels that others finished in 1, and so on. Recently I clocked up my 200th hour on Oblivion, and although I am tiring of it somewhat, it still holds a lot of interest and novelty to me at this point. Strangely, the time I spend on these games far exceeds that which I spend on explicitly ‘replayable’ games, such as Sid Meier’s Civilization, TrackMania, or any number of RTS games.

Anecdotally it seems like many people, perhaps older gamers, seem to want shorter and more focused entertainment these days. Is this just because they have played so many games and have less tolerance for obvious filler content? I’ve watched young children play certain platformers where they’ll happily try the same jump 20 times before they get it right, while I would probably have lost patience before half that many attempts. Or is it simply because older gamers have more free time to spare and they would rather see more variety and experience more victories in that time than playing one very long game would allow? It certainly seems the case that the industry is providing us with such games – And even when playing time isn’t decreased, the play area has shrunk and traded wide expanses for fine detail – compare Oblivion’s world of 16 square miles to Daggerfall’s 62, or look at the tiny compartmentalised levels in Thief 3 when compared to the sprawling cityscapes in Thief 2 such as the ‘Life Of The Party’ mission (the size of which which even this speed-run manages to portray effectively).

How does this trend for shorter games compare to the hours sunk into MMOs like World of Warcraft? Those of us who grew up with MUDs will recognise that this phenomenon doesn’t necessarily come from the presentation values, which in MUDs were almost non-existent, or even from the quality of the game design, since most MUDs gave you the equivalent of a text adventure with the worst parser since 1982 and an unbalanced version of the Dungeons and Dragons combat rules. Was it almost entirely from the socialising and the exploration factor? Maybe the combination of the two? (Brian Green has some thoughts on the relevance of different player types in a post made a couple of years ago.)

As much as I love long games, I know I could enjoy so many more if they were quicker to complete. I currently have over 30 games installed and which I play to a lesser or greater degree, but the 2 I spend the most time on being Deus Ex and Oblivion. These preclude me from making much progress on some other games (Bard’s Tale 2, Fallout, and Football Manager 2005 to name three that I’ve put on the back-burner for now) since the longer narrative driven games require a certain degree of attention and continuity. It’s easy to forget where you stashed some equipment or which NPC you meant to talk to next if you only play the game once a month, for example. So I suppose that is the downside of the games that are more demanding of time. Modern games are getting better at maintaining this state in the game for you – both Oblivion’s and Deus Ex track your objectives for you, whereas I have reams of hand-drawn maps for the Bards Tale games – but there is only so much they can do without giving you an in-game notepad which you scrawl notes into when you save and quit for the night.

What’s your preference – short play times or longer? Do both essentially give you the same value for money, and the payoff for your hours invested? Do you feel cheated by a game that ended all too soon, or by apparent filler put in to space out the content?

Related Posts:

  • No Related Posts
3 Comments more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!