75 Lessons Learned from Live Game Development

I conceived of and shipped live services games to 20 million players; here's what I learned.

In the course of making games for over 20 million players—based on popular IP like Game of Thrones and Star Trek—I learned a lot of lessons. This is just a few of them, although this includes some of the most painfully learned lessons.

BIG PRINCIPLES

• Every "rule" in gamedev has a great exception

• You probably won't be the exception

• Hard: Shipping; Harder: Shipping fun game; Hardest: shipping fun that scales.

• What few are willing to hear: making a great game is unreasonably hard, and therefore makes unreasonable demands of the team

• Shots on goal (trying ideas, shipping, iterating) matters most

PHASES OF PRODUCT

• You can only build 1 game vision; converge team & purge fiefdoms

• 0 to 1 is about shared vision

• Data is everything in the Live Ops stage; velocity of insight -> product improvement is predictor of success

PEOPLE

• Be wary of hiring people who harbor deep reservations about making money

• Be very afraid if the team building the game isn’t playing it

• Toxic / abusive team members suck

• Cynical team members suck

• Veteran devs are AWESOME, but beware of jaded veterans with a sense of entitlement.

HIRING

• Many people will say nearly anything to land a job at a game studio

• Hire optimistic people because game development is incredibly hard

• Work with people who want to make a great game right now more than anything else in their life

• Focus on “tell-me-about-the-time-you-did-X” questions (behavioral interviewing) and don’t waste time on hypotheticals

TEAM MIX

• Great teams with experienced craftspeople are foundational

• Adding fresh blood who need to learn/prove (e.g., interns) has a high ROI and better connects you to current culture

• Live Ops teams who run great games are usually not right to build a NEW game

FEATURES

• Smaller is almost always better than larger

• But “large enough” is even more important

• Replayability is gold

• It is better to cut mediocre features

MARKETING

• For mobile games: what Kotaku says doesn’t matter

• Meta critic score is one of the worst-designed metrics that exist

• App store featuring will not save you

• The sins of design will not be countered by marketing spend

TOOLING & TECH

Tools need to be native to the user (Unity for programmers, spreadsheets for designers, website forms for PMs, etc.)

• Manual processes suck

• Don’t build backend yourself

• Don’t build a 3d engine

• Technology prowess doesn’t win

PRODUCTION

• Games look like a mess until at least 90% done

• People think they are close to 90% when it's actually more like 50%

• It will take longer than you think

MORE ON VISION

• Reiteration of the Vision is a constant effort; don't take for granted

• Create the simple definition of what’s important

ITEMIZATION & ECONOMY

• Good shop design is critical—needs as much attention as any other part of the game

• Getting a rare item should be clear and awesome for the player

• Don't cap the size of your economy / monetization

• Pay attention to what people buy

UX

• Show your game to people IN PERSON, and take lots of notes on what happens when they play

• Pay attention to how performance scales as the size of data (inventories, etc.) grows

INNOVATION

• Innovation is good for capturing new markets, attention to craft craft is good for capturing established ones

• UX is often the difference between good and great

• You can’t really “lean startup” a game because too much of it is based on a complete experience

NARRATIVE

• Storytelling on mobile must connect with the audience within seconds

• Narrative != Dialog

• Narrative is represented through game systems

• Humans find meaning through story

DATA

• Instrument everything, you’ll probably want the data at some point

• Make it easy to access data

• Dashboards that don’t display actionable intelligence might be cool but aren’t useful

PLAYERS

• Love your players. (Contempt for players is doom)

• Players will speed run content faster than you expect

• Your most valuable cohort will probably be the people who show up in the beginning.

• Optimize single player experience before multi

DON'T PANIC

• Don’t panic if things look like a mess for the first 80% of the development timeline

• Panic if things look like a mess when you’re about to ship :)

CURIOSITY

• Team members should be really curious about what successful games like yours have done before

• Pay close attention If people on the team are experts on your target audience, and they don’t like the game

• Pay close attention if more junior members of the team aren’t learning from the more senior members; all of the reasons this might be happening are bad

• Be wary of know-it-alls.. unless they've shipped top-revenue games🙂

MORE ON PLAYERS

• Your most vocal players are good to listen to, but be careful because they’re not necessarily representative of your market

• Even bad games have their fans

• Intrinsically-motivated players are your core customers

• Extrinsically-motivated players (esports, live streamers, collectors, “play to earn”) may be valuable too, but are not your core

VELOCITY

• Any feature that depends on more than 1 programmer will be exponentially harder and riskier to implement

• The best features can usually be prototyped in days if not hours

• Code in the fewest languages possible, ideally just one

LICENSES

• Aligning incentives is critical

• Licenses can break through noise when nobody else does it; when everyone does it, worse

• Avoid over-licensed IP

• The IP biz dev person’s incentive is usually short-term (annual bonus) your incentives are long term (decade+)

• Walk away if licensor demands % of gross rather than a % of net (of UA)

• Walk away if licensor demands unreasonably strong control over when/if you ship

MONEY

• Debt for UA is like taking treasure from a pit of vipers — more ways to die than win

• Biz models that work in largest games may not work to scale your much-smaller game

• Be wary of backers long on money and short on gamedev experience

• Backers who don’t understand games will lose hope at your darkest hour

• Every game development process has a “darkest hour”

• Your forecast will be wrong

SHIPPING

• It is better to delay than ship before it is ready

• But it is better to ship before you run out of money than not ship at all

• If you can’t ship before running out of money, the culprit is probably that your scope was too great—not that the capital was too small

FINAL THOUGHTS

• If some stuff on this is contradictory, that’s OK. Games contain multitudes.

• If you haven’t failed in game dev you haven’t been at it long enough

• When someone declares the future of games, it usually isn’t

• Fear is the Mind Killer

Other Reading

Here are just a handful of my articles that I think you’ll enjoy if you’re a game developer:

• Why Scaling Games is Hard is about why games are so hard to make and succeed with.

• 42 Game Designs for Generative AI is about some game design ideas that benefit from the latest revolution in artificial intelligence.

• Game Economics, Part 1: The Attention Economy is the first of a 3-part series on the economics of games.