Destruction in video games

What would video games be today without the ability to destroy the environment? Battlefield would be less spectacular, Rainbow Six Siege would lose much of its strategic appeal and Control would be less satisfying. Today, destruction plays an important role in many games. This article is a quick overview of the different types of destruction, how they work and the different ways of synchronizing them on a network. The focus is on 3D, but much of what’s described here can also be applied to 2D.

I — Physical simulation

Every game has different needs and capabilities when it comes to implementing destruction. Some need precision, others need realism, and some want a simple decorative feature with low performance costs. There are different methods for all these needs. Each has its own benefits and drawbacks, and is useful in specific cases.

Static Destruction

Static destruction is the separation of an object into several elements in a deterministic way. Whatever happens, the destruction will always take place in the same way. This is a pre-fragmented type of destruction. In other words, the 3D artist separates the mesh of the 3D object into different parts in advance. When the object receives a sufficient amount of damage, the parts break off and become debris. The main advantage of this type of destruction is its low performance cost, enabling it to be used on low-end machines such as smartphones and handheld consoles. It’s also quicker to develop, which is the main reason why you still see it in so many games. But the big drawback of this technique is its low realism and the little freedom it offers to the player.

Static destruction is still very useful in specific cases, such as in the Battlefield series, where the collapse of buildings follows this system. One might well ask why a game with such a big budget doesn’t use more realistic destruction. Simply because the developers need to know the final result of the destruction to anticipate what they call levolution (the evolution of the level over the course of a game). This also allows the artists to create more spectacular destruction.

Dynamic destruction

Dynamic destruction is the destruction of a pre-fragmented mesh whose outcome is calculated in real time. We don’t know in advance what will break and how, but we do know the shape of the debris and its granularity. Today, this is the technique most commonly used in AAA games, as it combines a high degree of freedom for the player with reasonable computing costs. The way it works can vary greatly from one physics engine to another. In this article, we won’t go into detail about how each engine works, but rather focus on the common basics that can be found just about everywhere (in NVidia Blast, RealBlast, Chaos, Havok, etc.).

Fragment mesh efficiently

When creating a destructible mesh, developers need to define the various detachable parts in advance. Artists manually define the main parts of the object. Then, depending on the engine used, the sub-parts are either generated automatically (Chaos) or manually. In the case of the Chaos engine, artists are provided with fracture patterns which subdivide the parts. They can then redivide them if they wish, thus creating clustering levels. The idea is to break down the main object into larger elements, which then become independent objects and can in themselves be broken down, and so on from level to level.

Damage computation

When the mesh is ready, it can be damaged. There are several types of damage: impact damage, area damage and constraint damage. Impact damage is the simplest: the affected area is the only one to be subjected to force, and if this force is sufficient, the shape will break away. Area damage, on the other hand, can affect many parts simultaneously. In addition to applying force, they can weaken or break the links between parts. The result is not the detachment of a single large block made up of several parts, but rather the detachment of several blocks, some of which may still be linked together if their link is not broken. Finally, stress damage is useful in the case of objects with “weak” points liable to break if too much force is exerted on a part of the object. For example, if too much force is exerted on a table, the leg attachments are likely to break.

Implementing destruction

When the mesh takes damage, it follows rules that dictate what should break and how. The various parts of the object are represented by nodes in graphs. They are linked together by what’s known as a support graph or connection graph. In this graph, if a node is no longer attached to the others, then it becomes an independent object subject to gravity and the other laws of physics – it becomes a rigidbody. This graph can include anchor nodes linked to static objects. When part of a graph no longer has any anchor nodes, this sub-graph becomes a rigibody and collapses.

Procedural destruction

Procedural destruction is a change in the state of an object generated in real time, the result of which is unique. Unlike the methods detailed earlier, the object is not fragmented in advance. This technique requires a great amount of computation for each destruction, and is therefore not yet widely used, even in AAA.

In Rainbow Six Siege, the destruction of walls, hatches and floors must be highly precise and efficient. It plays a very important role in the game’s mechanics. A shot into a wall must create a hole the size of the bullet, not open a large breach. The explosives available with certain characters must also make very precise shapes in walls (Termite, Hibana) so that players can accurately predict the result of the explosion. As a result, surface damage has a very fine granularity, as the exact shape and area of destruction are unpredictable in advance by the developers. In the models seen previously, the parts of the destroyed objects remain large enough to keep calculation costs reasonable. Rainbow Six Siege’s developers therefore had to implement a method for very precise procedural destruction with limited computational requirements: procedural surface destruction.

In Rainbow Six Siege, the destructible elements of great importance to gameplay are all flat surfaces. It’s therefore quite simple to project the 3D model onto a 2D model, significantly reducing the cost of calculations. When the surface is damaged, a cutting pattern is generated according to impact position, impact type, material parameters, etc. …. The generated pattern is then subtracted from the 2D surface. Before the visual can be projected in 3D, the new surface must be triangulated.

Triangulation is the process of cutting a polygon into triangles. Triangulation is a step in convex decomposition, which consists in ensuring that all polygons on the surface are convex and not concave. Concave shapes greatly complicate collision calculations and are not supported by most physics engines. To triangulate the surfaces, the Rainbow Six team used the best-known algorithm, Ear Clipping. This is a fairly simple algorithm that iterates over all the vertices of a polygon. It looks to see if the two vertices adjacent to the current vertex can be joined together to form a triangle contained within the main polygon. If so, the two vertices are connected and a new triangle is created.

Many games that use destruction are online multiplayer games. After having described the general operation of local destruction, it’s time to talk about how it works in multiplayer games.

II — Networking

Using physics in an online multiplayer game poses a number of challenges. It has to give identical or almost identical results on all machines, while saving bandwidth to work on all types of connection. As destruction relies heavily on physics, it suffers from the same problems. There are different ways of synchronizing the state of an object on the network, each with different constraints and advantages (latency, precision, bandwidth consumption, etc.).

Deterministic Lockstep

Deterministic lockstep is the simplest and most bandwidth-efficient method. But it has some major flaws. It is based on sending inputs to all players. Inputs are actions that influence the environment. For example, if a character pushes a crate, he will send a message saying that he is pushing the crate in a certain direction with a certain amount of force. The receivers, for their part, will apply the force and direction received to the crate. The problem with this method is that the system must be deterministic, and physics engines are generally not deterministic (particularly due to the rounding of float numbers). Even though the result may be visually close, there will always be a collision or speed calculation that will cause the final result to differ slightly. In addition, a deterministic system implies that inputs are executed in the right order at the right time.

How it works

How can we ensure that inputs are executed in the right order on the client side and at the right time? To get the right order, all that’s needed is to number the data packets sent, and the client (the software that sends requests to a server) will follow the numbering for execution. But the slightest packet loss risks breaking the system’s determinism, as the client will be missing information. The most obvious solution to this problem is to use the TCP protocol. This protocol requires the client to send a confirmation when it receives data. So, if the sender doesn’t receive a response from the client after a certain time, he can send the data again. This ensures that all customers receive all information. This solution isn’t perfect, however: a loss will slow down the game. A technique using the UDP protocol solves this problem. This protocol doesn’t wait for confirmation from the client. The sender sends a list of inputs that he thinks the receiver has not performed. When the receiver performs a simulation, it tells the sender: “Don’t send me any more inputs x, I’ve already used them”, thus avoiding unnecessary resending of an input that has already been performed.

Once the inputs are executed in the right order, it’s a question of making sure they’re executed at the right time. To do this, we need to use an Input Delay Buffer. The client will accumulate the inputs received in a buffer, putting a precise time or number of frames (delay) between the application of each input. The client will have a fixed latency with respect to the sender. If packets are lost along the way, this causes a delay for the client, forcing it to reduce the delay between input applications to “catch up”.

In our case, this can be useful for static destruction, because as we saw earlier, this is a deterministic type of destruction. The only important information is the amount of damage received and the state of the object (destroyed or not).

 

Usage in Rainbow Six Siege

This seems to be the method used for Rainbow Six Siege’s procedural destruction. To ensure the determinism of their system, the developers use a random number generator (RNG) based on information such as impact position, weapon type, etc…. This number will be sent as an input to the network, and all machines will translate this number in the same way and apply the destruction locally. In R6, the order in which destruction is applied is very important. If one hole is applied before another, this can completely change the shape of “composite” holes. These are gaps that open up in walls when several pieces of damage are physically close together.

As a highly competitive game, the result of a shot into a wall has to be very fast. The shooter needs instant feedback. The problem is that if you apply damage and destruction immediately, you break the determinism of the system. Indeed, there may be information in transit on the network that we’ll receive after applying the destruction. The solution is to apply the destruction effect instantly (a simple hole for a bullet) and wait for the server to return to apply the real damage to the walls (which may lead to the formation of composite holes). This solution isn’t perfect, and it’s possible that the player ends up with a very slightly different state from the other players, but it’s minimal enough to be ignored.

Snapshot Interpolation

Unlike determinitic lockstep, snapshot interpolation doesn’t require each client to perform the physical simulation on its own. Instead, it’s a system in which the host regularly sends a scene update to all clients. The clients then simply have to wait for the information packets and interpolate between two updates of an object’s state. Interpolation is the process of approximating the current state of an object between two known states. Without interpolation, objects would teleport each time they received information.

There are several types of interpolation. The simplest is linear interpolation, in which a straight progression is made between two states. What we’re interested in here is Hermite interpolation, which, in addition to taking a start state and an end state, takes other parameters into account to be as close as possible to real movement. For example, if a player is running in one direction and the client receives two positions where the player has a different speed, it will take the speed into account and make the player credibly slow down between the two positions. With linear interpolation, it would have made him move forward at a constant speed.

The main problem with this technique is its bandwidth cost, since the more objects there are, the more information needs to be sent. Fortunately, there are data optimization and compression techniques that make it possible to achieve an affordable cost. We won’t go into detail here, but if you’re interested you’ll find plenty of information on www.gafferongames.com.

Snapshot interpolation is the most widely used physics technique in the industry today. In example, it is the default method for the Source engine (Titanfall, Left 4 Dead, Portal, etc.) developed by Valve. But when it comes to pure destruction, it’s not very useful, as you can’t interpolate the destruction of an object. A part doesn’t disappear gradually, but is usually either present or destroyed (or in motion, in the case of debris). It is therefore only useful for debris management.

State synchronization

State synchronization is, as the name suggests, based on the synchronization of states. A state includes everything that is visual for an object (position, rotation, etc.), but also everything that is not (linear velocity, angular velocity, etc.). Physical simulation is carried out on each client, but one of the clients or the server itself is designated as the object’s “owner”. This client is the authority on the object’s behavior. When one of the clients performs a simulation on an object it does not “own”, it sends the state it has obtained and waits for a response from the server to know whether it should correct the object’s state. The correction is made immediately, without interpolation. A person who does not “own” an object extrapolates the state of the object between 2 “official” states received. He extrapolates the object’s evolution using the last state received.

How it works

State synchronization is a technique that does not synchronize the state of all objects at once. Priorities must be determined. The player’s avatar, for example, will be updated very regularly, whereas an object unlikely to move will rarely be updated. To effectively define the importance of updating an object’s status, we can use a priority accumulation system. Objects gain priority (more or less quickly, depending on their importance) over time. When they are updated, their priority drops to 0. This ensures that even the least important objects are eventually updated. One of the advantages of state synchronization is its predictable bandwidth consumption. We can easily determine in advance a fixed number of states and inputs to be sent over one second.

Even if the sender sends the reports on a regular basis, the client will not always receive them at the same frequency. If the client applied the states as soon as they were received, and then received, say, 4 packets at once, it would run the risk of seeing objects make crazy movements. To avoid this, it has a jitter buffer which stores all the states to be applied. The client will wait for a precise moment specified in the received packet before applying the state correction. State updates are then regular and predictable. It doesn’t matter if a packet is missed, as a new state will quickly replace it. For this reason, it’s best to use the UDP protocol.

State synchronization is a technique used in many games. For destruction, it can be used in the case of dynamic destruction, where the most important thing is to ensure that all players have an object in the same state.

Network physics is complex and remains an important field of research. There are many other techniques besides the 3 mentioned in this article. Most of them are based on the same principles. For example, the lockstep protocol is close to state synchronization, but here everyone is an authority. Clients must agree on the state of objects in order to move the game forward. It’s not uncommon for games to use several techniques, depending on the needs of each object or game mode. For example, Halo 3’s co-op campaign mode is based on asynchronous lockstep protocol , while its competitive multiplayer mode is based on state synchronization.

 

Conclusion

This overview of destruction in video games comes to an end. I hope you’ve learned as much as I have in the course of preparing this article. I’ve only touched on the basics of a very vast subject, closely linked to the physical systems of games, about which there is also a great many things to say. If you’re interested in the subject, don’t hesitate to take a look at the sources of this article.

Any questions? Corrections? Any suggestions? Leave a comment below.

This article is part of the Real-Time Techs series dedicated to popularizing real-time rendering and simulation methods used in video games. Don't miss any future articles: Twitter / Mastodon / Bluesky.