This is part two of the four part series on value creation in games. Part 1: Value Creation in Games; Part 2:Engagement and Content Volume; Part 3:Engagement and Personalization; Part 4: The Game Engagement Landscape.

In my last post I talked about how value creation in games falls into two large buckets:  access and engagement.  This time I want to focus on the engagement portion, and more specifically, how we increase it.  I’ll give the usual disclaimer about how there’s many ways to slice this, but in my view there are two ways to increase engagement:

• Increase the volume of content
• Increase the personal meaning of content

Increasing the volume of content – the sheer amount of it that can be consumed – increases the possibility space and therefore the likelihood that the consumer will find something that engages them.  That may evolve over time – i.e. initial bits of content may grow dull but, due to the large amount available, new bits are available that may extend interest.

Increasing personalization reduces the possibility space in a way that’s meaningful to the individual player.  It does not reduce the possibility space for the game’s audience as a whole.  Think of it as the percentage of interactions an individual has in the game (relative to the total interactions they have) that are interesting to them.  What’s interesting to one user may not be interesting to another, of course.

In general we use three methods to increase the volume of content:

• Author a lot
• Re-use content
• Emergence

Authoring can come from developers or consumers.  In the hands of skilled developers the content is often extremely well-made and balanced, and difficult to pattern match.  But it runs out quickly, a lot goes unused, it doesn’t adapt well to varied player interests, and it’s expensive and economically hard to sustain except at very high sales volumes.

Letting consumers author the content (i.e. UGC, or what I like to call the infinite monkeys solution) generates an almost unlimited supply and the cost of creation is very cheap.  But it has its own challenges, including a terrible signal-to-noise ratio, difficulty maintaining cohesion and consistency with the overall product, and a dependency on some level of creative or technical expertise to generate interesting content (the burden of creation, at least for some portion of the audience).

Another alternative is to simply re-use content.  Far less expensive than developer authoring, it’s also relatively easy to balance.  For example, we might use meta-structures like high scores, scenarios or levels, difficulty settings, quests and so forth to package what is essentially the same core game loop in a larger play mechanic.  That can generate more long term interest and extend play, but it doesn’t actually solve the pattern matching problem since the core game loop remains the same (potentially leading to boredom fairly quickly).  Procedural content generation is another variation on this theme but tends to produce undifferentiated content.

That leads us to emergence.  In emergent play, core components are recombined to produce novel new play dynamics (in the MDA sense).  In the mid-90s, the colleagues at my first company often mocked my constant preaching about “complex combinations of simple, distinct elements”.  Emergence might occur at the systems level, or it might come from adding other people to the game (but not necessarily friends).  As with simply re-using content, emergence is inexpensive.  And it’s hard to pattern match, making it difficult for players to optimize play and get bored.  But it’s terribly difficult to balance.

Next time I’ll talk about the personalization side.

This is part one of the four part series on value creation in games. Part 1: Value Creation in Games; Part 2:Engagement and Content Volume; Part 3:Engagement and Personalization; Part 4: The Game Engagement Landscape.

I’ve been stewing a lot lately on how we create value in the games industry.  Given that there’s no explicit utility case to be made for our products, everything we do appears to fall into two buckets:

• Increasing Access
• Increasing Engagement

Increasing access is about friction reduction.  The electronic game value chain is filled with friction – everything from problems of discovery and delivery of product to basic commerce issues (payment types, price points and whatnot).  Even existence has friction when you consider the barriers to creation:  technical expertise, difficult of the platform, access to tools and development resources, and so forth.  Within the game itself, simply the demands of play – learning curve, short and long term time commitments – create friction for the user.

Reducing friction can often enable otherwise average titles to succeed.  A great example of this was consumer reaction to mobile games before the iPhone came along (2002 – 2006).  Multiple studies (from the tail end of that era) showed consumers reaching for their phones to play games in their homes despite the presence of superior products on consoles, handhelds and computers.

On the other hand, increasing engagement is about creating desire.  No matter how much friction we eliminate from the system, there still needs to be something on the other end that engages a consumer’s attention and pulls them to the product.  In fact, just as low friction can enable weakly engaging products, strong engagement can overcome absolutely ludicrous frictions (witness Minecraft).  It’s stating the obvious, but as long as engagement exceeds friction, you’ve got your customer.

Both methods of value creation are key to a successful product, but it’s important to understand the difference.  Early entrants to a new market segment might succeed by making mediocre products highly accessible, only to fail in the long haul if they don’t know how to increase the engagement side (or more telling, recognize the importance of doing so).

There are only two parts of the content value chain you cannot remove:  the content creator and content consumer.  That’s a paraphrase of an unknown journalist from the June 5, 2008 issue of the Economist who said:

“Publishing has only two indispensable participants:  authors and readers.  As with music, any technology that brings these two groups closer makes the whole industry more efficient– but hurts those who benefit from the distance between them.”

So if you want to play in the space between, you need to provide some value in reducing one or more of the following four barriers:

• Existence.  How difficult is it to actually create the product?  Am I coding in assembly or can I just use Flash?
• Discovery.  How does a consumer find out about the product?  Banner ads, google keywords or the social graph?
• Delivery.  How does the consumer get the product?  Do I have to drive down to the mall or can I just download it?
• Commercialization.  How does the content creator monetize the product?  Do I have to pay $20 or can I try it for free and pay for stuff in smaller chunks later?

We use talent and money to overcome these barriers.  In recent years, there’s been a tremendous decline across the board in all of them.  Modern development tools and increased hardware power have put a huge dent in the existence barrier.  Delivery friction is virtually zero given modern bandwidth costs.   Commercialization is almost plug-n-play.  Even discovery has been dramatically improved with the advent of Facebook’s viral channels.

As these barriers drop, a number of interesting things happen:

• Lower barriers mean lower capital requirements to bring a product to fruition.
• Lower capital requirements mean the volume of product that makes it over these hurdles increases substantially.
• More product means more competition, driving down prices.
• More product also means more niche products that address previously underserved interests.  These products can charge a premium over mainstream content.
• The closer these value chain barriers get to zero, the more they commoditize and become hyper-efficient.
• The more they commoditize, the more the costs start to backload, further reducing capital requirements for the content creator.
• As capital requirements drop, the sources of capital change and their influence over the content creation process falls.

There’s a bit of a feedback loop here.  If more products make it over the transom the discovery barrier goes up, for example.  And when a company has an effective monopoly over one solution (e.g. Facebook’s discovery advantage) they can intentionally raise barriers in other parts of the value chain, so long as the net gain is still positive for content creators.

Early in 2009, Monty Kerr and I went out to GDC to do a little research.  We’d both built multiple game development startups, often for new media or new channels (e.g. mobile phones in 2002 or Windows in 1994).  We’d been watching Facebook expand as a platform and wanted to pursue the space, but we hadn’t found an angle we thought was compelling.  Were we too late?  Was the ocean too red?

By the time the show was over, we had what we thought was a key weakness in the social ecosystem and a way to address it.

First, a clarification of terms.  Social network and social graph have been used almost interchangeably the past few years, and not without some confusion.  It doesn’t help that Facebook and other sites are called social networks in the online service sense, which is distinct from the actual social networks they may utilize.  For the purposes of this post, I’ll stick with the current Wikipedia definition of social network:

“A social network is a social structure made up of individuals (or organizations) called “nodes”, which are tied (connected) by one or more specific types of interdependency, such as friendship, kinship, common interest, financial exchange, dislike, sexual relationships, or relationships of beliefs, knowledge or prestige.”

Put more simply, it’s a set of relationships we have with others based on a specific, shared context.   We are each part of many different social networks based on various contexts, such as family, classmates, a book club, or a sport we play.  Some of them overlap.   And while much of the time we spend with these connections may have nothing to do with the what brought us together, that context is the reason for the network’s existence and is the always available fallback for any future interaction (i.e. if we cannot find anything else to talk about we can always talk about the one thing that clearly interests us both).*

A social network service, like Facebook, is not a social network.  More important, it doesn’t provide the context to create a social network.  All a social network service does is improve access to pre-existing social networks already developed by the user and help new services (like games) seed their products with users.  That’s tremendously valuable, but makes all added interaction secondary instead of primary.

Why is that a problem?  Because secondary interaction is wholly dependent on a pre-existing (primary) social network.  If you stop playing a game, you don’t lose contact with the individuals you were playing with – you already had an established bond with them beforehand.  The game has a tenuous hold on you because it’s not the reason for your friendship with those you play with.

The same could be said about Facebook as a whole:  if it went away tomorrow, all your social networks would continue to exist despite greater friction of communication within them.  In other words:  Facebook doesn’t own your social networks.

Another problem with being dependent on pre-existing social networks is that the number of users you can play with is artificially capped.  Only a small subset of friends from your pre-existing social networks will have any interest in the same game as you.  That means fewer people validating your interest, fewer people to share it with, and fewer reasons to keep playing.  The result:  less engagement and poor retention.

A game, however, is a context just like any other shared interest.  A new social network can be built for the user based on players they come to know while playing.  A game-centric social network has several advantages:

• It’s primary in the user’s mind.  If the game goes away, so does their connection to everyone they know because of it.
• It’s self-reinforcing.  The more people I know playing, the greater the validation that what I’m doing is worthwhile.
• It’s uncapped.  There’s no limit to the number of friends I can play with (other than natural limits, in the Dunbar sense).
• It’s platform independent.  Because the game is the primary context, any platform it resides on – a web portal, a social network service, a hardware device – has less power over the game’s audience and, by extension, the game itself.  If the platform goes away, or the developer would like to leave the platform, being the primary context for a user’s social network goes a long way towards moving them to other platforms.

A game-centric social network helps engage and retain users for much longer periods of time.  I’m not talking about gains measured in weeks or months but years and decades.  Think about all those pre-existing social networks you have – those are based around interests you’re likely going to be involved with for the rest of your life.  That’s why a game-centric social network is so much more powerful than sitting on top of a pre-existing one.

Just to clarify again, because the terms are annoyingly close:  a game-centric social network is not a game-centric social network service (building such a service would make the service primary not the games on it, although that would still be one up on Facebook in terms of owning their audience).**

We raised some seed capital against this concept in the fall of 2009.  Since we rolled the business up into a larger company shortly thereafter I can’t say whether we were right or wrong, but in almost three years I’ve yet to see anyone really push this model.  To me that still smells like an opportunity, particularly as increasing engagement has become more important for those still building games for Facebook’s red ocean.

Footnotes:

*A social graph, by contrast, is really just a tool for mapping a social network. You could, to some extent, use this interchangeably with social network, except that social graph has actually come to mean the entire mapping of your relationships within a social network service.  So I’ll yield to the more popular interpretation (which is interesting in a business sense but not terribly useful in understanding the reason for people’s relationships to each other).

**We also now have interest graphs, which are related to but not the same thing as a game-centric social network.

I find it odd that traditional game developers take a dim view of those who work on smaller platforms like mobile, handhelds and the web.  These games do tend to be simpler on the whole than their console and pc counterparts, and they lack the same level of production values.  Therefore, the argument goes, making a small game for a limited platform does not afford the developer the same quality job experience as working on a mainstream title.

I’m going to make the case it’s just the opposite.

I used to do a fair bit of sailing.  I even lived on a catamaran for about nine months.  One question that sometimes came up, if you needed crew for a longer trip, was what sort of experience you’d look for.  Sure, some open ocean experience was nice, and a guy who’d sailed everything from Olympic Solings to 65′ Swans was great.  But given a choice between someone with mostly big boat experience vs. someone with mostly small boat experience, which would be better?

Small boats are light and nimble.  They turn on a dime.  But they have fewer conveniences and tools to make them easier to sail.  They are extremely susceptible to the smallest variances in the water and wind, and every little change the crew makes — trim the sails, point slightly higher, whatever — can be felt instantly on a small boat.

Big boats are large and cumbersome.  They move and respond slowly.  As a result, they conceal many of the little changes going on around you.  If you haven’t already acquired a feel for the environment and how a boat behaves in it from sailing smaller vessels, the mistakes you make will be harder to recognize and resolve.

You can see where I’m headed with this.  Consoles and PCs have become large, bloated systems.  They have so many resources available that developers are spoiled.    Yes, more resources enable grander games and new play styles.  But there are so few limitations that developers don’t gain the necessary experience for recognizing and dealing with many problems that do arise.

Developers of mobile, handheld and web games are far more constrained.  Every little detail of these platforms matters, and resources are limited.   When we were making mobile games six years ago, we were trying to squeeze full NFL teams, rosters and playbooks onto devices with 100k-400k of RAM, 1 inch screens, keypads with 200ms latency to the OS, buggy JVMs, untested firmware updates,  and absent documentation.  Uphill in the snow both ways.

It wasn’t Madden, but it was far more challenging to produce a quality, fun experience on, say, a Motorola T720 than a PS3.  And the project’s developers learned far more about the fundamentals of game development because they were constantly made aware of, and forced to deal with, the limitations of the platform.