Emmeline Dobson, Game Designer, NiK NaK, Kuju

My Thoughts

A very short but comprehensive reasoning behind the wiki, very useful for convincing people I think 🙂

Notes

NiK NaK – Currently doing the Wizardology books to the DS, for kids. Lots of third person action games in her history (more by luck!)

As for Wiki’s…we know what they are (wikipedia is one, but is not “the wiki”). Wiki’s are:
– Quick and fast to edit for anyone on the site
– Anyone can read, make changes
– Quick and easy to link things together
– Single hub linking out to other relevant sites

Allows users to comment on topics and make suggestions, bring up problems easily.

Game Design Growing Up

Stage 1 – GDD (Game Design Document) is the design – 80-100 pages long, massive amount of information, high level sizzle material (the vision of the game) but not a lot of specifications. Very institutionalised. Usually part of your contract, delivered early to the publisher. Allows you to show the team can logically think through the stages, and not just a bunch of hacks. Publisher can also hang you with it under the contract if they don’t think you’re doing it right.

GDD is the vision. For the marketing, for looking at the hero, the background. The hype! Need to show it off to someone with a short attention span since so many go to the audience.

Vision is high level design but a lot, lot more design material in the areas broken up, from AI to Sound Effects. If you were to document it all (or it is, but in small bits) you won’t end up with 100 pages of documentation but 1000 pages – example of specifics like the camera in Super Mario 64 – needing a scale of movement, not instant movement, to stop nausea.

There’s also very little understanding of the low level game design – a lot of articles on the “general” and vision game design but so few on specific areas, such as level design or game mechanics.

You are also generally not able to copy your design from other games since your camera will be different, your controls will be different. You can analyse other games and put forwards a proposal spec for your game, and then implement it in a prototype and then maturing it. A lot of evolution, and a lot of chopping and changing of the game design during production. A lot of complaining going on about the design doc – too ambitious (how can you trust any of it?), it’s too big to search, constantly changing (and the design doc doesn’t keep up). A kickback against it!

Bonus stage – Don’t bother writing anything!

Quotes: “Nobody reads them anyway.” “The design is changing all the time anyway.” “The GDD is too big to read!” “Design docs are always too ambitious.” (I don’t trust them.)

A design needs to be as far as possible an accurate map of the game.

Talking to everyone working in a small team works (maybe up to 7 people), but it doesn’t necessarily work in a if team. So many small teams (Animation, art, engineering, sound, writing). You get in a queue to talk to the creative director, or queue unanswered emails – lowers moral since you end up with a lot of second hand information and so on.

Stage 2: “Doc-as-you-go” – process to get it to do small documents over time. Lots of talking and email. Still many problems, with organisation (since not everyone puts them in good folders, etc). Instead of wading through 80 pages, you go through 80 documents instead to find something. Things like creating tutorial controls is hard without knowing what the controls are. Need to really design them at the start, but “easy” to leave them to the end (where you say “Can’t do a tutorial in this monster infested area, need something else”). Also still become obsolete – 1 month or so might be around the timeframe.

Stage 3: Wiki.

How can a design wiki serve a game team?
– Is the design relevant?
– Is it comprehensive?
– Is it current?

Searching is a big bonus, much easier. Can push the right questions onto the wiki pages, in the appropriate places. Mind mapping the project out, weigh in the entire teams experience by putting it on the wiki from the start. Everyone can weigh in and improve the resource.

Power of hyperlinking – can link in appropriate information immediately. Find the information that’s important for the time/article.

The wiki is also more relaxed – has revision history, allows people to be less strict. Safe for people to get involved. Makes it fun as well.

Lots more that is outside the scope of the talk – what wiki to choose, what people are like editing the wiki and so forth. Email Emmeline for lots of links.

Questions.

Getting design document onto the wiki?
Design document pages added to the wiki, needs links to the parent. This can be used later to copy into word for ordering.

What about maintaining the lead (for times when people add but not discuss)?
Someone, yes, needs to keep a head on at least the design document area.

What about the too many cooks in the kitchen situation?
Need to control it with an established understanding about what the wiki is appropriate for. An artist designing a complex feature about having sex with wenches, getting STD’s and lots of other things. Have a word with them personally to understand the boundaries of useful contribution.

What about academic courses?
Yes, wiki’s are not just wikipedia, it’s information agnostic. Very powerful.

Crowd: Wiki’s used for funding bids – useful for collaboration – take quite a lot of maintainance and management but useful.
Crowd: Zoe Mode has one lead designer takes the decisions out of the wiki, but keeps a separate design document for the publisher and the wiki for internal things.

How many different types of wiki are there? Problems with the designers and artists say it is too much like code, rather then WSIWIG.
Designers, artists like WSIWIG, programmers like markup. Some types of wiki have both, which is a good idea.
Crowd: For multiple people working on one document, Google docs is the same document collaboration. Everyone can be typing at the same time, in a meeting even.