I wrote an article on the physics of MageQuit

DISCLAIMER: I COULDN'T FIGURE OUT HOW TO EMBED VIDEOS SO I RECOMMEND READING IT WITH VIDEOS HERE!

I miss the creativity of Warcraft III modding in the golden days of Blizzard Entertainment. I spent countless hours playing and developing Warcraft III mods. One of my favorite mods to play was called Warlock. Sometimes I wonder what my life would be like if I hadn't walked into my college housemate's room that day while he was playing it.

I became obsessed. The slowness of the wizards. The shrinking stage. The skillshots. The ridiculously slidey physics. I played many hours with my brothers and cousins.

Then came the Ouya. If you've heard of it, you probably chuckled just now, but this failed Android console and its eight-player support was the catalyst for the concept of MageQuit.

> Warlock, but with controllers and a shared camera.

The recommended development platform for the Ouya was Unity, so I jumped in. I knew the importance of slideyness in Warlock, but I struggled to recreate it in Unity. Let's go through these stages of grief together.

Stage 1: Character Controller

The Unity Character Controller is a simple "black box" solution to moving your character around and having them respect the colliders you placed in your scene. Almost every first or third person camera tutorial will start with one of these boys. But google "how to add velocity to a character controller" and you'll be saddened to see there's no such thing as velocity; you have to add it to the "move" function. However, the biggest reason a Character Controller is a bad fit for a physics-based game is that it's Kinematic, meaning it doesn't natively react to other physics objects. Even if you add forces to other physics objects artificially, they don't push back.

Stage 2: Vanilla Rigidbody

The rigidbody is how you add physics to an object in Unity. Want to simulate a tower of blocks falling over? Add rigidbodies to a bunch of box colliders and hit play. The problem with a vanilla rigidbody, though, is that the player has no control over it by default, and if you are overriding velocities for movement every frame, you are also overriding external forces which is similar to our issue in Stage 1 except that the rigidbody respects other rigidbodies. Additionally, ditching the Character Controller leaves us gravitationally challenged.

Stage 3: Unwanted Sledding

Because we wanted the land to get smaller over time, we opted to create sloped surfaces and slowly move the lava plane up during battle. However, relying on gravity to keep your rigidbodies on the ground means your characters are going to naturally "sled" downhill. The more you turn up the surface friction to fix this, the more you kill any chance at slidey physics.

Stage 4: Ground Check

The simplest fix for unwanted sledding is to only apply gravity when your character is in the air, and the simplest way to do this is with a Raycast. Shoot one of these downward from the character each frame and grab the distance between the character and the ground. If the distance is too large, apply gravity, otherwise "snap" them to the ground. The Raycast can also tell us if we are on land or in lava.

Stage 5: Splitting Velocities

That's great, but we still need to figure out how external velocity and movement can coexist. What if we track them separately? We could keep a persistent knockback vector that can be manipulated with game logic and a movement vector that's one-to-one with the player's controls, add them together each frame, and override the rigidbody's velocity with the result.

Stage 6: Custom Friction

Realistic physics simulations use something called Coulomb friction, which produces a sort of linear damping: a model that's far too abrupt to be considered "slidey". However, because we are now tracking our own knockback velocity, we have full control over how it behaves, and we can use exponential decay to make it extra slidey. Additionally, we know if we are on the ground or not, so we can also use different friction on the ground and in the air. For MageQuit, we used 0.96 for ground friction and 0.99 for air friction. This is why airborne players go much farther.

Stage 7: Movement Spells

At first, we were overriding the knockback velocity every frame when a player would use a movement spell, but this resulted in being able to completely nullify the knockback of an ultimate spell like Jetstream with a simple movement spell like Bullrush. The solution was to track yet another separate vector for spell velocity. However, because we didn't want players to feel like their movement spells were completely swallowed up by high knockback, we multiply the knockback velocity by 0.3 while a movement spell is active.

Stage 8: Physics Caching

I learned this much too late, but an important aspect of performance and reliability in Unity's physics engine is making sure, as often as possible, to only move rigidbodies using forces and velocities, so that the PhysX cache stays intact. However, since I was calculating gravity separately, I was only using velocities for the XZ plane, overriding the Y position manually, and essentially breaking physics caching every single frame for every single unit and projectile. In 2023, we released a patch that fixed this by taking that Y value and calculating the Y velocity that would get you there by the next frame. However, the suddenly "more correct" physics unearthed many other things that we were doing wrong, like spawning projectiles too low (they would get stuck in the ground randomly), Earth Tomb one-shotting mages through The Pit walls, and breaking combos that never should have been possible. The projectiles now spawn at a proper height, but it was the source of much grief for a while.

Stage 9: Prop Teflon

Remember how we're using Raycasts to determine the ground type? Well, there's a ground type I refer to as "prop" which is used for surfaces that we don't want players to remain on. These surfaces zero out the movement vector and apply a force in the direction of the surface normal. The Pit is surrounded by slightly tilted prop walls to gently bring players back in, and it resulted in this classic clip [mute if you don't like swears]. Calling this "orbit" is surprisingly accurate, mathwise.

Stage 10: Gratitude

Thanks for reading! This article was originally published on our Patreon and again I recommend checking it out there with the videos included because it's much easier to understand. Don't worry, it's a free article.

Love you, -Brett