The first hard Learning of the Cats

This post begins a journey of unpredictable length which describes things the Lean and Mean Cat Team has learned along the way towards achieving significance within the games market. We will begin with the hardest lesson first, then possibly move on to easier ones later.

A hard lesson for Expert Cat: Mastering Perspective

This is a lesson about communication and understanding where one of the biggest risks with your product really lies. Expert Cat has gone through a life long journey to develop an understanding for this type of situation so it will not be a nice and easy lesson to describe. But we shall give it a try, Expert cat is whispering his s33kritz into my ear as I try to write them down.

This is what Expert Cat looks like as he is trying to convey this message for me to write down.

As you can see he is sitting next to little blue dots and lines which say Node, Link and System. This might not seem like something which is a learning, but it is a pillar of the most fundamental learning he wants to tell you about.

He says that in the beginning he thought about the world as if it was made out of Nodes. That means things which has properties in themselves. It is an effective way of observing things to treat them as nodes and it makes life for the Expert Cat easier on the surface. He can describe them and point at them and people who listen to him has a decent chance to understand what he is talking about.

Links are a bit trickier to understand. They are the connections between nodes which describe that the nodes are interacting with each other somehow. This is a lot harder for Expert Cat to at first understand, even harder to make use of and almost hopeless to describe. How do you describe that the car and the road are connected through a link, you cant see it? Maybe the tires are a link, maybe it is the driver which wants to travel who is the link or maybe it is the engine which make the tires turn with force. Expert Cat almost goes crazy trying to describe this to other cats.

Systems are a bit easier to describe but harder to create. Expert Cat can lump a car, a road, an engine and a driver into a clump of things which together are a system. When he describes the whole system to other cats they intuitively understand that they could make some use out of the ability to drive along roads to places at speed and derive some type of value out of it.

When Expert Cat was young

As a youngster Expert Cat wanted to do great things for the other cats in the world and began working on creating things. Since back then he was only really able to understand the concept of Nodes he went about and made things. Sometimes his things caught a litle bit of interest among the other cats but nothing really worked. What is wrong with my things? - he though a bit sadly.

No one really wants things it seems. Well, actually there are situations where thing are wanted but those are special cases which Expert Cat will tell us about later in this story.

Expert Cat is trained by Master Cat

After making a series of failed things Expert Cat went out looking for a Master Cat who would become a great teacher. Master Cat began training Expert Cat at using different perspectives of looking at the world and introduced Expert Cat to the idea of systems. The things Expert Cat had been making were failing because they were not part of a system which the other cats were part of. The things which had partial success had by a chance become adopted by other cats as pieces of their personal systems which are hidden in the mystery of cat souls.

Master Cat spent years and years and mentored Expert Cat to learn how to observe systems. About ten years after meeting with Master Cat our Expert Cat emerged as a fully trained systems observer.

A trained Expert Cat

To make things successfully our Expert Cat learned to create links. Sometimes links demand the creation of Nodes, and sometimes links demand other things. The core understanding of Expert Cat was to see that things without links are dead weight, waste and useless creations in general.

The next problem for Expert Cat is to describe what a link is. This is a fundamentally tricky problem because they are always different in detail but similar in the abstract. Since the details always differ we can make one detailed example and try to move onwards from there.

Details of a Link

Lets us begin describing a link. We will describe the link of Eating. We can look at something and notice that it is getting Eaten. A good start. Expert Cat wants to create the link of Eating.

To create the link of Eating our Expert Cat needs to become dependant on two nodes. One node is a Cat, who Expert Cat thinks will be interested in eating. The second node is a Fish which Expert Cat thinks has suitable fit for the occasion.

This is a deep understanding of the Expert Cat. The value in the system of "Cat eats Fish" lies within the interactive process which is commonly called eating. The value of the fish which is not eaten can be considered "inventory" which according to lean is a risk. From now on when Expert Cat make things he defines his thing as the interaction between the nodes in the system. The ten years of training which Expert Cat has contained a few weeks of trying to understand the writings of Guru Cat Chris Crawford who says the trick to creating games lies with defining the design from the verbs in the design. Expert Cat believes this argument says the same thing with different words. Expert Cat believe verbs are quite useful when defining links.

Creating systems through Links, Nodes or Systems

While training with Master Cat our Expert Cat learned a few other things about systems. Different types of systems require different approaches towards their creation. To avoid needing to write far too much text we will narrow the problem down to two extremes.

The two extremes are described by a Guru Cat called Steve Blank. He uses a model which is a useful framework to dig at this problem. He uses the words "Customer Risk" on one end and "Technology Risk" on the other. Then there are things which has both...

On one extreme end we have a system where the risk is the functionality within the nodes. At this extreme end we find things such as a Fusion Reactor. If you can get the Fusion Reactor to work as it should then you have your value right there. Infinite power for a low cost. We can define this value as its node. If it works it will also have value for the other cats in the world.

On the other extreme we have the taste of Fish. Does the taste of the fish which Expert Cat is creating have any value on the market? The risk here is not that the Fish has a taste, or even if the fish exist, but rather if the taste causes the cat to eat. How does the cat eat the fish? Oh noez! This is so complicated Expert Cat is almost trembling at the notion of describing the situation.

To describe the problematic description as hypothesis

We need to use another lens to look at the problem to get a perspective which has a better chance of succeeding. To create the correct taste when cooking the fish our Expert Cat creates a hypothesis that says: "The fish tastes good enough to make another cat eat it." This puts the link to the test!

Now our Expert Cat can cook the fish with an inventive recipe and try to make another cat eat it. He can modulate his test and see if he can make another cat pay for the cooked fish, and see which of all the cats are willing to eat it or not eat it.

By successfully describing his fish recipe as the properties of eating he has obtained the all powerful insight into how changes to the recipe influence the value of the system. Wewt!

Ok, so what does this mean in practice?

Our Expert Cat understands how to differentiate customer risk versus technology risk. When Expert Cat joins a Mean and Lean Cat Team he knows that his team will be more or less suitable to handle the different types of risks. A team full of scientist and engineering wizard cats is likely to be suitable for taking on technical risk, which a team full of marketing Fixers and emotional Artist cats is suitable for taking on customer risk. A team which has a healthy balance of both is likely to take on challenges which contain both types of risk.

Kinds of risks for game creating cat teams

This is a pretty big system which practically is rather simple to understand.

Games with some Technical Risk:

• MMORPG's
• Next Gen AAA Console Games

Games with Customer Risk (Everything else):

• Flash Games
• Web based community Games
• Facebook Games
• Marketing Campaign Games
• Indie Console Games
• Indie PC Games
• Oldskool Games
• etc

Note that no games that the Expert Cat think is a game has purely Technical Risk. Defining a game Hypothesis as Nodes is thereby almost a guaranteed failure. Alright, Expert Cat jumped over a long series of arguments to reach that conclusion, but his time is running out and he wants to get out of here rather than keep on telling us the details of this story.

Farewell Expert cat, enjoy the sunshine and the Fish cooking! *waves*

Fixer Cat comes in to finish the lesson and says:

- Lean and Mean Cat Teams that use Agile or Scrum to create games need to learn how to define their Backlogs as links. If they fail to do this and instead base their work on creating nodes they become statistical death marches. However, if you create an MMORPG or a Next Gen AAA Console Title you can use a bit of both nodes and links to deal with technical risk.

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.

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.

Planning for Greatness

How can you plan to achieve something which is great? This is quite an interesting problem when the details of the end result are unclear as they always are with any entertainment production. If I were to supply an answer to this question I would have to begin with trust. Mutual trust is imperative to greatness.

This pops up in the game development industry through various funky ways. Almost no one has enough credibility in the gaming industry to be trusted with anything that is not an oldskool artform such as painting, writing code or making music. This results in a tiny number of pioneer game design luminaries riding a positive feedback loop of trust which everyone else struggles with aiming for a foothold.

A lot of people are struggling to develop trust in the arform of game creation (design is not an artform) but almost no one is reaching a point of credibility. The number of people who prove their ability to make games which work is enormous, the number of people who prove their ability to reliably create game which are profitable business is miniscule.

Almost everyone who has created profitable games did so by getting lucky. I usually call this kind of system a "darwinistic process" which means that the reason why they were successful is obfuscated by complexity. This is also the reason why a "repeat performance" is extremely rare on the level of the individual production unit. Getting lucky is a statistical anomaly and it is even more rare to get lucky twice in a row.

To plan for greatness you have to understand this pattern. Even if you do have a "trusted" fellow who can claim responsibility over a portion of the creation you have to understand that this person was mostly likely just lucky and got involved with a project which had a randomly lucky destiny. Armed with this knowledge you need to integrate the experience from this person with the new team. Teach everyone in the team how the successful fellow learned to reduce the statistical probability of failure with healthy motivation. This will develop trust.

Trust can also develop in several other ways. I would personally recommend communication as the primary tool. Once you have trust you can have success. If you demand success to feel trust you reduce your chances of success to the same level as all the other random mutations within the darwinistic soup of creativity.

Btw, being just another random mutation in the chaos that is life gives you a very poor probability of success.

Prelude to Greatness

The world of music production has shown me something about the concept of greatness. Greatness comes from the performance of the artists and experts involved with the production of music. You can sense a great production in the making when you have good performers getting their pieces just right.

The Robot Band Spaceforce are not great in this sense. I know that because the work behind their performance is not just right. Their level of ambition is also too high for me to complete within a reasonable amount of time. To prove this point I will have to make some less ambitious Robot song which I can claim reaches Robot greatness.

No great result is really random

I was fiddling with the mix and arrangement of the latest Spaceforce song and realized that I was messing with something that one of teachers said in at Musicians Institute. It wenst something like this:

- Parts of the production might appear to be random, such as the slight out of tune guitars on a nirvana album, but in truth it never is random. It is well through out and set to be just that way conciously.

There is a lot of wisdom in this and it does apply to a whole lot more than nirvana songs. It happens to apply to Spaceforce as well, when the production is young it has a lot of randomness in it coming from the first iterations which define the structure of the work. But the process of finishing anything is partially about removing everything random and replacing it with the concious refinement of the data.

This also applies to game design and storytelling, maybe you start with randomly generated pieces, but you should be well aware of why you keep anything which was randomly created. It will rarely do more good than harm to the end result.