Great Dane Games

Great Dane Games

Great Dane Games - all things gamerelated

This weblog is the digital playground for Anders Højsted. I'm a philosopher, indie gamedeveloper, writer & all-round renaissance man.

Userdriven Gamedesign

Game DesignPosted by Anders Højsted Sun, October 25, 2009 18:48

I've been a bit unsatisfied with the last blogposts about Shadows Of Europe and Students Massively Multiplayer Online Game. It took me a while to understand what the problem was: they remind me of corporate PR-interviews. They only deal with the result of the designprocess and very little with the actual process. Please bear with me.

"Designing" is the process of shaping of a given material into a form according to a set of specifications. The form is the "design". The specifications can vary a lot, based on intended use, target-audience, type of design (eg digital game), material, available ressources and (probably also) a lot of other variables.

When we design games, we create an interactive experience by creating rules, and a way to interact with them. When we create digital games, we imbed the rules in software. The game is the rules, the interface is our way to interact with them and we (usually) program the games to make them more accesible to a larger audience.

(I can recommend Robin Hunicke, Marc LeBlanc & Robert Zubek's article "MDA: A Formal Approach to Game Design and Game Research" for an introduction to the distinction between rules (:mechanics) and experience (:aestetics)).

Gamedesign is a process where you start with an idea ("wouldn't it be cool if...") and build it. Usually when you've built and playtested it, you find out that it isn't quite doing what you want to; it isn't quite the experience you were looking for. So you have to redesign it. And test it. And re-design it. This leads to the iterative cycle: (Re-)Design -> Test -> Evalutation.

(A bit more about iterativ development here: Iterative & Incremental Development)

Designchoices are made between and in each of these stages. And for a outside designer, these choices are the most interesting parts of the process. You can always hear about the inital idea and you can always find out what the process ended with by using the final product, - but you can't really hear about why the product ended up the way it is anywhere.

(One way of covering the process is to have a design-log where you document designs and note changes; they're good for gathering info about the process but are rarely made public. They also need someone to put the content in a context if outsiders are going to comprehend it).

Designers rarely talk about these issues. Partly because it takes time from the designprocess, but also because it reveals where you make mistakes. Often you'll have an brilliant idea about what will make billions, but after testing&evaluation you'll have to give it up, - and all of the sudden your Magnificient Feature (tm) ends up on the floor in the design lab. If you have a professional pride and have staked your professional skills on this feature, this bites. Hard. No need to launder that dirty linnen in public (Besides, everybody say that it's ok to fail because failing is learning experience, - but nobody rewards it). Everybody makes mistakes but nobody wants to talk about; it's a bit like sex.

However, if you don't talk about it, you can't get feedback on it. The problem with the SoE-post and the SMMOG-post is that I don't talk about the justifications for the features that we did/didn't decide to do (like not naming the biggest company in Scandinavia "Viking" or the compromise of using Interlock as the foundation for the design in SMMOG).

However, talking about the process - especially while it's taking place - has two major advantages: businesswise it generates PR, but most importantly: it generates feedback. If you take each design-phase, make the design public and ask people for feedback, integrate the feedback, have people test your prototypes, gather their feedback and re-design according to their feedback, you'll a) get more feedback on the project, b) have it tested more extensively, c) get more ideas for the design & d) give the customers a feel of ownership with regards to the final product. These are all good things.

(In Interaction design, this is called userdriven innovation and is all the craze these days; all the cool kids are doing it).

But there's drawbacks. If you do it, your design becomes public at a very early stage. It will probably be very sketchy and usability will suck, so many people will disregard it. Some people might be attracted to it, which is also bad, because many iterations later you will have a very different product on your hands. These issues can be handled by adjusting people's expectations; communicate loud and clear where you are in the process, so people know what to expect.

Public also means that your competitors will be able to copy (or at least draw inspiration from) your product, which gives you less of an edge market-wise. However, everybody will be able to see that your competitors are copy-cats and they won't have the upside of the goodwill from your open communication/user-involvement.

The user-involvement can also raise copyright-issues. If you've been the lead designer on a process with input from 20+ personens (or more) and these people aren't formally working for you, who then has the rights to the product? This can fairly easily be handled by a closed forum and a legal department with NDA/contracts/large men in long black jackets coming 'round, which should (for legal reasons) be the big companies approach to it.

I'd like to take a different approach to it, seeing as I don't have the funds for a lawyer and actually really prefer to trust people instead. So the deal's gonna be that anyone who contributes significantly to anything I do will be credited on it and I'll buy you a beer (or another beverage of your choice) and maybe dinner if we meet in real life. Deal?

I'll start posting about Evolution: Fitness ASAP.


  • Comments(0)//