Vehicle System The pains of writing your own vehicle system

Making a vehicle system isn't easy, especially when we don't have access to server-side physics functions. In this post, we'll talk about the problems encountered when making a purely client-side vehicle system.

Tom O'Sullivan

4 min read

As some may already know, gKarts is supposed to be an easily scale-able gamemode. With that in mind, it means that we're bound to some very heavy limitations, especially when we're using our own Source Engine server "gRust" (see our post explaining this here). Many things become suddenly impossible to achieve when your server has no idea what physics is, and that means it's up to your client to piece the puzzle together.

So what's the solution to this?

Well, the answer is client-side physics.

This means that we can take an extremely heavy load off of our servers, but at the cost of trusting the client a bit more than we'd like (we'll talk more about this at some point). It also allows us to do other fancy things on the client, like allowing controller and steering wheel support, zero input latency, and much more lighter networking.

So what's the catch?

It's a big one, so let me explain...

By processing all vehicle movement and physics on the client, we create several problems that need to be solved:

  • Constraints (weld, ¬†springs, motors, etc) can't be created by the client, so suspension and wheel rotation becomes our problem.
  • The PhysObj class in gLua doesn't give us a lot of useful data, so certain physics equations (eg: terminal velocity) become impossible to solve.
  • Parented entities don't have physics, so making an entity per wheel is as effective as having none.
  • Physics manipulation through gLua can be inaccurate at times, so we need a way to correct it.

How were these problems solved?

By a lot of time and pain, to be accurate.

After roughly a month of research and development, involving a lot of trial and error and investigation into existing games, we came up with a few conclusions:

Firstly, we decided that the only way for this to work would be to essentially "fake" the interaction of wheels with the ground. By that I mean we're going to have to pretend the wheels are doing stuff with the ground, when in reality there only touching the ground visually and not physically, sadly. This will work by making the body of the kart "float" slightly, whilst lowering the wheels visually to make them look like they're making contact with the ground.

We then looked in to the physics related problems that gLua loves giving us. It quickly became evident that screaming at Facepunch to add more physics functions to gLua wouldn't actually get us anywhere. So the only decent way forward is to rewrite how physics works entirely, I guess we could call this "gPhysics". Anyway, as we're only really trying to manipulate one physics object it shouldn't be too difficult to implement all the physics equations we need for it. With this being the case, it'd give us much more power over what we can do with physics and hopefully avoid more "botch fixes" around Garry's Mod's quirks.

Of course, with these conclusions comes a lot of work and number crunching yet to be completed. But it'll slowly come together to become a well made, lightweight and enjoyable gamemode.

So what does it look like right now?

Well to say the least, it doesn't look too impressive, so prepare for a massive disappointment...

A short video demonstrating current progress on gKarts vehicle movement.

As you can see in the video above, the vehicle system is far from complete. In fact, with new problems being found every day, it gets rewritten all the time (5 times so far to be precise). Each time learning at least one new and important thing and usually ticking off an item or two from the to-do list.

The current system implements an incredibly basic camera handler, supporting first and third person, although we expect to redo how the camera is handled entirely in the future to make things more modular and allow for smooth transitions.

The next notable feature is the movement input, this is probably the only thing that won't need to be redone, as there's not exactly many better ways of listening for key-presses. However, it may be expanded upon in the future by implementing the controller support mentioned earlier, along with sensitivity and steering linearity configuration.

Animations haven't entirely been looked at yet, but as shown in the video you can see the steer rotation has been hooked up to the movement system. Nothing else has been implemented as of yet, but we'll be making the wheels roll according to the kart's velocity soon and then add individual wheel suspension animation shortly after.

The final point to talk about on this preview is movement and physics. Currently, we're implementing our own gravity. It allows the kart to stick to walls and ceilings, which will open up new opportunities for maps in the gamemode and expand our current feature set. The other part to this is the very obviously unfinished movement, we're simply lowering the friction of the kart body and applying forces depending on the user's input. This clearly isn't going to be anywhere near to how it's done in the future, so next time round we'll have something at least a little more impressive.

Cool & useful finds

During the past month or so we've found lots of cool existing content on kart racing games and other useful stuff, here's a brief overview on some of our findings:

  • Mario Kart Source - This is a really cool project none of us knew about when starting gKarts, but sadly it shut down in 2012. All of the source code was released along with all the models, materials and maps, this leads us on to the next cool find...
  • Mario Kart Source: Maps Pack - This pack is a Garry's Mod port of most of the maps features in Mario Kart Source. It will likely be used in gKarts for tracks you can play on. The other notable thing from this is the test map (seen in the demo video), this will be extremely helpful when working on the vehicle system.
  • Tower Unite: Accelerate - Playing Tower Unite's Accelerate gave us a rough idea on what we want to achieve. We also did a bit of investigation on how their karts work, and took note on some of the pros and cons to doing it the way they are.
  • simfphys - Although most people already know of it's existence, it was nice to see how we would have been able to make our vehicle system. Sadly, none of the source code will actually be of use to the gKarts project.

So what's next?

Over the next week or so we'll be working on rewriting more of the physics which will lead on to making the movement feel much more realistic. Stay tuned to see how that turns out, and until next time, stay safe.