Tag: startups

How Emergence Changes The Business Model

December 24th, 2013 — 10:23pm

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


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

8 comments » | Emergence, Startups, Value Creation In Games

A History Of Knockabout Games: An Epilogue

May 21st, 2012 — 7:14pm

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

Comment » | Startups

A History Of Knockabout Games: Knockabout’s Demise

May 14th, 2012 — 6:15pm

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.

Comment » | Startups

A History Of Knockabout Games: What Actually Happened

April 30th, 2012 — 6:35pm

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.

Comment » | Startups

A History Of Knockabout Games: Funding, Equity and Staffing

April 23rd, 2012 — 5:32pm

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 business strategy can be found here.

Funding and Equity

Knockabout was mostly owned by myself and Monty Kerr.  Monty’s role was largely silent — he had an existing game development business to run still — but he had quite a bit of extra office space, desks and computers for Knockabout to borrow.  He also had spare resources (people) for us to use on a part-time basis, to complement the rest of us who weren’t going to draw any salaries for a while.   Since game development is primarily a labor intensive activity — almost all the expense is tied up in payroll and the space to house everyone — this took care of the bulk of our costs and allowed us to bootstrap the business (we later leased our own space and in an unusual reversal, sublet to Monty’s company).

We also gave a small amount of equity to three seasoned game industry veterans we thought would be critical to our company:  a director level manager to oversee the specific titles, a technology director, and the CTO of Monty’s current business (who was to stay there and migrate to Knockabout later).  We wanted these folks to feel and behave like owners, not employees, since they were so important to our success.

And we gave them ownership straight up — no options, no vesting.  We did have an option plan drafted, but never actually used it.  Our take was that options, in 2002, still had a negative connotation left over from the dotcom bubble.  There was no point in handing them out if no one would take them seriously.  So for most of the staff we had a simple, and generous, bonus plan:  any time profit distributions were made, 50% of it had to go to the staff.

Development Staff

For staff, we only wanted to hire coders and artists with prior game development experience.  The platform was going to be a nightmare as it was — I didn’t want people learning how to make games for the first time as well.  I just wanted experienced game developers who were good engineers (or artists who had strong illustration, modeling and animation skills) — that was the harder thing to find;  any good engineer could learn a new platform easily.

On the flip side, we skimped on management.  I wanted producers who were former developers so they could communicate well with the team.  That struck me as particularly important since the teams were so small (often one engineer).   So we would hire guys who knew how to make games, but were trying to transition from a technical role into a management one.  I was to personally train and mentor them in those roles.

That wraps up the planning phase for Knockabout.  Next time I’ll talk about what actually happened.


Comment » | Startups