Sakurai on Creating Games: Team Management (15)

Masahiro Sakurai, the creator of the Kirby and Super Smash Bros. series, shares a wealth of game-development know-how on his YouTube channel “Masahiro Sakurai on Creating Games”. This article summarizes and restructures the content of that channel by topic.

That said, a summary is only an entry point. So much of the value — Sakurai’s own words, his real-world examples, his pacing, and the footage itself — can only be gotten from the videos. So please don’t stop at reading the article; I strongly encourage you to also watch the original videos embedded under each topic.

This category covers the art of running a team to make a game in a group — info-sharing ingenuity, the director’s role, and more. Here we bring together the key points of both videos in the “Team Management” category (15 individual topics), structured in 2 parts following the 2 source videos. Each part opens with its explanatory video, so please watch along.

Part 1: Info sharing, the roles that make games, the case for daily reports (#01–#07)

A game is made by a team. This category centers on ways of thinking to run a production team smoothly. Not limited to development, it’s content that applies to anyone working in an organization.

https://www.youtube.com/watch?v=QIt_r5tNKaA

1. Team info sharing

The bigger a game gets, the less each staffer can tell “what they’re making.” Someone making one screw for a car can hardly picture it ultimately carrying people and driving. Work whose purpose and big picture are unclear is stressful. So Sakurai keeps the team’s air open with three ideas.

The daily report page is a page where you write progress, events, and your own thoughts, with a comment field for staff to exchange. The Shot of the Day is one dev screenshot a day (the origin of the “Shot of the Day” on Twitter). And the project showcase is a place, once every few months, to present deliverables like graphics and sound within the team. By presenting yourself, you gain a more bird’s-eye view, beyond merely manufacturing work. It costs a little, but it’s all upside.

2. The roles that make games

What role composition makes a game? Elementary, but something everyone is unaware of at first. Sakurai guides through the main roles that make games.

The director (Sakurai himself), one per team, gives ideas and decides nearly everything — the helmsman. The planner turns that into a spec, a blueprint, and the programmer makes it run as a game. Model, artwork, motion, effects, sound, UI make the assets, and technical supporter, manager, monitor, debugger support production. Each role needs coordination, and without mutual understanding it won’t run well. Sharing the purpose and the requirements of achieving it firmly matters.

3. Say what you think right away

While making a game, you might think “it’d be better this way” about a spec or a team rule. When holding such a grievance, the worst is not expressing it while you’re in the team and saying afterward, once the work is over, “actually, I thought…” No after-the-fact. It only satisfies your ego, the staff who hears it don’t feel good, and it doesn’t help the project.

Players who play the work can only complain even if dissatisfied. But someone inside the team, during development, has a chance to improve it. Just by being there, you’re in a very advantageous position. So first, talk it over. Don’t think “they won’t listen anyway.”

One more important thing: not just “this is bad,” but always set it together with “wouldn’t this be better?” That’s a constructive dev site. Even if the result keeps the status quo, just knowing the reason brings a sense of acceptance. Sakurai has lately set up a suggestion board so opinions can be raised without reserve.

4. A 10-person team is 7 people’s worth

Even with 10 people on a dev team, it doesn’t become 10 people’s worth of work. It depends, but 10 people is roughly 7 people’s worth of workload. That’s because management work increases.

Even with someone who can devote 100% to their own work, that alone won’t run the team. You need, at minimum, people who manage the amount and direction of work, and people who deal with the company and so on. You also need people who set and supervise the deliverables’ direction (lead designer, lead programmer, etc.). When a capable person becomes a leader, they can no longer mass-produce their own deliverables. If an experienced person turns to management, you lose the output they could have made.

But that’s what a team is. Capable people set direction and quality, smooth the operation, and move forward. A small project can have everyone working on production, but the bigger the team, the more power for operations and time for communication are needed.

5. Everyone learns the intent together

Sakurai faced a reflection point in developing Kid Icarus: Uprising. When the director conveyed an element to the planner, and the planner conveyed it to the programmer, the interpretation and deliverable sometimes came back 180 degrees off. The cultures of each dev staffer were too different, and instructions didn’t land — a real headache.

So from his own Smash 4, he set up a system: have everyone involved in that element hear the supervision content. When supervising a fighter’s special, where before it sufficed to tell only the planner, he has all involved — planning, programming, model, motion, effects, sound — attend. Chairs lined up before a big monitor, sometimes about 50 people listening.

Each staffer’s tied-up time increases and it seems wasteful at a glance, but the effect is superb. Each gains a deep understanding including intent, and when in doubt, the direction to aim for is clear regardless of role. It also contributed to better communication (a kind of overhead investment) on a large title. By the way, the lounge where staff gathered always had snacks (heavy on Bourbon-brand).

6. The case for daily reports

Since the Brawl days, Sakurai wrote a daily report within the team every day. Not public externally, and always on working days, weekend work included. He’d post 3–5 topics a day (project news, supervision content, bug reports, sometimes small talk), and each staffer could comment.

Daily reports have many merits. First, letting people get to know you. Sakurai is an “outsider” joining an existing team, and it’s harsh for someone unknown to issue top-down instructions. Read the daily report, and at least he’s no longer a stranger. Second, info sharing (unlike a blanket email, people come voluntarily, so it lands). Third, output training. Fourth, stimulus to the team. Fifth, progress checks. Note that when he tried to announce the next fighter in production (Sephiroth) in the daily report, the server went down from excessive access — even within the team.

7. Debugging never ends

To finish a game, debugging (squashing bugs) is essential. It’s not that he thinks “we’ll just fix it online later” — everyone naturally wants it perfect from the start. The problem is that today’s game scale has grown too big to fully squash with mere debugging.

For example, Smash has 80-plus fighters. Just the combinations of two are about 8,000, and adding each one’s moves, items, third parties, terrain and stages, and Spirits, the combinations become an astronomical number. Without repeating this many times under varying conditions, strict debugging won’t be achieved. It’s actually impossible — in a sense, “checkmate.”

Bugs are especially prone to appear around grabs, throws, Final Smashes (behavior that forcibly controls others), terrain, and Spirits. And the trickiest is the possibility that fixing a bug introduces a new bug. Fix one and you redo many checks. If a trend spreads that you can’t forgive anything but perfect bug removal, you effectively can’t ship games. Setting aside critical things like banking or aviation infrastructure, it’d be nice if, knowing the circumstances of game-making, your view shifts a little.

Part 2: Don’t defer decisions, the debugging setup, director vs. producer (#08–#15)

This part centers on management for moving a project forward — the company as an organization, speed of judgment, the debugging setup, and the essence of the director’s job.

https://www.youtube.com/watch?v=0RHPEr6VcD0

8. Making games at a company

Making games as a company employee, above all it’s grateful that your salary comes properly. On the flip side, raising results doesn’t make pay directly proportional to sales, but that can’t be helped. Game sales are globally polarizing: software that sells sells hugely, software that doesn’t sell utterly doesn’t.

When what you made doesn’t sell, you can’t say it’s anyone’s fault. “It’s not fun to play” is actually low-priority as a factor; there are all kinds — looks, title, promotion, rivals, target platform. And if it doesn’t sell, the company’s survival is at risk, but even so the people who worked are guaranteed pay. The responsibility lies with the company. A kind world, isn’t it?

Company game-making isn’t just making — there’s a mountain to think about: providing space and equipment, training newcomers, researching dev tools, translation and localization. Differences in standing cause friction, but a company is where you support and are supported. Shed the consciousness of “being made to work,” and helping each other to proceed is best of all, Sakurai says (adding, “Coming from freelance me, maybe it’s not convincing”).

9. Get it all done within the day

Sakurai looks at every kind of work in the team and issues revision requests. With a team of hundreds, he sees that many deliverables. Supervision requests come by email, and arrival time becomes the supervision order — “first come, first served.”

What Sakurai is thorough about here is, no matter how much piles up, always finish replying within the day. Reply right when mail arrives; if supervising, reply right after it’s done. Don’t let unread mail pile up at hand.

The time until you reply is time you keep other staff waiting. A keyperson’s delayed judgment directly becomes the team’s delay. Solve it fast and the second and third relays go more smoothly too. Note that since there are hours when no mail comes, a director might also secure their own time, like “no-supervision time in the morning,” he recommends.

10. Don’t defer decisions

Gathering people for a meeting to decide something, not reaching a conclusion, and “taking it back to consider.” Please do stop this. In principle, decide on the spot. If the person in the position to judge is present, press for a decision and decide immediately. “Don’t push the decision off — do it now.”

Most of game development is for the director to discern direction and judge. Branch points always come, and staff do long production based on that judgment, so if the destination is wrong, much time is wasted. The responsibility of judgment is grave. The wish to be careful is understandable, but in many cases there’s no time to waver. The number of people helped by immediate judgment is more than you’d imagine.

That said, alongside not deferring, flexibility matters too. When you notice a mistake, don’t proceed wrongly just because a decision was made — make it possible to re-judge. If a decision is the project’s course correction, doing it finely and repeatedly leads, in the end, to proceeding correctly.

11. The debugging setup

A debugging setup to squash bugs is needed for every game. Only a fraction of bugs surface in the retail version; countless are fixed before reaching that. Having programmers do test play too loses a lot of time, so it’s common to set up debuggers and search systematically. Sakurai explains the rough flow.

As a big premise, unify the ROM version (a bug found on a different version is no reference). Debuggers comb through the spec items, and on finding a bug, report it as a ticket (task) with repro steps. The manager ranks it (S = hang or data corruption, A = blocks progress) and assigns it. Once fixed it goes back to the debugger, confirmed across multiple combinations to close. Visualizing the tasks matters most. Versus games like Smash and open worlds are especially tough, sometimes running CPU matches overnight to find bugs.

12. Monitoring continues endlessly

For play, there are monitors more professional than the developers, who just keep playing matches. Their opinions are drawn up to balance the fighters against each other.

Up to Smash Melee, Sakurai tuned parameters by his sole discretion — everything from attacks to movement performance, tuned himself. Work on top of normal direction, so much he thinks “how did I make that?” From Brawl, about four test players joined, and through the new Kid Icarus and Smash 4, the monitor team was greatly strengthened from Ultimate. Many in number, gathering strong players, and online matches and tournament results became easier to reference.

Sakurai’s tuning policy is to deem rich individuality a good thing. Opinions splitting is the standard, and that’s where the fun is. He also test-plays 30 minutes at lunch under free-for-all rules. He sometimes thinks “is this balance okay?” but he trusts the analysis of the monitor team facing matches daily. Where Sakurai cuts in is often when individuality is about to be killed.

13. Director and producer

Generally, director and producer are hard to tell apart. Sakurai is sometimes called a “producer,” but he’s a director (helmsman).

The director holds nearly all decision power over the game’s content, the helmsman who thinks up the plan from the start. Usually one per team, to keep the policy from wavering. The producer handles team management, PR, funding, and staffing (assigning staff), maximizing cost-effectiveness. The reason a non-creator often gets interviewed is this division of roles.

That said, a producer sometimes gives ideas, and a director sometimes does rear support. Sakurai himself often doubles as producer. The standing differs, but the wish to make a good work is the same. Cooperate and proceed with good balance (things go smoothly with Nintendo, he says).

14. Elementary-schooler monitors

Hard to hold in this era, but a method that worked well in the past that Sakurai cites is, bluntly, “elementary-schooler monitors.” Having the in-development game played by staff’s kids, relatives, their friends, and so on. Ideally with snacks prepared, in a playground-like atmosphere.

Unlike practiced adults, raw reactions of playing the game come out — where reactions were good, where they got stuck on controls, where they seem about to get bored. It’s less about hearing opinions, more about observing the mood on-site. And above all, the staff checking it look happy too. It becomes a shot in the arm to get through work in a harsh period. It’s harder to hold now due to SNS and safety concerns, but if allowed, you definitely should.

As an aside, when an elementary-schooler played the first Smash and landed a Falcon Punch, one kid screamed “Whoa, it sends them flying this much!” “Maybe the first ordinary person to land a Falcon Punch. That kid’s probably a working adult now,” Sakurai reflects.

15. The director is a job of cutting

In the sense of direction (setting course), the director makes various decisions. What and how to do for a good result for the project, both instantly and long-term, considering discretion from various circumstances. It’s not always happy for the user. There’s a mountain of things that don’t go as planned — the computer’s limits, deadline delays, ballooning man-hours.

At such times, anticipating the damage and “throwing out luggage about to catch fire,” or correcting the course, is also the director’s job. The image of a cost-minded producer and a fun-minded director quarreling toward a compromise may be strong, but the director understanding the problem and adjusting is fastest. The director is a person who makes, and also a person who cuts waste.

For that, accurate information is needed as early as possible. If the premise info is wrong, every judgment goes off. The most troubling is dragging on while it doesn’t work out, then saying “I can’t do it” at the last minute. Consulting midway might have let an appropriate fix be given. Pulling out early might have spared the loss of time spent wavering. Including the troubles, pass the baton accurately and swiftly — that’s the message.

Summary

We’ve now gone through both videos and 15 topics of the “Team Management” category. Finally, let’s recap the key points of each part (= each source summary video) by individual topic.

Part 1: Info sharing, the roles that make games, the case for daily reports (#01–#07)

Part 2: Don’t defer decisions, the debugging setup, director vs. producer (#08–#15)

There’s a lot here, but I hope you’ll revisit it starting from whichever part caught your interest. Please also check out the related categories.