And yet physics has given him an enormous amount of grief over the course of TABS’ development - as well as all the other games he’s made at Landfall. Physics, after all, makes everything harder. “If you want to do something in the game, you need to figure out how to do it with physics instead of just doing it,” he tells me. And that’s why TABS, which is all about watching ridiculous parodies of extreme violence, is great. Take standing. For TABS, even standing is the result of intricate physics systems. Each unit is a ragdoll which naturally tries to collapse in a heap on the ground, since every body part has mass which the game’s gravity continually pulls downwards. So to get a unit to stand, Nylund adds upwards forces on its torso and head which act like a marionette’s strings, pulling it upright. To ensure a unit only stands when there’s ground directly below it, he shoots a raycast with a length of around the unit’s height directly downwards from its head. Only if the raycast hits the ground is the upwards force added. Then, to make the unit stand firmly on its feet, the game checks whether its feet are touching the ground. If they are, then it checks how far the point of connection is from the head. The closer the head is to the point of collision, the more force is added, compelling it to stand up more vigorously; if it’s fully upright, then it gets less upwards force.
Then, to give the unit the sense that it’s balancing on its feet, Nylund gives it a script which also works out when the unit should fall over. This script checks the mid-point of the unit’s feet and compares it to its centre of mass. When perfectly balanced, the two should align. But if the unit is, say, leaning forward, the mid-point between its feet will be behind its centre of mass and it will fall forward. To correct that, the script will pick up a foot and move it in the direction that’ll bring the mid-point closer to the unit’s centre of mass. So that’s standing. Now walking. Most body parts have a script that take a role in walking motions: the thighs pendulate back and forth; the feet are subject to upwards and downwards forces. “So, when the right leg should be moving forward, the thigh rotates forward and gets some force added upward,” Nylund explains. “When that leg is going backward, both forces are inversed, so the foot pushes into the ground and the leg rotates backwards.”
All these movements are accompanied by other tweaks, such as the friction of the feet, so they appear to grip the ground when they’re planted. “We also make the leg and feet really slippery so they have an easier time reaching their forward point,” he adds. That’s so they don’t get caught up on other body parts as a leg steps forward. “There are so many systems! I think we might be at iteration six or seven in total reworks of the animation system. We even threw out the entire codebase twice and started from scratch.” Naturally, TABS’ combat is also led by physics. Damage is calculated from the force a weapon collides with a body, checking if that body part has any damage reduction statistic, and then adding various multipliers. While a club only does its collision force in damage, a sword does five times the collision force. For the spear, if the collision happens within 20 centimetres from its tip, it does 10 times damage, but if it hits with the stick, it does much less. Physics governs how a unit holds and swings its weapon, too. The point at which the unit’s hand holds a weapon is a joint that locks it in place. Then every weapon has a relative position with the torso that it wants to be held at. The sword wants to be in front, so force is applied to keep it there. “It’ll wobble around bit, but it always tries to stay 50 cm forward from the torso,” says Nylund. Then it has a relative rotation it wants to stay at. The sword likes to point upwards, while the spear always wants to be rotated so it points forward. To swing a weapon, a unit first saves the direction in which it wants to hit, which generally goes from the point of the weapon – what Nylund calls the force point – to the enemy’s torso. Then, it defines the swing’s force with an animation curve. The curve starts at zero, then usually curves downwards for a moment, adding to the tip force away from the target, and then rises high, adding lots more force towards the target. “You get a bit of a wind-up, a tell that they will make a strike.” Where the force is added depends on the weapon. While the sword’s swing is led by its tip, the first swing of monk’s bow staff is led by one end, and then it switches to the other for the next so it alternates.
All of this is the work of years of trial and error, of Nylund feeling his way through systems. Or as he puts it: “It’s a lot of fighting with the physics to get the look you want.” There are so many variables involved in simply getting a solider to hold a sword correctly. “It could be what angle the hands are, how much the weapon weighs, how much force it needs to stand upright, how the joints for the hands to the weapon are set up, how stiff they are, do they have lenience in the angle they’re connected? Any of those things could be the right thing to change, but you can’t know without trying it.” But not everything in TABS is down to pure physics. While the massive boulders thrown by catapults are all physics, smaller projectiles like arrows and musket pellets are not, because of a classic problem that games face with collision. It goes like this: every frame, TABS checks to see if objects are colliding with each other. But if an object like a musket ball is small and moves very fast, there’s a good chance that a moment it collides with a given object will never coincide with a moment the game checks collision. The result is that they can easily clip right through objects. So the trajectory of TABS’ small projectiles is not frame-by-frame simulated. Instead, each frame the game steps the projectile along a path and then draws a line backwards to see how far it’s come since the previous frame. If the line collides with an object, then TABS knows they hit. They’re not physics objects, but Nylund has made them look like it: arrows can stick in a target, and, courtesy of some extra code that simulates a physics joint, they’ll even wobble realistically when it moves around.
But this solution still caused some extra messing around for Nylund when he came up with the samurai, a unit among the Dynastic faction. A way into developing the faction the team realised that it didn’t have an answer for ranged enemies. “They would lose against archers every time.” So the team thought, hey, wouldn’t it be good if the samurai could hit projectiles out of the air? The question was about how it’d work. Nylund’s first thought was what you’d imagine. “Have the samurai keep track of projectiles that are nearby, and if one gets too close, it does a swing animation towards it and sends it away.” Since TABS can have a lot of projectiles in play at once, perhaps the samurai could track them every frame by consulting a list? “But that’s a very performance-heavy way of doing it! And also, this system for the list would add some complexity which we didn’t really need before.” So the samurai’s deflection in fact works by placing an invisible sphere around the unit which only affects projectiles. Everything else can go right through it but projectiles will bounce away, with the samurai performing a swinging animation which is fast enough that in the heat of battle it looks like it’s reacting to the projectile, but not so fast that it throws the samurai off its feet. (Physics.)
But some physics have so far proven impossible for TABS. Nylund would love to add a ball and chain and nunchucks to the game, but these weapons consist of more than one connected physics object. One object starts affecting the other, and then the second one reciprocates… It’s the mathematics equivalent of acoustic feedback. “It very quickly starts getting very unstable. I’ve tried a few times to make those weapons, but either the swings would be so slow that they don’t look interesting, or if you made them fast enough, you’d see the parts of the weapons would be dragged apart and shake.” It might be frustrating, but at least it’s an understandable limitation. There’s one physics problem, however, that he’s never solved. Stick Fight: The Game is a 2D fighting game that Landfall made before TABS. It runs in a slightly earlier version of Unity’s 3D engine, and since it’s 2D, Stick Fighters’ game objects, from its fighters to the stacked towers and bridges of boxes which fly apart during a melee, are all constrained in the Z-axis, so they can only move up and down and left and right on the screen.
But no matter what Nylund did, he found the boxes would slide apart without any provocation. It was a big problem, since it meant it wasn’t possible to make levels by stacking boxes. The only reason Stick Fight is playable is down to what Nylund calls, “probably one of the most hacky solutions that I’ve made.” Everything in the game is sandwiched between two invisible and frictionless planes, placed a metre apart. Nylund laughs at how ridiculous it is to add an extra dimension of collision to solve collision problems elsewhere. But it works. He wonders if the problem is caused by constraining the Z-axis. “It’s not allowed to change the values in one of the axises to solve collisions, so maybe that motion somehow just stays and amplifies and it never goes, and eventually it starts affecting the two other axis?” Whether his theory’s right or not, one comforting thing is that the problem also exists in Unity’s entirely new implementation of its physics system. So at least it’s an absolute, a law of contemporary game physics. It helps, too, that Nylund is, by now, used to its subtle and unknowable chaos. “It’s so much a black box. So many things are happening that it’s not possible to actually understand, as far as I know, why something happens.”
