Corollary definition for design

If design is a process which develops the value of an idea. Then a corollary to this might be:

- Design is aimed at reducing waste.

Maybe this lean perspective is the source of the first definition but I would not know.

A Flawless Piece

Now I spent the weekend finishing and testing Tricklock.

This means that I will from now on accept any remaining defects within the construction of Tricklock as a part of his "personality" rather than try to fix it. I think this is a relevant insight to all kinds of production. Included within the piece of Tricklock came various prototype implementations of the other band members.

I could claim that the other band members are implemented to a functional cheap implementation. From here I have the option to use the "maintain multiple options" and actually make a production based on the prototypes which would sound reasonably decent. I have on the other hand identified the need to formalize the data set behind the other band members into modules which I can load easily to reproduce them.

To create these modules I will need to invest much time in infrastructure, and since I always aim to balance all effort against user value I will also add some time to refining the content of the modules for an even better result.

I wonder if I can uplaod sound files to this blog for the documentation of this process...

Practicing Agile on Art

To practice the kinds of principle which are described by Lean I started with creating a piece of music. I like making music, it is meditative and it uses some of my usually dormant skills which when I fire them back up gives me a serious dose of pleasurable feedback chemicals in my brain. Anyhow, creating music is an example of a very well defined production system and I like making abstract generalizations from things I know well to things I know less well. On the whole I can claim to be quite an efficient music production team all on my own, something I have a hard time claiming for the art of making games. Games require so much wider skill sets to go from idea to fully implemented in the cases that I am interested in so I can’t make a micro experiment to test the concepts of Lean development on my own with the game medium, and I can’t program well enough to make anything useful.

One of the great advantages with creating music is that I have access to a relatively decent implicit iterative method which covers the full production pipeline. I can tell if the instruments are tuned poorly, if the arrangement is busted and such technicalities. I can even tell if playing the instrument in the recording is giving a result which pleases the musician. This means that I pretty much know when I am cheating the creative process by accepting less than flawless components in the production. I can also cheat and get some explicit feedback from various sources such as sending snippets to friends over the internet or check details with a spectrum analyzer etc.

I also know that the end result is the interaction between the components and that I will not really be able to know in advance if a production will be good or not. I can generally feel it growing if I keep working on something which keeps me motivated. Almost everything which I ever finish is based on a mashup of old prototype songs. This mashup process is something similar to stage gate portfolio management which defines little pieces but without the information of how the pieces should interact to deliver an impression. This is also poorly managed by me with various references in my brain and plenty of broken snippets of recordings which I usually forget about. To bring this mess of components to life as something which I can claim to be something I finished I have to work through what my limited experience would label as a large process. I don’t like using samples, when I try I tend to get bogged down in editing the samples so its more efficient for me to just go straight at making the whole arrangements and tweaking the hell out the individual instruments.

The way I make music is fundamentally iterative. The goal is a mix of creation and refinery towards reaching greatness. Greatness is a state of perfect fit, “the goose bump factor”, an implementation which creates unique emotional response of some kind. This is hard work, I am rarely motivated enough to not give up and leave the effort as a part of the busted stage gate portfolio. It happens sometimes that I keep on going and the finished results are what I can use to run production technique experiment.

Writing this I sense that I will not be able to combine the whole argument in one big post. I will have to dig at details another time if I get there but I got some direct references at this point.

1 – Make it Flawless; applies to music production. This is a well known oldskool audio engineering principle which says that: “Make quality recordings of sounds; you can not make bad sounds good by tweaking them.” You can also not effectively engineer up a poor performance or a bad melody through creative editing, you can make it better yes, but you will be much less efficient than making the recording good in the first place. Compromising these early stages of the music production is like technical debt in software development, you can use them to move fast to a certain point but you will never reach greatness unless you go back at a later point and fix it. Such late fixes are often big risks as the new recording might interfere with the whole arrangement. This often leads to cascading failure of the whole production and all you get is yet another ambitious component of the stage gate portfolio.

2 – One piece Flow; this very much applies to music production. If you fail to follow it you will fail the Make it Flawless principle and learn to accept a poor result. The trick to one piece flow is to know your production method which is much easier in the world of music than when making games, especially for me since the process of making music in my case happily operates at a loss as long as I have fun with it. In the world of music production this goes through layers of development. You will benefit greatly from having the rough shape of the arrangement in place before starting to mix, you don’t start with the mix because then you will break the idea of one piece flow and en up with all pieces. The real question here is what the “one piece” is. In music the “one piece” is a multi dimensional argument. It can be used for an instrument, section, harmony, melody, mix, arrangement, lyrics and so on. The matter is the ability to identify the pieces and to learn how to be satisfied with one particular piece. This identification has its roots as a craftsmanship based on skills, theory and vision.

3 – Maintain multiple options; this is integrated with tools pipeline. In an ideal world I would call this “the mix” which is what you do last before sending the work to the ears of an audience. I am not sure if this is because I want the reference to fit or if it fits. The idea also carries through the arrangement by the theoretical structure of music theory. There is this huge set of lore which a master musician can use to apply multiple options to any given situation. I am not a master in this sense but I had an awesome Jazz teacher who showed me a few things about which doors can be opened to toss things around in a technically “legal” manner. It has been half a life time in my world since I had those lessons but their fundamental concept remains with me still. I’ll tell you the secret right here: All that theory is just a shortcut for connecting your ears to be the judge of what is good. It is a great shortcut and it is the key to collaboration and communication about the creative process of the medium. But it is nothing which resembles strict laws and the rules are there to be broken by the creator at will.

4 – Avoid Waste. This is a tricky beast, also very relevant to music. Defining what waste is in a music production is not that straight forward. Recording random things and putting them together is generally waste, sometimes it is a process which rapidly can fill up the stage gate with concepts. The real answer to the question of what waste is depends on the vision and goals of the production. If the goal is to increase the stage gate then an ambitious mix is waste, if the goal is to deliver on a vision then aimless noodling and random recording is waste. To know how to spot waste you need to be a well practiced craftsman of music creation.

My biggest problem for my music hobby is lack of vision. I like to blame this on the extremely efficient development method which gives me an extremely agile context. The studio software allows me to change anything at any time so I never feel like I have to spend any effort at creating a vision for the work. This makes it easy to get a false sense of progress towards greatness and the lack of vision rears its ugly head as technical debt within the whole arrangement which sends everything to the stage gate relatively often.

All of this stuff is generally applicable to most things in life. The biggest problem with implementing process optimizations toward value production is a lack of common grounds for communicating these kinds of ideas. Just as it is hard to make a band play good music without a fundamental common ground in music theory it becomes hard for a game developer to make good games without a common ground in development methodology and game design theory. Lack of common ground will require blind faith which is a rare human trait and it rarely lead to good results.

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.

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.)