Destruction has long been one of gaming’s most technically ambitious features, but few titles attempt to push it to the scale promised by BeastLink from Grove Street Games. Developed around giant kaiju battles inside fully destructible multiplayer environments, the project introduces a proprietary technology stack called SuperDestruction, capable of simulating hundreds of thousands of destructible instances and nearly 14 million individual pieces across a single map.

Rather than relying on scripted collapses or heavily authored sequences, the system is designed to generate destruction dynamically in real time. Buildings are procedurally assembled as players approach them, collapse differently every session, and synchronize across multiplayer matches using custom networking and physics solutions built alongside extensive modifications to Unreal Engine 5.

In this interview, Thomas Williamson, CEO of Grove Street Games, explains how SuperDestruction evolved from early experiments using Niagara and custom HLSL compute workflows into a large-scale networked destruction pipeline capable of even running on current-generation consoles. 

Can you introduce BeastLink and explain the core idea behind the project? What kind of experience are you aiming to deliver with this original kaiju combat IP?

Thomas Williamson, CEO of Grove Street Games: BeastLink is, at its heart, based on our studio’s desire to make the ultimate kaiju game. Every notable kaiju game so far has focused solely on fighting, or kaiju themselves are giant setpieces of the gameplay.

In BeastLink, you start off as a human, on foot, in this giant, destructible sandbox, beholden to the strength of powerful kaiju also roaming the map (whether they be player-driven or bots) until you gain the ability to become one yourself. Once you’ve BeastLinked with one of these enormous creatures, you become the ultimate tool to overcome the obstacles of that game’s scenario or choose to terrorize the opposing team. 

A major hook here is the SuperDestruction system. At a high level, what is it, and what design goals did you set for it early in development?

Thomas Williamson: It’s our proprietary technology that allows us to bring to life Kaiju’s destructive power that we usually only see on the big screen. Our main goals were to design a system that allowed us to have dynamic content for city building that could break apart into an ungodly number of simulating physical pieces, and have this work over the network. We needed this to run on current-gen consoles. Early on in tinkering with available systems, it was clear that no one had remotely considered this kind of scale with existing physics APIs. So a few years back, we found ourselves on a path to building something very new.

When a skyscraper collapses or a large structure breaks apart, what determines how that destruction unfolds? Is it fully physics-driven, partially authored, or some combination of both?

Thomas Williamson: Everything in SuperDestruction is fully dynamic. There is no pre-authored destruction in BeastLink. Every time you see a building collapse, that’s the first time it has collapsed that way. Every building is actually put together on the fly as you get close to it, so none of them are truly static content. Honestly, we’ve just scratched the surface in terms of what this system can do. We’re very excited about the possibilities as the technology continues to mature.

Many multiplayer games treat destruction as either heavily scripted or mostly client-side. What made you want to build a fully networked destruction system from the ground up instead?

Thomas Williamson: Looking back, it was probably hubris, hahaha. It’s been a huge undertaking that I can easily say we underestimated when we started out. However, the needs were clear. We wanted giant kaiju messing up a city in a big multiplayer game. And with our very small content team, we had to make it something dynamic and easy to iterate on. There was only one way to really make that happen: tons of work and experimentation.

You’ve said BeastLink supports real-time synchronized destruction across all players. From a technical standpoint, what were the biggest challenges in making sure every player sees the same destruction results reliably?

Thomas Williamson: Fortunately, this came inherently from the design. All destruction has to go through a simple thought process when networking: how much does this destruction matter, in terms of being an exact match for an individual player?

If a Kaiju is swiping its tail through a building 1,000 feet away, we can trust the player’s computer to simulate a good bit of it. Especially with context: that sort of destruction is going to make that entire building collapse very soon. The player doesn’t need an exactly correct result, just a very close one.

Now, if the player throws a grenade and blows a hole in a building in order to get inside, the results of that destruction need to be very precise. Heuristics are built into each game event, prioritizing each physical event in terms of player-perceived accuracy.  Finally, we have very fast correction techniques for each client to “check in” with the server to make sure they agree on the results of destruction, with quick and transparent corrections to the player.

One of the standout details is the scale: 250,000 destructible instances and nearly 14 million individual pieces on a single map. How do you approach building, organizing, and optimizing destruction at that level of complexity?

Thomas Williamson: Given our team size: LOTS of procedural generation! Each map is about 1 square mile (2.5 km^2). Our buildings, with some exceptions, are constructed from kits that automatically fill out exteriors and interiors. The artists can then go in and customize. They can specify window and trim patterns, replace ground-floor store fronts, and attach destruction props as dressing. 

Our trees and bushes automatically rotate, slightly scale, and have randomized coloration patterns. Anything to make the sheer amount of work of populating these dense maps, we’ve attempted.

There is a lot of custom work, of course, such as bridges, landmarks, etc, that just required a lot of manual effort to build into destructible assets.

Can you talk about how SuperDestruction works inside Unreal Engine 5? Which parts of the system rely on built-in UE5 functionality, and where did you need to create custom solutions?

Thomas Williamson: The very first iterations of it were close to pure Unreal. We used Niagara essentially as a compute shader, with lots of custom HLSL nodes. This drove a rendered lookup table that we used for fixed transforms on individual pieces in a Material Function. The destructible assets themselves are built using their fracture tool, then exported into a special kind of Static Mesh asset we created. Networking was a bunch of remote procedure calls back and forth between the client and server.

As the tech evolved, we made extensive changes, and now truly just use some parts of Unreal as a convenient glue to get the systems talking to each other. We have custom rendering of compute results directly into the GPU Scene Graph. We’ve added a bunch of functionality to Nanite to support tons of tiny dynamic subinstances without creating a bunch of memory overhead. Our networked physics consists of deterministic client/server calculations with custom data structures for passing results back and forth.

How do you handle replication and bandwidth concerns when so much debris, collapse behavior, and environmental change are happening at once in a multiplayer match?

Thomas Williamson: I will say specifically that the debris itself and how it collides with you is not hugely relevant to the physical results of the gameplay. We had to prioritize destruction in terms of how much the player would really care or notice.  It’s not that each piece is “simulating correctly” at you; it’s that there’s something making those pieces come at you. That’s what the player ultimately cares about. To quote Ron White: “It’s not that the wind is blowing, it’s what the wind is blowing.”

What does “total environmental agency” mean in practical gameplay terms? How much freedom do players really have to reshape the battlefield?

Thomas Williamson: Since everything is procedural and everything is destructible, the player is free to carve up the city how they see fit, down to the individual panes of glass. Weapons, vehicles, Kaiju, and other creatures can all cause destruction. The destruction is fully dynamic, so the environment is fully dynamic. This has been promised by so many games in the past. It’s very exciting to be here, making it a reality.

Destruction tech can often look impressive in a demo but become difficult to balance in an actual multiplayer environment.

Thomas Williamson: This is so true! Our game sessions progress in interesting ways with so much destruction and asymmetrical gameplay. While the stakes rise and the action gets more intense, the environment becomes more and more leveled. This removes corridors and protection for players, exposing them. We end up balancing the destruction with rewards and drops everywhere, so players who take risks have a chance to be increasingly powerful. 

We’ve made over a dozen game modes and playtested the heck out of each to find the best balance of sandbox, freedom, competition, and emergent gameplay. Most of them went in the bin, haha. We have a spreadsheet with, like, a hundred more game mode ideas. There are so many possibilities that it makes our heads explode. Playing the game, we know we’ve created something people just haven’t experienced before, but that comes with the legitimate fear of getting it wrong if we try to own everything about the game’s direction.

We’re counting on beta and early access players to get involved and give us great feedback. So I’m very, very stoked to get this game in front of more people who care, making the future of BeastLink a community effort.

What were the biggest performance hurdles the team faced while building SuperDestruction, and how did you work through them?

Thomas Williamson: The first problem was figuring out how to construct our geometry to break apart in a way that could be driven by the artists, but also physically behave. We ended up constructing a special mesh pipeline using Unreal’s Fracture tool and a custom mesh processor to embed only the necessary data to separate those pieces in an efficient format that could be read by both the physics engine and the renderer on the GPU.

The next big problem was how to efficiently get all the moving pieces from their computed physical position into the rendered scene, and then do that in an efficient way for global illumination and shadowing to be accurate. We came up with some interesting tricks based on the state of the physics. Global illumination in Unreal builds over multiple frames, so a fast-moving physical piece really doesn’t matter at all for GI, so velocity is important. Shadow invalidation is similar. We group our physical pieces into intelligent boxes that size based on actual movement in clusters, and just invalidate those shadow regions.

Did building a system like this change the way you approached level design or environment art for BeastLink?

Thomas Williamson: Yes, and I think our artists are still very angry at me when I told them the system just is not compatible with pre-placed decals. We do have some ideas to work around this in the future, but that’s an example of the sort of serious constraint that has bothered them. 

One other serious constraint is the sheer size of the data. It’s more efficient for us to store the data about how to construct and customize a building in the map in real time than to just store all the data of all those thousands and thousands of pieces in a file. This is very different from the traditional Unreal workflow and has caused a few of its own headaches.

What kinds of player behaviors or emergent moments has SuperDestruction enabled that would not have been possible with a more traditional destruction pipeline?

Thomas Williamson: There are so, so many. At the end of the day, though, this is a Kaiju game. There’s a special feeling to being a human, hiding from a giant lizard who is destroying a skyscraper, trying to get at you. You’ve got the resources to BeastLink with a sleeping Kaiju just behind him, maybe you could sprint through the building and between his legs while he is busy…

Are there any specific examples from BeastLink where destruction directly changes strategy, traversal, sightlines, or combat flow in a meaningful way?

Thomas Williamson: It’s designed to change ALL of these things from three different perspectives, actually!

As a Human, you have access to rocket launchers, grenades, rifles, etc. You can shoot through windows and doors to get inside buildings. Well, if you shoot through a window with a rocket launcher, the rocket will bust through the glass and destroy whatever's behind it, but you get the idea. These sorts of interactions give you the means to hide, to camp, or to burst into areas unexpectedly.

In a vehicle, whether it be a sedan, a tank, or a fixed-wing jet, you have to bust through all kinds of obstacles, or use areas as makeshift ramps, or deftly fly around collapsing buildings. You have to contend with the rubble from all the destruction that significantly affects the traversal of the environment. You’ll have to choose vehicles carefully depending on the terrain you're anticipating. A fast sports car makes sense for dodging falling buildings, but a slow SUV is better for navigating ground rubble.

If you’re a Kaiju, suddenly the destructible buildings in the map turn into a special ‘topology’. You gain XP and ‘mind sync’ from destroying buildings standing between you and your goal, but this takes time. You are possibly more susceptible to human ground fire in tight spaces while you clear an area. But in an open area, you can get around a lot more quickly. You’ll be more susceptible to open fire, particularly from flying vehicles, but other humans and vehicles will be able to grab and/or eat them. A lot of this is situational, and it’s different every time.

For developers reading 80 Level, what were the biggest lessons your team learned about building large-scale networked destruction in UE5?

Thomas Williamson: Not sure I would recommend it, to be honest! It’s been a scary development process because we made a game and a technology at the same time, and we didn’t know if today’s hardware would be able to handle it. Our gameplay wasn’t fun for a long time because of low framerates and server and network hitches, and it was pretty impossible to really know how it was all going to come together. But then it did. It took hundreds of separate great ideas to make this system fit together. 

I would say the biggest lesson we learned was more philosophical: if you have a big dream with big ideas, surround yourself with amazing people and get to work. I know I’ll always look back at this development cycle and think of the people I did it with and why, not necessarily the challenges we faced.

Thomas Williamson, CEO of Grove Street Games, Developer of BeastLink

Interview conducted by David Jagneaux

Don't forget to subscribe to our Newsletter, join our 80 Level Talent platform, follow us on Twitter, LinkedIn, Telegram, and Instagram, where we share breakdowns, the latest news, awesome artworks, and more.

Are you a fan of what we do here at 80 Level? Then make sure to set us as a Preferred Source on Google to see more of our content in your feed.