Last week I talked about how mid-core games aren’t the answer to consumer engagement issues.  This week I want to take a closer look at some of the underlying design problems with casual and hardcore thinking, and how we might better address them.

It’s been several years since I first talked about games and attention.  At the time, I noted that games compete for our attention with other games, other media, and interruptions from friends, family and work.  Despite all the advances in friction reduction over the past decade, games are hard pressed to thrive — nevermind get noticed — in this noisy media environment.

Looking ahead, the trendline is not positive.  Content creation costs keep dropping, so the amount of content available keeps rising.  Our choices are unlimited but our time is not.

Traditional solutions to the attention problem fall into two buckets:

• Reduce friction (a.k.a. the casual solution)
• Add depth (a.k.a. the hardcore solution)

In general, good casual design affects a player’s willingness to play, while good hardcore design affects their desire to play.

The Casual Solution

The friction reduction method requires games to:

• Have few barriers to entry
• Be commitment friendly
• Be attention span agnostic
• Have a short build-try-fail loop

That’s all good.  However, while these characteristics reduce friction and increase a player’s willingness to play, they don’t actually generate a desire to play (or to keep playing).  In an effort to meet the requirements above and make the game more accessible, most designers simplify the game’s mechanics and the way those mechanics combine, effectively reducing the play dynamics as well (in the MDA sense).  The result is a shallow product with a small possibility space and little long term retention.

Casual games succeed by demanding less from the consumer — they don’t ask you to sacrifice attention you might prefer to devote to other things, complementing rather than competing with other media.  The best of these products tend to have large audiences with low unit economics and short user life cycles.

The Hardcore Solution

The depth approach, on the other hand, means the game:

• Has extensive and varied play dynamics
• Has a lot of content to consume
• Gives the player a reason to make a deep personal investment (often through persistence, identity and relationships).

Again, a good list.  Games of this type tend to create a strong desire to play.  Unfortunately, they also erect a lot of barriers to someone’s willingness to play.  To create a wide range of play dynamics, many designers simply pile on the game mechanics (i.e. they keep layering on the rules and systems).  That’s a lot for someone to learn and then remember from session to session, and with a lot of mechanics to comprehend, 100% focus is required.  The only players willing to do that are the few that will make a large personal investment in the product.   The result is a deep product with a large possibility space and great long term retention, but it bounces most consumers at the start.

Hardcore products succeed by being more compelling than other media — they ask for your undivided attention and tell you it’s better spent on them than competing options.  High quality hardcore products tend to have small audiences with high unit economics and long user life cycles.

Hardcore + Casual

There’s nothing inherent to these two approaches that makes them incompatible, but you can see how solving for one can easily lead to problems with the other (it doesn’t help that, as an industry, we’ve set up a false dichotomy that places casual and hardcore products at opposite ends of the same spectrum;  mid-core is the latest iteration along these lines).

Much of the problem starts with the game’s mechanics, where most casual games have simple mechanics and simple dynamics, and most hardcore games have complex mechanics and complex dynamics.  There’s a reason for that:  they’re much easier to design and balance (simple dynamics imply a small possibility space, which presents fewer outcomes to balance;  complex mechanics make it easier to isolate systems for independent tuning, particularly when dealing with the large possibility spaces associated with complex dynamics).

What we really want are games with simple mechanics and complex dynamics, because simple mechanics are easy to learn and remember, while complex dynamics are deep and engaging.  How we do that is the subject of next week’s post.

A few weeks ago I attended Chris Crawford’s interactive storytelling gathering in southern Oregon.  It was a small group, less than a dozen, but the composition was fairly diverse and included game designers, industry execs, interactive fiction authors, academics, writers and even one venture capitalist.

There’s a lot of debate about what interactive storytelling is and how to solve the “interactive storytelling problem”.  I think this is a bit misguided as it tends to treat interactive storytelling as a singular technological hurdle to be overcome (like 3D rendering).   But interactive storytelling isn’t a problem or a technology, it’s a category, one that will likely have multiple viable product types that each have their own set of challenges to be solved.

I base this on the simple observation that if you’re going to create a category called “interactive storytelling”, there must also be a category of everything else called “non-interactive storytelling” which includes such wide ranging possibilities as “novels”, “music”, “movies”, “comics”, “poetry” and so forth.  While it doesn’t logically follow that interactive storytelling must likewise have more than one form of expression, it does seem more than probable given the diverse range of methods for non-interactive storytelling and the really broad macro level categorization (interactive vs. non-interactive, neither of which is actually descriptive of what someone might experience).

In other words, I think it’s a mistake to think of interactive storytelling as one more means to tell a story the way a novel or movie does.  It’s really a massive grouping of expressive forms, some of which may be mirrors from the non-interactive side of the fence (e.g. “interactive novels”) and some of which may be new things entirely.

This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  The start of the series can be found here, and last week’s post on Knockabout’s demise can be found here.

I wouldn’t feel too sorry for Knockabout, by the way.  We shut the company down cleanly, without debt.  Everyone found work quickly.  Our publishing partners still talk fondly of the titles we created for them.  And something odd happened after we closed the doors.

Early in Knockabout’s existence we did a deal with Motorola to OEM our pinball game on some of their handsets.   It was a colossal waste of time and money that we never thought we’d recoup (our max upside projection was about 10k– we did it mostly for the relationship).  We’d only ever seen one royalty report, and it was so small as to be inconsequential.  We had written the whole thing off.

Except that, three months after Knockabout’s end, we started getting checks from Motorola.  Checks that were large enough that we could have saved the business if we still had staff or an office or anything.  But we didn’t.  So we distributed the money to the shareholders.  We had no way to project how much would come in or for how long, but every quarter a new statement and royalty check would arrive in the mail.  For two years, money came in and went right back out.

On top of all that we got inquiries from both Microsoft and Sony about the pinball game, and ultimately licensed it to both of them.

Was all that enough to make up for the cash we sunk into the business?  No.  But it did soften the blow substantially.  Monty and I often joke that we should have made pinball and immediately shut the company down.  The real lesson, perhaps, is that we should have put more faith in our own IP and focused on that with a smaller staff.  We didn’t need to build the shop like our past businesses — a few guys would have been sufficient to achieve sustainability and from there we could have scaled up as appropriate.

The larger observation is that speed isn’t always as critical as it appears.  Any time you enter a new, emerging space, there’s a tendency to view the window of opportunity as small.   You have to move fast, grow quickly, establish a foothold before the value chain ossifies and fills up with established players.  To some extent that’s true.  But I think there may be a case for being patient and growing organically, not worrying about the timeline and just adapting as you go.  If you’re small, really small, you’re actually pretty nimble — large tectonic shifts in the space don’t kill you.

That wraps up the series on Knockabout Games.  The entire sequence is below:

Before The Start

Product Strategy

Business Strategy

Funding, Equity And Staffing

What Actually Happened

Where We Failed

Knockabout’s Demise

An Epilogue

This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  The start of the series can be found here, and last week’s post on how Knockabout’s strategy failed can be found here.

In the end, Knockabout got caught in the typical developer trap, going from project to project, always in danger of missing payroll should a milestone slip.   We reached a point where we couldn’t sustain the business and had to shut it down.  Rather than conceal this from our staff and business partners til the last possible moment, we took a gamble on a better (and I would argue more ethical) approach:

• When we first saw things starting to crack, we informed everyone that we were at risk.  We didn’t know if we were going to have to close our doors, but we didn’t want anyone to be caught by surprise.  This was risky– our staff could start jumping ship and our publishers could cancel projects.  But none of them did.  We talked about options and scenarios, but mostly we worked hard to keep revenue flowing.
• A month later we revisited the situation and made the decision to wrap up the business (for reasons I’ll outline shortly).  Again, we told everyone.  Because we had titles under development, we told our publishers we would do our best to complete them, but it would likely cost more than they had budgeted.  All but one decided to continue.  We then asked our staff to stay on until their respective titles were done.  That meant as much as two more months of work.  We also said we’d help them find work if they needed it, and we’d give them severance if they stayed to the end.  All but two stuck it out.  I’d like to think being open and honest with everyone — publishers and our developers — compelled them to stick with us, but I can’t say for sure.

Not everyone understood.  One publisher initially agreed, but was baffled when I asked for more money to complete their project.  He told me I shouldn’t pay my staff unless they meet their milestones.  I explained that every one of my engineers already had jobs lined up with better salaries than what I was paying them.  They were there out of loyalty — he was welcome to not pay, but the project wasn’t going to finish.

Why did we close our doors?  Why not raise money, borrow from the bank, or scale back operations?  That may have been an option.  Indeed, we had deals on the table for another round of products.  But they all looked like the last round of projects, which meant we’d have a hard time surviving unless we were perfect on delivery (and we clearly didn’t have a track record to support achieving that).

We also looked ahead and didn’t see an exit.  Our strategy didn’t produce value in the space the way it had in the pc and console sectors.  And we didn’t have the capital — or the time to raise capital — to change the nature of our business.  So we moved on.

Many of our colleagues faulted the space — it was hard on developers, market conditions were tough, very few survived.  But if you’re running a business you can’t ever point to external factors.  Every problem is ultimately a problem of execution.  If you don’t see the changes happening around you, or you fail to adapt, the only one you can blame is yourself.

Next time:  An epilogue of sorts.

This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  You can find all eight parts of the series below:

Before The Start (this post)

Product Strategy

Business Strategy

Funding, Equity And Staffing

What Actually Happened

Where We Failed

Knockabout’s Demise

An Epilogue

Before The Start:  Why Mobile?

In the fall of 2002 I sat down with longtime friend and business collaborator Monty Kerr to talk about a new venture.  I already had two game startups under my belt, and I’d just come off a one year break (most of which was spent living on a catamaran).  I was recharged and ready to dive into something new.

We didn’t have any idea at that point what kind of games we wanted to make, but we had two requirements:  it had to be in a relatively new space, and it had to be games.  So I got on a plane and made a three city tour of the west coast — Seattle, San Francisco, Los Angeles — to chat with friends and colleagues about the state of the industry and where things were headed (we also spent some time with folks here in Austin).

There were three sectors we were considering:  casual downloadable, mobile, and boutique MMOs.  All three were fairly new and unexplored at the time, but each looked ready to explode (indeed, in hindsight they all did).  We ultimately chose mobile almost by reduction:

• Boutique MMOs were much more costly than the other two ($500k – $1m a pop) and would require raising capital.
• Casual was exciting, but it felt like we could do this sort of startup any time — shareware games had been around almost 15 years at that point and it didn’t seem like anything was going to make entry into this space more difficult in the future (although that turned out to be wrong).
• Mobile had a small window that had just opened up.  If we wanted to try it, we had to go now.

The clincher was actually a conversation I had with Mitch Lasky, then CEO of JAMDAT (which later became EA Mobile).  Mitch gave me a thorough rundown of the value chain and how money flowed through it, and talked about the various challenges of building games for handsets.  And he shared some data.  What was most interesting, though, was that the first mainstream color handset had just launched (the Motorola T720), and people were suddenly starting to buy games.  Real money was flowing.

Building The Plan

I spent the next two months diving into all manner of research about mobile games:  carriers, publishers, developers, technology providers, handset makers, and so forth.  The way I like to do this is to write an operational plan, of sorts.  The goal is to create a document that covers how the space works and how we’re going to build a business that can thrive in it.  But it’s not as organized as a business plan and isn’t trying to pitch or sell anyone on the concept.  It doesn’t even need to be complete.  The purpose is to identify all the moving parts and look for opportunities on which to build a strategy;  the act of writing it down forces one to see everything and articulate that strategy clearly.

Knockabout’s plan was about 200 pages and unfinished.  And it was never looked at again after we launched.  That wasn’t because parts of it became slowly invalid over time; rather, it was because the process of putting it down on paper had effectively committed it to memory.  We knew it inside and out.

There were four basic parts to our strategy:  product, business, funding and development.  Next time I’ll dig into our product strategy.