Sakurai on Creating Games: Programming (9)

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 technical ingenuity that supports development — rational naming, parameter tuning, and more. Here we bring together the key points of both videos in the “Programming & Technical” category (9 individual topics), structured in 2 parts following the 2 source videos. Each part opens with its explanatory video, so please watch along.

Part 1: Rational file names, parameter tuning, ticket management (#01–#05)

This category is technical talk that faces the computer directly. Since it varies greatly by development environment and team size, it centers on an overview within what’s safe to share, but you get a glimpse of on-site tuning ingenuity.

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

1. Make file names rational

Sakurai sometimes accidentally says Smash’s “Up Special” as “Special Up” in reverse. In fact the development name is “Special Up,” and the whole team calls it that. There’s a rational reason.

Each move has a file name (label name), carried over since the first Smash. The A-button normal attack is Attack, the B-button special is Special. A weak attack is Attack 1, a smash attack is Attack 4, expressing strength by number, with direction tagged as center N, up H, side S, down L. A side smash attack is Attack S4, and aerials get “Air.”

The merit of this rule is that the file name immediately tells you the move, and it lines up neatly when sorted. Attacks group by strength number, Specials in a separate category. Put direction first as “S Attack” and sorting scatters it. “Special H” in Japanese becomes “Hissatsuwaza Ue” (Special Up) — the origin of the dev name. Meanwhile, the official name is “Up Special” because the player’s input starts with the direction (hold up while pressing the button). File names should be concise and clear, so even a newcomer gets them at a glance. Japanese developers should avoid romaji names as much as possible — they become meaningless to overseas people.

2. Mechanisms that make tuning easy

What matters in game-making is tuning. It’s a trade secret so he can’t reveal specifics, but Sakurai uses a mechanism that exposes every value he wants to tune as a “parameter.” For an attack-power-10 move, the mechanism to perform the move is in the program, while the value 10 is externalized as a parameter so planners can tune it later.

Writing 10 directly in the program works too, but then you’d have to touch the program every time you tune — a hassle. The program is the bone; parameters are the muscle. Enlarge or speed up the muscle and you change the nature of the same thing. Parameters are compiled and maintained in Excel, and being able to fold in formulas is a big merit (you can specify relatively, like “this move is 1/2 the power of another”). Since Smash has many parameters per attack, low-frequency tuning values are hidden to prevent human error.

Reflecting values onto hardware needs a convert, mechanized as an Excel add-in and reflected to the dev machine at the push of a button. In the days of the first game and Melee, one convert took 10 minutes, there was no Excel, and Sakurai wrote all parameters in text. From Smash 4, parameters were organized, and it became easier for many people to touch and to trial-and-error, widening and deepening the tuning. It’s where the most trial and error is repeated, so do have a rational mechanism in each team.

3. Wrap parameters in 【】

Where last time was about character-common parameters, this time it’s individual parameters based on the spec. Game creation flows as: the director’s idea, made into a spec by a planner, built by a programmer, with the planner tuning parameters. A program is done if there are no bugs, but parameters keep getting tweaked to the very end.

When based on a spec, you first need to finely convey where you want parameterized, and it must make sense to people other than the author (since multiple people tune). The conventions Sakurai arrived at are three.

① In the spec, write parameter names colloquially. ② Wrap things to parameterize in lenticular brackets 【】. ③ Mark spots to numericize with ○. For example, “【X velocity on counter】 starts moving at ○, while 【X deceleration】 slows by ○ each frame.” The “lunge sideways while decelerating” spec can be imagined from text alone. You get a file lining up the 【】 words and values, and tweaking those values tunes it. Normally things tend to be shown only by names like X velocity, but making it colloquial and clarifying what you want to tweak makes it understandable. It suits individual specs, not general-purpose parameters.

4. Task management with tickets

This leans toward team management. Now, for titles of a certain scale, most work is ticketized — not paper but digital data managed on a server via a tool. Whoever holds this ticket does that job, clearly.

Making one character takes many steps — planning, spec, model, motion, programming, effects, sound, balance tuning — each ticketized and handed off. Each ticket has a leader, assignee, deadline, and status (in progress, done, on hold, etc.), and since you can check held tickets, nothing slips through or is forgotten. It spans upstream and downstream (you can’t make motion without a model, etc.), and if it’s not in time, downstream sometimes starts on a guess — but it’s better not to make it too serial. Debugging is reported via tickets too, routed to assignees via leaders. Visualizing the work matters. It’s a mechanism that didn’t exist long ago, but now it’s so important that work won’t function without it.

5. Family BASIC

The biggest trigger for Sakurai entering the game industry was Family BASIC. Released in June 1984, about a year after the Famicom, it’s a setup that lets you use the Famicom as a gaming PC. Sakurai owns a unit, even painting the yellowing white parts himself.

The RAM was just 2KB (full at about 2,000 characters), small even for the time, but it had good features making use of the Famicom’s traits. Even in basic programming, it was surprising that the MOVE command moves a character easily — just specify a sprite number (0 for Mario, 1 for Lady, etc.), direction, speed, distance, priority, and palette. The trick is being able to use character presets very easily; an amount of program that would exceed merely drawing dots on an ordinary PC runs with just this.

Sakurai learned things like how inertia affects feel with it, putting it to use in developing the first Kirby. The MOVE command had only 8 directions and was easy but unwieldy, so he also shows building programs with more practical sprite commands. Backgrounds can be drawn with Mario Bros.-style assets, though there’s the Famicom-specific attribute constraint (color changeable only in 16×16 units). With two dry-cell batteries on the back of the cart, you could do battery backup — adopted before 1986’s Dragon Slayer.

In the 1980s, many aimed for a PC to make games, but at about 400,000 yen it was out of reach for a middle-schooler. Family BASIC could be bought with half a year’s allowance. Had he not touched this, neither Kirby nor Smash would have been born. You never know what becomes a trigger, but trying to make something first matters — and he hopes this program becomes a trigger that increases future creators.

Part 2: Smash’s knockback, file management, debug mode (#06–#09)

The second half is themed on Smash’s unique knockback settings and the mechanisms that support large-team development. The usually-invisible backstage of development is told, within what’s possible.

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

6. Smash’s knockback

Smash’s attacks don’t simply subtract attack power from the opponent’s health. From the gameplay of launching, unique settings are possible. As a premise, the higher the attacker’s power and the higher the opponent’s accumulated damage, the bigger the launch. Let’s look at the parameters involved.

The vector is the launch direction; Smash can set every angle finely and individually, and a correction following the attacker’s movement reduces aerial-combo whiffs. The reaction influence value is a multiplier, enabling fine control like “high power but doesn’t launch much” (and vice versa). The reaction additive value ensures a minimum launch (so a launching attack holds up even at low damage; used with influence held down). The reaction fixed value is fully fixed regardless of damage. Mario’s Super Jump Punch keeps the multi-hits fixed and launches only on the last hit via the influence value, landing regardless of the opponent’s damage. With this composition continuing from the first game, it turns an unusual rule into a fun game.

7. How many people edit files

With a large team, hundreds keep building the same game. Someone edits a file and someone else edits it too — how do they avoid clashing? Sakurai too once wondered. Here’s an overview.

A game’s deliverables split into countless files, increasing in proportion to scale. Most are watched by a management tool, with files uploaded to a server. When someone edits, they lock the file, upload after editing, and release the lock. But then only one person can edit a big file, which is inefficient. If it’s doubly edited and clashes, the tool compares the edited spots and attempts a merge (stitching together), with remaining conflicts resolved by hand.

Proceeding this way, it should be fine in theory, yet “reversion” somehow occurs — a phenomenon where someone’s edit vanishes entirely and goes back to before the edit, somehow common. The management tool backs up each edit, so if lucky you can restore from one prior. “In theory there’s no problem, yet trouble somehow happens frequently. Relying on such a mysterious management tool, many projects run today too,” Sakurai concludes.

8. Debug mode

During development there’s a debug mode (development mode) with various features — for making the game while doing all sorts of tests and analysis. In Smash you can set everyone’s health to a fixed value, but in the old days without it, you’d set Fox’s side-tilt to attack power 100 to test — without debug features, ingenuity and effort were needed. The launch-trajectory display in Training was also originally a debug feature, adopted because it’s easy to understand.

The video’s “shot of the day” is also taken in this mode, freely freezing the screen, erasing fighters, zooming out, changing the angle of view. But you can’t place things into depth, and there are limits like items disappearing. Sakurai recommends a form that completes with one normal controller, since needing a separate controller is a hassle to find later. Many debug modes are removed feature-and-all in the retail version, but since it’s used daily it greatly affects development efficiency. Items tend to bloat, so manage and care for them while proceeding conveniently.

9. The transparency feature

What Sakurai introduces as handy to keep in dev mode is a model transparency feature. Smash Ultimate lets you specify part (or all) of a fighter’s model to make it semi-transparent or hide it.

What’s it for? To check movement well. For example, a caped character can be hard to see poses on because the cape gets in the way; before, they erased it via scaling or the model, but being able to do it in dev mode is handy. It also helps with checks outside development. At a certain 3D fighting game’s site too, clothes and jiggle physics could be cut for expression, and the motion looked easier to see. The “shot of the day” was, he says, taken right after implementing this feature.

A feature to toggle display per element is common too, and was used frequently. It’s a developer-side mode, but a partial transparency feature is rather recommended, he closes.

Summary

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

Part 1: Rational file names, parameter tuning, ticket management (#01–#05)

Part 2: Smash’s knockback, file management, debug mode (#06–#09)

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.