I like cars. Well, to be more precise, I like driving them, and trucks, vans, forklifts, and tractors too. It's not the power or the speed, but the visceral interaction that gets me (If only there was a japanese car maker with a very specific word to describe this feeling).
Therefore, it shouldn't come with any surprise that as soon as I installed Unity for the first time, the first thing I googled was:
But just after that I searched how to make a car, and then again how to make it move. At last I went after the simplest possible camera followscript, which was very quickly modified because a camera completely fixed on a gameobject is not very cash money to look at.
Results were encouraging. So much so, that in the excitement of the moment every notion on screen recording was forgotten.
This is of course magnificent, but problems would soon arise.
As everyone else who has ever tried to make a vehicle in Unity, early on I started noticing that the cars were jittery, generating strong vibrations even with no player input, and rather undrivable.
// Imagine motion sickness-inducing footage //
So, just to be quick, here's a non-exhaustive list of the tested solutions that didn't work:
- reducing physics time step;
- increasing spring/suspension stiffness;
- using bigger/smaller wheels;
- activating/deactivating rigidbody interpolation;
- trying every combination of rigidbody interpolation.
At this point I noticed that AI cars were not showing any problem (well, apart from constantly crashing into walls). It took me a while to get my head around this, because the difference between player cars and AI ones was not on screen, it was (and still is) behind it.
No, not the player, the camera. In particular, the "follow target" behaviour of the camera. A quick test setting an AI car as the camera target proved my suspicions.
So, you may ask, what was happening? Well, the aforementioned script modified the camera transform and accessed the target rigidbody at every frame, thus forcing rigidbody interpolation anyway. This, combined with the fact that apparently interpolation works on everything but vehicles, made for very anger-inducing results.
The solution was accessing the target rigidbody variables only on the physics update, while keeping the camera transform movements at every frame to improve smoothness.
And now, a rundown of the different drivable vehicles in never sunset racing project. There are not a huge number of wheels available, but I think it's much more important to have a few very different cars, rather than a million similar ones with different textures.
The Mouton is untamed, uncontrollable, and unstoppable. It's been thought as an all-road go-kart, which means it's very good to reach every roof and mountaintop, but requires quite a substantial amount of patience.
The Grandtour is the champion of old-school european sports-cars: rear wheel drive and very very very beautiful to look at.
The Bastille is epitome of frenchness, and can deliver all the grandeur you might want. It has soft suspensions and a long wheelbase. These mean that it's not a particularly speedy car, but it's easily controlled and makes for a relaxing ride.
The deMeo is a van, simple, no-nonsense, and reliable. It's front wheel drive and very prone to tipping on the side. So, yeah, it's ridiculous to drive around.
The Cali4nian is a rugged american pick-up truck to rule every road. And in "every road" the sky is included too, because for reasons unknown it flies pretty good, for a brick.
The Sweden takes inspiration from the real-world rugged, mine-tetsted, trucks. And some may ask: then what is its purpose in a city-set game? And the answer is: it redefines the idea of rush-hour.
The Wolf has been designed with a simple idea in mind: what happens if you race a really long lorry against other really long lorries? I don't know the full answer yet, but it contains a drop of despair. 10/10
Thanks for reading all the way through, and feel free to comment here or trash the game on Twitter OptergSoftware (@opterg) / Twitter