Monday, September 28, 2009

Hypothesis - Bartle types as network agents

About a year ago I took the time to read through this 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.

Saturday, September 26, 2009

Feedback pipelines

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

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

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

Dangers of iterative production techniques, part 1 of n

As I mentioned in a previous post 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. ^^

Friday, September 18, 2009

How. A sub-atomic structure

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

How Things Happen

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

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

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

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

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

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

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

First Crackle – Peak Crackle – Last Crackle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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