DevBlog #2 – Cars

After posting the previous post on reddit, the viewings of the site shot up. It boggles my mind that people the other side of the world read and saw my work. Just crazy. I’ve also started a Twitter account for the project, enables me to properly reach people interested in the project Anyway, let’s talk about cars.

I’m aiming to reach a blog post every week released on a Monday, showing off the development process and having other posts for announcements and such

Preface

I like little details, especially in games. It’s little things which you see and go “huh, someone put effort into that, and to make this neat little thing most people won’t realise”. I find it satisfying, makes the world far more believable. Star Citizen or GTA V are perfect examples of this, and it’s just one of those things which make a game that much better.

When I started developing Project Taurus, I decided that I would follow the same path. Add little details which just show attention to detail and the fact I care about my project.

Driving Model

As I mentioned in the previous blog, Unity shipped with it’s WheelCollider, which for the arcade experience I am aiming for is perfect. It allows you to configure the grip of the wheel exactly how you’d like, and it’s built in ability to handle motor and break input was brilliant, and shaved a bunch of time off of development for that.

To begin with, the motor input was simply a constant multiplied by the input value, which was 1 for ‘W’ and -1 for ‘S’. This gave a very very basic implementation of movement, but it didn’t account for breaking.

Developing the driving model further meant that I changed it to a slightly more sophisticated system. For example when pressing ‘S’ to reverse, I would check first if we were going forwards, I would then apply breaking force rather than a reverse motor force. Slowing down far more effectively and achieved a result similar to what I was after.

However, a problem I faced was that if the breaking force was constant regardless of speed, at higher speeds 500N of breaks would do next to nothing to slow down nearly a tonne of speeding metal. So, I decided to implement the following to emulate breaking similar to that of real life.

This achieved what I wanted exactly, 40 was chosen at random and it seemed to work. I want to say it’s an exact science which I spent ages researching, but in-fact it’s just a number I picked and one that worked.

In the previous blog, I showed the following gif demonstrating some basic and simple game play.

The drifting in this was achieved by having a lower sideways frictional value for the rear tires, allowing you to chuck the back end out by turning in a direction. My aim for this particular car is for it to be hard to control but insanely fun once you get a hold of it. Whereas the DMW 3M will have a smaller turning circle but stick to the ground like glue.

Also, I haven’t had chance to show off a render of that yet:

The reason it doesn’t have lights in the sockets will be explained later on in the post.

Exhausts

In the gif you can notice there seems to be a varying amount of smoke coming out of the exhausts. This is because the amount emitted varies upon the current input into the game. It’s more noticeable on a controller, where you can get varying input values. I thought this would be a neat way of showing some attention to detail, and something that I just find cool.

This was achieved with Unity’s Particle System. Which is in itself a great tool. I created a plain sprite which was a 4×4 pixel (I imagine this could’ve been achieved with a 1×1 pixel grid, but I wanted the ability to maybe add some detail down the line) and then simply changed the colour using the Particle System inspector.

Initially, when you turned corners this happened:

This is caused by the simulation space being local instead of world. After changing this. I achieved the effect below:

Lights

Although there isn’t necessarily a reason for me to have working and functioning lights, there equally isn’t a reason for me to not. Plus the inclusion of night maps means I’ll need lights at some point, so why not have them all the time?

A simple way of implementing them to me was just have the light sources attached to the front of the car which are enabled/disabled based on a key press. However, if you looked at the front of the car, the material would look plain, and it would have looked really weird with a dull/unlit “light” which was emitting a bright light.

To tackle this, I removed the white lights from the model of the car, and then made a separate object which I would then be able to change the material of. This is why the DMW 3M above doesn’t have any lights in the sockets. I would then place the object into the socket inside Unity. Using a script, I then changed the material between the default one and one with a glow effect attached based on the status of the lights.

The future

Next time around I’ll be delving into the map creation process, including how I track the position of the car around the track.

I will also be developing the cars, including tire marks and other features.

Thanks for reading!

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *