Road Not Taken: Godot’s VehicleBody in Hovertank22

It’s no secret that I’ve been captivated by trying to make vehicle driving feel good for as long as I’ve been programming. Initially Hovertank 22 (formerly OWTD) used Kinematic movement as described here. But it wasn’t quite right. I have a strong memory of how much more fun World Of Tanks was after they introduced proper physics. I decided that if a third person perspective (as oppose to top down) was going to be used, I should probably use some sort of physics.

In Godot you have at least two options: the ‘easy’ one, using VehicleBody and the hard one, using a bunch of 6DOF joints. I elected to use the former, in this barn-burner of a PR. And it… well it sort of works, I guess.

As you can see, though wonky, the Tilter is able to navigate the terrain. It’s using a single visible steering wheel in front and the tracks are represented by two invisible wheels in the back. This movement model is, of course, built for car driving games, so the trike configuration cuts into the stability badly. The requirements of “Eamonn’s Ideal Vehicle Game” and thus Hovertank 22, however, call for tanks. Unfortunately, this has major disagreements with the movement model.

The basic idea, I figured, for implementing tank movement has been to treat each track as a series of wheels. To turn right, you drive the wheels on the left side and brake or reverse the wheels on the right side. In a real tracked vehicle, this causes it to turn. In Godot’s model, however, wheel slip seems to be very all-or-nothing: the vehicle stays in motion nicely but as soon as you cut the wheel and one track slips, the whole vehicle starts to drift uncontrollably. While some amount of drifting was desired, this turns out to be unplayable. And, worse, messing with wheel slip values didn’t really help.

Editor screenshot showing how the Cobra’s wheels are configured

Another problem with this movement style was that when the vehicle was in motion, differential steering worked far more effectively than from a dead stop (I assume that this has something to do with how overcoming friction is coded.) In order to turn from a stop you need to overcome the friction of all of the wheels, so turning while stopped was impractically slow. I implemented a fix which increased power when you weren’t moving but it was unsatisfactory and resulted in a vehicle that jerked around suddenly and violently.

I suspect that customizing the 6dof version might be able to overcome these limitations, but I don’t have the bandwidth to try it. Similarly, it might be very possible to implement this sort of thing as a custom integrator and bunch of rays, but again, that was more of a lift than I had time for.

Faced with basically a negative result from this experiment, I’ve decided that I’m going to roll back (ha) from the VehicleBody approach. I may switch back to a top-down perspective, and also may try switching out heighmapped terrain for tile terrain.

So what did I learn from this little excursion? You really need to validate your assumptions about how something is going to behave before you stake a project on it. I’m glad I didn’t fully do that (I still have a path forward for Hovertank ’22), though pulling it out is definitely going to be a setback.

Leave a Reply

Your email address will not be published.