March 22nd 2005
From Consciousness
Explained
by Daniel C. Dennett
Early in the book, Dennett begins to set out a method for Phenomenology.
You don't do serious zoolology by just strolling through
the zoo, noting this and that, and marveling at the curiosities. Serious zoology
demands precision, which depends on having agreed-upon methods of description
and analysis, so that other zoologists can be sure they understand what you are
saying.
Serious Phenomenology is in even greater need of clear, neutral method of
description, because, it seems, no two people use the words in the same way, and
everybody's an expert. It is just astonishing to see how often
"academic" discussions of phenomenological controversies degenerate
into desk-thumping cacophony, with everybody talking past everyone else. This is
all the more surprising, in a way, because according to long-standing
philosophical tradition, we all agree on what we find when we look inside at our
own phenomenology.
I would argue that almost every piece of writing, serious
and non-serious, academic and anti- academic, on the subject of videogames, is
simply the result of people 'strolling through the zoo, noting this and that,
and marveling at the curiosities'.
'Oh, I just noticed that Lara Croft plays with concepts of femininity, I'll make
a note of that.'
'Crikey, isn't the gameplay in Halo smashing?'
'Resident Evil 4 has a different camera system to the previous games, but the
control system has hardly changed. How clever I am!!'.
'Katamari Damacy is unique'.
All perfectly true, worthy statements, entertaining and containing some insight.
Mostly useless to game designers.
As Dennett states, any system of learning (zoology, phenomenology or the study
of videogames) needs 'agreed-upon methods of description and analysis',
otherwise you get 'desk-thumping cacophony, with everybody talking past everyone
else'. Often, I think you'll agree that we find ourselves in the doing the
latter. I think we are moving, albeit slowly, into a situation of some
agreed-upon terminology - the works of various writer/designers including myself
should help that, (although what we really need is a proper peer-reviewed
publication where we can set this stuff out formally and in agreement), but the
methods of analysis are going to be a little harder to come by.
Commercial interests often drive this sort of thing, and we can already see game
analysis becoming somewhat formalised and codified by the likes of Microsoft,
amongst others. These types of tests are generally focused on products in
development, and they tend to focus on user-centric problem-finding and
problem-solving analysis. For example 'is the inventory system intuitive?', 'can
the user aim properly?'. They also keep their findings secret, for obvious
reasons.
Those types of investigations are valid, especially if you have to quickly fix
something between alpha and beta, but the work of usability labs for product
testing is never going to create the foundations of an analytical system.
I'm not sure what kind of body or organisation needs to collect this data, but
it would need to be peopled or policed by working game designers. We'd need to
look for trends and conventions that are hidden from 'strollers'. We'd need to
analyse in a systematic and creative way, collect and share data and concentrate
on facts rather than opinions. A real academic process is one of some structure,
some creativity and a lot of information. That information needs to be organised,
consistent and useful. It needs to relate to real products in the marketplace
and our everyday experience. It needs to help designers do their work and help
academics do their business of analysing and theorising. The data from the study
of videogames needs to be simply presented and described in easy to understand
language. It's probably going to be boring work, but work that pays real
dividends for those committed to collect and collate this information, and those
who discover the hidden secrets and conventions in the data.
We are getting there, but we still have a long way to go, and nobody seems
willing to step up and make an effort. Data collection isn't as sexy as
intellectual posing. Are we forever going to be a gang of disorganised,
secretive, cacophonous, pseudo-scientific, pseudo-artistic professionals, or are
we destined to become something else?
Oct 5th 2004
From The
Pleasure of Finding Things Out
by Richard Feynman
Following the destruction of the Challenger Space Shuttle on January 28, 1986, a
commission was formed, led by Secretary of State William P. Rogers. The
scientist on that commission was Richard Feynman. His report was almost
suppressed by commission as it was seen as embarrassing to NASA. In an extract
from this report, he talks about the differences between bottom-up and top-down
design.
The usual way that such engines are designed (for
military or civilian aircraft) may be called the component system, or bottom-up
design. First it is necessary to thoroughly understand the properties and
limitations of the materials to be used (for turbine blades, for example), and
tests are begun in experimental rigs to determine those. With this knowledge
larger component parts (such as bearings) are designed and tested individually.
As deficiencies and design errors are noted they are corrected and verified with
further testing. Since one tests only parts at a time, these tests and
modifications are not overly expensive. finally one works up to the final design
of the whole engine, to the necessary specifications. There is a good chance, by
this time, that the engine will generally succeed or that any failures are
easily isolated and analyzed because the failure modes, limitations of
materials, etc., are so well understood. There is a very good chance that the
modifications to the engine to get around the final difficulties are not very
hard to make, for most of the serious problems have already been discovered and
dealt with in the earlier, less expensive, stages of the process.
The Space Shuttle Main Engine was handled in a different manner, top down, we
might say. The engine was designed and put together all at once with relatively
little detailed preliminary study of the materials and components. Then when
troubles are found in the bearings, turbine blades, coolant pipes etc., it is
more expensive and difficult to discover the causes and make changes. For
example, cracks have been found in the turbine blades of the high pressure
oxygen turbopump. Are they caused by flaws in the material, the effect of oxygen
atmosphere on properties of the material, the thermal stresses of startup or
shutdown, the vibration and stresses of steady running, or mainly at some
resonance at certain speeds etc.? How long can we run from crack initiation to
crack failure, and how does this depend on power level? Using the completed
engine as a test bed to resolve such questions is extremely expensive. One does
not wish loose entire engines in order to find out how a failure occurs. yet, an
accurate knowledge of this information is essential to acquire a confidence in
the engine reliability in use. Without detailed understanding, confidence cannot
be attained.
A further disadvantage of the top-down method is that, if an understanding of a
fault is obtained, a simple fix, such as a new shape for the turbine housing,
may be impossible to implement without a redesign of the entire engine.
Any seasoned game developer will see the analogies between
the processes described and our work. Thankfully, we do not find ourselves in
situations where people's lives depend on our decisions, but the complexity and
expense of game development certainly has a lot in common with medium to large
engineering projects.
I obviously favour a bottom-up approach to game design. Game technology
development is generally already produced in a bottom-up manner, as coders tend
to be au-fait with the techniques Feyman describes. What designers need to do, I
think, is examine this type of process and apply it to their field of work.
The materials of game design are obviously the primary low-level elements of
interaction in the game. These fast, simple actions and reactions form the basis
of all the players experiences and as such should be treated with as much
respect and time as the basic materials in an engineering project. Feynman uses
the term 'experimental rigs' which is an idea that can be directly applied to
game development. It is usually quite easy to create a small prototype of an
interaction or action in a cheap and cheerful manner in order to stress-test
your concept. This might be a 'blue room' to test character movement, or a
shooting gallery to determine weapon accuracy cones. It could be a text-based
app that simulates population growth or character development.
Like the aeronautical engineers, the next stage is to use those selected
materials in the manner of what Feynman calls 'larger component parts'. These
are usually objects in which two or more smaller components interact (for
instance bearings in a bearing housing, or a sprocket threaded to a spindle).
Our game design equivalents would also be instances where low-level actions and
interactions are combined. For example the 'blue room' may get an enemy dropped
into it, or a series of pickups or weapons placed. The shooting gallery could be
combined with character movement or the weapon attached to a vehicle. The text
based population growth app could be combined with the interactions of
individual population members in combat or mating.
As soon as we being to combine elements in a bottom-up manner, we can have a
high degree of confidence in the solidity of the individual elements, and be
pretty sure that any anomalies are now the result of the interactions between
elements, rather than intrinsic problems with the elements themselves. Because
the system examined is simple, we can get to the root of the issue, resolve it,
and find ourselves with another confident, solid system.
Now, as we move up a level, it is possible to look at actual component parts of
the game as a whole. Levels/environments/stages/tracks etc. We know we have
solid, dependable systems, that are fun to use, easy to understand and elegant
to control. As we build levels, we can be pretty sure that if the game suddenly
looses something, this is the result of the level content, rather than the
systems. Because we have proven our low-level elements, we can avoid the
all-too-familiar meeting where it is decided the missions aren't fun, therefore
we need to examine the game systems. If we isolate each stage of the process,
like a scientist, we can much more accurately determine the cause of the
problem.
Finally we have robust elements, interacting correctly, and set in enjoyable,
entertaining environments. We can bring the levels together and examine the game
as whole. Hopefully any changes made to the flow and structure of the
missions/stages/tracks will be evident here, and we will not need to edit
individual missions, or add or remove low level systems. We may need to edit the
content, to ship on time, or to make the game consistent, but we can be sure
that those dropped levels were good individually, just not appropriate for the
entire game object.
Just as Feynman says, the disadvantages of top-down design are rather familiar -
expensive re-iteration, dangerous lack of knowledge about the interaction of
subsystems and inflexibility in the design when problems are found. All of these
things are costly, demoralising, but thankfully in our case not
life-threatening. If you follow the bottom-up approach, however, I believe they
are really quite easy to fix.
August 22nd 2004
From Notes
on the Synthesis of Form
by Christopher Alexander
Alexander is making distinctions between ancient forms of design (the ritualised
building of houses in primitive cultures) and their modern equivalents (the
building of houses designed by architects who are schooled formally by
academia). This is a subject which he talks about at length, but the general
principle is one that can be directly applied to videogame design.
In the unselfconscious culture the same form is made over
and over again and again; in order to learn form-making, people need only learn
to repeat a single familiar physical pattern. In the selfconscious culture new
purposes are occurring all the time; the people who make the forms are
constantly required to deal with problems that are either entirely new or at
best modifications of old problems. Under these circumstances it is not enough
to copy old physical patterns. So that people will be able to make innovations
and modifications as required, ideas about how and why things get their shape
must be introduced. teaching must be based on explicit general principles of
function, rather than unmentioned and specific principles of shape.
I shall call a culture unselfconscious if it's form-making is learned
informally, though imitation and correction. And I shall call a culture
self-conscious if its form-making is taught academically, according to explicit
rules.
I would argue that many game designers and development
houses are still operating under an unselfconscious system, and I think this
type of habit can be damaging to the future of those who use it.
An unselfconscious designer does things because they have always done things
that way. They repeat habits and patterns and process without questioning their
reasons in each individual application. They tend to do things the same way over
and over. They do not apply measurement, science or other academic principles to
their work. This makes them dangerously inflexible.
Consider the unselfconscious house builders of Polynesia. The building of a
house within that culture is a ritual - everything is done in a traditional way,
from the choice of location and the placing of supports to the application of
covering materials. Priests and elders are present at every house building,
making sure that the process is being carried out according to those traditions.
Things are carried out this way 'because they always have been' and any attempt
to deviate from this ritual is met with serious opposition within the culture.
This process of house building has obviously been very successful - the slow,
measured evolution of the form of the houses has meant that no single individual
is able to make a design mistake or instigate a dangerous fashion in building.
It also functions well in a pre-literate community. The techniques of building
are passed on by observation and copying, without the need for detailed plans.
This inflexibility can, however also cause problems. If, in a theoretical
Polynesia, a sudden change occurred in the climate, the unselfconscious system
would not be able to keep up. Heavy rains or snowstorm would not be able to be
dealt with by the ritual, as it frowns upon experimentation and the
understanding of the specific reasons for the design.
Many game developers show a similar inflexibility in process, and it leads to
the same potential for danger. The 'high priests' and 'elders' observe the
development process, and ensure the ritual takes place as they have always done
it. Any deviation from the tradition is met by scorn, and most of the time the
games produced show a marked similarity to previous products which have used
that traditional process. Academic, scientific and analytical techniques are not
allowed, as they could call into question the origins of the ritual - the search
for true knowledge is withheld and the high priests and elders maintain power.
This process works well if the game development environment is as static as the
Polynesian weather. Unfortunately, it isn't. The videogame market is subject to
lurches and shifts, as technology increases in jolts with new hardware cycles.
The size of audiences and budgets similarly grows, at an often surprising rate.
Similarly the audience is getting older, and old genres and IPs are often not
met with the same enthusiasm that they have in the past. Furthermore the
videogame market is more and more subject to fickle trends and fashion as it
moves into the mainstream.
This is the environment where the unselfconscious designer finds themselves in
danger. With the technological and economic environment in flux around them, the
ritualised techniques they developed can suddenly become out of date by a
serious margin. The habitual and often idiosyncratic systems they have devised
over the years no longer achieve the same successes that they have in the past.
Games can be developed that are out of date in genre, setting or tone.
Technology can be developed in a slapdash or unorganised way which is no longer
competitive. As selfconscious developers take the lead, with their use of
flexible, modern organisation, an academic approach to technology and content
development and the use of formalised communication of ideas within and between
teams, the unselfconscious developers find themselves at a loss, scratching
around for new ideas and systems, and feeling suddenly vulnerable as the old
rituals prove themselves useless.
It is the previously successful organisations and individuals who are most at
risk from this phenomenon, as they are likely to feel that their systems, habits
and rituals are more valid than others. They are more likely to hang on to the
old techniques because they have all the successes of the past to prove that
they work. The problem here is that the successes of the past happened in the
past.
It is only by the rejection of this unselfconscious process, the constant
evaluation and re-evaluation of techniques, the application of academic and
scientific measurement and technique that any designer (be it a house builder,
telecommunications designer or videogame developer) can make sure they don't
become as much a historical footnote as the straw house builders of Polynesia.
July 21st 2004
From Six
Degrees
by Duncan J. Watts
A Nonlinear View of History
The notion that outcomes can only be properly understood in terms of the
interaction of individuals, each of whom is reacting in real time to the
decisions and actions of others, presents us with a quite different view of
cause and effect than the one to which we are generally accustomed.
Conventionally, when something or someone is successful, we assume that the
extent of the success is proportional to some underlying measure of merit or
significance. Successful artists are creative geniuses, successful leaders are
visionaries, and successful products are just what consumers are looking for.
Success, however is a descriptor that can only be applied after the fact, and
with hindsight it is easy to be wise. Our typically outcome-oriented view of the
world, therefore, leads us to attribute the success of something to whatever
characteristics it happens to exhibit, whether or not those characteristics
where ever recognized as special beforehand.
What we don't generally consider is that the very same thing, with the very same
characteristics, just as easily could have been a dismal failure.
Watts is using this brilliantly described insight to support
the argument that elements of culture are parts of a complex network of
interaction, and can therefore not be considered in terms of simple cause and
effect. This idea is one which would be useful to apply to videogame
development, I think.
It is our natural reaction, whenever we experience an effective videogame (be it
effective from a design or commercial point of view), to immediately try to
discover the process that was used to create this success. These examples of
process often become part of videogame legend. I would consider the following
examples of legendary process.
1. The team on Metal Gear Solid 2 each had a book in which they sketched and
jotted down ideas. At the end of the week, the team's senior staff would examine
everyone's book and consider including the ideas.
2. The team on The Legend of Zelda: Ocarina of Time had a large wall at one end
of the office, on which they stuck Post-It notes. These notes represented
brainstormed ideas about features to add to the game.
3. Lionhead Studios have a continual influx of young work-experience testers
that play the studio's games, sit in on design meetings and offer their
opinions.
4. John Carmack takes his laptop on holiday and works seven days a week.
5. Miyamoto's teams at NCL habitually take a game to beta, scrap it, and start
again from scratch.
6. Yu Suzuki invited his six-year-old child into the development of Shenmue, in
order to get their opinion on gameplay and story.
It is the received wisdom that these examples of esoteric process are
significant contributing factors to the success of the associated games. That
people who take chances and push the boundaries in process can expect to reap
the rewards in games that likewise push the boundaries in user experience or
commercial success. I'm not sure that this is the case at all. As Watts says;
Conventionally, when something or someone is successful, we assume that the extent of the success is proportional to some underlying measure of merit or significance.
What if the people behind successful games had no idea what
they were doing to manufacture that success? What if these were processes that
were too subtle, complex or unconscious to be identified, let alone communicated
to others? What if (as is often the case) successful creators and teams are
unable to repeat their initial success precisely because they are unable to
determine what they did right in the first place? What if none of these esoteric
and legendary methods has any effect on the projects at all?
The relationship between cause and effect in other people products in other
people companies is so complex, and probably so different to ours in our
individual teams, that I think it should be given significantly less
consideration than we currently give it. If we continue to analyse process over
product, then we are doomed to see random success and failure, and we will never
have a codified set of skills that we can pass onto other designers. We'll be
forever worshipping artistic geniuses, only to scratch our head in confusion
when they create a dud next time around.
We need to look at the actual experience of playing the game in as much detail
as we examine the process of developing the game. We need to identify what it is
about the low and high level structure of Ocarina of Time that makes it so
compelling, before we read three hundred interviews with Miyamoto in which he
talks about applying the experiences of playing as a child to development. We
need to understand the complexities of the cultural and economic landscape that
make State of Emergency outsell Beyond Good and Evil, before we blame the
failure of the latter on the magic get-out-clause of 'bad marketing'.
By looking at a game in detail, precisely examining the experience and
possibilities of the product, we get right to the centre of things. Yes, Kojima
might have come across that game mechanic while reading Plato, but that doesn't
mean we should all rush out and buy The Republic. The path which he took to
create that mechanic can never been re-created, even by him, so lets not waste
our time examining it. We need to look at what it is about the object itself
that works, before making any assumptions about the process that created it.
Once we think we've determined what the game is doing right, then we can look at
creating a process tailored to our individual circumstances which that can help
us emulate that kind of success.
June 27th 2004
From The
Pleasure of Finding Things Out
by Richard Feynman
The world-famous physicist is describing his time spent on
the Manhattan Project
in Los Alamos, New Mexico during WWII. The team have just taken supply of some IBM
Tabulators to help them with the vast amount of calculations they are doing
on the project. A certain Mr. Frankle is in charge of the machines, and Feynman
notices a change in him...
Well, Mr. Frankle started this program and began to suffer from a disease, the computer disease, that anybody who works with computers now knows about. It's a very serious disease and it interferes completely with the work. It was a serious problem that we were trying to do. The disease with computers is that you play with them. They are so wonderful. You have these x switches that determine, if it's an even number you do this, if it's an odd number you do that, and pretty soon you can do more and more elaborate things if you are clever enough, on one machine. And so after a while the whole system broke down. He wasn't paying any attention; he wasn't supervising anybody. The system was going very, very slowly. The real problem was he was sitting in a room figuring out how to make one tabulator automatically print arc-tangent x, and then it would start and it would print out columns and then bitsi, bitsi, bistsi and calculate the arc-tangents automatically by integrating as it went along and make a whole table in one operation. Absolutely useless. We HAD tables of arc-tangents, but if you've ever worked with computers you understand the disease. The DELIGHT to be able to see how much you can do. But he got the disease for the first time, the fellow who invented the thing got the disease.
So there you go. People were doing it at the very dawn of
computing.
How many people have you seen succumb to this disease? Have you ever been
infected yourself? Ever worked for a team that is infected to the point that
they become shuffling zombies?
Designers, especially today, where technical expertise is pretty much a
pre-requisite of the job, are very susceptible to this disease. As scripting
languages and tools become more powerful, it is ever more tempting for designers
(people who should be considering the customer experience above all others) to
stop worrying about entertaining the public and concentrate on entertaining
themselves.
We've all seen the signs. A coder exposes a new aspect of the game to the
designers, and before even thinking about it they've got something on screen and
they are entranced by the power in their hands. Before you know it, they've
devised the videogame equivalent of Mr. Frankle's 'bitsi, bitsi, bitsi'
arc-tangent tables. A complex and satisfying technical problem with no use to
the project whatsoever. It might be a complex AI manager that does things the
player with never see. It might be a flashing icon in the HUD that a coder and
artist should be dealing with in the last three months of the project. It might
be a level which is full of clever tricks but plays like a dog.
I'm not suggesting those who succumb to the disease are weak or inferior at all.
As soon as I find myself doing a vaguely technical task I get re-infected and
start fiddling with useless crap which entertains me rather than contributing to
player experience. What a smart designer needs to do is understand that they
will succumb at some point during a technical task, be able to recognise the
symptoms nice and early, and take the necessary steps for recovery as soon as
possible.
Some designers might find they can cope by stopping technical work and doing
some creative work for a day. Some might find they can simply concentrate their
mind on the design document and implement like a robot, without giving
themselves leeway to fiddle. Some might rely on a lead designer to pick them up
and put them back on the straight and narrow. Others may become completely
infected and become a coder (joke).
The worst thing that can happen is for this disease to infect an entire team, or
someone in charge of a team. Under these circumstances the whole project becomes
focused around the pleasure of the loop (idea, design, implement, results) and
focus is permanently lost on the final end-user experience. Games developed this
way are pretty easy to spot. They have lots of little moderately impressive
elements, each technically impressive and entertaining for the viewer for about
five minutes. They usually take over five years to develop. I once worked for a
company who's founder used to get excited about developing scripting languages
that were fun for the scripters to use, or that in some way did something
clever, new and completely useless. That company spent a year longer than
scheduled implementing scripts on that project and in the end they all had to be
hard coded because the scripting language was so impractical.
It all comes down to an ironic fact. Using computers is fun. They give you power
and control and the opportunity to experiment and be creative. All of that
entertainment is available to the user of the software or system. All we need to
do as game designers and developers is make sure we are creating environments in
which our customers feel that enjoyment as much as we do. We want the players to
become infected, while staying away from the disease ourselves.
May 30th 2004
From Notes
on the Synthesis of Form
by Christopher Alexander
A designer may object that his thinking is never as verbal as I have implied, and that, instead of using verbal concepts, he prepares himself for a complicated problem by making diagrams of it’s various aspects. This is true. Let us remember, however, just what things a designer tries to diagram. Physical concepts like “neighbourhood” or ”circulation pattern” have no more universal validity than verbal concepts. They are still bound by the conceptual habits of the draftsman. A typical sequence of diagrams which precede an architectural problem will include a circulation diagram, a diagram of acoustics, a diagram of the load-bearing structure, a diagram of sun and wind perhaps, a diagram of the social neighborhoods. I maintain that these diagrams are used only because the principles that define them – acoustics, circulation, weather, neighborhood – happen to be part of current architectural usage, not because they bear a well-understood fundamental relation to any particular problem being investigated.
Where a number of issues are being taken into account in a design decision, inevitably the ones which can be most clearly expressed carry the greatest weight, and are best reflected in the form. Other factors, important too but less well expressed, are not so well reflected. Caught in a net of language of our own invention, we overestimate the languages impartiality. Each concept, at the time of it’s invention no more than a concise way of grasping many issues, quickly becomes a precept. We take the step from description to criterion too easily, so that what is at first a useful tool becomes a bigoted preoccupation.
While reading these passages I experienced an interesting
and pleasurable sensation. What I was reading expressed a feeling I have had
experienced unconsciously, but never solidified into a concrete concept. This is
one of Alexander's strengths as a writer, he seems to come at concepts from an
odd and original angle and somehow express things that are obviously true, but
surprisingly obscure. I'm sure I'll introduce you to more of these revelations
in later updates.
The problem Alexander describes is one that is prevalent in game design just as
much as architecture or product design. In the confusion of working in a field
with little formal structure, it is all too easy to grab onto any large floating
object. Alexander points out that those concepts that can be most clearly
expressed are precisely the 'large floating objects' that we notice first. For
example, in creating a design document or project schedule, it's very easy to
start addressing issues that are easy to grasp, without actually examining the
project's real needs.
This idea relates to my constant repeated mantra that designers need to focus
more on the low-level fundamentals of games rather than the higher-level
interactions. It just so happens that the higher-level interactions are
precisely those that 'can be most clearly expressed'. I think this is probably
the reason for this typical mistake made by designers. In a design document I
can very easily use the written word to describe plot, character, mission
structure, weapon capabilities and enemy descriptions, but it is almost
impossible for me to clearly express the dynamics of the character's mid-air
jump control. Similarly in a conversation I can express some concepts more
easily than others, often frustrating myself and others as I struggle to put
into words a description of a sub-second interaction or completely abstract
notion. People who have worked with me will recognise this frustration well.
There are two ways which we can address this issue, as I see it. The first is to
rigorously apply positive discrimination in our work to ensure we always apply
adequate time and energy to precisely those aspects of a design that we are
having trouble describing and expressing. The moment we find ourselves
struggling with language, confusing or boring people in meetings, making odd
abstract drawings or waving our arms in the air, we need to be aware that we
have just come across one of those aspects, make a mental note of it and be
aware that this aspect of the project is likely to become easily obscured by the
less important, but easier to express aspects.
The second method of addressing this issue is to make attempts to apply
terminology to things that do not yet have them. This is hard to do, because it
feels pretentious and academic, nevertheless if there is something we are going
to find ourselves referring to and describing at length in the duration of the
project, it is vital that it has an agreed label for it. This applies not only
to aspects particular to the project, but also concepts and techniques that we
can carry from project to project.
May 18th 2004
From The
Tipping Point
by Malcolm Gladwell
While examining the details of what makes a piece of communication effective,
Gladwell describes a famous piece of scientific analysis.
The pioneer of this kind of analysis – of what is
called cultural microrhythms – is a man named William Condon. In one of his
most famous research projects in the 1960’s he attempted to decode a
four-and-a-half-second segment of film, in which a woman says to a man and a
child, over dinner: “You all should come around every night. We never have had
dinnertime like this in months.” Condon broke the film into individual frames,
each representing about 1/45th of a second. Then he watched – and watched. As
he describes it:
‘To carefully study the organization and sequence of this, the approach must
be naturalistic or ethological. You just sit and look and look for thousands of
hours until the order in the material begins to emerge. It’s like
sculpturing…Continued study reveals further order. When I was looking at this
film over and over again, I had an erroneous view of the universe that
communication takes place between people. Somehow this was the model. You send
the message, somebody sends the message back. The messages go here there and
everywhere. But something was funny about this.’
Condon spent a year and a half on that sort segment of film, until, finally, in
his peripheral vision, he saw what he always sensed was there:
Now I'm a pretty analytical and anal fellow, but that
description of Condon's research is shockingly detailed, even to me. But when
you think about his actions in the context of the rest of science, it doesn't
seem that odd. Much of our understanding of the world comes from the analysis of
elements that are very small in relation to the system being analysed. The
structure of atoms helps explain the more complex phenomena in chemistry, the
behavior of cells biology, and the detail of sub-atomic particles and forces
physics.
So what's wrong with applying the tool of micro-analysis to other fields? It's
turns out that there's nothing wrong with it at all. fields on the borderline of
science have been busy adopting microscopic analysis for many years. An example
would be in the subset of linguistics known as 'Phonetics' or the science of
speech sounds. Central to the study of Phonetics is the element known as a
'Phoneme'. The use of the microscopic phoneme elements really helps Phoneticians
(like my girlfriend) understand how the vast complex stream of speech is
structured, because it subdivides complex sequences of sound that happen too
fast to consciously hear, into discrete units that can be logged and examined.
Condon's microrhythms research is an example of microscopic analysis applied to
social interaction, and I think this type of analysis has a place in the
development and understanding of videogames. The content in a game is thrown at
a player in a manner that is too fast for us to comprehend. Like the dense
clusters of phonemes in speech, the television, speakers and rumble motor output
from videogames sends out vast streams of information which we are unable to
process in detail. Without realising it, as gamers we are bombarded with
thousands of atomic particles of 'gameplay' every minute we sit and play.
What really needs to happen is for someone to do what William Condon did with
human interaction - take a short sequence of gameplay, and painstakingly divide
it up into constituent atoms, applying the Phonetic rule that the atoms should
be the smallest possible size while still being meaningful in the context of the
analysis.
As it turns out someone has done what Condon did with human interaction (without
being aware of his work, I hasted to add). That person is me, and you'll be able
to read about my analysis and method at some point later this year...
April 4th 2004
From Notes
on the Synthesis of Form
by Christopher Alexander
When I read a book, if I find a passage that is some way relevant to my work, I
tend to fold over the page so that the corner of it points to the relevant
section. I've just finished this famous book on design theory by the Cambridge
educated mathematician and architect and I have nineteen folded pages, which is
pretty good for a book that only numbers 130 pages. I could have just folded
over every page, given the amount of stuff which is relevant, but that would
have been a bit silly.
To be honest the best recommendation I can make is that you read the book, but
I'll pick some of the passages the page-corners are pointing to so I can
illustrate the recommendation. Bear in mind this book was written in 1964, two
years after the creation of the first videogame Spacewar by Stephen Russell and
others at MIT, an event that Alexander was doubtless completely unaware of. The
book manages to discuss design in such a brilliantly general way that it can be
applied not only to kettle makers and architects (its intended audience) but
also people like us sitting in front of LCD monitors forty years later. Some of
it is a bit bizarre, it's certainly a little difficult to read, but there are
some real gems for those willing to stick it out. I'll keep the comments to a
minimum, because the quotes really speak for themselves.
The use of logical structures to represent design
problems has an important consequence. It brings with it the loss of innocence.
A logical picture is easier to criticize that a vague picture since the
assumptions it is based on are brought out into the open. Its increased
precision gives us the chance to sharpen our conception of what the design
process involves. But once what we do intuitively can be described and compared
with non-intuitive ways of doing the same things, we cannot go on accepting the
intuitive model innocently. Whether we decide to stand for or against pure
intuition as a method, we must do so for reasons which can be discussed.
I wish to state my belief in this loss of innocence very clearly, because there
are many designers who are apparently not willing to accept the loss. They
insist that design must be a purely intuitive process: that it is hopeless to
try and understand it sensibly because the problems are too deep.
I wish to state my belief in this loss of innocence very clearly, because there
are many designers who are apparently not willing to accept the loss. They
insist that design must be a purely intuitive process: that it is hopeless to
try and understand it sensibly because the problems are too deep.
Now we are at a second watershed. This time the loss of innocence is intellectual rather than mechanical. But again there are people who are trying to pretend that it has not taken place. Enormous resistance to the idea of systematic processes of design is coming from people who recognize correctly the importance of intuition, but then make a fetish out of it which excludes the possibility of asking reasonable questions.
24 Carat solid gold.
The modern designer relies more and more on his position as an "artist", on catchwords, personal idiom, and intuition - for all these relieve him of the burden of decision, and make his cognitive problems manageable. Driven on his own resources, unable to cope with the complicated information he is supposed to organize, he hides his incompetence in a frenzy of artistic individuality. As his capacity to invent clearly conceived, well-fitting forms is exhausted further, the emphasis on intuition and individuality only grows wilder.
Hands up who recognizes people they have worked with or
perhaps notable 'rockstar' designers?
There is much more I will come to at a later date, but Alexander makes some
excellent points on the need for a synthesis of artistic and analytical
thinking, the dangers of using verbal categories to organise problems rather
than categories that are fundamental to the problem itself, and a brilliant
contrast of ancient (unselfconscious) methods of design with modern
(self-conscious) ones. He's evangelical but cautionary on the use of process
over intuition and he illustrates his ideas with mad diagrams (and
linguistics-influenced hierarchies and tree diagrams).
Looking at Alexander's other work, I find he has written a
four
volume
series
called the 'Nature of Order'. that costs about a hundred and fifty dollars in
total. Where's my credit card?
Mar 22nd 2004
From A
Short History of Nearly Everything
by Bill Bryson
In a chapter about the early attempts at measuring the Earth, Bryson describes
the obsessive technique used by mathematician Richard Norwood in his efforts to
determine the length of a degree of arc of the earth's surface.
'Starting with his back against the Tower of London, Norwood spent two devoted years marching 208 miles north to York, repeatedly stretching and measuring a length of chain as he went, all the while making the most meticulous adjustments for the rise and fall of the land and the meanderings of the road. The final step was to measure the angle of the Sun at York at the same time of day and on the same day of the year as he had made his first measurement in London. From this, he reasoned he could determine the length of one degree of the Earth’s meridian and thus calculate the distance around the whole. It was an almost ludicrously ambitious undertaking— a mistake of the slightest fraction of a degree would throw the whole thing out by miles— but in fact, as Norwood proudly declaimed, he was accurate to “within a scantling”— or, more precisely, to within about six hundred yards. In metric terms, his figure worked out at 110.72 kilometers per degree of arc.'
Scientists have been using manufactured measurement devices
and specific measuring techniques since the earliest days of engineering, and
today they use all manner of vastly expensive and hugely impressive devices to
determine all sorts of values for objects that we can't even perceive, never
mind take a guess at the measure of.
What form does measurement take in game development? Well, you can be pretty
sure that the programmers on your team are measuring quite a lot, determining
the amount of time it takes to compute something or the amount of memory used to
store something, and all of this generally logged, cross referenced and
available to everyone who needs it. Your production guys are also probably
making an effort to measure time in man-hours, keep an eye on team size and
track the expenditure of the team in hard numbers. Artists are more than likely
working within established size conventions for characters/vehicles/agents and
(hopefully) keeping a keen eye on the poly-counts and texture measurements of
their work.
So what are the designers measuring? How big is one of your levels in
game-units? How long does it take you character to land after hitting the jump
button? What's the length of a standard combat encounter? Approximately how long
does it take for your heroes to level up in real-time?
The chances are the answer to those questions is 'uhh...dunno'. There's nothing
absolutely terrible about that (I'm sure a bunch of amazing games have been made
with an entire team of otherwise brilliant 'uhh....dunno' designers), but I
think there is a lot that you can learn about your game and other games if you
spend an afternoon with a chinagraph pencil, a stop watch, the tape-measure tool
in your level editor and a video camera. Here's some interesting values to
measure.
1. Time
How long do some key things in your game take to happen? This could be anything
from your character jump, weapon reload, level load time, mission length, game
length, typical time between save-points etc.
2. Distance
What are some of your average distances in your game and are they consistent? Do
they follow a deliberate pattern? Are all your four-player multiplayer maps
about the same size, are the two teams in a CTF map about the same distance from
each others maps, is the choke point directly central? Do you have one vehicle
that is unintentionally longer than the rest? Does one of your enemies have a
longer melee weapon than you expected? Has anyone been keeping tab of gameplay-critical
distances?
3. Density
How often to things happen in your game? How spaced apart are the enemies, the
pickups, the resources etc? Is there a consistency or deliberate design to the
density of elements in the game?
4. Weight
Looking at your difficulty curve, how are you dealing with the spacing of tough
sections? Is the game 'light' at one end and overly 'heavy' at the other with
content and plot, or is it unattractively 'lumpy'? Do any of your
weapons/enemies/abilities feel out of balance with each other? Do players favour
one strategy or technique over others where this is not wanted? Is the game
overall too 'heavy' with difficulty or plot?
5. Mass
Just how much stuff do you have in your game? How long is/will be a
play-through? Is there any extraneous mass in the game systems or content? Do
the game systems feel unnecessarily bloated? Like a sports-car designer, can you
justify every bit of weight on the vehicle? Is there anything that could be
trimmed away to make the product fitter?
6. Velocity
How fast does your game move along, in terms of the rate of unlocking/learning
abilities/weapons/tools? What about the speed of plot development, the
introduction of other elements like characters? How quick do your
characters/vehicles/agents move in relation to the game world? Do your players
control these velocities or are they determined by you as designers? Is this
intentional?
8. Area
Looking at the screen, what are the relationships between this 2D plane and the
things that inhabit your world? How does the character/vehicle/gun/agent move in
relation to screen-space? What proportion of the screen is filled with UI? How
much of the screen is drawing floor and how much sky/ceiling? What is the
relationship between the importance of game elements and the amount of real
estate they use in the screen? All of these measurements are much easier if you
draw on the screen with a chinagraph pencil or a washable marker.
What are you supposed to do with this info? Well you might learn something in
the process of measurement, maybe you haven't been paying attention to the
expanding or shrinking nature of one of these values, maybe there's a value that
seemed to make sense a while ago, but that now seems too big/small, maybe you'd
never even considered the need to measure or pay attention to a particular
value.
You might also use this data to try and tune your game to feel more like other
titles you either admire, or which have set important conventions in your genre
that you wish to follow. For each value you want to investigate, take two or
three games which you feel have nailed that area of design, and measure them
using the same method you used to measure your own title. The chances are you
find some correlation or convention in the figures between games that feel right
in those areas (the two successful games might have the same reload time for the
shotgun, the same waiting time to create a low-level unit, or the same amount of
screen-space used by the vehicle in a sharp turn). Compare that convention to
the value in your game, and try to adjust yours accordingly to bring it in line
with the others. If you are lucky, you might find a solution for that nagging
problem you were finding hard to solve.
Mar 7th 2004
Natural Hierarchies
From Biophilia
by Edward O. Wilson
'Elegance is more a product of the human mind than of external reality. It is best understood as a product of organic evolution. The brain depends on elegance to compensate for its own small size and short lifetime. As the cerebral cortex grew from apish dimensions through hundreds of thousands of years of evolution, it was forced to rely on tricks to enlarge memory and speed computation. The mind therefore specializes on analogy and metaphor, on a sweeping together of chaotic sensory experience into workable categories labeled by words and stacked into hierarchies for quick recovery.'
I've already talked about the power of analogy, so lets turn
to the other organisational principle of the mind, the use of hierarchies. If
the mind is designed by nature to organise complexity into hierarchies, then how
come designers use them so little? Let's have a look at a possible method for
the integration of more formalised use of hierarchical organisation by
designers.
Wikipedia has a great page
describing the numerous meanings and applications of hierarchies including this
section:
‘Many aspects of the world are analyzed, arguably
fruitfully, from a hierarchical perspective. Science provides the following
examples:
In biology, organisms are commonly described as an assembly of parts (organs)
which are themselves assemblies of yet smaller parts, and so on.
In physics, the standard model decomposes bodies down to their smallest particle
components.
In linguistics, words or sentences are often broken down into hierarchies of
parts and wholes.’
This type of hierarchical reasoning is the one that is most
useful to us. Linguists, Physicists, Biologists and Game Designers have
something in common- they all deal with the understanding or creation of complex
phenomena which contain information which can be perceived in layers. The use of
layering and hierarchies directly increases the efficiency their work. For
example, in Biology information presented in this way tells you nothing:
Organic chemicals, social groups, organelles, cells, families, atoms, organs,
organisms, species
But the following hierarchical organisation is one of the cornerstones of the
science
Species
Social Groups
Families
Organisms
Organs
Organelles
Cells
Organic Chemicals
Atoms
In this 'stack' the jumble of terms is transformed into a system whereby the
position of an element gives us information about it's relationship to other
elements. The hierarchy tells us that families are collections of organisms, it
tells us that species are made up of social groups and that cells are
collections of organic chemicals. These relationships have an impact of the work
of biologists - The study of dynamic family relationships (say, conflicts in
sexual selection amongst brothers in chimpanzee families) is informed by
information from the study of the behavior of organisms (The precise mechanisms
of male chimpanzee sexual behavior) , which is in turn informed by the
interrelationships of the organs in the organisms (the genitalia and mental
functions of the brain in the chimp).
In game development, designers are unlikely to apply as stringent an
organisation of elements, and as a result they can miss out on the advantages of
this type of system. Most design documents are unlikely to structure information
about game systems in anything other than a linear jumble. Here's a typical
jumble of game that we might typically see in the course of reading a design
document.
This organisation of this information tells us nothing about the interrelationships and the dependencies of each system and the lack of weighting or order makes it quite difficult for outsiders to understand. But we can improve on this jumble by creating a hierarchy;
This tree diagram tells us three important things that the
jumble could never say.
Firstly it gives us information about elements of the game which are made up of
groupings of several smaller elements. The story is made up of a bundle of
missions, and the missions are bundles of different interrelating game systems.
Understanding elements as being made up of groups of other elements helps create
a clearer picture of the process. It teaches the team that it's a mistake to
start writing the plot until we know what types of missions will work, and it
also explains that mission design needs to wait until we know what our game
systems are going to be.
Secondly this diagram tells us the dependencies between systems that are
important in development. The jumping system can only be implemented properly
after the completion of the running system, there’s no point in polishing the
turret system until we get a sense of how the vehicles carrying the turrets
work.
Finally the hierarchy gives us information based on the application of one other
criteria. I’ve placed what I feel are the most important aspects of the game
design at the bottom of the tree. The lower an item is placed, the earlier it
needs to be implemented, giving more time for polish and iterative work. Using a
tree like this in development, I would encourage the team to tackle elements at
the bottom of the tree first, slowly moving up the hierarchy until the team
moves into content creation (missions and story) in the final stage of
development. In a sense this tree is stating 'don't worry about the stuff at the
top of the hierarchy now, we have fundamentals to concentrate on'.
Hierarchies like these can be a very useful reference point throughout the
development of a game. They allow designers map out the entire game at an early
stage, in a way that is easily communicated to others and can act as a point of
reference throughout the developmental process. They let project managers see at
an instant the most effective scheduling order for gameplay related code and art
assets, as well any potential bottlenecks and important dependencies. They give
coders a familiar and organised vision of gameplay modules that they can
understand in an instant without trawling through wordy design documentation,
and they can also give senior management and publishers an overview of the
project and information about possible budgetary requirements in an instant.
Feb 18th 2004
The Power of Analogy
From Creativity
and Intuition: A Physicist Looks at East and West
by Hideki Yukawa
‘Suppose there is something which a person cannot understand. He happens to notice the similarity of this something to some other thing which he understands quite well. By comparing them he may come to understand the thing which he could not understand up to that moment. If his understanding turns out to be appropriate and nobody else has ever come to such an understanding, he can claim that his thinking was really creative.'
This quote I think brings up two distinct aspects of the
game designers process which are vitally important.
1. Analogy within games.
As a designer working through problems and issues in gameplay design on a daily
basis, it's vital that you have enough knowledge to be able to draw analogies
between the work you are doing on your project, and the work already complete in
other games on the market. Good designers make an effort to find these analogies
and for great designers this it is an unconscious process.
You may find for instance that the precise issue of button assignment for your
object interaction system has been solved more elegantly in an RPG or you might
find that there's a beat 'em up with a great progression structure that solves
your issues of plot development in an FPS. An encyclopedic knowledge and a keen
eye for analogy within games is essential in your day to day work. You need to
be able to see across genres and apply abstract structural analogies to find
solutions to problems. In the same way a scientist is able to see beyond the
surface of a subject to see the hidden patterns and logic beneath, game
designers need to have a mental record of the structural blueprints for all the
games they've played. In what way is Mario 64 like GTA?* What are the
similarities between The Sims and Crystal Castles?** A good analogist sees them
in seconds.
2. Analogies outside of games.
He's the most over-quoted game designer of all time, but Will Wright was making
a great point in his 2001 GDC keynote when he made analogies between game design
and architecture, toy robots, comic strips and Japanese gardens. The rather
typically insular psychological make up of game makers, and the huge obsessive
effort that is required to learn the craft of game development doesn't exactly
foster an ideal breeding ground for familiarity with the wider world, but
Wright's point was that there is a huge amount of rich and varied information in
other subjects that can lead to a better, fresher understanding of games.
A keen analytical mind will often search around subjects to try and find
patterns and structure that can be applied to other subjects, just as Yukawa
describes in the quote. Perhaps there is something to be learnt for game
designers in subjects are diverse as food design, pornography and the elegant
combination of function and form in a pair of jeans? By limiting our analogies
to games, films, literature and comic books we are potentially limiting the
creative possibilities of our craft. I have a friend who works as an architect,
and we often talk together about our experiences in the workplace in terms of
project and team dynamics, the design and implementation process and the
interesting dynamics between predominantly creative and predominantly
engineering people. Each time we speak I am surprised by the huge degree of
correlation between our two experiences. I would even suggest that he has more
common experience with me than many of my contemporaries in game development. In
the future I might be able to solve problems in game design by talking with him
about them. The same might be said for what I can teach him about my
experiences.
Learning about other subjects, talking to people in other complex fields and
observing the world around you can open up new ways of thinking about and
approaching your work. It doesn't always work (I read about ten almost identical
mountaineering books before I realised there was absolutely nothing in common
between mountaineering and game design), but it's always fun finding out.
* The most striking similarity is in the way the games
carefully deal out tasks for the player so that at any point there is more than
one 'mission' available. Players can get very frustrated by the difficulty of
one mission, without it stopping their progression in the game, as there's
always something else to try somewhere else. I'm surprised more people don't rip
off this idea, as it's technically simple and easy to design.
**Both are isometric (duh) and both deal with sensations of panic related to
time management.
Feb 11th 2004
Biophilia and Darwinian Action Adventures
From The Blank Slate: The Modern Denial of Human Nature
by Steven Pinker
In this chapter Pinker is searching for evidence that man’s appreciation of
art is innate, and therefore universal across cultures and grounded in the human
brain's prehistoric evolution.
‘A wry demonstration of the universality of basic visual tastes came from a 1993 stunt by two artists, Vitaly Komar and Alexander Melamid, who used marketing research polls to asses Americans’ taste in art. They asked respondents about their preferences in color, subject matter, composition and style, and found considerable uniformity. People said they liked realistic smoothly painted landscapes in green and blue containing animals, women, children, and heroic figures. To satisfy this consumer demand, Komar and Melamid painted a composite of the responses: a lakeside landscape in a nineteenth-century realist style featuring children, deer, and George Washington. That’s mildly amusing, but no one was prepared for what came next. When the painters replicated the polling in nine other countries, including Ukraine, Turkey, China and Kenya, they found pretty much the same preferences: an idealized landscape, like the ones on calendars, and only minor substitutions from the American standard (hippos instead of deer, for example). What is even more interesting is that these McPaintings exemplify the kind of landscape that had been characterized as optimal for our species by researchers in evolutionary aesthetics’
(More about this experiment can be found at Komar
and Melamid’s website)
When I read this passage in The Blank State something immediately grabbed me.
The description;
'landscapes in green and blue containing animals, women, children, and heroic
figures.'
Immediately sounded to me like a description of the opening levels of an action
adventure or RPG game. Could it be that the kind of settings and narratives in
these games reverberate in human culture for the same reasons the McPainting
images do?
Legend of Zelda: The Ocarina of Time is the highest ranked game of all time at Game
Rankings. It's opening levels contain landscapes of green and blue,
populated by animals, women, children and the heroic figure of the player. Look
at an image of Hyrule Field next to one of Komar and Melamid's Mcpaintings
I could have deliberately picked an image from
Ocarina of Time that was even more similar to the McPainting, but I think this
image of Hyrule field has enough striking similarities for the sake of this
examination. Both are predominantly blue and green. Green and blue were in the
favourite top three colours chosen by each country polled in Komar and Melamid's
experiment. Both images contain relatively flat undulating landscapes, with
distant features (if we were able to move the camera in the Zelda shot to the
right we'd be able to see a nice picturesque mountain). Both have a heroic
figure in the centre foreground, and if the Zelda image had one of the Hyrule
Field monsters in it, we'd have our prerequisite hunt-worthy animal. The early
levels in Ocarina of Time also contain women and children (as do most starting
environments in RPG's).
I'm not one to easily jump to conclusions, but it seems to me that the findings
of Komar and Melamid can be applied to the creation of landscapes in videogames.
If you want to create an idyllic environment to destroy and have the player seek
to save, you could do a whole lot worse than examining the detail of their
findings. If you are worried about making landscapes that appeal to a
cross-section of international games players, then don't because it seems we all
have the same taste in natural beauty. Could it be that the relative lack of
impact made by The Wind Waker and Beyond Good and Evil be related to their much
less welcoming drowned worlds?
This innate human appreciation for a certain, very specific type of landscape is
part of the biologist E O Wilson's 'Biophilia' hypothesis. He argues that the
human mind evolved to appreciate landscapes and environments that gave our
ancestors an advantage in the prehistoric plains of Africa. Archetypal biophilic
scenes typically contain a wide view of the landscape (to keep an eye out for
approaching predators and enemies), a body of water (for drinking and washing),
trees (for fruit collection), animals (to hunt), and distant pathways and
mountains (for the promise of exploration and further riches).
Feb 11th 2004
The Reductionist’s user manual
From: Consilience : The Unity of Knowledge
by Edward O. Wilson
In writing an overview of the scientific method, Wilson begins to describe the
concept of reductionism, the term used for the process of examining systems and
reducing them into smaller, more manageable parts.
'Here is how reductionism works most of the time, as it
might appear in a user's manual.
Let your mind travel around the system. Pose an interesting question about it.
Break the question down and visualize the elements and questions it implies.
Think out alternative conceivable answers. Phrase them so that a reasonable
amount of evidence makes a clear-cut choice possible. If too many conceptual
difficulties are encountered, back off. Search for another question. When you
finally hit a soft spot, search for the model system – say a controlled
emission in particle physics or a fast-breeding organism in genetics – on
which decisive experiments can be most easily conducted. Become thoroughly
familiar – no, better, become obsessed – with the system. Love the details,
the feel of all of them, for their own sake. Design the experiment so that no
matter what the result, the answer to the question will be convincing. Use the
result to press on to new questions, new systems. Depending on how far others
have already gone in this sequence (and always keep in mind, you must give
complete credit), you may enter it at any point along the way.’
Sounds like an interesting description of some aspects of
the mental process of game design. Let's look at it bit by bit.
'Let your mind travel around the system. Pose an interesting question about it.'
Generally we don't have to look very far for an interesting question! The mental
wrestling of the game designer usually begins with a problem or question posed
to them about their system - 'What is the button configuration for this
action?', 'Where on the interface can we put this?', 'Is there any way we can
simplify this?'
'Break the question down and visualize the elements and questions it implies.
Think out alternative conceivable answers.'
This should indeed be the next step in the action of problem solving. What
precisely is the problem, what are the elements involved and what is implied by
the question itself. 'Why is this action in the game?' 'Why do we need this to
be on the interface?', 'Why does it need simplifying?'
'When you finally hit a soft spot, search for the model system – say a
controlled emission in particle physics or a fast-breeding organism in genetics
– on which decisive experiments can be most easily conducted.'
Scientists simulate the natural world in the lab with model systems - fast
moving, easily set up and giving hard, repeatable data. As game designers, once
we have a possible answer to our question we should do exactly as the scientists
do - get it in the game, or in a test bed and see what happens. We can even go
one step closer to the scientist and put the solution into a usability lab to
discover what happens to the system in a more accurate model of the real world
of customers and controllers.
'Become thoroughly familiar – no, better, become obsessed – with the system.
Love the details, the feel of all of them, for their own sake. '
In my opinion, the obsession with the details is what makes a great designer.
The obsession with the system, the feel for it, for it's own sake is what leads
to the polish of a game. It's only by living in the system, understanding and
engineering the details and becoming obsessive with the tiniest of decisions and
interactions that you can create good create products.
'Design the experiment so that no matter what the result, the answer to the
question will be convincing.'
Once you've found your problem, searched for solutions, tested them and become
obsessed with the details of the system obviously you need to make sure your
solution is convincing. This should be done by ensuring that you are not swayed
by your closeness to the design. Be ruthless with yourself, seek the opinions of
people you trust and respect to make sure you have a convincing solution to the
problem.
'Use the result to press on to new questions, new systems.'
Scientists use knowledge gleaned from experiments to serve as a foundation for
further enquiry. Game designers do something similar. Our experiences solving a
specific problem can be applied to similar problems we come across in later
projects or later in the same project. It may even be wise to make a diary of
decisions and thought processes that can be consulted later.
'Depending on how far others have already gone in this sequence (and always keep
in mind, you must give complete credit), you may enter it at any point along the
way.’
This is a final important point. All science is based on references to
information discovered by previous experiments. Scientists are not ashamed of
publicly utilising the knowledge and conventions of their forefathers, in fact
the whole of science would come tumbling down if each experimenter tried to
re-invent the wheel.
Game designers have come some way in this respect, but I feel there is a
definite need for us to be more open and positive to the idea that we need to
search for the conventions and build more formally on the successes of those who
have gone before us. If game design were a pure art, then we'd be right to feel
the need to forge forward on the crest of individual creativity, but game design
isn't an art, it's a craft and a science, and crafts and sciences depend on the
conventions, the discoveries, the tools and the knowledge of previous work in
the field.