Feb 11th 2004
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.
Feb 11th 2004
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 18th 2004
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.
Mar 7th 2004
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
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.
Mar 22nd 2004
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.
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.
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?
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?
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?
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?
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?
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.