A reductionist model of humankind

Anyone who read this is statistically likely to be annoyed by it. It is also not founded in any real research that I know about, just a bunch of conclusions drawn by myself through looking at things and probably cherry picking my sources.

Humans are agents in a big system based on other humans and the rest of the world they live in. The system is too large for us individuals to see how the system works even at a short distance away from where we stand. This is what makes us individual, local properties.

What makes us different on an individual level is what we know and how we think and this might appear like great differences on the surface. But in fact it stands for a tiny portion of what a person is in comparison to the position within the whole system. The definition of the individual – you come from your most immediate surroundings through life until now and your expectations on the future based on extrapolating the system in a predictable direction.

As we grow up we learn to attach blame and praise for how we operate on ourselves but this is primarily a bunch of fake social magic which our system has invented as method for success, as success for the system, not for you, through the last few thousand years. The biomechanical machinery in your brain is built to trigger on stimuli which it learns to associate with rewards or stress based on randomly testing the world to see how it operates. We spend the vast majority of this random testing on figuring out how people within the system work and what things we can do to make them exhibit useful behavioral patterns. It was quite a different result a long time ago when we roughly belonged to the same system as some kind of monkey.

Anyhow, condensed this means that we really all are just the same. We think we are very special because our own consciousness happens to sit without ourselves but we can be relatively certain that we would have been easily replaced by any other consciousness given the same circumstances as ourselves.

Given this potentially evil, if you like that type of language, argument we can probably figure out how the system operates even at a great distance. The people that are so far away that you have no chance of knowing anything about them will have done exactly the same thing as you did until right now. They have been trying to figure out how the system operates from experimenting randomly with the available local properties. Based on these local properties they have developed a personality which will be roughly the same as your own, regardless of where they are in the system.

It is very unlikely that they will be reading this text, har har, which means that you will possess a different set of data to use for interpreting the world. Which also mean they might even speak another language and associate other things as stressful or rewarding, that’s their local experience and it will have the power to shape their model of the world.

Now the responsibility of art becomes to manipulate the agents in the system towards performing actions which increase the experienced value of the whole system. Increase the full volume of the value, the average, the mean average and increase the minimum value per system component, the risk of failure and so on. The only reasonable compromise is the reduction of the individual maximum, which on a system level is waste anyway.

The usefulness of bugs

This is an interesting topic we had a little look at recently. In my world a bug is a subgroup of something that with a wider definition would be called a defect. Googling for a definition of the term defect gives a useful result quickly which says this:

- An imperfection that causes inadequacy or failure.

This a good place to start.

In my experience the vast majority of defects associated with professional game development or entertainment in general belong to the category of inadequacy of the user experience. I would call it ‘inadequate emotional attachment’. It happens that the experience of the player is significantly damaged by the existence of a good old fashioned bug. A program failure or crash will generally not be helpful towards the emotional state of the user but these problems are thankfully not all that common anymore and various measures are in place to remove them from software products.

A much more common problem is the lack of something intangible which makes playing the game feel just right. There are tricks or theories you can use to make better games but they are not generally accepted yet so they are hard to describe without getting into very lengthy descriptions of things. So instead of getting stuck in a theoretical black hole I can use a metaphor from the art of making music.

Most of the music that reach you will have been analyzed through a rigorous process of defect detection. During its creation the music you hear will have gone through lots of iterations, thousands to millions of tweaks and changes have been made to create the result that is emotionally attaching enough to reach your sensory system. These tweaks have had all kinds of reasons for being done. Different composers or music creating organizations have different methods towards doing things but in general we can take a reductionist look at it.

Most of the work done when creating music is inadequate on the idea level. The idea behind the work is not worth the trouble of refinement. The musician detects this quickly and iterates the idea. Eventually the idea is iterated to a point where it reaches something I will call experiential harmony. This is based on all kinds of details, such as the sounds of the instruments, the arrangement, the rhythm, melody and so on. The result may not yet be anything complete but it has reached a “proof of concept” level. To reach this point the musician has gone through defect elimination of several types. Different types of defects are eliminated based on different techniques.

Finding a good sound is the process of selecting the right instruments for the various parts of the arrangement and placing them in the sound image where they fit. This is something which typically starts with a great lot of simple defects and ends with a system of sounds which interact experientially productive.

Finding the notes played by each instrument is another type of defect prone creative process. Some parts come naturally and some are iterated heavily. It is easy to get to a state where the music is broken due to bad notes. These can be detected and changed from bad to good relatively easily.

The difference between a defect note and a defect sound is of some relevance to the topic of this article. The classical, and in modern times rare, bug is defined as a defect note. It is an explicit error in the construction which can be removed or changed to improve the emotional attachment of the product.

The more common defect in a user experience is a complex problem which arises from the interactions in the whole system. We hear player say various things to state the existence of these defects.

The game is too hard, the game is too easy, boring, slow, stressful, not interesting and so on. You might think that “he wrote boring and not interesting as different things, how stupid.” But from a game designers perspective these are different things, boring is about patterns and the interesting is about context. When you use a players feedback to iterate towards value you are well served to realize that most of the feedback you get will be describing symptoms of complex problems.

A complex problem is in this context a defect which arises from the interactions in the system. Classical examples are unrestrained positive feedback loops. These are so common that we even got a specific label and fix for them which is “restrain feedback loop” by changing how the system interact or process data in one or more points. When the player says the game is too slow it means that the player is waiting for relevant information for too long, this is matter of pacing and tuning which has different complex structure in different parts of a game application.

What makes this fundamentally interesting is that the process of creating emotional attachment is not reactive to user feedback. User feedback is useful for providing the process with relevant information at some points, especially useful for detecting complex problems in the system. The solutions to problems need to come from the system creators.

If the project which is creating this emotional attachment classify defects which are complex problems as bugs you are likely to have a much worse problem than bugs unless you already have reached primary business objectives for the whole product which means it will be ok to have a total failure anyway since everyone is happy with the already accomplished result.

From a musicians perspective it is intolerable to accept bugs. The existence of bugs in music means that you prefer making more of the bad music than making valuable music. You can use this strategy during the iterative process and for example accept bugs in the melody while refining the sound but you will never consider a piece of music to be “done” until it is free from defects and thereby flawless. This means that bugs which are reported from end users should return to the product development as the highest priority backlog, if they return as a randomly prioritized task list you are most likely far behind schedule towards reaching business goals.

Practically we can probably look at several strategies which deal with these problems. I myself believe the development team needs the mandate to stop defects from reaching the end user in the first place as they are the least likely to be having other goals than making a great product. If you reach a state where it is more important to release a defect product than it is to create a flawless product you are probably in trouble already.

Target audience

Who likes a particular piece of music?

This question has a lot of answers. I would not be able to answer it in detail. All I can hope to do is to understand the piece of music and how it relates to world according to some quantifiable properties.

• What kinds of music it is similar to
  
• If it is easy or challenging to listen to
  
• If it is easy of hard to perform
  
• Maybe also what it is about

These can be broken down in little pieces. Like which things are similar to what, detailed infuences and so on. The relationship to the audience is influenced by these details. You rarely really know in advance which things have what influence. To get a satisfied audience as a musician you focus on making the music as good as possible. There are some genre dependant properties which define more or less strict rules for the audience. I usually like the extreme of improvisational jazz, as it is one of those hardcore music genres with a comareably small and devout following. It is also defined by quite rare properties with strong influence over the artform.

There are those moments when peple convert to become listeners to this type of jazz, they might make the leap based on a lot of various motivations. Not very relevant really...

When it comes to games I am quite confident that the same general principles apply that exist for music. The difference for games is from my perspective that most of the games we know are like improvisational jazz. Every game has relatively strict and strong influences which fence the player off from the experience.

A game will require the player to make that leap to become a player. The interesting question is why the player will make the leap. And how the game can make the leap as painless as possible.

When you want to push normal people to become listeners to improvisational jazz you can use a few tricks. Like making the musicians play things which are easier to listen to and follow than what they commonly do.

Maintaining multiple options

This is a Lean productivity trick. Mary Poppendieck describes it well in this awesome movie; http://video.google.com/videoplay?docid=-5105910452864283694 - you have to watch it if you care about making good things.

When looking at game development this is done on a regular basis in some of the pipelines, most obvious when drawing art images through how the layer system operates in photoshop but also in how programmers write code with branches and classes, how storywriters use word processing software to keep dialogue and story flexible and how musicians create the music score with their software such as ProTools maintaining all the versions of the songs on the HD while edits are happening to a subset of files.

Now the question becomes how to apply this to the combined user experience which results from bringing all these pieces together. As the network theorists say something along the lines of: the whole system is the combination of the nodes and the interaction between the nodes. The game which becomes the user experience is the interaction between the nodes, the code is one node, the music is another node, the image art is a node, the interface is the tool which the user has available to navigate the network which in a good game becomes a modular agent in the network.

The game itself is a system which measure the skills of the user, these skills are deployed in context by the user to navigate the whole network. Any piece of the network which is outside the users path is roughly what lean would call "waste".

For the whole game system to maintain multiple options we'll need to expose the interaction between the nodes as readily changeable and generally transparent, human readable, data with some level of backwards compatibility. This is an utopian model, but it is not fully a pipe dream. In a not very far future we will know much more of the principles of game design. From my perspective these principles started with Chris Crawford and his model of interactivity, they have moved forward a lot with things like Raph Kosters theory of fun for game design and Daniel Cook's model of skill chains. There is a lot more stuff in this mix worth a mention, but maybe we'll go there another time.

With a better understanding of the principles for game design we will be able to identify differrent types of interactivity and thereby define the interactions between the nodes in the system with an explicit format. Music has several kinds of explicit data formats to present the patterns of sound on on various levels of abstractions, waveforms, instruments, overtones, harmonies, rythms, notes, tabulature and so on. Several of these have alternative modes, you can define a "tone" through various methods either as an "instrument (violin) playing a note (A) for an proportion of a bar timeunit" or a "fundamental frequency (440Hz) with 9 overtones (i think thats the violin if I remember it right) playing for a time in seconds". You can keep on going and define the waverofm as a function based on trigonometry if you prefer but I'll skip that example. I think the point made it through without. Note that the actual psychoacoustic representation of the violin is a lot more complex than these primitive models but on the theory side of things you go there if you want to, which is about never unless you are a bit "special". For the synthesizer manufacturer its all the way down through the trigonometry that wins the day with modulation, also trigonometry, controllers and stuff.

Game design theory is today at the stage where everyone communicate with a randomly selected spray from the whole arsenal of terminology, or rather, different people use different terminology to say the same thing and they generally don't know that there are other terminologies which define the same interactions within the system. They can barely even communicate with each other without first synchronizing the language which is a hard problem. Some very experienced designers will have a gut feeling for a lot of the principles, I myself find that I have a better grasp of some models when analysing a game play experience and some others when writing a game concept. I must admit that I also don't know the whole system, I don't think anyone does. There is no "first dan black belt" of game design and not even Sid Meyer, Will Wright, Chris Crawford or anyone else would have it if there was one.

However we can start in the pragmatic side of the equation and create a data model which best expose the whole system as nodes of data and interaction which is the transportation of other data through the system at the request of the user through the interface agent.

Now you could claim that this is already done with the programming langugage itself, and to some degree that is true. However the game systems which people play today are requiring domain experts which are not always competent programmers. (Programmers don't tend to spend most of their time doing user research as example, thats sub-otpimal to most production efforts.) Also maintaining multiple options through having several version of the whole code base is unlikely to be much help.

So what kind of data can define the interaction between nodes in the system?

If anyone wants to take a stab at it go for it, or bring up examples from various game engines. ^^ (Or I will later on and then it gets texty as usual.)

Iterating towards value

It is commonly accepted that the user value in a game and most things has a statistical probability to increase with the number of iterations it has gone through. This goes for things such as fried meatballs, your DNA, a guitar solo, a sound and so on.

This takes on different forms in different areas of life, since I am interested in writing about game development I will focus this story on some of the forms involved with making games. The process relates to cooking and music production, but since this is a big topic I’ll leave most such fun references out.

The relationship between iterations and value is often plotted as a neat little graph.

Note the S-curve type of deal going on. That says something about the existence of “no value” iterations at the beginning of the process. You got to get to some point before you have anything, then eventually it is finished and stops getting any better. To get anywhere interesting with this topic we have to take a look at the definitions of the graph. What is the value you get as a function of # iterations?

What one iteration is

One iteration is the work done from the point where there is an idea about doing something to the point where what was done has resulted in useful feedback. This is a fractal concept and it has several types of zoom levels and dimensions. The one zoom level most commonly associated with game development is on the product level. One iteration on that level have its value measured by feedback originating from the potentially shippable product through various test procedures such as user testing, technical testing and getting accepted by the product owner. These are examples of something I will call explicit feedback.

Explicit feedback gives a quantifiable measure of value which is obviously visible to the involved parties. These summarize as “done” when everything pass defined criteria often called a “definition of done”. Generally if feedback from the work shows an insufficient or negative value increase the iteration has failed.

Another zoom level for one iteration with an explicit feedback loop is the creation of code data, commonly called programming. If the code is broken it will fail to compile and all kinds of feedback is generally built into the code pipeline to prevent broken code from entering the system. The programmer makes a new iteration of the code to improve the value of the code without first shipping the code to the end user to test if it has any value. These iterations are fast, some broken code can be iterated on in a matter of seconds. This time unit defined by the time it takes to iterate is sometimes called “cycle time”, which I will also use a fractal concept. I will call this comparably low zoom level of iterating for “creative process”, the programmer creatively create the code.

Another type of creative process is the creation of images. The artist uses an image creation tool such as photoshop to create image art. This is also a fast process. The artist will generate art data on a second to second basis, undo things that go wrong and create new pixels with a stylus without thinking of it as iteration. The artist also maintains and switches between multiple options throughout the production of one image. The feedback which closes one iteration in the creation of a pixel of art data is internalized by the artist. I will call this implicit feedback.

Implicit feedback is not obviously visible to anyone. It is to the observer a subjective measurement and often leads to all kinds of emotional distress for the involved parties when it comes time to analyze the value of the output of the creative process based on implicit feedback structures. To the professional artist it is not fully subjective as some principles of the arts guide the creative process but in large it’s a relative mess compared to the efficient explicit structure of code creation. It also happens that different artists use different principles for this process which often cause communication problems, but mostly everyone has learned to live with this process quite productively.

Now that we have a model to differentiate iterations between ones based on explicit and implicit feedback it becomes much easier to understand what things you can put in through the value creation process.

A guitar solo runs its first several thousand iterations as an implicit process before it reaches the point where it gets explicit feedback in the form of praise or complaints from band members, audience or other people involved with the music production. Improvisational jazz is an example of the solo going directly from implicit practice to the end user without explicit iteration, even driven by the goal to change between each gig! The details of the solo are guided by a lot of musical theory internalized by the jazz guitarist.

The development team for a product increase its value based on explicit feedback from the producer or the team itself, as well as the implicit feedback within each team member and their feelings towards doing good or bad work. Scrum is an example of a process which forces some of this feedback to be explicit. This is good in the sense of providing direction but as all game designers or players should know we humans have the property of “gaming” systems towards maximum reward for minimum effort, hence it is likely that if not guarded well the process is used by the team to optimize towards getting the positive explicit feedback at the lowest cost possible. This is in game design terms sometimes called “bottom feeding” and needs to be guarded against by the rules of the game which define what to do to get which feedback. Another game design term which becomes relevant in explicit systems is the “mastery problem” which means that the better players will dominate the feedback structures of the game and win at a cost to the other players. Neither is good for the value of the product and digging into these details may be a topic for the future.

When explicit and implicit feedback systems fail to agree on if an iteration is successful or not there is often all kinds of problems surfacing. If these problems happen often the whole product is most likely going to fail on the market.

Implicit equals difficult

Making enjoyable and fun interactive games is primarily based on implicit iteration. Some fundamental infrastructure such as code and having a development team can be considered explicit but getting the experience to a point where the market value motivates the investment goes through tons and tons of implicit iteration.

Many of the implicit structures in a game are based on established art disciplines such as creating images, animations, music and storytelling. The product trusts itself to these domain experts effectively collaborating as a team. There are tools to rapidly iterate these components in isolation and it is part of the expertise of the experts to be masters of these tools.

The real problems surface when the implicit feedback relates to the sum of the parts of the system in the form of information design and game design. To make the game play experience have any value these also needs much iteration. Yet again there are skills and principles in the design expertise that help this process but they all fall under the implicit feedback umbrella and thereby cause communication problems.

If you look at the game industry at large you will find that there are a lot more games in certain categories, this makes the game industry appear relatively narrow. Many games resemble each other and are based on each other. The games that have been successful become so by playing on their strengths. The things that can be iterated relatively fast are strengths while things that iterate slow are weaknesses. Most are built on development techniques which upfront know where the pipeline is fast and where it is slow. This gets successful when each domain expert in the area of design owns the iterative loop for the implicit creative process. The things that have a cycle time measured in minutes or seconds reach the point of noticeable value, while anything which has a slower cycle time measured in hours or days should be considered as experience-wise valueless infrastructure. Those slower components of the experience will not be what make the user reliably have a gratifying experience. You might get lucky, but to get from lucky to certain the fundamental trick is to get the cycle time down to the range of seconds.

Techniques for effective iteration

Now that we have gone through a somewhat too big background of the problem we can take a look at a solution.

Based on concept, product vision or creative direction take a deep look at the idea which is going to result in user value then list the main components of the user experience.

• Take a through, cross-functional, look at each of these pieces. If there are more than a few dozen and in the hundred or so range you probably mistook the user experience for something too granular or technical. Or your team might not understand what the experience is supposed to be which might be a sign for future trouble.
  
  
• With the list in hand maintain the cross-functional approach and categorize the pieces in cycle time as estimates in seconds, minutes, hours, days and weeks. Include dependencies in these cycle times if needed, for example if it is relevant that some animations blend properly in the feedback system consider the pipeline for animation blending in the cycle time for animation feedback.
  

Now make three categories

1. Usability Infrastructure, everything with a cycle time of days and weeks in here
   
2. Shoehorn User experience, the things with a cycle time measured in hours
   
3. Reliable User Experience, seconds and minutes
   

With these three categories freshly composed remove everything except the third, fastest, category and see how well the things in this fast list match up against the idea about the product. It probably won’t match up very well. Don’t panic! This is quite common when making interactive entertainment and it is to your advantage. Most of your competitors will expose their weaknesses if you can figure out where their user experience is bogged down in the infrastructure category. You can also save your project by avoiding dependencies on the user experience which resides in this category. You will have some, that’s unavoidable but at this early point you have the ability to shed complexity to move the right things to the category of reliable user experience.

A general trick for getting the interactive parts of the system to the level of reliable user experience is to make all feedback elements dynamically changeable. For example if you have a storyline with a movie in it you will have the experience defined by the movie as a feedback element for an event triggered by the user. It is now important that the person who knows how to make movies can change the movie inside the experience with fast cycle time. If the cycle time is slow for movies don’t make them as parts of the system. Put the movie in the beginning instead as an intro which has no dependencies of interactive nature.

This can also be done for the verbs of the interaction circuit. You can’t expect to add a new verb with a fast cycle time so the verbs themselves go in the category of infrastructure. You can however adjust the subject the verb interact with, such as the width of a hole you need to jump over, how fast the opponent is running in a shooter. The verb can be changeable too such as the target area of the weapon or the height of the jump, expose suitable adjustable variables in an easy to change and preview data model. Beware tho, don’t mess up all the level design by changing the jump variables after production of the levels has started!

Use a recursive strategy to tune the experience. Make sure that the user is protected by efficiently tweakable variables to lean against all the way along the user journey. This will allow you headroom to react to feedback on the user experience at any point during the production. The larger percentage of what the user experience you get in a fast iterative loop the better. It’s better for the user to play a tiny game with a flawless emotionally satisfying user experience than a bigger game with a few uncomfortable moments. Note here that proper pacing is not to equal “uncomfortable” because the player will need both peaks and throughs on the emotional side to enjoy playing.

Exceptions

There are some exceptions when we look at the established game industry. Mostly they are rooted in incredibly huge budgets. Someone is spending so much money on the business that you can move the infrastructure category one notch up to the week level and just pour calendar time and man hours on making slow iterations instead. This also tends to interact with established development pipelines such as game engines for specific types of interactions. This approach is however on its last legs or already dead but it made some good stuff the last decade.

Another type of exception is the undiscovered market. You usually don’t predict these, but it happens that a new market is discovered by a product developed with a random approach towards creating value. Usually the resulting product is soon dethroned or bought by a big budget competitor. Looking at the music industry we see these random productions rather often but for each successful one we see thousands and maybe millions of failures. Reliable and consistently successful musicians iterate more or less consciously towards a safe result including all relevant disciplines in the process.

A lot of products also have no ambitions of providing a valuable experience. Instead they provide something else of value which may be relevant information or a service with pragmatic and explicit solutions to specific user needs, however games are only partially explicit and rarely pragmatic experiences.

phew, thats a long post...