Monolith Soft just published the programming chapter of their ongoing staff interview series dedicated to their work on The Legend of Zelda franchise. Three members of the programmer team sat down to talk about what it actually looked like, day to day, to collaborate with Nintendo on The Legend of Zelda: Tears of the Kingdom, from building team culture from the ground up, to making a bird-type character feel genuinely alive, to fighting for an idea instead of taking the easy way out.
The three programmers are identified by initials: Y.T., who leads Monolith Soft’s programmers and technical artists and was personally responsible for implementing Tulin, the Rito sage who accompanies Link throughout the game; M.K., who joined the Zelda team for Tears of the Kingdom specifically and handled NPCs, mini-challenges, and enemy characters; and H.N., who focused on enemy characters and was responsible for implementing several bosses.
The first thing that stood out was how easy it was to just ask
The interview opens with a question about how Monolith Soft’s programmers fit into the broader development structure, and Y.T. draws a clean line between two types of programming work: building the systems that make a game function at its core, like physics and graphics, and building the gameplay on top of those systems. Monolith Soft’s programmers handled the latter. They implemented the actual play, working alongside Nintendo.
What comes next in the conversation is almost more interesting than the technical stuff, it’s about how the team actually communicated. M.K. explains that when he first joined, what struck him immediately wasn’t the scale of the project or the pressure of working on a franchise like Zelda.
It was how low-friction the whole thing felt. If he didn’t know something, he could just post in the shared team chat, “does anyone know how to handle this?”, and someone would answer. No hierarchy to navigate, no having to figure out who the right person even was.
That wasn’t just a cultural vibe, either. There was an actual written guideline inside the team that said, in effect: even if you don’t know who to ask, ask anyway. M.K. says seeing that spelled out, and then watching it play out for real in daily conversation, made it easy to settle in fast. He didn’t need weeks to figure out the unwritten rules. The rules were written.
H.N. adds that throughout development, the programming team held regular retrospectives at key milestones. Not high-level post-mortems, small, practical check-ins where they’d surface the friction points that kept coming up. The moments where no one stepped up, or where people weren’t sure whose job something was.
Each one of those became a mini-guideline. Y.T. notes that this habit of not letting things slide, of actually talking through the small stuff instead of just moving past it, kept going all the way to the very end of development.
Making Tulin feel like a living creature without making him useless
Y.T. was the one responsible for Tulin’s behavior in-game, and the way he describes the challenge is genuinely one of the more interesting parts of the interview. Tulin is a bird. He flies. He follows Link around. That sounds simple, but getting it to actually feel right turned out to be a balancing act with no clean answer on either side.
If you let Tulin fly loosely and naturally, the way a real bird might drift through the air, he ends up too far away the moment the player actually needs his power. That’s a gameplay problem. But if you keep him close at all times, locked to Link’s position, he moves like a drone, mechanical, robotic, completely stripped of any sense of life. That’s a feel problem.
Y.T. describes a long, careful back-and-forth with Nintendo to find the right balance, not just for open-air exploration, but for every context the player might end up in. What does Tulin do inside a cave? Inside a dungeon where vertical space is limited? During a boss fight? When the player is using another sage’s ability at the same time? Each scenario needed its own solution, and each one came out of actual conversation with the people responsible for those parts of the game.
H.N. makes the point that this kind of cross-section thinking wasn’t unique to Tulin. Every action and every item in Tears of the Kingdom had to work right across every situation the player could throw at it. That meant the scope of what any single programmer was responsible for was huge, and collaboration wasn’t optional, it was built into how the job was done.
Nobody let go of the fun version just because it was harder to build
This is probably the section of the interview with the most to say. M.K. starts by describing his own honest starting point: he came in with the mindset that a programmer’s job is to make the planner’s and designer’s ideas work technically. You hear the idea, you make it run, you move on. That’s the job.
What changed was an experience he describes around one specific mini-challenge in the game, “Ball Carry,” a deceptively simple thing where the player has to transport a ball as far as possible. The twist is there are no rules about how. You figure it out yourself. That kind of open-ended, anything-goes design is exactly what makes Tears of the Kingdom feel so alive, but it’s also genuinely hard to program, because when any approach is valid, the potential for bugs showing up in unexpected ways is enormous.
M.K. is transparent about where his old instincts would have taken him: the moment a planner pitched something like that, he would have said “that’s difficult” immediately. And he walks through what happens next when a programmer does that. The idea starts shifting. “What if instead of carrying it anywhere, you have a fixed distance and a timer?” Technically safer. The ball is still there. Problem solved, except the original thing that made the idea exciting is now gone, and it happened quietly, before anyone really noticed.
H.N. puts it plainly: it’s easy to convince yourself that the watered-down version is fine because the core concept is technically still intact. Y.T. acknowledges that risk-aversion is completely natural for programmers, seeing potential failure points is literally part of the job. But left unchecked, it kills good ideas early.
What shifted M.K.’s thinking was experiencing firsthand that when the entire programmer team put their heads together, they could almost always find a path through.
Once he felt that for real, his default changed. Instead of leading with what was difficult, he started leading with the question of how to actually make the exciting version work, then figuring out the risks from there. H.N. summarizes the team’s overall approach simply: they were a group that stuck it out together, no matter which direction the problem was pointing.
M.K. says that approach, the refusal to settle, the willingness to keep pushing on the fun version of an idea, is one of the things he credits most directly to working alongside Nintendo.
Speed was the other half of that equation. The team didn’t lock down detailed specs before touching code. Their rhythm was to build the minimum version of something as fast as possible, then gather around it as a group and check whether it actually felt like the right thing.
If it did, you built more. If it didn’t, you adjusted and rebuilt. H.N. talks about how this was especially critical for boss encounters, which touch so many interconnected systems, story, player abilities, enemy behavior, progression, ,all of which are themselves in motion. Moving fast wasn’t just about efficiency.
It was about staying relevant as everything around you kept changing. And sharing early meant the whole team could account for what you were doing before it became a problem for them.
M.K. and H.N. both note that everyone on the team maintained a high level of awareness about what was happening everywhere else, not just in the programming section, but across planners and designers too. That shared awareness is what made the speed possible. You knew what was in flux, what was settled, and what was about to change, so you could make smart decisions about where to put your effort.
The goal from here: A team that can say yes to any idea
Y.T. closes the interview looking ahead. Monolith Soft wants to grow the programmer team in size, and the intention isn’t just to add headcount. The goal is to make sure everything the team learned through the Tears of the Kingdom development, every insight about how to approach a gameplay problem, every lesson about how a programmer can genuinely contribute to making something fun rather than just making something functional, gets passed on fully to whoever comes in next.
The word Y.T. uses to describe what they’re building toward is “tough”, a team tough enough to answer any idea that gets thrown at them.
The interview is part of Monolith Soft’s ongoing developer series covering their involvement with the Zelda franchise, published on their official recruitment site.
We at Geek Realm Hub previously covered the interview about the Character Art and Modeling in Tears of the Kingdom.
So what do you think, does knowing what went into something like Tulin’s AI change the way you see the game? Drop your thoughts in the comments, we want to hear from you!