Games, Art and Design

It's never to late to learn new skills

2011-03-12T02:11:00.000-08:00

It is now roughly a year since the last post. It was an interesting year but I won't be writing about it now, perhaps sometime in the future i will. Instead I am going to write a little about my new project in personal development.

Learning some basic coding skills

I realized I have spent the last 20 or so years learning all the basic skills for making games except for programming so it is about time I do something about that and get a decent hunch about how to do the programming part too.

I will primarily focus on learning how to program in JavaScript. This choice is based on three fundamental arguments.

1: JavaScript is sufficiently capable of teaching me what I need about Object Oriented Programming and Test Driven Development. From what little I understand about it these methods of writing code is rather transportable between different languages. It is also rich enough for making fully fledge gameplay although perhaps not the most ambitious scales of simulations such as individually thinking soldiers in big armies or fluid dynamic physics and such but those are not needed.

2: JavaScript is coming very strong in the world of game development. My prediction says that in a few years most people who build games build them with JavaScript, CSS and Html5. And several will be using various webgl libraries so create nice 3D games too.

3: JavaScript has an awesomely fast speed of iteration. Change something and get feedback in the implemented game within about 2 seconds. About the same speed for getting feedback from jsTestDriver for unit tests or FireBug/Chrome console for coding errors. This rapid Cycle Time extends to the deployment pipeline which, by having a git clone in the public area of My Dropbox all I need to do to send a test product to a tester on the internet is:

- Git pull

- Paste the link to the test subject. Or make them refresh if they already are there.

The new version is live and in use within about 10 sec on average a bit depending on how moody dropbox is, the time ranges from about 4 sec to up towards a whole minute whenever dropbox is having problems or suffering from heavy use or whatever it might be that makes it slow during american office hours.

There are a few more arguments I could raise about the choice of tech to study through such as having the internet full of people who are going through the same experience, lots of open source material, plenty of documentation with browser API's and so on. Now i got to go back to figuring out how to replace nasty if sandwiches with less horrible code.

Another good reason is that a good friend and great programmer said something like "JavaScript feels so rebellious compared to C". I like rebellious things.

Facebook tries to implement a global nation

2010-04-26T02:18:00.000-07:00

The latest hubbub about Facebook and their plans makes an interesting case. From my perspective they are trying to create a kind of internet government. If they reach any level of success there will be all kinds of systems waking up to protest. The other governments come to mind as an example.

Countries commonly frown upon anyone who creates their own currencies for their citizens, just as one of many examples of things that might become a good drama of scale.

Priorities and dynamics

2010-03-18T08:32:00.000-07:00

An interesting problem for prioritizing an agile project is the relationship between what is most important and what is needed. This might seem as a paradoxical problem as the thing which is needed is the one which is important. But it is not, and in this post I will try to note down how this can be.

A crude summary of the concept of prioritization might say it is an activity which prevents you from working on the wrong thing. Commonly a set of features which makes the product reach a critical use case. This activity also takes a look at these features and breaks them down into further prioritization to make the product tighter. Then you start building it.

So far so good, to describe why this is not quite as simple as just figuring out the priorities I will fall back on my usual comparison with music production. When you are about to create a piece of music you will have references, either explicit ones that you talk about with the production team or implicit ones that you are silent about or even innovations. These references help you prioritize. This is practically done by something called music analysis and there are some models for this. The ones I use have a mix of formal and informal properties and I won’t dig into these more than describing the simplest level.

Imagine that you listen to a song, now think about which thing in this song is the loudest. *waits a little* Ok, you found an important instrument, maybe a snare drum, a base or something else. Then think about an instrument that you hear quite often. *waits a little more* Ok, you found another important instrument.

In the world of music production this analysis keeps going on for quite a long time, it keeps on going on during the production and it is also done on the finished song. You might start with the hi-hat which is relatively quiet, then a cymbal appears, then a sidestick, a kick, a ride, a cymbal fill and a snare drum. That’s a reasonable set of instruments used to bring in the drums. And you will use the same hi-hat at a few different intensity levels a lot of times before you are done.

The variation of experienced intensity or even volume is sometimes described as dynamics. A good song will have a lot of almost quiet and very subtle sounds going on which gives ambience, harmony and feeling to the whole song. Without these your music is crippled. Imagine making a song with only the loudest and most intense instruments. Some musical genres almost do this, electronic dance arrangements come to mind but these also contain subtleties which are harder to put your finger on.

Now imagine that you have very little experience with music but the company you work for has decided that it is strategically important that you manage the production of the music played in the marketing campaigns for the coming five year. It has to be about five minutes long and sound a bit like a disco song made in the 70’s, and you have a budget which affords you two people working for about a month.

This is a relatively easy mission for an experienced music producer, but it’s quite challenging to the beginner. When you meet your two musicians that will make the music for you during the coming month and you describe your mission they will start asking unpleasant questions. Maybe, so which of the 70’s disco songs should we take our influences from? Since there are vocals in 70’s disco we’ll have to figure out who will sing and what that will cost. How good of a singer do we really need? Is it ok if the singer is a bit flat? Or maybe better to remove the singer and then aim at a more instrumental arrangement? Oh, since you can’t answer these questions for us let’s just listen to this reference and prioritize the parts you think are the most important, then we’ll put them in the song one after another until we run out of money.

So now we have figured out that the base, the kick drum, the organ and the vocals are the four highest priorities. Which one should we finish first? This is a kind of question that will kill you if it happens in the music industry. In this particular example case it is a symptom of a conflict which is based in lack of understanding between the customer and the production team. The two musicians know that they can’t reach the goal of the client on budget and starts to force the client to reduce the scope. To successfully navigate out from this problem the client has to budge on something which was defined in the strategy.

If this happens in the music industry you got a decent solution, just buy the song you want from whoever made the original in the 70’s. In the world of interactive software you don’t have this luxury, your options are limited and all of them are unpleasant. The statistical solution is to start answering the questions and actually building the prioritized things until the money is spent. The market will treat your product as it deserves.

Interactive software, just as music, is riddled with challenges of a dynamic nature. I’ll pick the easy part and talk about feedback here. An example of very intense type of feedback in interactive software is a shaky camera movie. The user clicks a button and then a movie starts playing where the camera shakes and there are loud sounds. A less intense type of feedback is a slight highlight on the button which lights up when the player places the mouse cursor above it.

Imagine that you need to prioritize these two against each other. Which is more needed, which is more important? The answer to this question will depend on who you ask. From my perspective it really depends on the dynamics of the overall production and your concept but the general notion is that increased dynamic range is better than a focused one.

The other day I came upon a tactical production technique which helps with this problem but it appears to have been invented for another purpose, which was to help the team finish within budgetary restrictions. The tactical solution is to bring in items from the whole spectrum of priorities to each product iteration, aka sprint. This has to be done with some consciousness of course, pick suitable low priority items to go with the high priority ones.

This way your metaphorical “music” will end up having Drums, rather than a Snare and a hi-hat. But who is the drummer? ... that's another topic.

Corollary definition for design

2010-02-16T05:29:00.000-08:00

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.

Erlang vs. Metcalfe

2010-02-15T05:26:00.000-08:00

In the life of Game Designer we can get a better understanding for the concept of quality by combining two old and trusty mathematical properties. I have hinted at these concepts in older posts but I have put off writing this one for a while. I'll try and make it quick.

Erlang says that quality is 1 when something does what it is supposed to do when it is expected to do it. Things that do almost what it should do, or for less than all the time when it is expected to do it has a quality which is somewhere between 0 and 1.

Metcalfe´s Law says that the number of links in a connected system increases exponentially with the number of connected nodes.

At this point I'll introduce my own definition of antiquality.

Antiquality is what you have left after you subtract quality from 1. Such as if you have a telephone line which has noisy crackles for 0.6 seconds every minute of a phone call your quality is 0.99 and antiquality is 0.01. At this level the amount of antiquality in a simple phone call is not a problem to the user. Its a minor annoyance at worst.

The interesting thing begins to happen when you connect a bunch of phone lines to each other. Imagine the phone call as a conference call with all phones connected to all other phones. If one line crackles the crackling is broadcast to all the other phones. You don't need a whole lot of phones in this system before the quality level needs to be a lot better than 0.99 to get any kind of useful communication going.

When we look at games and other experiential constructions such as a brand, we as humans have the tendency to connect every bit of the experience with every other bit. Our brains are like a super network which categorize every bit of antiquality with every other bit of antiquality presented beneath the same symbolic structure. For any product which is more complex than the most simple of things we will quickly label the whole experience as useless antiquality, unless the actual quality is a true 1.

So how can you use this understanding to build a product with true quality?

That is a different story. But it begins with understanding what the product is supposed to do and when it is supposed to do it. If need be you adjust these parameters and you make sure your user is well informed about this framing or you will quickly be labelled as junk.

Agile Failures

2010-02-10T04:06:00.000-08:00

There has been a lot of almost mainstream media whining about how projects fail despite using an agile development methodology. Lots of blog posts about how agile cause trouble and how scrum fails in companies.

This post aims to start a journey which looks at my perspective of this trend. The journey begins with looking at the businesses which invest in projects and we’ll begin with separating these into two major factions.

Faction 1: Profitable business.

The profitable business has found a way to reproduce a profitable sale. Steve Blank uses the phrase “repeatable sales model”. My interpretation of this is that there is a potential market value which is reliably converted into money through the business activities. The repeatability causes a reliable equation to play out where you have a high chance of staying on top of positive revenue through conducting very low risk maneuvers until the equation changes when you have the option to adjust to maintain your profits.

Faction 2: Not yet profitable business

The not yet profitable business has bigger costs than earnings. This is quite simple and includes everything which is not yet profitable. In many cases you can see a profitable business include portions of this in the profitable equation, for example by making design improvements or product line extensions. The more common scenario is however attempts at creating a profitable business out of an idea.

Now that we have these two major factions we have a tool for understanding several ways to achieve failures which will make any methodology fail. Since everyone has learned that the typical waterfall project is going to fail by default it’s not that interesting to talk about, but we’ll try and stick to general failures which can be blamed on Agile.

To predict how you will fail you can start with asking yourself: where does the money that finances the project come from? If it is financed by an already profitable business you have a particular case. If it is financed by venture capital you have another and if it is financed by yourself, often as some type of hobby, you have a third. Among these three candidates you have one in particular which spells uncomfortable failure louder than the others. The least loud failure is when you are paying yourself. No one expects success from a hobby. If you are funded by venture capital you are expected to fail about 90% of the time. No one is surprised when investments fail to find a return. The loudest failure is when an already profitable business invests in unprofitable projects. These also seem to be the ones which plays the blame game and tries to blame agile methodologies for their failures.

If you look at an already profitable business from a capitalistic perspective you would think they should not invest in a new “not yet profitable business” and rather send that money to their investors. But for various reasons they generally don’t operate this way but attempts to reproduce profitability in new innovative manners. These become complicated matters.

A profitable business has generally spent a great lot of effort to achieve their profits. As a game designer knows you will be conditioned by expending effort at achieving a goal. So the profitable business has been conditioned by its own success. This conditioning is cultural within that company. This culture tends to have an agenda which prioritizes protecting the profitable business against risks. The practical implementation of this protection is commonly called bureaucracy.

Bureaucracy causes risky product experiments to have such a great cost that they have to be cancelled before they reach the market. It is better to send the investment immediately into the trash bin than to use it to cause a potential harm to an already profitable business. This also has the benefit of creating plenty of work for bureaucrats who thereby can be hired to handle the paperwork.

Eventually this causes polarization within the company where creative forces such as marketing eventually is urged to brute force the bureaucracy to revitalize a now aged brand. They can see their market share slowly being poached by competitors. At this point in time the culture has set really well. The creative forces rally enough of a budget to overcome the cost hurdle set by the bureaucrats and begin their project.

Since times change and you learn that using “traditional methodologies” will cause failure this project must begin to work with an Agile methodology, they usually try to work with scrum.

The root of the problem here is that scrum does not remove the cultural conditioning which practically has become embodied within the bureaucratic parts of the company. There will be plenty of reasons to interpret the new project as a risk to the profitable business and thereby justifying interference.

I don’t know if there is any particular solution to this problem but I do believe that a better understanding of this structure will reduce the costs of failure for any business which is investing in any type of projects. And this is just the beginning.

To propose a practical solution to this I will recommend making investments into new business areas at a healthy distance from currently profitable businesses. Mere proximity might increase the cost of failure.

From my experience with scrum I interpret some of the rules as engineered to refuse interference from bureaucracy. These rules cause a kind of cultural power struggle within an already profitable business when scrum is introduced. Power is usually owned by the bureaucrats and scrum becomes the loser and an embodied target for the blame game.

Time

2010-02-10T01:55:00.000-08:00

Writing posts gets low priority when many things needs to be done.

The Cost of Art Forms

2009-11-05T03:48:00.000-08:00

This is a relative type of general production cost.

Poems are cheaper than Pictures
Pictures are cheaper than Music
Music is cheaper than Movies
Movies are cheaper than Games

Hence games are the most expensive art form, unless we consider architecture to be an art from but I don't think architecture belongs here. I kind of tried to fit "website" in this list first, but it isn't an art form, just a technology which carry these other art forms.

Games are the most expensive in this list. There is however a component of the structure that I ignored here which games exploit to reduce the cost per minute of entertainment which is recursion. You can't effectively reduce the cost of a movie by reusing the same scene or the same music. But you can effectively extend the duration of a game by reusing the same rules with only minor variations of the underlying data.

A General Learning of the whole Cat Team

2009-10-28T10:33:00.001-07:00

This is a much simpler lesson than the hardest lesson of the cat team. Maybe you shall find it easier to grasp too.

Before the Cats got Lean and Mean

When the Cats were going through the last phases of kittenlife and almost had grown up they began training at doing work together. In the beginning they had a hard time getting anywhere. Ofcourse such young Cats are going to need to learn a lot of things along the way towards greatness. This is one of the things they learned early.

How to keep Cats busy with doing work

The cats sat down in a room together, looked at each other and talked for a while about what they are really good at. You probably already read the post about the team and know what their skills are. They got a lot of skills, and they made a plan to make sure all the skills are used as much of the time as possible. Wizzard Cat makes awesome Magic, Fixer Cat fixes a lot of things which appear to need fixing, Artist Cat makes much of the emotional Art and Expert Cat makes many great plans.

Working with this plan the whole Cat team made themselves very busy. They worked late nights, they made marvellous things and they had a lot of fun. They kept up this production for a long time since they knew it takes a long time to get any good result so they produced a lot of things.

After a few years the Cat team looked up and realized all the work they had done had resulted in nothing more useful than good times, practice and things. This is not a very useful result, what were the cats doing wrong?

Doing things rather than achieving goals

The Cat team had optimized the work effort for local optima. Keeping the team busy with doing what each Cat is really great at had caused them to fail at reaching the results with only can be met by Cats who help each other meet common objectives. This is an insidious trap which will catch unwary Cats who fail to maintain the discipline needed to keep the whole team focused on the most important objective, which for Lean and Mean Cat Teams is profitability.

By making sure all the cats are busy doing the things they are really good at doing they don't have time to learn about the things at which they suck. In this case they were sucking at setting priorities for the team and they failed to realize that what they were doing instead was waste.

The one trick which turned the Cats around

After realizing that the first few years of optimizing the work to do the wrong thing they turned the whole problem upside down. Instead of even worrying about what they are the best at they began figuring out what their product really needs right now, thereafter do that work together. They began testing their product against the userCats they were building it for and started to see that some things were decent, but most things were quite bad compared to what the Cats had though before they tested.

Now they were on to something. But there were some problems. Often they found that the product was full of bad magic which broke when the userCats tested it. Since Magic is what Wizard Cat does this made the other Cats scared that they would be unable to help Wizard Cat with fixing the broken Magic.

How the other Cats become assistant Wizards

The Cat Team of four cats, with only one Wizard Cat who needs to repair the broken Magic figured out what to do with the problem. The first bit is simple, the other Cats can make sure Wizard Cat is well informed about the symptoms of the broken Magic. The other cats in the team make sure there are userCats ready and waiting to test the new and improved Magic every time Wizard Cat finishes another spell. The other cats in the team can also help Wizard Cat with doing continuous exploratory testing and workshops to keep Wizard Cat really well informed about the value of the improved Magic.

When the problematic Magic is really badly broken the other Cats start talking to their friends to hear if any other Wizard Cats might have cast this spell successfully in the past. They dig up information and possibly seek out Greater Wizards who can help get the Magic in place. Since the other Cats sometimes can't do anything to be very helpful to Wizard Cat they begin spending more time together with Wizard Cat to learn how these Magic spells are cast. This makes the other Cats become low level Wizard Apprentices who will be better at gathering reagents which are more useful to Wizard Cat than what they otherwise usually produce.

Wizard Cat can not always be supported by the other Cats

Sometimes Wizard Cat also needs to be alone with his Spellcasting. At these times when the other Cats are unable to do anything else which helps Wizard Cat they have a few options. They can do some work on customer research and get better at understanding what type of product the market wants. They can do various planning experiments and test if they can come up with some neat solutions to the other problems the userCats have encountered while testing. They can even start sketching on something which is less important than the thing which Wizard Cat is working on. They can practice their skills at making tests or teaching each other about the deeper understandings of their methods.

They can even spend some time with the tools they use and build various little prototype things which in almost all cases are waste. But the practice is not waste so it has some kind of value. They can also do random things such as visiting their grandparents, have some coffee and get a bit of a tan. Someday in the future there will be room for Wizard Cat to enjoy these kinds of breaks when maybe Artist Cat gets stuck with needing to fix broken emotions in the product.

On a general level the cats found that even in these cases where one of the Cat Team Members gets really stuck with the most important piece of work it is better to avoid trying to produce other work with the rest of the team while the big hurdle is overcome. The really scary part is when the stuck cat is totally unable to know if the problem even can be solved. If such an unpredictable situation happens the Cats might have to back off and change their idea about the product. But first after trying to solve the problem.

Maybe next learning is how the Cats figured out to avoid Broken Magic...?

The first hard Learning of the Cats

2009-10-24T03:52:00.000-07:00

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

2009-10-21T12:22:00.001-07:00

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

2009-10-20T09:41:00.000-07:00

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

2009-10-15T12:07:00.000-07:00

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

2009-09-28T04:41:00.001-07:00

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

2009-09-26T04:12:00.000-07:00

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

2009-09-26T03:27:00.000-07:00

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

2009-09-18T05:55:00.000-07:00

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.

Protons, chairs and art

2009-08-21T01:57:00.000-07:00

Things have a tendency to be composed by other things. How things break down depends on which system you use to break it down. Music as I have previously written about can be broken down into music grammar, an example might look something like this.

Opera > Act > Instrument > Key > Bar > Note

I don’t really know anything about opera so don’t think this is correct in detail, however the point is that the full experience consist of a significant hierarchy of information regulated by some grammatical rules.

Another example of a thing which breaks down into some kind of grammar could be a chair.

Chair > Material > Structure > Molecules > Atoms

Again I don’t know anything real about physics but again the point is the same.

It appears as nothing is exempt from the property of existing within a greater whole. The chair might exist within a room, which exists within a house in a town and so forth. The value of the chair might be linked to the town in which it is and what the local trends and cultures happen to be around there. Also atoms break down into smaller particles and forces if you desire to extend the model even further.

Now I’ll try get to the point of this little post.

In the case of music you can individually analyze each level of the breakdown for value and defects. If there are too many notes in a bar of music the music is defect which will make the whole opera sound foul. If you don’t know that the cause for the foul sounding opera is the existence of too many notes in one bar for a particular instrument you might attempt to repair the problem by adjusting everything else to fit the broken piece.

Much of the game design theory which I find on the internet contains the concept of how to break down games into their hierarchies. I find many of them exciting, especially the skill atom concept by Daniel Cook at http://lostgarden.com/.

However there is something which nags at me as feeling insufficient with all the models I have seen so far. I suspect the cause is that the breakdown into a “grammatical” type of structure is limited to present only a portion of the piece. In the world of music the missing pieces might be covered by two additional components.

1 – The instruments and their properties
2 – The musician

These two properties can be seen as extending the breakdown of music into even finer components which define the properties of a note.

.. > Key > Bar > Note > character > harmonics > dynamics > phase > modulation > etc

Or you can turn it around and describe the waveform which is the end product of the Opera as math... a suitable task for a clever programmer with a big computer perhaps.

It might seem unlikely but there are several pieces of music which has its user value linked to the interaction between phase and dynamics within a single note. Two types that come to mind are electronic music and classical soloists who both expend great energy at refining these subtle parts of the product.

Now It might be about time to make an attempt at breaking down games into their relevant areas or materials. That will be another post.

Care is needed

2009-06-29T05:45:00.000-07:00

I just read through the excellent first installment on the Game Design Concepts by Ian Schreiber. I recommend reading it: http://gamedesignconcepts.wordpress.com/2009/06/29/level-1-overview-what-is-a-game/

The definition of game is an interesting matter. I would add to his something like this:

A game "requires that the player care about the outcome of the game."

This is relevant during the play session. Since the game is defined as an "Activity" already I will lump this one in with the definition of game. If the definition was aimed at the construction of the game in its idle state I would remove it.

Format

2009-06-16T12:59:00.000-07:00

Something i have been pondering for a while.

The form of play in games is to see what happen when you do things.

Along the way you encounter other forms, play goes through feedback which presents consequence. Is it that easy to describe?

Planning for Greatness

2009-05-21T08:19:00.001-07:00

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

2009-05-14T14:43:00.000-07:00

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.

Iteration 2

2009-05-09T08:02:00.000-07:00

A lot of various edits from the previous version. Now the video also contain a very cryptic little story.

Note: The production value is still extremely low, the whole piece of work has not been given a large number of hours. The low production values makes it some kind of fun on a wierd level.

No great result is really random

2009-05-07T13:06:00.000-07:00

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.

Feature Creep or Vision work?

2009-05-05T09:36:00.000-07:00

Ok so now I have made this rather horrible video with the robot band. This had a series of interesting consequences. One is that I now feel the urge to refine the music so it shows off the individual talents of the robots better. If I go for this I'll have to make some major rearrangements so they all play solos, Doppz is missing his synt-bass solo, which is a quite rare beatie anyway. And Some cool synchronized solos would be interesting between the guitar robot and the keyboard robot.

After the rearrangement would be done which is an effort of several evenings of work at least I will have to make a new video which shows these new scenes.

Since I have no practical limit on the ambition of the production other than doing it for the fun of it I will categorise this type of work as product iterations. The music would be iterated farther to fit a more well defined vision.

If I did have a set of measurable ambitions and, not that it would happen but if, the work already qualified as sufficient I would call this type of further iteration as overly ambitious or feature creep.

This works, in some ways

2009-05-02T18:42:00.000-07:00

So this is the result of putting sound on Blogger. To get sound up you got to make a movie, add the sound to the movie and upload it through some beta enabled version of Blogger which connect with google video somehow.

So this is iteration 1 of a Spaceforce song. Just finished tracking everything and set some levels, spent hours removing compression from some samplers. As first iterations go not a whole lot of the thing is done with much effort yet.

Since you need to have a picture along I couldnt help but make a low budget video to go with the robot performance. All in about a day and a half of work to write, record and mix, then about 2 hours for the fantastic video. Maybe interesting things will happen when I start mixing this thing.

Noticed that uploading the thing sent it through a pretty bad audio processing which probably reduces the size of the sound data by a few %, at the cost of nasty swischy-swoschy compression defects.

Ideas

2009-04-26T08:31:00.000-07:00

If design is a process which bring out the value of an idea, then what is an idea to begin with?

Wiktionary offers some definitions, among them this one: "The transcript, image, or picture of a visible object that is formed by the mind; also, a similar image of any object whatever, whether sensible or spiritual."

Which appears a bit cumbersome. I will yet again create my own definition to serve my own purpose.

- An idea is a collection of information with undetermined value.

This is a bit rough, but its enough to hook it up together with my definition of design. What yo can do with an idea is what is interesting. There are two main techniques for determining the value of an idea. You refine the idea either through creating artifacts around it which can transfer the idea to more brains, or you construct something that is the embodiment of the idea to see what happens. These two techniques are quite different.

Drumming up value

2009-04-21T13:01:00.001-07:00

So Tricklock is busy drumming away at an experimental space ballad as performed by Spaceforce. It runs at 90 bpm and tries to convey a bit of what goes on inside robots as they travel through space towards unknown alien civilisations. Having decided that Tricklock is not going to complain at his sound I can use him as a kind of infrastructure on which the rest of the song is built.

There are some problems which reduce productivity towards a useful result and they are hidden beneath the ability to change the arrangement around when need arise. I end up doing a lot of something I will call "backwards sequencing" which means that I realize the result will be better if I go back and shuffle the rythmic infrastructure to satisfy the needs of the other band members, mainly Schmooth who is the keyboard player.

This makes me think that I will need to work on Schmooth next so I can determine which parts of Schmooth and Tricklock needs to be in agreement on how the song infrastructure really operates before any large amount of work is sunk into details that require rearrangement of the core structure. I am expecting Schmooth to have 4 roles to fill with varying impact on core structure. Having a steady drummer who can tell the keyboard player how things should work will hopefully make this upcoming job a lot easier than creating the drummer was. If that is true then Tricklock already prove some type of value.

A Flawless Piece

2009-04-20T02:22:00.000-07:00

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

Tricklock - The Drummer Robot

2009-04-16T11:42:00.000-07:00

Tricklock is a very ambitious drummer robot. He is built on 32 triggers, with an average of three samples per trigger which in turn are velocity sensitive leading to roughly 90 or so samples in total. The 90 samples are then sent to 8 separate stereo channels for mixing purposes.

Kick, Toms, Overheads, HiHat, Snare, Perc, Shaker and WierdSFX

The main drum channels except for the WierdSFX and Shaker channel are sent to a Drum Submix for an overall level control so the whole package can be automated on its own. The Drum sub is also sent to a drumroom reverb for some ambience. We can expect that Tricklock will be doing all kinds of wierd processing on this setup eventually, but his bones are now in place.

The samples range across a mix of more or less natural samples, the idea is that Tricklock will be able to electronically play most of the genres I might consider for the Spaceforce band later on, from light ambient kinds of things, pop, rock and electronic.

Considering my ambition to follow the idea of a Flawless first Piece for Spaceforce I will probably keep on tweaking some details of Tricklock for a day or two before I feel satisfied with his final setup. So now Tricklock and I will start playing around with random grooves.

Defining a motive

2009-04-16T08:50:00.001-07:00

I am very much driven by the need to have a motive. This reflects strongly on my hobby projects and when I do things aimlessly the result tend to be reduced to a conceptual effort without value.

To do something about this I need to create a reason for putting up with an effort. For hobby projects there is a good lot of slack on the side of communication. There is no need for anyone except myself to really understand the motive. To make a different type of thing I will try document this incomprehensible process here, you might not be able to follow it well. But I'll try make it readable.

I need a motive for making some sci-fi music, for a larger scale hobby project which is a bit under the radar and hopefully will deserve proper mention later on. What are my options?

1 - Make something that I want to have for my own pleasure.

2 - Make something I think others will like.

3 - Make something for the fun of it.

Ok, so I pick the fun, thats #3 in the list.

So what is fun?

Fun is learning something by using skills which I can develop during the creative process. This is the reason for picking option 3.

If I were to go for #1 I know I will personally dislike the result until my highly picky ears are willing to accept the output on an emotional level. This will require something I expect to be close to an infinite number of iterations. SinceI am somewhat reluctant to invest the rest of my life in this hobby project I will abondon this option.

If I were to go for #2 I would expect to need to work so hard that I will never finish, if I aim at pleasing an external audience my probability of success is limited by my inability to measure my progress against a target audience so this one is out.

Going for #3 I'll start with identifying which skills I want to develop. Thats relatively easy. Production methodology, guitar playing, mixing, rigging, storytelling and some other random stuff not worthy of mention. I will conciously abandon the skills of designing up value, I'll move outside that concept by pretending that I dont care about it in this particular case. The work involved with design in this case would also not be within my means to execute.

Now I have the basic idea, so how to I create the motive from here?

Last piece I made defined pieces of a motive I will use and I'll call this an informal vision.

The informal vision

Setting: Sci-fi (Technology has made changes to the world and the idea is to use the context of the changes to present a message about something which may be more or less deeply hidden in a story or fantstic context. What the technology is will be part of the vision of the effort.)

Method: Roleplay (I'll pretend to be some entity within the context and define details of this entity partly during the development process starting up. This entity will be a band, which is a part of the technology in question.)

Background: A Story

The story in short:

A political party, The Network Party, created a new ideology based on mathematical proof of optimized average and total life value of all humans in the world. This was such a powerful ideology that the political party spread its rule to cover the world and save the planet earth from destruction by consumeralism and economic competition for resources. As the party gained strength it became obvious that mathematically proven principles are well managed by computers. This led to the ideology being implemented in code and thereby further optimized, the implementation was known as The Network of Organized Democracy, usually called The Network or "TN" as shortened by l33tspeeking people.

Humankind was now living an awesome life happily together and they decided to journey towards the stars. A few million years later humankind has spread across the vastness of space. To establish new colonies they sent robots which are connected to The Network. These robots spread propaganda for The Netowrk to alien worlds in preparation for the arrival of human tourists and adventurers.

The Network developed several series of propaganda robots, one of the successful brands travel through space in the form of musicians. They bring the glory of The Network through galaxies by playing songs which they modify iteratively towards fitting whichever alien species they encounter. They can also defend themselves if attacked, but they generally are peaceful. Humans can also purchase these robots directly from The Network by spending a decent lot of their consumption allowance on each robot.

Anyhow... the setting for the work in question is to create odd iterations of the robots propaganda music. This leaves me without any reason to worry about making anything which either attempts to sound real, natural or great. I can focus on the skills I think I can hone through the work.

The details is to roleplay the robots. And the robot band is known as:

Spaceforce

Vocals: All 4 robots participate in singing

Guitar: Roxxor

Drums: Tricklock

Keyboard: Schmooth

Bass: Doppz

The first job in the process of creating the next song in their setlist is to define the sounds of Tricklock. This time I'll aim at the Make it Flawless principle, meaning that I'll spend a lot of effort on getting the drum sounds of Tricklock. I think Tricklock will get his own post before I am done with him. Now to setting up a whole lot of samples in the drum machine... time to start working.

Practicing Agile on Art

2009-04-14T08:08:00.000-07:00

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.

Quality Confusion

2009-04-14T01:30:00.000-07:00

I find the concept of "quality" to be among the more abused components of game developmen and maybe even for artistic expression in general. The problem is that different people consider different things to be quality. The main stances towards quality which I am familiar with are something like this.

Engineering: Quality is when it works technically elegant.

Business: Quality is when it has obvious sellable features.

Art: Quality is making an impression.

Perfection: Quality is meeting established goals.

The more common among ordinary people is the perspective of business quality. People talk about the obvious sellable features when they talk about a product. They often and faulty equate a small number of features as a poor quality product. This flawed reasoning is the core motivator for me writing this post.

To start correcting the problem we have to change a little bit of what describes business quality. We have to replace the word “features” with “advantages”. After we have made this correction I will easily argue the stance that to reach high quality you have to nail all four of these perspectives.

Next problem is that the reasoning above really does not talk about quality the way I consider quality. I would call the above statements for “needs” which are base requirements for reaching ROI with anything. If losing money is desired then compromise on one or more of the perspectives.

Real quality is meeting all of the product needs without the existence of defects.

Quality is not a creation or induced by adding things, rather a result of a well balanced methodology. An arch enemy of quality is the misstake of associating ambition level with quality. This leads to the common problem of people claiming that small simple products are having “low quality” which is a fundamentally flawed argument. Those simple products are, when successful, rather reducing ambition for increasing quality.

Layers of iterative development process

2009-04-07T06:24:00.000-07:00

All the layers in this image contain iterative process, of varying formal structure.

Note that each level also tend to be branched to different territories, at the bottom you have different types of experts or artists producing different types of work often through implicit iteration.

Goals

2009-04-06T00:52:00.000-07:00

Straight from wikipedia: Goal Setting involves establishing specific, measurable and time targeted objectives.

This is a point of setting goals which which appear to be failed by teams that fail at agile development. A goal for a devlopment or I guess any business needs to be formulated in a manner which describes the state of things upon completion of the goal.

Following this principle is sometimes quite hard. Lots of the flak tossed at scrum lately can be aimed at the lack of useful goals.

Setting useful goals takes a whole lot of time and when a whole team is working on the problem together people often start showing signs of stress symptoms from feeling of wasting time. However having bad goals is worse than wasting time.

A reductionist model of humankind

2009-03-29T10:32:00.000-07:00

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

2009-03-29T06:01:00.001-07:00

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

2009-03-21T11:13:00.000-07:00

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

2009-03-15T09:15:00.000-07:00

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

2009-03-15T06:59:00.000-07:00

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

Usability Infrastructure, everything with a cycle time of days and weeks in here
Shoehorn User experience, the things with a cycle time measured in hours
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...

Pull Schedule - everything?

2009-02-27T23:16:00.000-08:00

So its commonly accepted that pull scheduling is efficient, quite a lot more than push scheduling. If we look at it from the information network perspective as I brought up here http://gamesartdesign.blogspot.com/2009/02/productivity-as-information-network.html previously it appears as if there is a general trick to it.

User Value and its derivates pulls development from the team. The derivates of user value is in this case stuff like product vision, strategy, audience, test feedback and such.The whole team process the User Value requests as a unit. Each team member is always ready to have information pulled on request from the team.

To avoid getting interference from management the team is likely to benefit from keeping track of progress towards the User Value derivates. Post it on a wall and update continously so this information dosnt become a burden to deliver.

Limits of art?

2009-02-22T09:13:00.000-08:00

What message is beyond art?

This question is interesting on a general level. I would not directly label myself as an artist, maybe a musician or at least having had an income from writing, recording and engineering music. Everyone who is involved in making music has at least one leg in the artistic aspect of the art form. Even the guy who connects microphones to the recording technology is developing artistic skills. Once you leave the making of music and go to the business of selling music some people quit thinking they are artists, but really they are also involved with delivering the message to an audience, which is of some relevance to the experience of listening to the music.

I would believe the same can be said about movies, books, comics, oral tradition and everything else, and… games.

I can imagine quite well how to use music to convey almost any type of message. The exact meaning will be relatively irrelevant but the topic is up for grabs. The market for music would probably not be interested in paying for an opera about riding the bus, unless it is made by someone who is generally interesting for some other reason than the particular piece of work in question.

The same can be said for games. You can make a game which conveys a message about being a tree, it is not likely that the game will accurately make the player feel like a tree but I am sure a player can be made to identify with a tree. Raph Koster says he really wants games to be able to convey the feeling of being a tree, I don’t see that as very doable. But I do see a game where you pretend to feel like a tree, or maybe get to care about what the feelings you might have as a tree.

Is there a limit to the artist?

Does it require a Mozart to make classical music, or a young male to make a first person shooter? This really becomes more of an interesting topic when you aim at some specific resonance among the audience. I don’t see this as an existing restriction unless you try to impose severe limitations on the details of the production techniques involved.

Forcing Mozart to make a death metal song would probably not be a very good way to use his talent towards meeting a demand among a certain audience. However I am quite sure that Mozart would be able to entice this audience using more of his familiar tools if he put his mind to it. Well, back in the days. The direct problem with the game industry is that most have imposed severe limitations on their production techniques.

In most cases where you aim to remove these limitations you are quite likely to also remove every other chance of success you had. Understanding the abstract principles of making art is limited to relatively few people. This is also not an easily measured skill, its harder to use a theoretical measurement to measure a game artist than it is to use a theoretical test to measure the skills of a musician. Maybe someday this will change, but games will require a heavier effort than what it took to bring music to a level of theoretical measurement of accomplishment. Lucky us the productivity of the world has increased a bit the last 500 years or so, maybe I will see this development happen.

Productivity as information network

2009-02-22T03:53:00.000-08:00

There are some great descriptions of how to achieve productivity around the web. A culled list of things which the more enlightened models seem to agree on looks like this:

Measure productivity in market value change, often derived from user value.
Maintain a special interest in anything you did which has negative market value so you can remove it.
Avoid anything which reduces your efficiency towards creating value in the future.

This list can be described with other words:

Test the production output before attaching it to the product.
Handle all kinds of defects consciously, from bugs to bad ideas and everything in between. Lean says; stop the line quality.
Never sacrifice product integrity to increase productivity.

To achieve positive productivity and develop market value there are several techniques in the production toolbox which probably are more or less familiar. There are lots of bad or outdated techniques which have been tested and found to be bad such as working over time, measuring productivity in code or features and developing towards a rigid specification. These bad ideas are not that interesting, but it happens that even a modern team fall in their traps.

The interesting things happen on the good idea side.

Team size limits

Team size around 7 members. If this is because our brains are good at chunking the function of each team member, because biological networks get saturated with communication if nodes recieve information from more than 7 sources, if it is for some other reason such as creating a temporary family or that this number is about where you can find all relevant disciplines for creating user value I don’t know. The good thing is that it (the reasons) does not really matter.

Responsibility distribution

The team, not a boss, determines how to create value within given constraints. Scrum does this partially by defining goals which the team convert into tasks aimed at realizing the value of a time box. Lean appears to approach this through something I recall as “on demand production” via pull scheduling the development when the market demands it.

Understanding of User Needs

The whole team understands what the product aims to be and how it aims to meet a demand. This often shows up as a transparent product vision and the methods used for testing user value where the whole team is involved with understanding the needs and problems of real users.

The whole business as a biological network

I will now make a very poorly grounded statement:
- The whole business is a biological network with nodes made out of humans.

This network exchange information about what needs to be done to satisfy a market with the goal to make a profit in money or sometimes a less direct unit such as “cred” or brand awareness.

Biological networks are relatively well documented on a scientific level. I am not well informed on the subject but there are some properties of biological networks which even I understand and which may be interesting when optimizing information flow towards meeting market value.

Information degrades every time it passes a node.

The network specializes towards dealing with certain types of information. Common specializations are to improve short range communication at the cost of gimping long range communication. We cannot, for example, well understand the emotional stated a source node which is at some distance and emotions carry a lot of information.

The cost of relaying information across the network affects the amount of information relayed.

If I understand this correctly we humans have learned that communicating information across several nodes is close to impossible. We end up either limiting the message to something insignificantly small and useless or we end up saturating the network with protocols which becomes needed for the information to survive its journey through the network. Btw, such measures does not work very often. When implemented they provide a structure for social mobility and people create links when communication is needed.

Node failure is random

A node which gets swarmed with information will fail to operate properly. This causes some hesitation towards accepting information among hub nodes. The practical effect is the same as above, the network limit itself to avoid non-random node failure.

It looks like the good ideas of productivity are natural adaptations towards optimizing the biological network.

The product vision is integrated with the team.
Defects are seen by the whole team.
The actual user value is measured directly by every team member.
The decisions on how to react on feedback are determined by the team.

Relevant information for the team is at most 1 node distant.

Constraints are negotiated between the team and the client.
End users deliver feedback directly to the team.

The interesting part here is that I don’t see much other organizational structures having taken on this approach towards optimization. They probably have a slower darwinistic evolution cycle, while software development productions often mutate several times per year. Lots of large organizations appear to try strong arming their biological networks to work as digital networks and actually go ahead with implementing communication protocol rather than reorganize the network to fit naturally with our human senses. (Hello email rules and conventions.)

The infrastructure problem

If your user value is heavily dependent on large infrastructure, such as a nuclear plant and a power grid I would not guess if this type of optimization scales up. It would appear reasonable to think that you can scale the production of such a large system efficiently by optimizing the information network to fit the properties of the biological network which build these kinds of things. You will probably get a few layers of abstraction between the development team and the actual user value, defects and future velocity.

This little post should have had some nice images with it. Maybe I'll update it someday if it still makes sence in the future.

User Value measuring is art, craft or science

2009-02-18T09:40:00.001-08:00

Measuring user ualue can be considered to be more or less scientific. There are arguments for the scientific approach, but there are also arguments for an artistic approach especially when the values you need to measure are subjective.

There are some parts of user value you definately can measure with a scientific methodology, if you can do so it makes sense to use the available scientific methods. Most common entertainment productions will usually not have this ability readily available. Using an artistic approach towards measuring user value would in my book be the last resort, and whenever going down this route expect a lot of failures.

>skips past what a craft is.

The measuring of user value appears to best fit as a craft.

User Value, by looking at users

2009-02-15T07:59:00.001-08:00

With a definition of design fully focused on creating user value it appears important to have a decent understanding of what user value is. The most important aspect is that it needs to be something you can measure.

The first and most useful method comes through looking at and listening to users, or testers who reasonably well represent users. This method is a bit ugly because it will not give you much hard data. The lack of hard data will inhibit the ability to communicate the result to anyone without insight into the actual test itself. People you need to communicate the result with will have to trust your interpretation of the behavior exhibited by the user during the test. You are already fully loaded with test analysis hardware for this particular type of test, use it. We’ll look at methods for scaling up this type of test later but for now think small.

You can start measuring the value of any design as soon as you can find a test subject. A good start may be to talk about the idea with someone. This is extremely cheap, but the test output is very unreliable. However if your design gets shot down by such a primitive test then go back and start over. Or adjust accordingly, possibly by replacing the test subject with another tester.

If your cheapest test is successful it might be time to invest a bit of effort into the design process. What kind of investment you will benefit from depends a lot on the idea itself and your own skills. At this point I tend to find myself needing to develop my own understanding of the idea which is getting developed so I sketch up a series of takes on the idea. If the idea is associated with a game type of product or if the idea is the whole game itself I tend to find a primitive sketch of interface components to be a decent start. This helps me get a better grip on what actions the user should be taking. The end result does not inherit any particular components from this simple sketch, but it gives me a better fundament for testing the idea on more test users.

If the idea survives this far and if it is simple enough it is time for a functional prototype, some paper prototyping is a good idea to start with. If the idea has a close relative implemented in an existing product you can look at altering that product to fit the idea or if you got plenty of time and access to the right skills develop a prototype in code. However most ideas are critically dependant on the value of other ideas, after you got the first idea to the point of where you can invest some time in it you are likely better off measuring the value of the other ideas which it depends on. Take your time and go through each idea until you have collected a firm picture of all the relevant ideas and their individual value before promising any end result to anyone.

Keep in mind that ideas are cheap, plentiful and most often bad. Avoid promising that an idea has value until after you have verified its value against a decent representative of users. By continously measuring the things you do against test users you increase your chances of designing successfully. When you fail to get a successful test from an effort you have produced waste.

Approaching Design as topic

2009-02-15T05:26:00.000-08:00

From what I can find there is no common description of what design is. There are quite many different definitions around the web and several additional ones if you look through books on the subject.

Let’s have a look at the better candidates of what I found by googling the topic.

As a verb one definition I like is “to plan and make (something) artistically”. As a noun there are other good ones such as “an ornamental pattern” or “the arrangement or features of an artistic or decorative work”. These speak about the artistic nature of the word which is highly relevant.

Another way to look at is through formal definitions. A good one by Dick Buchanan who is a professor at Carnegie Mellon University School of Design says:

"Design is the human power to conceive, plan, and realize products that serve human beings in the accomplishment of any individual or collective purpose."

This is nice. It takes into consideration the human component in the creative process and in the perspective of the end user. It also, the way I read it, takes into consideration the realities of turning an idea into a product. This is a useful insight but I rarely find it to be properly attached to design in particular and more associated with product or business development in general, where design is of relevance but not the primary responsibility. I can't claim to understand what the last third of the definition really means, “in the accomplishment of any individual or collective purpose”. Maybe it exists to exclude that which has no purpose. Maybe I should take some time and study the topic in question rather than ramble on about it.

Despite the fact that I like this definition by Dick Buchanan as well as some descriptions of the meaning of the word design I don’t find them useful to serve the purpose of approaching the everyday problems of designing products.

Instead of spending a lot of time to find a definition which works for me I’ll make my own. I want a definition which is useful when describing what I do. Which also brings out the kind of goals a design effort aims to meet. It would be nice if the definition also is easily understood by normal people. A definition made for specialists may be helpful when digging deep into the problem but a definition suitable to the topics I intend to dig at with this blog needs to be relatively simple.

My definition of design becomes this:

Design is a process that realize the value of an idea.

Is this enough, or is it too wide? A potential point of failure for this definition is the concept of “user value”. This definition becomes all about user value, but it excludes the conception of the idea. Unless the idea is to come up with a valuable idea in which case we can apply the design process to develop the idea in itself, messing around with paradox is not a hobby of mine so I’ll quit here.

If I am lucky someone will come along and shoot this definition down before I get horribly entangled with it. Next topic might take a closer look at user value in particular.

Blogostart

2009-02-15T03:50:00.000-08:00

So this blog is started. I don’t have much ambition with it but the idea is to collect various thoughts about designing games in one place. Alright, this is not a very novel idea and there are a lot of great game design blogs out there. I don’t expect to add any value to the game design blogosphere with this effort. All I expect is to collect information for myself.

If you happen to come across this blog feel welcome to make comments.