Complicated vs. Complex: Why Game Development is Hard

Posted April 11, 2015 by Mike Sellers
Categories: games, industry

Tags: , ,

Developing a game is difficult, to put it mildly. And it never quite comes out the way you plan. Despite this, many developers and (especially) project managers — smart, talented, ferociously hard-working people — continue to believe that somehow this time they’ll make the right schedule and be able to predict months in advance when their game will launch.

This never works (okay, unless you’re just copying someone else’s game). And yet, project leaders continue to create Gantt charts of doom, or to try out one production methodology or another in hopes of making game development predictable. As one pervasive example, Agile/Scrum has long been touted as the way to successfully develop a game. Unfortunately, as some have long suspected and recent data has shown, using Agile isn’t a predictor of game development success (but see below). In fact it scores about as well as using a traditional (and long-reviled) Waterfall process!

Okay, so making a game is hard. Really hard. We all know that. But why? And what can we do about it? Read the rest of this post »

Adding Debt to your Daily Scrum

Posted April 7, 2015 by Mike Sellers
Categories: Agile, game development

Tags: ,

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 Next Book You Should Read

Posted April 6, 2015 by Mike Sellers
Categories: industry, practice

Tags: , , ,

This is a post I’ve been meaning to write for a long time, and its time may have passed. But I keep finding people who haven’t read Ed Catmull’s Creativity, Inc.. If you’re someone who leads creative teams (or is just interested in how this is done), this book should be next on your list. In fact, set aside whatever management book you’re reading now and go get this one. It’ll be better.

Ed Catmull is the President of Pixar, and according to many is largely responsible for its continued success in delivering movie after movie that are both commercial and creative hits. In this book he goes through war stories and “lessons learned” that will be familiar to anyone who’s ever read a leadership or management book. But Catmull adds to this his unique perspective applicable to leading teams that have to be both outstandingly creative and also commercially successful. How to do this is, to point a finer point on it, something that the games industry has yet to figure out.

Among the worthwhile points made in the book are some specific practices that I believe can benefit any creative team, if their management will implement them — and stick to them. The last chapter (actually after the Afterword), “Starting Points,” offers “Thoughts for Managing a Creative Culture.” any of which are useful on their own. You’ve no doubt seen many of these before, but reading about them in context and in actual use at Pixar gives them new life.

The Braintrust
To me the single best practice that I got out of this book was the use and structure of Pixar’s Braintrust. This is a group of people — all experienced enough to get out of their own way and act in a service position rather than feeding their own egos — who review and help develop each of their movies from initial pitch to final cut.

But here’s the significant thing: this isn’t an “executive review committee” that each director comes before as a supplicant, waiting for approval or the ax to fall. It’s not where business decisions are made. It’s not even where creative decisions are made. The Braintrust reviews a movie in progress (and they must be seasoned enough to see past rough cuts) and calls out issues they see. But then they don’t try to fix them. They may not even offer solutions. The director is responsible for taking the feedback and figuring out how best to address it. There’s a story in the book, for example, about a problematic scene in The Incredibles (p102-103). The group discussed the problem, and then later the director returned with a solution that none of them had foreseen — or that anyone would have seen in a typical “management” meeting.

Feeding the Beast and nurturing Ugly Babies
Another key idea that resonates well with any creative team is that of the “Ugly Baby” vs. “the Beast” (pp 129-138).  “The Beast” is that which must be fed — the never-ending pressure and need for commercially viable products. “You’ve got to to feed the beast.” We’ve either all heard that or lived it, often sacrificing creativity and originality to do so — which is how Disney churned out a series of lackluster movies years ago, and how many game studios continue to pump out a seemingly unending array of uninspiring games. The “ugly baby” is a reference to how almost any new idea is at first “awkward and unformed, vulnerable and incomplete.” As Catmull says, these need to be nurtured, but this is in opposition to the needs of the Beast. Which is why we in games so often kill our ugly babies.

As one example, he details the development of the movie Up. The movie as pitched was nothing like it is now: the story originally began with a king and his two sons living in a castle in the sky. The princes, who hate each other, fall off the cloud and land on earth. There they have to learn the lessons of life, and in the process are befriended by a strange tall bird.

As you can imagine, the movie went through many, many iterations to get from there to the masterpiece we have today. In fact, Catmull says, the only two things to survive the entire process are the title and the tall bird. The director, Pete Docter, went through revision after revision, eventually converging on the story and world he and his team wanted to bring to light. Docter’s comments in the book on the difficulty and necessity of failure in finding the right story are illuminating.

I could go on, but I’ll end this with one final quote from the book about failure and the desire management often has to control everything in the creative process:

Whether you’re coming up with a fashion line or an ad campaign or a car design, the creative process is an expensive undertaking, and blind alleys and unforeseen snafus inevitably drive up your costs. The stakes are so high, and the crises that pop up can be so unpredictable, that we try to exert control. the potential cost of failure appears far more damaging than that of micromanaging. But if we shun such necessary investment — tightening up controls because we fear the risk of being exposed for having made a bad bet — we become the kind of rigid thinkers and managers who impede creativity.

If you are someone who leads creative teams, or who ever hopes to do so, I cannot recommend this book highly enough. And by the looks of the mountain of creatively vacant products our industry (and others like it) continues to drive to the market day after day, the wisdom accumulated by Catmull and Pixar is something we desperately need.

Emergence and a Flock of Neurons

Posted April 3, 2015 by Mike Sellers
Categories: Cognitive Science

Tags: ,

Dan Scherlis just sent me a short video showing starlings in flight,starlings in flight taken at 600 FPS. This fascinating video led me to think about emergence (never far from my mind) and ultimately to recent work in brain organization, or what’s known as the “connectome.”

Videoing the birds at a fast speed enabled the videographer to mark out the path of each bird.This showed how the path and “personal space” around each bird evolved, and thus how the flock formed and reformed over a period of just a few seconds.

Flocking is well-known as a beautiful example of emergence. A flock may be enormous and create complex shapes, from the signature flying-V of geese to dynamic abstract shapes that change moment by moment. One of the amazing things about flocks is that they arise from three very simple rules:

  • Don’t hit any bird near you (keep your personal space)
  • Go in about the same speed and direction as the birds nearby
  • Steer toward the center of mass of birds near you

That’s it! With those three rules and no central coordination, incredible dynamic flocks of birds (and schools of fish, etc.) appear (you can see a simple demo of this, complete with code, here).

Emergence
We say phenomena like this are emergent because a new level of organization appears that has no direct reference to its components. In the case of birds, no bird is the “flock master.” Nowhere is there a plan for what they flock will look like at any given time; the “flock-ness” simply emerges on its own from the autonomous behavior of the individual birds in it.

This points out how you can tell when something is emergent, as so many interesting structures and behaviors are: not only are they driven by individual-but-connected behaviors of their constituents and not by central control, but they also create a structure that is more easily described as a whole rather than as the sum of its parts. it’s much easier to sketch or describe what a flock looks like as a flock than it is to give the same description by noting the precise position and direction of each bird in it.

To use another well-known example, Conway’s “Game of Life” plays out on a 2D grid in which any cell can be “alive” (occupied) or “dead” (vacant). The game consists of just a very few rules:

  • Any live cell with fewer than two neighbors dies (loneliness)
  • Any live cell with more than three neighbors dies (overcrowding)
  • Any live cell with just two or three neighbors lives on happily into the next turn
  • Any dead (vacant) cell with exactly three neighbors comes to life (reproduction)

Despite the simplicity of these rules, this game is well known for creating marvelously complex patterns. Perhaps the most famous is the “glider,” which appears to walk its way across the grid:Game_of_life_animated_glider While the shape itself, the “glider-ness” is persistent, each of the cells making up the glider changes over time. In one sense, there is no glider, since it is made up of individual cells turning on and off based on rules that have nothing to do with “making a glider” or any other shape. But the glider is nevertheless describable as a thing, an object that can be defined without reference to the rules the cells themselves are following. As with any emergent phenomena, it’s easier (more parsimonious) to describe the glider on its own — for example, as “moving down and to the right” against the background — than it is to describe the individual interactions between each of the cells turning on or off with each time step.

From Flocks to Brains
Which brings me back to the starlings above, and from there to neural organization. The birds flock together, moving and forming and reforming moment by moment, as we have all seen. But in the video above the addition of their “flight lines” gives them, and the flock they form, a persistence we don’t typically see.  Image by Jason D.Yeatman in Yeatman et al., Nature CommunicationsMRI diffusion map by Stephen Rose, University of QueenslandWhen I saw this, it immediately reminded me of some other images that have been appearing over the past several years of the “connectome,” — the “wiring plan” for the brain.

These images show the pathways of neurons in the brain — the parts of neurons in the cortex that connect to other parts of the brain, enabling thinking. Without taking a deep dive into the science of neural development and how individual neurons “find their way” from the deep core of the brain to the cortex during early development, the similarities between these pathways and those of starlings in flight is at least superficially apparent.

I suspect these similarities point us to the deeper corresponding processes in each case, and thus to the resulting emergent structures: the here-and-gone flock, and the somewhat more persistent brain — and mind — of each human.

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

Posted March 30, 2015 by Mike Sellers
Categories: game development

Tags:

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]

Dragon Con 2014

Posted August 31, 2014 by Mike Sellers
Categories: Uncategorized

Tags:

dragoncon logo

DragonCon ends tomorrow. It’s been terrific and honestly, somewhat eye-opening for me. It’s enormous (60,000+ people), with an unending number of talks and panels on anything connected to games, movies, fiction, and a ton of other topics. I spoke on a panel on Friday on “making awesome video games,” which was fun and easy duty.

It’s also sort of a concentrated geek Mardi Gras that takes over downtown Atlanta (the locals love it too, which is nice — they say it “makes Labor Day into Atlanta’s favorite holiday”). The lobbies of the Marriott, Hilton, Hyatt, and other hotels downtown are packed (and I mean packed, several floors deep) with people just about 24 hours a day. I’ve been to big conventions before, but nothing as concentrated as this.

There are people in costumes (“cosplay”), many stunningly elaborate, as far as the eye can see. They’re all made by fans of just about anything you can imagine. Some are sly jokes, but most are just unadulterated and un-self-conscious love for some character — or “property” as those of us on my side of the industry looking-glass tend to say.

On that note I have to say that being here has been a useful re-education for me: It’s helped me regain an understanding of the real joy people derive from fiction, shows, and games (my own little “Sullivan’s Travels” moment). Sure it’s all froth, but everyone knows that and they jump in anyway. People “like liking things,” as one TV character said, and being able to share that with others brings its own form of joy.

For my part, and at the behest of two of my daughters, both veterans of the convention, I put on a tux and a small arc reactor I made over the past few weeks, resulting in an older (but I’m told creditable) Tony Stark — or as one person said, “oh, you’re ‘The Most Interesting (iron)Man in the World!'” There will, I’m sure, be pictures.

And with any luck at all, I’ll be back next year.

Rumblin’

Posted November 6, 2013 by Mike Sellers
Categories: Uncategorized

I realize, for those few who check this blog, that I never mentioned where I am now.

Still in the SF Bay Area, geographically, but I’ve moved to Rumble Entertainment, where I’m now Creative Director. Rumble’s current game is KingsRoad, a very cool free-to-play fantasy RPG with excellent gameplay, graphics, and multiplayer. We’re working hard on expanding the features and world of KingsRoad. Of course, we have some other things in the works as well. Rumble has a terrific team of game veterans who, I’m happy to say, really get game design, supporting strong production values, and the importance of providing increasing depth in their games.

I’m continuing to work on my AI as well, and it looks like may be teaching again this winter. More on that soon.

One other thing: if you happen to see an ad below this post, well, it’s not mine, it’s from WordPress. They make their software freely available, so now and again we get to see ads. It’s the 21st Century.

 


Follow

Get every new post delivered to your Inbox.

Join 353 other followers