🦍 Most quality assurance teams exist to stop players from breaking a game. On Donkey Kong Bananza, the assignment ran the other way: make sure players can break absolutely everything, then make the wreckage safe to live in. At CEDEC 2026 in Yokohama, two Nintendo programmers walked through how that inversion actually worked, right down to the bugs they decided to keep.

A game about smashing things smashes itself

Donkey Kong Bananza arrived on Nintendo Switch 2 on July 17, 2025, the first original Donkey Kong title since Tropical Freeze in 2014 and the first 3D platformer in the series since Donkey Kong 64. It carries a Top Critic Average of 91 on OpenCritic, and at CEDEC 2026 its development team took Grand Awards in Engineering, Game Design and Visual Arts, with Nintendo sweeping the fourth category too through the Nintendo Music team.

CEDEC is Japan's largest game developer conference, run by the industry body CESA. This year it ran from July 22 to 24 at Pacifico Yokohama North and online, and Bananza got four separate sessions covering different sides of its central idea. The QA session ran on July 24, delivered by Tatsuya Kurihara, who led the technical programming and voxel work, and Fukuhei Hamazaki, who handled object programming and QA.

The technical foundation is voxels, essentially three-dimensional pixels. Terrain, enemies and even NPCs are built from them, which is why a punch can carve out only the part it actually connected with, and why you can tear a lump of ground loose and hurl it somewhere else to build a platform.

Then you hand that to testers. Predictably, things fell apart. Squeeze into a narrow gap opened by your own digging and the collision detection gives way, dropping Donkey Kong through the map into an endless fall. Break enough at once and the frame rate suffers. Polygons come apart and leave invisible ledges hanging in the air.

Not "stop the clipping" but "plan for what happens next"

The fix that most studios would reach for is a rule. On Super Mario Odyssey, built by much of the same team, one such rule required that V-shaped terrain always be capped so characters could not wedge themselves into the crease.

That approach collapses the moment players can generate their own terrain. No amount of care from the level designers stops a player from building a shape that breaks the game, because the player is the one building it. And blocking that would mean taking away the freedom that is the entire point.

So the team stopped trying to prevent clipping and started designing what happens after it. If Donkey Kong is going to slip through a surface, the question becomes which side he ends up on. Falling through the floor is a disaster. Popping out through the ceiling is survivable. Caught between a moving wall and a fixed one, he is pushed out on the moving side. Caught between a voxel and a non-voxel object, he goes out through the voxel. And once he ends up somewhere he should not be, the voxels immediately around him are destroyed automatically, opening enough space for the physics to settle again.

The bug is not prevented. It is given a landing.

Building on the assumption that players will skip your game

The same logic got applied to progression. Bananza is structured as a sequence of stages, but a player who can tear off terrain and throw it can bridge a gap to a distant platform, walk past a boss entirely, and land in the area that follows.

The obvious answer is an invisible wall. That was rejected as another restriction: finding a route and then being told it does not count is the opposite of fun. Instead the QA team decided that sequence breaks were acceptable as long as they were fun, and that the real job was making sure nothing downstream fell apart. Skip a boss and you can still fight it later, with its reward intact. Skip an event and the dialogue that assumed you saw it gets swapped out, so nobody who accidentally jumped ahead is left wondering whether they broke something.

The extreme case involved the Bananza transformations themselves. Five are meant to be learned over the course of the game. Skilled play makes it possible to reach the ending with only two, which would have been fine except that the post-ending content assumed you had all of them. Rather than closing the shortcut, the team added an event at the ending that hands over every transformation you missed. The dialogue around it makes the moment feel like an unlocked reward rather than a patch.

There is a running joke in speedrunning communities whenever a game holds together under a route nobody could have anticipated: did the developers actually plan for this? Here, at least, the answer is on the record.

Destruction itself is mostly permanent, so the landscape carries a record of what you did to it. There are exceptions. Fight a boss that tears up the ground and the arena ends up nothing like where you started, which makes the retry unfairly hard. So certain places, collapsed bridges included, restore only what needs restoring when the player comes back, and level designers set that behaviour in the editor.

Putting the testers inside the team

Performance was handled the same way, by refusing to trade away the destruction. Since smashing is expensive, everything else had to get cheaper. Each stage got its own optimisation team of programmers, artists and level designers, backed by spheres placed in the world that visualise where the load spikes, per-object load listings readable without engine knowledge, and a recurring internal bulletin ranking the heaviest stages and tracking their improvement. It made progress visible, and it made teams usefully competitive with each other.

The staffing decision may be the most transferable part of the talk. Nintendo's testing is handled by Mario Club Co., Ltd., a wholly owned subsidiary founded in July 2009 and based in Kyoto's Higashiyama ward, with 432 employees as of September 16, 2025. Bananza, however, was being made in Tokyo. So core testers were seconded north and folded into the development team as members rather than as an outside vendor.

That changed what testing could be. Testers sat in development meetings and understood why a specification existed, not just what it said. Questions went straight to the implementer instead of into a ticket. Working from the level editor, they could see what play was intended and then go hunting for the places most likely to buckle, and they built and maintained their own test stages.

Debug tooling arrived early too, letting anyone add, carve, restore or wipe voxels, change surface materials, and script Donkey Kong's inputs frame by frame for bugs too fiddly to reproduce by hand. An automated suite warped through the whole game, breaking terrain where breaking was required, playing cutscenes and collecting every collectible, and errors it caught were fixed the same day. Some of that tooling was also put to use in DK Artist, the game's in-built sculpting mode.

The quiz: fix it, or keep it?

Kurihara and Hamazaki closed with three real cases, presented as a quiz.

First, a bridge of thin ice designed to be crossed at speed as Zebra Bananza. A tester tore up the snow nearby, threw it onto the bridge and walked across on the platform instead, transformation unused. Kept, because working out your own answer is more interesting than performing the one the designers wrote.

Second, a boss fought from a minecart by lobbing bombs at its core. A tester ripped chunks out of the surrounding terrain, built a platform, walked over and beat it at close range. Also kept, though it created a knock-on problem: fast travel is disabled while you are riding the cart, so a player not in the cart could warp away before the victory sequence finished. The team did not remove the exploit. They just blocked warping in the moments right after the boss dies.

Third, a race stage where winning the race lifts you onto a giant trophy and opens the way forward. With the right transformation you can simply fly up to the trophy. Kept again, on the grounds that skipping the race in the racing level is funny. The only fix was the dialogue afterwards, which had cheerfully praised a race you never ran. Now it asks whether you were quite sure you did not want to win it first.

Removing the minus, growing the plus

The three principles the team set at the start were: destruction should feel safe and enjoyable, restrictions should not accumulate, and anything genuinely fun should be kept. Kurihara and Hamazaki summarised it as QA that does not only subtract the negatives but actively grows the positives. That is a noticeably different job description from the one most studios write.

It is also a philosophy that overseas developers rarely get to read in full. CEDEC sessions run mainly in Japanese, and coverage in English tends to stop at the awards. That gap is a shame here, because the argument being made is not really about voxels. It is about who a bug belongs to. When a tester finds something the designers never intended, most pipelines treat that as a defect report. This one treated it as a proposal.

In Japan, the reaction to this talk has been less about Donkey Kong and more about whether any of it survives outside a studio with Nintendo's resources and its unusually close relationship with its own QA subsidiary. What does the balance look like where you are: do the teams you know ship the happy accidents, or file them?

参照