My design method: how do we actually design ?
Hello there dear reader.
In my last post on AltDevBlogADay, I talked about "Perimeters" and "Interweaving". In this one I'm going to talk about "Exploitation". You might want to check my last post to get the whole picture if you haven't read it yet.
One question I ask myself quite often when playing an excellent game, watching an excellent movie or listening to awesome music is: "HOW DO THEY DO THAT ? @__@"
How does one reach such an expert level ? How is such awesomeness made ? Where do I even start ?
Like I said when describing the idea behind interweaving in my first post: find a nice place and DIG for gold.
You could say that finding such a place is "inspiration". From what I know, awesomeness isn't made overnight. It's usually more: 1% inspiration, 99% work, and exploitation is part of the 99% work.
The main question today is, we have our work basis, but HOW do we actually design games ? How do we build upon our central idea ? Our core-concept ?
From what I know, it's... a good question ? I guess we "just do it" ? That's using our intuition right ? Except...
Intuition is not enough
By designing from intuition, you're probably fixing the symptoms but not the causes, stitching features together rather than interweaving them. Intuition rarely gives precise answers. To treat causes and weave elements together, you need to get to the root of the problem, which is often located deep within the system. Intuition gives you broad answers, not precise ones. Intuition doesn't help to craft fine art: intuition is the bucket fill tool of design. When digging deep for an answer, you'll be looking for something relevant, precise.
Another reason why intuition isn't a good enough tool, is that thinking is hard, and we often stumble into pitfalls. Our brain isn't perfect, it misses things, it forgets things.
How can we circumvent this problem ?
Externalize your thought process. If you list stuff and read through it regularly, you won't forget. If you map everything on a graph, and look at it regularly, you'll often find stuff you were missing before. That doesn't guarantee you won't miss anything, but it'll help a lot. This is where my exploitation method comes in handy.
How it works
So we've got our perimeter, and we want to make a game out of it. What do we do ? Well first, I would say you can start by listing. List everything you can think of for each of the lexical fields of your base axes. List synonyms, antonyms, and anything you can think of that fits in the lists. Then list everything you can again, but starting from what you've listed before. You could call that a second pass, which can and should be followed by many others.
Some words will sound right for your game, others won't. You need to proceed to understanding why. What should go in and what shouldn't, and why ? Try to find where the frontiers of your lists are, it's probably the most important thing you need to do.
If you want to add words to the lists that aren't necessarily linked to your axes, go ahead, you need those words.
"Can we put it into the game" VS "should we put it into the game": you want to know if a word you're thinking of that hasn't been found through listing should go into the lists ? Find out if you can find a way to add it from what you already have, or just add it if you really feel there's no doubt about whether it should fit in or not, then find out why. You should always justify everything you do when it comes to making design decisions, consistency and all that.
So list, list, and list everything you can, without any consideration for sorting the stuff.
I would say this is the analysis phase. You should end up with something looking like this:
Why yes, this IS frenglish with a majority of french, it's just to give an idea.
This is a sort of lexicon of your game. Now you need to find links between the words you have listed. Any kind of link will do, as long as you think there is a link. Find intersections between the words of your different axes, that is, match/link them together. This is how hyperweaving is done: you find large loops in your graph that run through more than one axis. You might end up with something like this:
It's pretty horrendous isn't it ? Bear with me. I've mentioned that this is the analysis phase right ? You need to synthesize what you've found. You can do that by summing up similar words or set of ideas together with a single word. You most importantly also need to find loops within your graph. You might end up with something like this:
A bit more manageable isn't it ? The thing is, you don't necessarily need a single graph to do the work. Several lesser graphs can do the job just fine, and you should probably do that anyway.
So... what I'm getting at is:
- list everything you can
- if there is stuff you list, that you think isn't relevant to your game, find out why.
- analyze (expand): find words and link them.
- synthesize (reduce): find loops !
- repeat ! you'll find new stuff to add each day, you'll find stuff that can be simplified, etc.
So, you have a list of everything that should go into your game. Now you need to find where it goes. Maybe it should be a part of the UI ? Maybe it should be part of the background lore ? Maybe it should be a mechanic ? Maybe it should be part of the art of the world ? Maybe it should be part of the writing ?
The work I do with this method is like carpentry: it can show or be hidden, but it's always there. Like a retaining structure, we're talking about digging remember ?
Why all the listing you might ask ? Well, from what I understand, it works because it simulates creativity. I would say that creativity is an algorithm, and that the method I'm describing here is the thing. What does creativity do ? It looks at things, and makes links between them, actively creating new data from pre-existing data. That's what inspiration is: we're more creative when we have a basis than ex nihilo. And listing the possible elements for your game is the basis you need. Furthermore, finding links is what creativity does, for those of us that aren't naturally creative, it's pretty useful
It's like low-level code optimization, except this is design: low-level design optimization.
I was initially planning on expanding further on the upsides of this method, but the post was fast becoming huge and was losing focus, so I'll write about that next time, alongside other general-purpose design considerations.
I think some of this is pretty familiar for some designers, but I hope it's still useful somehow.
Have a nice day and see you next time.