Efficiency by Forced Iteration

This is a technique I apply on almost everything I do which has any expressive ambition. I'll call it Forced Iteration, I have not previously though of it as anything which has a name. After power-reading the stuff that Eric Reis and his crew is doing I realize it lies dangerously close to the idea of Continuous Deployment.

I have been messing around with the creation of usually unambitious artistic artifacts such as pieces of music, texts or even little experimental games. What I have realized over about twenty years of doing this is that the most effective way to improve the result is to publish it and make it available to some kind of living and breathing real audience. Even if it is only one other person in the audience this is vastly better than avoiding the publishing step.

What I do is that I first fiddle with the piece, this blog post is an example of such a piece. Then after I start losing tempo on the production of it I'll publish it. This causes me to feel a slight level of panic that I just published something which is total rubbish. The understanding that the rubbish is already out there and potentially being consumed by an end user triggers a reflex which makes me fire up a burst of energy which I spend by seeking out the worst flaws and I fix them just a few minutes after the publishing. Whew... the feeling of fixing the broken bits before anyone really saw them is actually quite good!

Now after the worst bits are fixed I will have a bit of breathing room which I use to judge the resulting piece of work more closely. This tends to spit out a new series of micro-iterations which hammer away at the lesser errors that I can see.

I am not a good writer, and I know that my English skills are quite lacking compared to what you'll see from a more engaging writer. This knowledge sets my level of ambition to be relatively low when it comes to making this blog great. Maybe someone who is smack dab in my target audience finds it comprehensible enough. Well, anyway...

The act of forcefully publishing the unfinished piece of work effectively speeds up the process of going from the idea of doing something until it meets the standards set by my level of ambition. I believe that I find this behaviour to be natural from having somewhat of a background as a live performing musician, even if it was a long time ago now. The live performing musician is in a constant state of streaming art directly to the audience. The reaction from the audience is the fuel which drives the engine of creation. And the idea that my audience will see the first iteration fuels the engine that creates the second, and so on it goes.

By using Forced Iteration this way the volume of fuel is maximized, at least for my type of engine. I know there are great artists who achieve greatness by going the other way around, but I have no idea of how they really do it, or how fast they really work.

The Symptom of Repeated Success

This is a post about something I have heard about happening from some distance. Organizations working with scrum or similar methodologies reach the conclusion that the methodology does not fit them. This is a hypothesis about why that tends to happen and a bit of reasoning around the problem.

As developers begin working with scrum or other agile methodologies it often appears as if they manage to achieve a productivity boost and gain features at a faster rate than they were used to. The teams really like this and find it to be a good practice. There is however one problem surfacing relatively often which present itself as a positive symptom of continuous and rapid success. However, behind this seemingly great facade hides a problem that seems eeringly common. The rapid increase in productivity and success is often a symptom of well... failure.

Now I'll have to explain, yay!

The problem is that the team is not achieving manageable failures. Every backlog item which comes from the product owner is successfully implemented and done within a sprint or two of work. Often each sprint contain several backlog items and the product takes on several new features in rapid succession. Now there is one of two possible states that you are in, one of these is more probable to be true and the other is likely closer to resembling a joyous pipe dream:

1: Awesome!!

• The production is going on rails and creating fully tested and reliable user value with every backlog item which is started. The Product Owner is a domain expert in the field, has incredible insights in design and production techniques and is well connected with the market.

2: Hmm, what did the user feedback say again? Does that really match our Definition of Done? Or what does it really say?

• The testing of user value does not inform the team about how much value they have been producing and they are developing features blindly.

If your team is experiencing this symptom of the repeated success you have a statistically troublesome scenario. The problem is that for the "Awesome!!" result to really occur you need to have one of the best Product Owners in the world. These guys are quite rare. You might also be part of an organization which is building an existing product within an existing market, this is the metaphorical equivalent of a Nuclear Power plant. The problem is known and the solution is known.

The user Values you develop are not known beforehand

It is quite likely that you are developing a product which aims for a niche market or a low-cost alternative within an existing market. In these cases your Product Owner will need to use the development team to run experiments against the market to find out how to handle the unknown factors. Be especially aware if you are making a new product in a new market, that means your hypothesis will be wrong almost all the time.

As any scientist will know you will not always validate all hypothesis as being true from their first experiments. This is where the failure of agile and scrum screams its loudest, at least from my perspective as Game Designer. I know that even the best of designers will only have a theoretical foundation which pre-validates a portion of the designs. A generous estimate says that you will be roughly correct maybe 70% of the time, but each feature contain several sub-hypothesis which in turn has about the same probability of success. This means that more than 20% of your Backlog will be dead wrong. And now I am being very nice about that number...

Features which are not valid user value is waste which is expensive to clean up

If you are part of an agile team which fails to invalidate the hypothesis within the Backlog be aware that you are most likely producing a huge design debt within the product you are working on. Not only are you failing to find the defects before they impact the user experience, but you are also failing to understand where the real user value actually reside and are thereby effectively torpedoing future design efforts aimed at cleaning up the debt.

Personally I would advice that the only reliable way to step out of this trap if you are sitting in it is to treat design debt just as you treat technical debt. Design Debt most commonly rears its ugly head as increased complexity within the user experience. Once there are many features of surmised value within the product which has been deployed it becomes quite difficult to separate the ones which have user value from the ones which don't. This is a type of debt which grows fast with compounding interests because the probability that any future backlog actually does anything good to the user value drops with the complexity of the already faulty design. This is well supported by how system complexity also increases exponentially with the number of components as neatly described by Metcalfe's Law.

The way out of Debt is slow and painful

You will need to slow down and begin to refactor the user value through effective measurement within the product. The more common attempt is to increase the volume of features which has the result of increasing the volume of produced waste.

I am not too sure about development teams which have had the ability to climb out of this type of mess. The most common exit strategy I hear people deploy is to package the failed product as "valuable experience" then starting over with a new vision, mostly to achieve the same experience next time. There are also other tricks of business magic which some have been able to perform where they can sell the work done to wealthy customers.

Conclusion

Beware of agile teams that do not report failures from the interpretation of relevant feedback from valid tests. These projects are quite likely to be creating delayed waste which have impact enough to be fatal to the project. When working on a particular backlog item ask yourself: "How would the statement that this feature is waste be defeated by a valid proof to the contrary?"

If the best answer you think you will get is a whole lot of opinions then you have a good reason to help improve the development process.

The complete cat strategy guide for game production

This is a story about a group of agile cats with skills and a passion for games who build a game together. They met somewhere and founded:

One Lean and Mean cat machine which will be doing something cool and have an awesomely good time together while doing it. The cat team introduces themselves and writes witty descriptions about what they do on their Google Wave.

Fixer Cat: "I am like doing all that stuff that no one else does, making sure that nothing stops the other cats from doing awesome stuff. I am obsessive about development process, cycle time, kaizen, integrity and communication. Other IT projects might call me a combination of QA, Operations and maybe Producer."

Artist Cat: "Art is like a universe of symbolic language which has emotional resonance and communicate directly into the users brain through traditional data generation. I paint, I make sounds, I write texts, I make landscapes, labyrinths, hats, mice, animations, music, particles, movies and everything that you see and hear within the game. I got quite the education to know the theory, tools and practices of all these spiffy art forms."

Wizzard Cat: "Computers speak directly to my soul. Little impulses of electricity becomes living worlds full of cats and mice through the magic I perform. You might think the world is made out of things, I know it is made out of math, logic and process. Nothing within the game reaches the player unless I make it work. All the programming languages, technical platforms, rendering engines, deployment process, automated testing and the lot is stuff I have mastered. I am quite awesome."

Expert Cat: "Sun Tzu would be pwnd by me. If he wasn't dead already, I am still alive. I know marketing and how to position products. I know how to measure success and set goals which will be even more successful. I speak directly to the end users and learn what they desire. I communicate the markets desires to the team and workshop with the team until they prove they understand what the market wants. I test the products on the market and improve our results relentlessly. A game developer would call me a designer, maybe a non-traditional artist or a biz analyst. I also do stuff like interaction design and scripting when needed."

Our four cats are maybe not using the most conventional titles as the ones you might be familiar with. But keep in mind that these guys are mean and lean cats. They don't follow conventional rules. They make their own rules and play their own game to win.

Two kinds of players here, you know them already... In the world of cats they dont know they are a market. They just want to live their lives happily and in peace.

The cats start working on a vision which causes a lot of half friendly cat fighting, including hissing and big fuzzy tails. Eventually cool cats reach agreement and begin with reality checking what they agreed upon. They keep running around in this loop until reality align with their concept. Or maybe it is the other way around, its difficult sometimes. If they fail they go back to the vision but these cats are so mean they only fail about half the time.

The cat team takes a close look at the vision and how it is positioned on the market. They don't want to run into those nasty big competitors, some smaller competitors are quite ok however. They know what they are doing so they pick a spot which looks like it might have a few lonely cats without suitable and good games to play.

Since the cat team has found its market position for a game they can start hammering out the concept. What kind of thing is this game that these other userCats are likely to want? They figure out what kind of symbolism might stimulate this audience into taking action. What kinds of goals the userCats are likely to find engaging. And they put these things into a list of priorities for production.

With priorities sitting on the wall as post-it notes they take the first one and they go out on the streets where userCats are hanging around waiting to be entertained. They talk to the userCats and carefully nudge up some information about the highest priority. Woot! This works! UserCats like this type of stuff... well sometimes at least. Quite often they have to run this loop a few times before userCats seem to provide the correct information. They might also learn new things about the competition here which needs to be taken into consideration. Sometimes they even encounter the wrong userCats and have to change them for others.

With a successfully developed list of priorities the cat team starts producing prototype products. They think this is what a Minimum Viable Product is about. They bring it to the userCats and see what happens when the user cats try it. In the beginning it does not work very good, but the mean and lean cat team knows how to repair their broken prototype and after a while the userCats start to appear rather engaged when testing it.

And there it is! The cat team has found resonance after a few attempts of prototyping. This is a key moment for the team to get a morale boost which will bring them forward towards cat nirvana.

With the successful prototype to guide them the cat team goes into production.since they are so lean and mean they don't need any more cats for this, all they need is an even tighter relationship with the end userCats. So they pull userCats really close to the team to make sure they can test their product continuously against a useful feedback pipeline.

At this point the team starts investing a significant portion of their time into making sure that they can keep up a high speed through the loop. A lean and mean cat machine knows that the most important thing is to be able to react to feedback as fast as possible and they keep on making their reactions faster and faster for every circuit through the loop. The Wizzard protests loudly when the magic might be going kaboom in the future and the Expert stops the production and does a "5 whys" if the feedback from the userCats starts sounding like strange noises.

While running through the production loop the cat team is making these userCat loops, Daniel Cook named them STARS. Each feature consist of many of these loops and each iteration the cat team add value to these loops. Stimuli is the first thing the userCats encounter. The team makes sure all the stimuli in the game makes sense and fits the expectations of the userCats and sometimes they make sure that the userCats are positively surprised when moving through the STARS loop.

Daniel Cook is a hero for lean and mean cat teams.

Eventually the cat team will be successfully stringing the userCat loops together in some awesome patterns. As the Newbie user cat successfully runs through the loops the Newbie cat gets more and more engaged. The cat team is so good at this that the loops are whole and working. UserCats experience good pleasure and they don't burn out or feel confused and annoyed. As a userCat plays the first finished parts of the game it feels showers of dopamine in its brain which are produced when the nerve system extends its associations to better handle the Skills required by the game.

When the cat team picks up a new piece of the game to build they know that they are only in the beginning of a journey which will need a few round trips with the same piece. They are quite competent so they understand that trying to add another piece before the current one reaches the "market demand per feature threshold" is going to lead to a ton of waste in future production.

While working on making one function in the game good they methodically monitor the feedback from userCats for each iteration. They keep on iterating until there is statistically reliable proof that the purring is caused by the product and not something else.

Oh noez! The cat team has run into a road block!

Regardless of how many times they iterate on a piece of the concept which aim towards the vision they just can't make the userCat purr from it. This is a tough spot to be in. Now they have to do a pivot. Such a lean and mean cat team is not very scared of this problem. They know that they have a solid core product developed which causes userCats to purr satisfyingly. To keep on progressing their product so they can get even more purring all they need to do is some analysis and observation.

The cat team steps back a bit and takes a close look at the market again. "Ok" they say, lets figure out where to move now. Should they abandon the project? Switch to some totally brand spanking new vision? Or ignore the feedback and release it anyway? No, instead they keep one paw firmly planted in their current vision, and prepare to take a step towards a new direction.

They adjust the aim of the vision a bit, keep the successfully developed userCat value, kill the remainder of the old backlog and define a new set of concept pieces which will lead to the new visionary point they find interesting.

Eventually the game does all of the things it should be doing and the userCats are excitedly running along its dopamine infused feedback loops, having a blast and feeling the luurve all around. The userCats realize that the lean and mean cat team made something that was just perfect for them and they send love letters and even a bit of money to the cat team.

The Cat Team are heroes in the world of the userCats and they know it. What the cat team will be doing next is a secret hidden within the future.

Hypothesis - Bartle types as network agents

About a year ago I took the time to read through this http://www.tp.umu.se/~rosvall/publications/rosvall-phd.pdf which contains some interesting perspectives about the world which I find relevant to game design. The first quite practical idea that struck me from thinking along the lines presented is that we can look at the commonly used four Bartle types as agents in an information network. Before I go straight at the idea I have to describe what I mean by information network in relationship to this particular post.

An information network is any system which relays information through links to nodes. For the case of a an online game, which is where the Bartle types come from, this information is typically in the form of text, number, items, levels and so on. We can summarize it as everything any player does which can be observed by any other player either directly or indirectly as a piece of information in the network. The nice thing is that we don’t have to care about the details here.

If you want a good background for understanding the following arguments I recommend reading the publication linked at the beginning of this post. Otherwise maybe you might be interested in it for some other reason.

Quick and dirty Information Network theory background

Nodes are positions and actors in the system, for the case of this particular perspective they are players.

Links are connections between players which transfer information. A Chat conversation is a link, group membership, trade, spatial proximity and so on. We can categorize links as a kind of relationship between players. Links are commonly measured as a relative strength. Measuring links in a binary fashion as used in this text implicates that there is some threshold under which the relationship is too weak to warrant representation in the model. For example between two players who briefly saw each other or had a brief conversation. If you have a project where this type of detail is of relevance feel welcome to extend the model to fit the data which you can understand.

An important piece of background for understanding this text is that links are attracted to nodes which has and communicates information.

Some poorly formulated theory follows:

Bartle types can be detected within a game by tracking changes to the information network. How you would do this practically is not going to be part of this post. Each player can be considered as a node, or we can group players together if you like, but on this very abstract level it does not matter, at least not to me.

The Achiever is a node which generate information through its activities. The Achiever activities are typically focused on explicit goals within the system, such as obtaining things of value. The information gathered by the Achiever is primarily about the Achiever as a relationship to these goals. Such information will spread out from its source to other nodes in the system.

The Explorer determines the value and priority of information in the network. The values found by the Explorer are relevant as meta information and attract links just as any information does. By careful examination and comparisons of available information the explorer is the node which labels information as more or less relevant within the system. If you have played some WoW you might argue that this is done by the auction house, I would argue that there are other things which are information, such as raid tactics, rare spawns, cute little pets, fun quests, interesting situations, chat conventions and about everything else.

The Socializer is a node which relays information by attaching links to available nodes. Information and the priority of information attract attention from the Socializer. Once the Socializer node has obtained information it will use the information to attract new links.

The Killer is a node which cut the network by removing links and nodes. The Killer is unpredictable and will at random select a piece of the network and cut it. We can make a guess which says that the Killer will cut the network at about 2 degrees separation, or more, from its own position.

Feedback pipelines

Game production use the word ”pipeline” for the technology and behaviors needed for adding data to the end product. This is a great and useful component to the iterative process. There is a system which can be optimized for speeding up the time needed to change the data from one state to another. I have no real idea of how much of the budget for a large scale production goes into developing this pipeline. I guess it is significant and well motivated.

Now to the point of the argument, the investment made in the feedback pipeline is most likely much smaller for most game projects. This is not well motivated and I believe it surfaces as a tremendous cost, for successful project it means your staff needs to be incredibly competent and able to manage implicit iteration without excessive waste. For failed projects it is the one major cause for failure.

I knowingly use very strong words here because I want the notion challenged so I learn something useful from it.

Dangers of iterative production techniques, part 1 of n

As I mentioned in a previous post http://gamesartdesign.blogspot.com/2009/03/iterating-towards-value.html there are, from my personal perspective, several ways to cut an iterative process. This post is about general risks with any of these, and likely other, cuts.

Risk 1: Feedback conditioning

This is a risk which occurs whenever you keep getting similar feedback through a series of iterations. The shape it takes is much like what happens to us humans when we get accustomed to living close to a paper manufacturing plant which stinks of sulfurous chemicals. Our brains get used to the initially nasty experience and we get used to it. A game development team which gets familiar with some feedback and determine that it is part of reality will make a worse product than they could.

Risk 2: Reliance on implicit feedback loops

When the measurement is implicit as with the case for how the subjective components of the product are experienced it is quite likely that the team will fail to understand when they reach the top of the value s-curve and keep on investing in things which are done. For us who spend our time with the modern art form of game design this is horribly difficult to communicate. I also believe it is more difficult for the other art forms in game development as well than what it is for the older more established media. How do you know when you should make a new animation rather than keep on iterating the current one?

Risk 3: Lack of direction

This is the most often mentioned risk which comes from a combination of lacking vision or the communication of a vision which is hard for the team and business to understand. As a consequence of a poorly communicated vision the team lacks a foundation for understanding even explicit feedback loops and will progress erratically.

Risk 4: Going in circles

When the team has too little room to maneuver they rick failure to understand how to change the next experiment in the iterative process to improve the feedback state of a production. This comes appear to often come as a consequence to another failure which cascades down as an unmanageable cost of an effective cycle time. If changes to the product reach a certain volume the next change will be driven by risk aversion, risk elimination is likely to continuously surface with the same solution over and over.


Do you think this list should be extended, feel welcome to add your own risks and I’ll try bake them into part 2. ^^

How. A sub-atomic structure

To begin with the effort of breaking down games into individual parts I need some rules to follow. I’ll begin with making a rule which says that the breakdown needs to have a useful purpose for making better games, or at least analyzing games for potential improvements. Since I preliminarily have the intention to make a comprehensive model for some analysis I will segment the effort and give each component its own story. I will also go for the large scope and make this breakdown for “computer games” rather than board games and I will aim it at what has value in the marketplace.

How Things Happen

Games are composed of “things”. At this point we don’t need to dig into what these things are, that is going to be covered later. What we need to concern ourselves with at this point is the matter of how.

When you create a game you have the option to determine how things happen in the game. A lot of your options are going to appear as hard wired in the technology or genre which practically is a matter of cost efficiency. Since we are not concerned with cost for this particular topic we can ignore things such as genres and technology and purify the idea of how.

How, for the purpose of this text, is a matter of matching sensory requirements of the user with events in the product. We humans have sensory systems which have been developed through a long time within an environment which honed our DNA through analogue API’s. These are often referred to as nature. Our senses are developed to detect things in nature and it appears as if things in nature come to our attention through some natural properties. A suitable example of the way nature works to catch our attention is perhaps how a branch of a tree breaks when you are climbing on it.

You are standing on a branch in a tree and feel it sway slightly beneath your feet. Suddenly you hear a crackling sound of wood fibers breaking, the branch bends swiftly and you fall. This is a simple model of a natural “how”. We can plot it over time and get a little sequence.

Swaying –> Crackling –> The Break –> Falling –> Ouch!

For the purpose of fully detailed analysis we can consider the crackling as an individual how. How does the branch crackle in nature?

The crackling is going on for a short time and begins with the first crackle, the first fiber that breaks signifies the moment when the branch starts crackling. When the branch crackles its most intsenively we definitely can tell there is some breaking going on. The last fiber that breaks signifies the moment when the branch has finished crackling. We can plot the sequence of crackling over time and get another graph. We can assume the time is short, maybe about one second.

First Crackle – Peak Crackle – Last Crackle

Us humans have developed a in a world where branches crackle as they break. The crackling is an integral part of how we learn climbing in trees, something which probably was more important to us a few million years ago but anyhow, our brain uses the crackling to learn about trees. Since games are much about learning things (which is a topic we will return to later) it is important that the way things happen in games match the criteria for how the brain organize sensory stimulation.

Something that is really rare in nature but awfully common in poorly built games is the metaphorical equivalent of branches that breaks without crackling. When things happen immediately we fail to learn what happened. We stand on the branch and suddenly the branch is broken and we are falling. This causes a sequence of sensory failures and the player often experiences a negative value in the product as a business consequence. Our ancestral monkey humans quickly learned that certain types of trees are treacherous and should not be climbed, that is the markets rejection of a poorly built “how”.

From here we can make a comparison with how things happen in a piece of music. This is a comparison for practical purposes because the structure of how has been dressed with a terminology in the music world. We can look at a note that gets played. We don’t need to care about which not or why it is played.

Someone who tweaks synthesizers will be quite familiar with the concept of envelope which sometimes is called ADSR. Envelope primarily defines how the sound signal changes over time. It is commonly connected to how the amplitude, or volume, changes over time, but can also be connected to other things such as filters, phase, pitch and everything else you might want to involve in the note. Since it is easier to understand what happens with amplitude than the other things we will use that as a reference.

When a note begins, the A in ADSR which stands for Attack is set to fits between two extremes. These extremes are instant and very slow respectively. No natural instruments really has an instant attack although some instruments which would appear to be close to instant would be a small bell, a pluck on a guitar or the pressing of a key on an electric organ. An instrument with a very slow attack is also tricky to imagine but rubbing a gong with a brush until it howls would be an example, a singer who makes a very quiet noise and slowly increase the volume until it is loud or an orchestra which slowly builds a crescendo from silence. The real point is that the shape of the attack matters a great lot to the listener of the music.

The remaining parameters of the ADSR will get a bit shorter descriptions.

The D stands for Decay. Decay defines how the note changes after the Attack has player through but while the instrument still is “alive”. For example how the note from a piano sits there while the piano key is pressed.

The S stands for Sustain and defines how the instrument behaves while it is continuously stimulated. For example how a violin sounds while the bow is acting on its string, or how the organ sounds while the key is kept pressed.

The R stands for Release and defines how the instrument behaves when it is told to stop. How the string stops making sound after you release the key and the dampener interfere with the movement of the string.

When building a game we choose how the envelopes for feedback systems are set. The shapes of the envelopes give the feedback fit within the overall experience. Chances are that a very successful game has more variation in its envelopes than less successful ones. It can be argued that feedback is a fractal concept which exists within all levels of the design and that there is an envelope on the feedback from managing a guild in an mmorpg as well.

Figuring out how your particular game should structure its envelopes is an iterative process within the development cycle. Making conscious design decisions for how each component operates from the direct to the abstract will likely help make you understand your product better.

Feedback envelopes are from the perspective of a structure or “grammar” for game design at the sub-atomic level. You can feel them, test them and evaluate them as individual contributions to the overall experience without needing to worry very much about their dependencies on the higher up structures such as skill atoms or story for a good long while. An important thing to keep in mind here is that it is a relatively hefty task to iterate feedback envelopes and you are likely to benefit from determining your level of ambition before you get started spending time on a very ambitious scope in this matter.

Example of mechanics which has an envelope you can test in some isolation.

An attack, accelerating a car, steering a boat, jumping, killing an enemy, selecting a puzzle piece, completing a puzzle, becoming a friend, using the manual, starting the game, etc. There should be no end to which things in a game has a how.

From here we can go back and look at the envelope for the full story of the breaking branch in the tree.

It begins with swaying, converts to crackling, breaks, sends the person falling, from where the next envelope takes over and defines some kind of ouch! A very big part of the learning in games comes from the envelope of the ouch. Learning in games is also something which has been well explored by many experienced designers the last few years so I won’t have to write much about it when I get there.