I’ve identified the two separate implementation details that cause Thruster-Boosting (TB) to be more powerful compared to Grip-Flying (GF). In short,

1. GF suffers a 2% penalty to rear booster power which TB does not.
2. Thruster rampdown is generally slower with TB compared to GF. How much exactly depends on TB technique, though with optimal input can be around 50% slower.

### Definitions

• Thrusters: The four thrusters on top of the car.
• Booster: The car’s rear booster.
• Grip-Flying (GF): Using Grip (usually together with Boost) to fly through the air. Note that pressing opposite thruster directions simultaneously counts as pressing Grip.
• Thruster-Boosting (TB): Using the car’s thrusters (usually together with Boost) to fly through the air, without using Grip.

### Boost Power

The first of these implementation details is in the code for `BoostGadget` (the car’s booster). The following is the relevant snippet:

``````if ((this.carStats_.WheelsContacting_ > 0 && (Mathf.Abs(input.Pitch_) > 0.1f || Mathf.Abs(input.Roll_) > 0.1f)) || input.Grip_)
{
force *= 0.98f;
}

// Apply force to car
``````

What this code does is reduce the boost force by 2% under certain circumstances, before applying the force to the car. Carefully reading the condition inside the if statement reveals that the force is always reduced to 98% when grip is held, while it’s only reduced for TB when at least one wheel is contacting a surface. So the first advantage of TB over GF is that it doesn’t suffer from this 2% loss in booster power.

### Thruster Rampdown

To understand this second effect, we must know a bit about thruster rampdown.

Thruster rampdown is the mechanic where thrusters lose power over the first few seconds of their use while in the air. Power starts at 100% and goes down to 40%, where it remains until the car lands, at which point it goes back to 100% (at least a single wheel touching a surface is considered landing).

In the code, the field that keeps track of the rampdown is called `thrusterBoostTimer_`. A value of `0.0` corresponds to 100% power, and a value of `2.0` corresponds to 40% power. The line of code that updates this field looks like this:

``````this.thrusterBoostTimer_ += Mathf.Clamp01(downforce / 52.5f) * dt;
``````

`Clamp01` simply clamps its argument to the range [0, 1]. `dt` is `0.01`, as this code runs 100 times per second. The value of `downforce` depends on whether or not Grip is held, and on the thruster inputs. In the case of GF (holding Grip, no thruster input), `downforce` is `52.5`, and so the expression reduces to

``````this.thrusterBoostTimer_ += dt;
``````

which means the timer is incremented at a rate of 1 per second, and so it takes 2 seconds to reach the value `2.0`. So with GF, thruster rampdown happens over 2 seconds.

With TB though, `downforce` depends on the thruster inputs. Pure roll gives `26.0`. Pure pitch gives `52.5`. We can get any value in the range [0, 58.5854] with the right thruster inputs. The fact that smaller values of `downforce` will cause the timer to tick slower is key, as you’ll see.

These two lines of code immediately follow the previous:

``````float t = Mathf.Clamp01(this.thrusterBoostTimer_ / 2.0f);
downforce = Mathf.Min(downforce, 52.5f * Mathf.Lerp(1.0f, 0.4f, t));
``````

What these do is cap `downforce` down to the appropriate value for the given `thrusterBoostTimer_`, implementing the thruster rampdown effect. So, for a given timer value, there is a maximum value `downforce` can be at after being capped. Any extra downforce we had over this limit has no effect on the force the car receives.

So in the case of GF, during the first 2 seconds during which the thruster rampdown occurs, we are causing the `thrusterBoostTimer_` to tick down needlessly fast by inputting a constant `downforce` of `52.5` into this capping code. For an optimal TB technique, we’ll want to input just enough `downforce` based on `thrusterBoostTimer_` so that none gets lost in the capping step. It turns out with this strategy we can make the thruster rampdown take 3.04 seconds instead of just 2, prolonging the time we have stronger thrusters.

It’s clear that the common TB technique of simply spinning the gamepad stick is far from ideal for controlling the amount of downforce we’re inputting. As are keyboard controls, with its lack of analog control.

I implemented the optimal TB idea as a Spectrum mod which tweaks my controller inputs. It should be possible to implement it purely as a kind of macro outside the game though; making a Spectrum mod was simply more familiar. The way the mod works is it replaces the grip button with an optimal TB button. While the button is held, the mod alternates between sending pitch up and pitch down inputs on each physics frame (which is 0.01 seconds long). The magnitude of the input is chosen such that `downforce` is set to the optimal amount, as described above. With a bit more code to properly combine the generated input together with any thruster inputs the player might be giving, the car has the same feel as with normal grip.

### Testing

I used the level [NWBO] Simply Straight to do testing on. It’s a short track consisting almost entirely of a straight GF/TB section. I currently hold the world record on this track with a time of 15.81 seconds, which I get using GF. Prior to the leaderboards being wiped when the game hit v1.0, Tiedye had the top spot with a time of 15.7x seconds he got with TB (I don’t remember the hundreths place). Using my optimal TB mod, I was able to get a time of 15.56 seconds (not uploaded to the global boards of course).

Technique Time
GF 15.81
Tiedye TB 15.7x
Optimal TB 15.56

I also made my own test map, “TB Test” (not published), which is an even simpler map. These are the results:

Technique Time
GF 14.60
Optimal TB 14.45

Given that the flying section is only about 6 seconds long on that map, a 0.15 second improvement is significant.