DevBlog #8 – It’s been a while

It’s been a while since the last Development Blog, but a huge amount of progress has been made, and some great things have happened.

Steam – We’ve been on Greenlight, and been Greenlit!

In the time since our last post, we’ve both been on Greenlight¬†and have been Greenlit. We did this in under a month, something which I’m super happy with and excited about.

This campaign was launched following a small dialogue I had with some of the guys at Steam regarding Steam Direct and whether it was worth launching onto Greenlight, their answer was straight up yes, and so we jumped in.

I was checking the Greenlight page as I did every day to see the number of votes and if there were any new comments. I then noticed the huge green banner at the top:

This was great to see, and a huge thanks to everyone who voted for us.

Steam – Getting everything ready

Setting up the store page, accompanying store art, and several other things took a few days to get setup. Collecting some screenshots which really show off the game is an important step, and something I’m definitely taking my time with.

The Store Page is up here, and will be built upon and added to over the next couple of weeks.

The Game – What’s been happening

For those of you who are either subscribed to the sub-reddit or are active on our Discord, you will have been seeing various images and gfys of gameplay, and even seen some of the future work-in-progress stuff. I’m trying to keep the development as open as possible, as I think keeping the community in the loop is an extremely important process.

One of the major implementations since last time was the Demolition Derby, and by god do I love it. It’s fun, fast-paced and lives up to the expectations I had of it. Bugs definitely need to be fixed, but it’s coming along great.

Initially, car’s would not despawn, so after a few minutes you would end up with scenes like this:

However, car’s now de-spawn after around 5 seconds, allowing for more longer play sessions.

Customisation has taken huge leaps forward, and I’m super proud of how it all works and has come together:

(That has been taken from an older build, colour options now fall under the “Customisation Nodes” system rather than the menu to the top right.

The game has also had many bugs fixed, and has moved over to a proper versioning system now. Which brings us on nicely to the next topic of dicussion.

The Alpha, and what follows

The Open Alpha is coming soon, I have been saying that for a while now, and I don’t like to be ambiguous, but I can say for definite you guys will be able to play something soon. Whatever that may be.

I’ve had several discussions with people on Discord with regards to Alphas, even considering Early Access. I have stated many times my reluctance to utilise Early Access, the stigma around it is something which I do not wish to attract, however it’s an extremely useful tool, and could help me build up the game with feedback from the community implemented at every stage. This will be fully decided towards the end of the alpha, but nothing is set in stone yet.

One of the most functioning aspects of the game currently would be the Demolition Derby, so it’s likely that the first Alpha you guys get will contain the Demolition Derby, customisation, several vehicles and the free mode to be able to explore two tracks as well as get used to handling of the cars. The AI is due for a huge re-write, which is why the Race mode will likely not be included in the early builds you guys receive. Another important aspect to note is the Multiplayer. I’ve had many many issues recently, largely due to my early implementations of the system, back when I wasn’t 100% sure on how UNet’s system functioned. So this is likely something which will not be included in the initial builds, but will definitely be included in the future.

I’ve developed a small roadmap for the game’s future, and this includes the early access idea, but again nothing has been decided in regards to that.

The future

Most of the next couple of weeks will be the start of implementing the new AI and networking system in order to try and get the improvements ready for the Alpha’s. More DevBlog’s will be written as well, I’ve had an extremely busy time recently and haven’t been able to find the time to give this blog justice.

As always, thanks for reading!

DevBlog #7 – Alphas, prototypes and a whole lot more

These past few weeks have been extremely busy, and great progress has been made. Work has begun on more of the customisation aspects, vehicle destruction and plenty of improvements and optimisations. We’re also closing in on the Open Alpha which will be discussed later.

Outside of this, a load of behind the scenes thing’s have been done, as well as a bunch of admin work. This game making thing ain’t easy you know ūüėČ

Bringing everything together


Customisation is taking centre stage, as I want to be able to show off that as soon as possible. It’s coming along to say the least, and I’m excited to show off how thing’s are being achieved.

To begin with, I decided to build up the system for the wheels, and the storage of all the car “mods” which is done using JSON. We have a “mods.json” file which for now contains a single wheel, but comes out as such:

    "wheels": {
        "wheel_basic": {
            "display": "Basic wheel",
            "description": "Standard rally tires - fun for all ages",
            "prefab": "Cars/Wheels/wheel_basic"
That should be all self-explanatory, with the display being the display name, so what’s shown on the customisation screen. Followed by a brief description and a path to the prefab to load.
This is going to be expanded soon, with the wheel slip values and stuff. But for now this is the foundation I’m going to be building off of. This ties into an extra configuration set of variables on the car configuration, see below:
    "allowed_mods": ["wheel_basic"],
    "defaults": {
        "wheel": "wheel_basic"

Here we can see what is considered an “allowed” mod. Basically an array of all the mod class names, and it will only allow you to choose modifications from that list. Defaults is fairly self explanatory, and is simply the class name of what wheel is used by default.

In the game directory, there will be a file called “profile.json”. This will contain player name, car of choice and also your modifications for each car. Easily editable outside the game, so even better.

Using JSON.NET, this is de-serialised into a bunch of dictionaries of objects, and allows me to poll any information at any point. I’ve used this system with games in the past, and in experience it works great!

The profile

Mentioned above, we have the core player profile. This will be refined later on, but is the central file for all things specific to your player, separate from the options file. This will help down the line with split-screen/local multiplayer.

Here will be stored your modification preferences for cars and any other things which are relevant to your player. I wan’t to keep it as open as possible for people to tinker with, so they can dive right in and change the game to how they’d like it.

Vehicle destruction

Recently I’ve been developing a basic model of soft-body physics for Project Taurus, it’s in early stages, but it’s coming along:

Work begins on destruction

This was created by clicking on parts of the mesh, it then moves the nearest vertex 1 block in in the direction of the click. This is to demonstrate directional collisions, so a hit from an off angle will be different  than head on etc.

This needs a huge amount of work, and won’t be at a decent stage for a while, but I’m super excited to be able to show off where I have got to so far with it. A few issues to overcome applying it to cars but after that we should be away with it.

The Open Alpha

So this is a awesome announcement (albeit a little bit late on the blog) is that we’re having an Open Alpha within the next few months. It’ll be a great opportunity to show off the game to the community, and also help raise awareness of the game. More details are to follow, but you can sign up for it here.

I’m super excited to give you guys the ability to play, and hopefully you’ll like it.

The future

Huge amount of admin things to do, features to implement, models to make. Loads of work to be done, so I’ll be extremely busy over the next few weeks getting things nailed down. I may have to cut back on the blog-writing to make larger, more content-filled posts¬†which have far better things to show off.

Thanks for reading!


DevBlog #6 – UI Flow and bug fixes

Another busy week outside of Taurus, plenty of emails, plenty of work. All good things, and the game has seen some great progress. The UI is coming together really well, which I’ll be showing off later. Also a huge amount of code organisation, nailing down the multiplayer code to allow the game modes to be added easily.


Main Menu

The UI is the most visual improvement this week, saw a bunch of changes which make the game far more professional looking, as well as making it flow and look great. Anyway, onto the gifs and images as well as some explanation as to how it all works.

Main Menu UI

Above you can see the first pass of the ‘Main Menu 2.0’ as I’m dubbing it. Currently being built to support the open testing in the future, it still needs refining, as well as some graphical representations of how some the options effect in-game.

Animation Controller for Main Menu

So above you can see the outline for the animations on the main menu with the Animation Controller. We start at idle, then dependant on triggers which are called by functions attached to buttons (The reason they are called by functions over directly from the button is so that I can add extra functionality down the line). Then we wait until the next trigger to play the reverse animation and go back to the beginning. I’m really happy with how Unity’s animation recording system in general is holding up, not having to worry about using Splines or other such solutions to this makes developing new stuff really simple.

Spawn Screen

Spawn Screen

I thought it’d be good to show the latest and greatest for the spawn screens. With some blur added,¬†actual Player Name shown, display of car and stats it’ll be looking great. All the information pertaining to the map is stored in a JSON file, which I’ll discuss more about later.

I wanted to keep it simplistic, a un-detailed overview of the map, basic information (Can’t really call it lore at this point), as well as a preview of the map in the world is what I wanted to achieve, and I’m super happy with it’s results.

Map/Car/Everything data storage

I’ve recently begun moving over the configuration of vehicles and maps etc into JSON files rather than the object serialisation possible through the inspector in Unity. I’ve had many many issues we’re I’ve had to revert to a previous source due to Unity wiping all the data due to a file being corrupted, and when fixed it was blank. To solve this, and also begin the foundations for¬†modding. The dangerous and exciting world of hopefully Steam Workshop if all goes to plan and we achieve Steam.


As always, bugs are made, bugs are found and bugs are fixed. With the codebase getting larger and larger, this takes more and more time. As tracing back the different systems can be quite a task.

To help combat this, I’ve continued the organisation of the code. In the long run this will be definitely worth it.

The future

The next couple of weeks will feature refinement on both the UI as well as far more work on car customisation. I’ve made some progress on the Game Design Document, but pairing that with budget and admin related things it’s taking it’s time to finish it.

Thanks for reading!

DevBlog #5 – All things pink

These past two weeks have seen a huge amount of improvements and changes which I’m super happy with. The community is really starting to come together, and we’re seeing some great fan-made submissions of cars on the subreddit and discord. We also have a new site, which I designed from scratch last weekend. Anyway, into the game!


Development has started on the Desert themed map, with the track layout and nodes sorted, and basic cluttering has begun. A quick preview of that can be seen below:

Very very early days, but I like to give you guys the latest of the in-development screenshots, helps you see what the final product will become.

This is probably one of the better screenshots showing off the track-node system, you can see how it loops all the way around. Overall, I’m extremely happy with how that system is coming in use, as it tackles many problems such as the AI and the player tracking.

Car customisation

This was something I had always planned for later on in development, but I had an idea this week on how to approach this, and so I looked into it and here we are, the basics of customisation are coming together.

A system which I’m probably going to re-write down the line, but for now it fulfils my needs, it simply changed the colour on the actual texture. As the .obj format I use from MagicaVoxel uses a palette texture, all I have to do is modify a single pixel in the texture to change the colours on the car. A more ideal approach which I will look into implementing in the future would be using a shader to achieve this, but for now this system works, and I haven’t seen any downsides. If anyone does think of any, please feel free to comment below!

Also, I decided to try out a more “brighter” colour scheme:

Happy with this, I moved on to designing a UI mockup for the car customisation, which will be implemented over the coming weeks properly, but this is what I am aiming for:

The idea is to have each point as something you click on, then you can edit the car from that. So above you can see what would happen when someone clicked on the wheels, they get a list of the wheels they can have, and it goes from there.


We’ve also seen the birth of the new Forsche 449 this past week:

There you can see it in action on Forest, super quick, fun as hell. My current favourite car. A more detailed render of it can be seen below:

Exterior render

Interior – from front

Interior – from rear
Some minor work still needs to be done, such as the addition of lights to the vehicle, aside from that it is good to go.

I’ve also improved the model of the basic tires vastly, before we had something like this:

Now, the vastly improved and far better looking:

You can see it featured on the models above, and in my opinion it makes for a really nice looking basic tire.

Other stuff

So matchmaking saw some minor improvements and optimisations, as well as the multiplayer. I’ve had some issues with objects syncing, not sure if that is to do with UNet or my own fault, but they are being fixed by the dozen.

Code has been reorganised, moving behaviours into different classes/objects has helped make things far more manageable, as well as help fix some bugs we’ve had. One of which for example was that if you created a server, closed the server down, then started a new one again you would be stuck in free-mode regardless. Also if you pressed Escape for the pause menu, there would be no menu, but the screen would still blur. All interesting stuff, and now all fixed.

The future

The finalisation of the racing game mode is soon to be completed, once that is finished, I’ll be moving onto the more fun demolition derby style mode(s).

Internally, the finalisation of the Game Design Document (GDD) will allow me to release more information on the availability of modifications, and also the type of content to fully expect.

For more instant updates along the style of as-soon-as-I-finish-it follow along on Twitter.

Thanks for reading!

DevBlog #4 – Getting Somewhere

This week was a busy week, so busy I’m a day late. But we’ll forget about that bit for now. Let’s get onto what progress has been made.


I finished Snow this week, it’s fully cluttered, with fences, rocks etc. making the map seem more detailed and actually really improves the looks of it. The header for this post is an area I’m particularly happy with. This included some new assets being created.

Included under the “Maps” topic is the track-node system I developed to help track the player position around the track and also guide the AI. I added the node option for direction only, this will help guide AI but won’t impact their throttle inputs, allowing for tight spaces where they shouldn’t slow down. Such as the bridge on forest, which combined with a bunch of other issues led to the following hilarity:

Things went very wrong


This week saw leaps and bounds for the development of the AI drivers. Bunch of tweaks towards the calculation of their target speed really brought down the number of flips and suicidal wall-crashes they got themselves into, but also some nifty collision detection.

I discovered half-way through the development of my AI of Unity’s Rigidbody.SweepTest¬†functionality. This allowed me to search an area in-front of the car for collisions with potentially dangerous things.

Initially, I used this to check for walls/trees/fences , static objects. This brought down the number of issues, but I was still having some. Car’s would often get stuck on each other, and that needed to change.

As I still wanted the AI to collide into players and each other, the AI will only avoid cars below a certain speed. This allows for high speed crashing, but helps prevent low-speed annoyances.

Combine this with tweaks to their configuration, and we get a far more sensible AI.


The UI this week saw a huge buff, for example on the main menu we went from this:

Old main-menu

To this:

New main-menu

Getting rid of Unity’s default UI skin was a major step in the right direction, a small change to implement, but gives far bigger impact on the game.


This week also saw the birth of Apollo, the Matchmaking system I’ve created to help support the multiplayer of this game. Apollo will run alongside Steam’s Matchmaking in order to allow GoG/DRM-free releases which can play with the Steam folk, just not through Steam.

Apollo will be developed over the coming weeks, but it is shaping up to be really powerful in terms of supporting Project Taurus.


I moved from Unity’s standard controller input system over to XInput, this gives far more flexibility and control, and grants me control over the feedback motors inside the controller itself. I used the collision system to generate pulses when the car collides with something substantial. As I said previously, it’s the little details.

We also now have a Reddit community. I’ve been building it up since Saturday, and it’s gone extremely well. With over 100 subscribers already!

The future

This coming week will feature little work on Taurus due to external commitments, but I’ll be working on the community and finishing the basis for the first functioning game-mode: Racing.

Thanks for reading!

DevBlog #3 – All about Maps

Today I’m going to talk about the map making process today, as well as the way the actual race circuit itself is implemented in order to track player progress as well as guide AI.

Later on aswell I’m going to talk about the actual changes I made this week, because I haven’t done that properly in a blog as of yet.

Map Design

Map design, as with anything, starts with me scrawling something out on paper which resembles a track. For example I pick a theme, say winter. Then build up around that. They are built in MagicaVoxel, like all of the assets in the game. After around 30 minutes worth of work, you end up with something like this:

This is then imported into Unity, which is where the real work begins. The placing of all the trees, assets, track nodes, spawn locations. All the fun stuff.

We’ll start with the simple stuff, placing assets.¬†

Pictured above is the tree I’m going to use on the winter-themed map. It’s based off the model I used on Forest, but this time covered in white blocks to resemble snow-fall.

This is an example of the tree placer script at work. I simply have to click where I would like the tree to be placed, then the script creates a new one with a random rotation. This helped make the forest look natural and real, as well as being super quick to create.

“Snow” as it is current dubbed in-development is still being created, so I haven’t had much opportunity to fluff it out with fences, grass and extra details. But here is some game play with some of the AI:

Position Tracking

In order to track the players position around the track, as well as providing a guideline for the AI, I decided to use a system of track nodes. In the simplest way, each node links onto the one following, so we can track the progress between the two. This is done by a simple Vector algorithm which gets the closest point on the line between the nodes that the car is.

Each yellow cube represents the track node, with the red line between them representing the line I mentioned earlier. You can just see the white line off of the Tiny, that is the line between the car and the closest point.

Using some basic Vector maths, you can calculate the distance between each node. Given the amount of nodes, you can then calculate an extremely precise positioning in a race.

The track node system also doubles up as a way to power AI. In the simplest terms, they drive towards each node, then once approaching a corner (within 20 units), they begin to aim towards the next node. The AI will be talked about more as it is developed further.

Progress this week

This week saw a huge step forward for the AI in the game. I actually implemented them properly to start off with, as well as implementing collision prevention and also what to do when they get stuck. It still needs a lot of refining, but I’m extremely happy with how it’s progressed.

As well as this, we saw the creation of “Snow”, the winter themed map which you saw a bit of above. Also, the featured image of this post is a rendering of the next map to implement. Which I haven’t given a name to yet. Probably will be something boring, I’m not good at naming things.

Thanks for reading!

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


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.


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:


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!



DevBlog #1 – First Foundations

Welcome to the first blog post regarding the development of Project Taurus, an arcade racing game. In this post, I’m going to discuss the roots of the project, as well as current progress.


One of the biggest choices to make in this stage of development is what tools to use. Which engine, which image editor, which modelling software to use.

I tried Amazon’s Lumberyard¬†and Unreal Engine¬†before settling on Unity. Although some members of the GameDev community consider it the “rookie” engine to use, I found it’s asset pipeline and scripting suited my needs best, as well as having a powerful object inspector and editor. Another box it ticked was the ability to extend it relatively easily, which allowed me to add some scripts to help on the importation of the .obj format I was using for the meshes, as well as a tree placer script (which doesn’t just work for trees, any asset which requires random scaling and rotation with quick placement) which helped make the development process that much smoother.

For image editor, Photoshop is my go-to in every instance. Simply the power of the package makes life that much easier, while providing a strong base of tutorials if you ever need to find out how to do something new. Any images for press or the blog or the game are done through that.

For modelling, I could simply use something such as Blender, working with voxels would frankly be an absolute bitch. A tool I had come across in the past for working in a voxel art style was MagicaVoxel. This I found to be brilliant for my needs, and ticked everything I wanted. The built in render allowed me to produce some of the images below, and the export options suited me well for Unity.


The style of a game, whether it be art or setting, is always a huge factor in development. The Voxel art-style has always interested me, as you can achieve good looking results with relatively low amount of work. So the first step I took was to develop a basic car in order to see whether the style will work with this setup.

I was pleased with the result, based off of a Mini MK VII, specifically the rally variant. Obliviously, as I can’t use the original name of the car, I decided to call it the Tiny MK VIII, as it bears resemblance to the original name. From the looks of the car, I decided the art style did work, and pursued to make another popular hatchback from the era, the Golf GTI MK 1.

Again I was happy with this, and decided to go with the name Gulf TGI Mk 1.

Map Development

Initially, I used a test map to begin testing all of the driving mechanics and how the cars worked in-game.

As you can see, it was extremely basic. But allowed me to test how cars worked, as well as how the assets looked in-game. Scaling was a huge issue initially, however, with some import scripts in Unity which I smashed together quickly and configuration of MagicaVoxel, I got that all sorted. One thing which eluded me for a while was setting the origin point of objects. My aim was to get the pipeline and workflow down to the minimum effort required by me to add assets to the game, and I was reading several posts online about importing into Maya or 3dsMax and the such in order to reset the origin points. However, thankfully not too long ago MagicaVoxel added support for configuration the origin in the .obj export in the config file, making life that much easier.

The first map I decided to work on was a forest map, and to be simply known as forest through development until I settled on a name. Here is what I got together in MagicaVoxel:

I was happy with this, a lot of empty space around but I will cut down on that at a later date. Fast-forward a few days, add some major functionality here and there, alongside some camera effects so it looks even better and we ended up with this:

Oh, and did I mention, I made a coupe. Specifically a BMW M3 E30, the first mass-produced M car that shifted ass like no tomorrow. You can see the exhaust trails from beneath the car, as well as some functioning lights, and is that two cars? Yes. Yes it is. You can read some more about that below.


One of the most important aspects of this game for me was multiplayer, and the game will revolve around that. Of course, there will be a significant single-player aspect. But I want this to be the game you launch up with a couple of mates for a few hours and dick about, race, time trials. Launch each other into space with some buggy tires and the such.

Unity ships with UNet, a surprisingly viable option for my multiplayer needs. However, another option could be Photon, which has all the bells and whistles and is promised by many to solve all of UNet’s horrible and horrific downfalls. The problem is, I couldn’t quite find just yet what they were. To this current point in development, I haven’t found an issue which I wouldn’t have had with Photon. I may be setting myself up for failure here, reaching a point down the line where I simply go “Oh fuck” and realise a fundamental flaw in UNet which prevents me from ticking one of the boxes in my brain for this game. But I cannot seem to find it.

Reading up online, I found one the major free-to-play successes of recent years, Unturned, was built upon UNet. With this reassurance that it does work, I decided to stick to UNet, and sally forth.

The goal is to have several game modes:

  • Free Mode – Where you just drive around, smash into stuff, test car’s etc
  • Race Mode – Simple one-off race with friends, strangers, bots or simply nothing,
  • Trial – Several laps aiming to get the fastest time
  • Tournament – Which features several races, gain points each round and a podium finish at the end

Car Handling

One of the things I saw taking the most amount of time in development of this project is configuring and tweaking the handling of the cars. I elected to use the built in WheelCollider component in Unity to base this off of. This required a Rigidbody on a parent object attached to the wheel. Simple to set-up, I was happy and away. As I correctly assumed, it took several hours to stop me from sliding about every time I even thought about changing direction. After several hours with the Tiny, I achieved this:

(Click on the image to see a higher-quality gfy)


The future

Taurus is early in development, so plenty of things are bound to change or be removed. I will delve into each section more deeply in the future as I both develop it further and increase my understanding of the topic. This isn’t just a game I’m working on to eventually sell, but also a learning trip for me. My understanding of certain Physics aspects and Networking topics is ever increasing during the development.

I hope you enjoyed reading.