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.