“What should game developers learn from Blizzard failing at Titan?”

Over on Quora I was asked to answer this question. Here’s what I wrote:

A few clear lessons come to mind:

1. Most games fail. Having a team that is smart, passionate, talented, deeply experienced, and insanely well-funded doesn’t change the fact that your game is most likely to fail.
   

   Let that sink in for a moment.
   

   Not even having had an enormous success one time means you will be successful the next time. Hard as it is to say, if you’re lucky this happens before the game is released (or even announced!). The long droughts between successful games is part of the landscape of the games industry, and something almost everyone has to internalize.
   

2. Failure is not permanent. The story of game development and the games industry is nothing if not one of re-invention. Developers, properties, technologies, and companies all re-create themselves every few years. You try something new, you fail, you try again. Just as success is not a given, neither is failure. You fail, you sit, you cry, you mourn, and then you get up and try the next thing. That’s been my experience in more than two decades in the games industry.
   

3. Know who you are. While re-invention is pervasive, it’s also true that success breeds inertia: the longer your company is successful at doing what it does, the harder it is to change that course. Is your company about ground-breaking innovation, or about tweaking known formulas? Both can work. But culture is real. Cultural inertia is real.
   
   Here’s a story I don’t often tell too publicly: in 2002, I interviewed at Blizzard for the lead design position on this new game they had going, World of Warcraft. I had recently been the lead designer on three MMOs (Meridian 59, SimCity Online, and Ultima Online 2 — one out of three of which were released), along with leading the design on The Sims 2. I had a really terrific day talking with the team at Blizzard. But every time I said something like,”oh that’s cool, and you could really take this in a new direction,” the response was along the lines of, “well… we’re really not trying to reach too far with new things on this project.”
   

   At the end of the day I sat in a conference room while the managers conferred. While I did, it became really clear to me that this was a great team and a great company — and definitely not the job for me. I’ve spent my career trying (and very often failing) to do things that were really new, and that’s not what they were trying to do. So, when they came back in the room (I’m abashed to say I don’t recall now who it was I talking with), they very graciously said, “we like you, the team likes you, you have a great resume… but we just don’t think you’re the guy for the job.”
   

   I feel incredibly fortunate to have been able to interview for that position, and even more fortunate to have been able to respond, in that moment, “You’re right. This is a great project and team, and I’m not the guy to lead it. But I think I know who is.” I recommended Tom Chilton, a terrific designer who was on the team I had just left, and someone who was a classic fantasy MMO designer in his bones. Not too long after that he took the job, and is still at Blizzard doing great work.
   

   The point of all this is that at that time, Blizzard knew who they were and what they wanted. They had an established culture and they played into their strengths in phenomenal ways.
   

   But that strength also made it more difficult for them to in fact do something new, to make whatever it was that Titan would have become. I mourn with them a bit for what might have been, but I also celebrate their re-invention via Overwatch.

Advertisement

Is there another way?

Game dev folks, I’d like your thoughts on this one: Michael Martinez, CEO of JuiceBox Games, wrote a smart and heart-felt mini post-mortem of his company, which is shutting down. In it he details the difficulties of running an effective game development business in today’s market. 

I don’t know Martinez, but I agree with most of what he says 100%. And of course I have immense empathy for him and his team, and the difficult decisions he’s had to make.

That said, I’m left with the nagging feeling that he (and many other smart people) have bought into the equation of “game dev success” that requires many millions of dollars of investment. JuiceBox had a $2.54M seed round, the kind of money which then requires hit games to sustain the business. This view is hardly new; it’s how people have been setting up businesses for a long time (and how I’ve set up some of mine in the past). However, it also leads to the kind of tunnel vision that makes the conclusion that “games are a hit-driven business,” inevitable. It’s the classic (if often self-defeating) “go big or go home” mentality that shoves aside all other possibilities. The thing is, I don’t think that conclusion is actually all that inevitable: we can do this differently, with less risk and more success.

Artisanal Game Development

“Tabletop games are to computer games as plays are to movies.”

This is something I’ve been saying for awhile, with an echo of Terrance Mann’s “movies will make you famous; television will make you rich; but theatre will make you good.” For a game designer, I’m increasingly convinced that there are few ways to better hone design skills than by creating tabletop games. When the only computer available is in the players’ heads, this restricts how much you can hide bad game design behind glitzy graphics or mountains of bookkeeping.

A couple of weekends ago I spent an incredibly enjoyable, exhausting, and enlightening time at Protospiel in Milwaukee WI. This was a gathering of fifty or so game designers and playtesters. I tested my in-process game a couple of times and reaped a wealth of terrific feedback. Playtesting is almost always useful, but this was like tapping into some mainline of game design thought and knowledge.

I should say that I also played a bunch of others’ games. That’s the magic of Protospiel: almost everyone brought a game (or more than one) to test with others, and played others games in turn. The variety of games was huge, from a truly elegant Love Letter-like game (with even fewer cards and possibly more strategy) to an educational (but still fun) game about the invasion of mussels and algae in the great lakes, to games with seeds and zombies and prison breaks and a bunch of other stuff.

Few of those there were full-time game developers; most had day jobs unrelated to games. And yet the quality of games in development was what I would expect from a “professional” gathering. Moreover the dedication to making a good game was equally high, as was the ethos of giving constructive, insightful, egoless feedback to others. Each person I saw or overheard recognized the strengths of a given game along with its rough spots — and inherently the work it took to get the game to where it was.

This, I think, is what I would call artisanal game design. Games made with care, craft, and pride. And in physical, table-top form, and therefore forced into as much design elegance as possible. Many of these are games that the designers hope to sell, so this isn’t some anti-commercial endeavor. On the other hand, this is the furthest thing from being some slick start-up ploy to build and flip a company as fast as you can without real regard for the product you’re making.

I think this is a useful return to the roots of modern game development. I’m sure this is a highly effective way to hone skill in game design. Whether it’s a way that someone could build a career (or even a viable second income stream) remains to be seen.

Adding Debt to your Daily Scrum

Debt in a project (technical or otherwise) is something no one wants in a project.  But I believe it belongs in every Daily Scrum / Stand-up meeting.

Everyone who uses Agile/Scrum knows the the three big questions used in a Daily Scrum or Stand-up meeting:

• What did I finish yesterday?
• What am I working on today?
• What is blocking my progress?

These questions are meant to be the daily pulse of the project. Among other things, this short meeting is how you (as project leader or Scrum master) spot the trouble spots before they become crises.

But a few years ago I noticed — after being stung by it a few times — that there was a question missing. So I’ve added a fourth question that everyone is expected to answer in daily Standups:

• What debt have I incurred?

I added this to our meetings after noticing that sometimes a task would be called “finished,” would be moved to testing and then acceptance — only to find out later that, in order to make the original time assessment and get the task (and user story/feature) into the current Sprint, someone had to cut corners: some temporary art was used, a bit of unfinished design was papered over, or a single-use function was quickly created, knowing that it would have to be refactored later.

Ideally when this happens, a new task should be added to the backlog to be addressed later — that would keep the debt transparent. But in my experience this often does not happen, whether due to the intense focus in mid-Sprint or the reluctance of someone to point out that their task isn’t really finished.

So, I started including the debt question to be answered by everyone every day. It takes only a moment to answer, so it’s not in danger of burdening the brevity of the meeting. It’s also not always the most comfortable question to answer — no one likes to admit that they had to take a shortcut that’s going to need attention later. But it also gives team members a natural outlet that’s just part of the process to bring this up. Doing so gives everyone a more accurate picture of what actually remains to be done, and just as importantly, helps refine future task scheduling. Most of all, it prevents the dread of instabilities or unfinished bits lurking in the shadows as you come to a release.

Finally, having an open understanding of any debt incurred helps you as a manager spot those who are making a habit of cutting corners and help them to move past it. Left unaddressed, this practice can ultimately undermine the product, making it less robust or require a surprising amount of time in “bug fixing” (when a lot of debt is often silently taken care of). Helping those on your team estimate tasks more effectively, not cut corners — or do so judiciously and consciously — and ultimately make a better, more stable product is good for everyone. Even if it can cause a bit of squirming in a daily meeting.

The Keys to Game Development: What the Best Teams Do (the TL;DR version)

The Game Outcomes Project led by Paul Tozour recently published some fascinating work on why games succeed or fail: what practices correlate positively or negatively with successful game development projects? This appeared on his blog in five parts (1, 2, 3, 4, 5) and on Gamasutra. The results are based on a survey of “roughly 120 questions” sent to game developers in November 2014. There were 771 responses, of which 273 were complete and referred to projects that were completed (i.e., “neither cancelled nor abandoned”).

I encourage you to look at the pages linked above; the results are highly detailed and presented in a readable but quantitative way. On the final page, the team lists their Top 40 reasons why game projects succeed or fail. These are listed in order of correlation with success based on the survey data. As with the overall results, the list is detailed and a bit dizzying, with different practices popping up throughout the list.

To condense this down to more comprehensible chunks, I have gone through their list and grouped similar items together. These appear below. The numbers in brackets at the end of each line refer to the corresponding items on the “Top 40” list. Where possible I have kept these in numerical (and thus correlation) order.

It should be noted that each of these effects is statistically significant: if you follow them, you significantly increase the chance that your game project will be successful (where success is framed in terms of ROI, artistic or critical success, or some other internal goal). Likewise to the degree your project deviates from these, the greater your risk of cancellation or some other form of failure.

Here’s the very short summary-of-the-summary. Great, successful teams:

• Create and maintain a clear, compelling vision of what they’re doing
• Work effectively, staying focused and avoiding unnecessary distractions and changes — but without extensive crunching
• Build cohesive teams that trust and respect each other, hold each other to high standards, but allow for mistakes too
• Communicate clearly and openly, resolving differences and meeting regularly
• Treat each team member as an individual — professionally, personally, and financially

So what’s not on this list? Two big things leap out immediately:

• Having a production methodology is important [#26 on the list], but whether this is Agile, Waterfall, or something else has no effect.
• Having an experienced team is also important… it doesn’t appear directly on the list, but if it did it’d be down around #36 out of 40 on this list of significant factors.

With that, here’s my condensation and re-grouping of the Game Outcomes Project’s detailed work for What Great Teams Do (numbers in brackets refer to the place on the “Top 40” list of practices correlated with success):

Product Vision

• The vision is clear and understood by the team, including what will be delivered and what’s expected of them [1]
  • Embodied in specs/design documents, complemented by ongoing design work [36]
• The vision is compelling: viable, leads to clear action [1]
• The vision is consistent: cautious about changes or deviations; vision does not drift over time [2]
  • Enlist all stakeholders when changes are necessary [21]
• The vision is shared: team believes in and is enthusiastic about it [3]

Product Development

• Focus: understand and act on high-priority tasks driven by the product vision [1]
  • Individuals don’t go off on their own priorities [1, 19]
• Leaders pro-actively identify and mitigate potential risks [2]
• Work effectively: remove distractions, avoid extended crunch time [4]
  • Team is trained on and uses their chosen production methodology [26]
  • Ensure that tools work well and allow effective work [29]
• Estimate task durations frequently and as accurately as possible [16]
  • Team members have the authority to determine their own day-to-day tasks and are involved in determining time allocations for tasks [30]
• Carefully manage any necessary technology changes during development [31]
• Determine priorities for each milestone based on the current state of the project [40]

Teams

• Cohesive: the team believes in the game vision, team leaders, and each other
  • Team shares values and sense of mission [1, 8, 14, 17]
    • Team priorities trump individual priorities [19]
    • Foster an atmosphere of helpfulness [35]
  • Team works to minimize turnover [6]
    • But: remove disruptive/disrespectful members swiftly [12, 13]
  • Foster and environment of mutual respect, from management and the team [12]
    • Team members genuinely care about each other as human beings [37]
  • Organized: structure of the team is clearly understood [25]
• Able to take risks (within the bounds of the product vision and priorities) and learn from mistakes [5]
  • Avoid wasteful design thrashing [9]
  • Celebrate novel ideas even if they don’t work out [10]
  • Discuss failures openly [18]
• Hold each other to high standards [11, 17]
  • Invite respectful collaboration and review of work [11, 39]
    • Reward those who ask for help or who support others [35]
  • Call each other out when necessary on counterproductive behaviors [17]
  • Ensure individual responsibilities and roles match with their skills [20]
  • Ensure that individuals have opportunities to learn and grow their skills [28]
  • Hold each other accountable for meeting deadlines – but not to the point of eroding team morale [34]

Communication

• Everyone buys into decisions made by the team or team leaders [3]
• Resolve differences – product or personal – swiftly [7, 12]
• Frequent feedback on their work [9]
  • Ample praise on a task well done [22]
  • “no surprises management” – don’t hold something back [9]
• Team is able and willing to speak openly even on difficult subjects [27]
  • Team members feel heard, even if a decision goes against their view [15]
  • Politics are minimized by open, respectful communication [17]
  • Open-door policy and access to senior leadership to raise concerns/offer feedback [23]
• Clear expectations on tasks and behaviors [24]
• Team meets regularly to discuss topics of interest, ask questions, identify bottlenecks [33]

Individuals

• Use individually tailored financial incentives, not royalties or bonuses tied to Metacritic scores or similar [38]