In this final post on emergence in games, I want to talk about how emergence impacts the business model.

Discovery

Emergent games are inherently social.  The more emergent a title is, the higher the volume of novel content generated by the players:  there are more surprises, more varied progress, and more opportunities for self expression.  As a result, there’s not only more to share, but more that players want to share.

Just look at The Sims:  that product has more shared content than almost any other on the planet despite being single player and lacking built in viral hooks.  Or Minecraft, a game with no marketing budget and a ridiculous amount of commerce and distribution friction.  Giving players interesting things to share — and by interesting I mean things that appeal to non-players — dramatically increases the native viral coefficient for the product and reduces the cost of discovery.

Player Life Expectancy

In previous posts I’ve noted that emergence increases the possibility space for players, which in turn increases their engagement (by reducing the pattern matching problem and increasing the likelihood of finding something interesting to play).  Greater engagement increases player life expectancy, and players who play longer are more likely to monetize.  The data Kongregate has data been sharing the last few years is particularly compelling on this point.

Development Expense

Launching a live service-based product puts you on the content creation treadmill:  you’re in a race with your players to author content faster than they can consume it.  That’s a very expensive proposition for most games if they want to maintain player engagement (it’s not enough to re-skin content or re-purpose mechanics since players will have already pattern matched the play dynamics).

In an emergent game every tiny bit of new content combines with all the old content, refreshing it and exploding the possibility space all over again.  Balance issues aside, both initial and ongoing content creation costs are small and manageable.

The Business of Play

So emergence lets us use the underlying mechanics of the game itself to drive discovery, increase player life expectancy, and reduce development expense.  That’s a much better approach to long term sustainability than optimizing LTV > CPA and trying to re-capture players in another game when they churn out.  In fact, emergence allows us to re-think core assumptions about how we make games.

Our industry is in the business of selling experiences through play.  Traditional game companies make products with a finite life, and they offer players more play by creating new products.  This approach comes with some inherent problems:

• A short product life cycle means the threshold for success is high.  You need a large audience to return enough revenue to cover expenses, which in turn drives up customer acquisition costs.
• It’s very difficult to find this level of repeat success, so companies use portfolio strategies to offset risk.  This raises the success mark even higher, since now a few hits have to cover a bunch of duds.
• Milking the hits you do find can help, but sequels only take you so far (see Eidos and Tomb Raider as one of many examples).  These product lines get tired over time, due in part to the small possibility space that offers little in the way of new play.

This is what we call a hit-driven business, because if you fail to keep making hits, you die.

With emergence, you offer players more play in the same product.  There is more play in one emergent game than in 100 traditional games.  I’m being arbitrary with that ratio, but my point is that the possibility space is so large players never run out of interesting things to do.   As a result:

• These games last forever.  A long product life cycle requires a smaller audience to generate the same return, thereby reducing customer acquisition costs and making less competitive niche genres viable.
• With a long product life and a large possibility space, you have a lot of flexibility to adapt your product.  You take multiple shots on goal with one game, not many.  That’s less expensive than building new products until one hits.
• Games of this type stay fresh for a very long time — there’s less risk of player attrition due to product exhaustion, and there’s no need for sequels.

You have to re-prioritize many of the metrics we use for evaluating success if you’re going to build products this way, but if you’re willing to take the long view emergence can get you out of the high risk hits business and into a safer, more sustainable model for making games.

The entire series on emergence can be found here:

Games Have An Attention Problem
Attention and Emergence
Emergence and the Build-Try-Fail Loop
Key Challenges Creating Emergent Games
How Emergence Changes The Business Model

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”.  The start of the series can be found here, and last week’s post on how Knockabout’s plan played out can be found here.

So some of the things we did worked well.  It didn’t play out perfectly though.  A number of problems presented themselves:

• Our costs rose with each round of titles too.  Not as much as the funding, but it was a couple years before we finally closed the gap.

• We chose to emphasize quality over everything else.  We had a limited number of resources, so that meant delivery date was not #1 (we would rather slip than be less than great).  I had a theory that, assuming you have the talent to deliver, the difference between a good title and great title in the traditional game space was perhaps 2x in development cost.  But it was 5x in sales, and those sales would cure all sins.   Except in mobile it wasn’t 5x, it was more like 1.2x, which doesn’t justify the development math.  We were making licensed sports titles for the #1 publisher in the space and garnering the top review scores.  It didn’t matter.  Consumers had trouble differentiating titles prior to purchase (14 characters for your game’s title, and no screenshot or other information), and didn’t seem to value them very differently beyond that (not enough for word of mouth to take off).  The COO for one of the major mobile publishers told me flat out that he’d rather have two mediocre titles for the same budget as one great title.

• We were slow.  This turned out to be Knockabout’s achilles heel.  Yes, we sacrificed time for quality.  But it went beyond that.  We couldn’t hit a date to save our lives.  I don’t have a good explanation for that.  In my first company we had taken people who had never shipped before and got them to hit every date, so part of me thinks I took that for granted — after all, our team had a ton of experience shipping product.  Or maybe our choice to go with more junior managers was wrong.   Those all feel like thin excuses though.

• Platform support, over time, became the critical skill to have as a developer.  We were building reference builds — i.e. a version of the game on 4 or 5 handsets that represented a sample of the possible memory and screen configurations.  The publisher would then send those off to a shop in India or Russia to have them ported to 200 handsets at $300 a pop (these days it’s more like 5000 handsets).  We couldn’t compete with that porting price.  But the developers who won were the ones who built a framework that could spit out ports at a push of a button.  The publisher would pay them the porting money, and they’d have no additional cost.  Of course, they had to limit their products somewhat, or choose ones that didn’t push the envelope like ours.   But by the time we realized we had to take this approach it was too late.

• We eventually hit a development budget cap.  We were getting the top rate in the space, but the return wasn’t there and publishers stopped increasing their per title development budgets.

All of this led to some difficult decisions.  We were trying to split our time between our own games and those for our publishers (our own titles were self-funded, we always dedicated resources to our publishers for the duration of our deals).  But as deadlines slipped, we applied more of our resources to our contractual commitments, and eventually had to can everything but our pinball game.  Bye bye breakout and blackjack.

And since we were bootstrapped, we had no capital to address the porting framework problem or to bring in more resources.  We were living a typical hand to mouth existence, with payroll dependent on hitting every milestone.  There was no buffer, and at 16 people, we couldn’t personally cover the difference.

I have quite a bit of game design experience, and that’s the role a played for Knockabout.  But I was also the CEO, which meant I was responsible for various business development and operational functions, plus managing the guys managing the products.  In addition to not having the time to actually do all that, it created a really awkward situation for the producers:  I was their boss, but I was also the guy on their team they needed design work from.  I had a good rapport with individual developers, but it undermined the managers.

Hiring junior managers was probably a poor choice too.  We saved money, and the guys were talented.  But I never spent the time to help them grow into their roles, throwing them in the fire and devoting cycles to business and design issues.

Our assumptions about distribution were also a little off.  While many of the carriers were encouraging developers to go through publishers, Verizon asked us point blank why we were using JAMDAT and not going to them directly.  In the long run I think that would have been hard to sustain (and we certainly couldn’t have gone direct to every carrier), but we might have been able to capture more short term revenue.

There were some unexpected staffing complications as well.  We gave a small signing bonus to one engineer we hired;  he took it, quit a month later and refused to repay it.  Another engineer came to work for us and quit after two weeks because a competing company made a better offer.  That’s random stuff that just happens:  both guys came in on personal recommendations from people already working for us.  In a startup you always have to expect the unexpected.

Next time:  Knockabout’s demise.

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 equity and staffing plan can be found here.

Sure enough, our method of meeting publishers long before pitching worked well to establish our presence in the space.  By the six month mark, if I was introduced to a new publisher, they had almost always heard of Knockabout in advance.  We hadn’t even shipped a title yet.

Early on we signed up with JAMDAT to build the next version of their solitaire game.  Their first one was a great seller, so despite the lack of a brand, it seemed like good bet (and in the early days of mobile, just having a simple name for a title — e.g. solitaire or racing — was often more effective than long brand names that didn’t fit well on the deck listing).  A few months after that they gave us their NBA title to build.  In both cases, we overspent relative to what they funded.

We eventually signed on with a few other publishers, mostly to build games based on movies or sports.  And we added JAMDAT’s NFL property to our list.

For our own IP, we built three titles:  pinball, breakout, and blackjack.  We received almost a dozen offers to distribute the pinball game, and ultimately signed with JAMDAT.   Not only did they offer the best deal, but it made sense given how much work we were doing for them on their major brands.

We also signed a royalty-based OEM deal with Motorola to put our pinball game on a number of their handsets.

We constantly kept in touch with publishers and handset providers we weren’t working with, always looking for worthwhile deals.  Our steady workflow, particularly with high profile publishers like JAMDAT, gave us walk away power in contract negotiations.  We even dropped a potential deal with THQ in the late stages of negotiations because they refused to discuss a few critical parts of their contract (if anyone ever tells you “that’s just the way it is” in a game development contract, you should tell them “just where it is” they should shove it).

As expected, we overspent on our titles.  We got the results we expected too:   the games were very high quality, consistently rated #1 by reviewers in their respective categories;  and each subsequent deal we did was higher than the previous, often doubling in size.

We managed our publisher relationships very well too.  When things did go wrong, they were supportive and worked with us to find a solution.  In one instance, where we knew we were going to miss a movie launch date, the publisher pulled the title and sent the assets off to a chop shop in Russia to get a quick product out the door.  But they also immediately called us to try and lock us down for another title before we went to another publisher, going so far as to send us a milestone check before we’d even determined what the game was or had a contract in place.

Most of our staff were software engineers.  We had one full time artist who was crazy fast, and the platform limitations put a severe limit on how many assets we could provide (max download sizes ranged from 100k – 400k).

It didn’t play out perfectly though, a topic I’ll cover next time.