Last Thoughts

Now that my project has reached the end, I am quite pleased with several features that I managed to implement (mainly the wapoints and lap system, as well as the interactable environment.

The main problem that I see with the game, is the fact that it has two big bugs. Although I managed to implement fixes for a majority of bugs found in testing, I was unable to find a fix for the car mechanics. I believe the problem may have been caused when the .blend file misplaces some of my meshes as it was imported. I also have the suspicion that it does not recognise the front of the dune buggy as the front of the actual game object, and so it steers of at an angle it believes to be 'straight forward'. I searched for a long time what could be causing this, as well as making several posts on the unity support forums and the maker of the tutorial, but to no reply. The camera flickering bug may also be related to this problem.

There is also a problem caused when the car is not steering on flat terrain, in which case the controls reverse and accelerate becomes brake. Both these problems hamper the gaming experience, and are my top priority to fix if I had time to continue with the project.

After searching for fixes, the problem may lie with the unity engine itself. The problem could be a result of the way the Unity engine handles physics and wheel colliders. I have found several examples of other people having the same problems as me (with no fix) that are posted below.

http://answers.unity3d.com/questions/5509/why-is-my-vehicle-steering-on-its-own-when-i-accelerate

http://forum.unity3d.com/viewtopic.php?t=27912&highlight=physically+smooth

http://forum.unity3d.com/viewtopic.php?t=32284

Timer fixed

Very close to the deadline, but have finally fixed the timer. *sigh of relief*. Apparently, the problem was caused by by the result of the division being rounded up to the next integer if the decimal point is above .5.

To fix this, I needed to use Mathf.FloorToInt function to make sure the lowest integer is always returned. Thanks to andeeee on the Unity forums for this fix.

Health Bar (partially) Fixed

The problem with the healthbar before is that when the health would be reduced, the health bar would disappear from the screen. To look into this bug, I created a GUIText that would print the health to the screen. Sure enough, the health went down to the current value but the health bar still disappeared. I then printed the value of the healthbar width to the screen, and when health decreased, the width value went from 225 to 0.

I printed the formula (health / maxHealth) to the GUIText next, which went from a value of 1 to 0. From this, I could tell that the problem was caused by this conversion. By changing the type of health and maxHealth from integers to floats, this solved the problem.

I have also changed the health system so that instead of health decreasing passing through a waypoint, that colliding with a tree deduces it instead. However, I was unable to implement it so that every tree in the track reduces damage (since they are not gameobjects) but I have placed one tree in the track (tree sticking out on inside of first corner) since this tree is a gameobject.

Waypoints Fixed

Found out the problem with the waypoints, quite a silly mistake on my behalf actually. The lines:

if(other.gameObject.name == "Waypoint_1"){
Waypoint1Col = true;}
if(other.gameObject.name == "Waypoint_1"){
Waypoint2Col = true;}

Should have been:

if(other.gameObject.name == "Waypoint_1"){
Waypoint1Col = true;}
if(other.gameObject.name == "Waypoint_2"){
Waypoint2Col = true;}

That's what happens when you copy and paste code though. I also took this time to update the waypoints so that it doesn't work if you drive the wrong way round the track. New code is written below:

if(other.gameObject.name == "Waypoint_1"){
Waypoint1Col = true;
}
if(other.gameObject.name == "Waypoint_2" && Waypoint1Col == true){
Waypoint2Col = true;}
if(other.gameObject.name == "Waypoint_0" && Waypoint1Col == true && Waypoint2Col == true){
Waypoint0Col = true;}
if(Waypoint0Col == true && Waypoint1Col == true && Waypoint2Col == true){
NoLaps += 1;
Waypoint0Col = false;
Waypoint1Col = false;
Waypoint2Col = false;
}

Tree Colliders Fixed

Took me a while but I have finally fixed the tree colliders so that the dune buggy can crash into them. At first, I thought the problem lied with importing the terain from another project into my OverDrive project. Even though 'Enable Tree Colliders' was checked, the collision would not be detected.

Turns out the reason it didn't work is the prefab that was used to place the trees didn't contain a collider to begin with. Instead of using the 'Thin Tree' prefab, I needed to use the 'Thin Tree Collider' prefab located in another folder.

Results from Testing

After giving the game to 5 test users to do some black box testing, the results were mostly as expected. The main issues that users had were with the steering and camera issues, as well as the timer increasing at the 30 second mark, and being able to drive straight through the trees.

There were also problems which were brought up which I did not know about, such as the steering on the car messed up if the player was to drive off the road into the trees. Another problem was that the lap would increase even if all of the waypoints were not driven through.

I have the next couple of weeks to try and address these problems, which will be documented in the blog. The full results from testing can be seen in the final report.

Testing

Now that the menu is done, I can begin the testing stage of production. Unfortunately, there are some parts that had to be cut from the game due to lack of time but if testing goes well then there may be time to go back and implement them.

For black box testing, I will be getting several test users to play the game, and bring up any problems they may encounter.

Added Points

The original idea of the game was based on scoring points to win a race, and not finishing first. To reflect this, I have quickly implemented a points system for Speed and Style. The player can get 500pts by taking the shortcut over the river (passing through the shortcut waypoint) or by driving at a speed of over 75 mph (+1 point per frame).

Was quite easy to do but the while implementing the speed based points, the game would crash while running the while() loop. Was fixed by replacing if with an if() look. Since there are no AI racers, I am unable to implement scoring for 'Aggression'.

Menu

Carrying on with the main menu screen, I came across a nice tutorial on the internet that makes use of the GUILayout function to make navigational buttons.

http://www.unitylabs.net/tutorials/user-interfaces/game-start-screen

Using the tutorial as a guide, I created a new scene for my title page and imported the background image using the same method as the HID image.

Cutback

In order to try and make up for lost time, I am making the decision to cut back on the main menu.

Instead of the original idea of having multiple menus such as controls and settings, I will just have the one title menu with an option to either start playing the game, or quit. Since unity has an option to choose the game resolution and quility settings outside of the game, this will not need to be made.

Last bit of the HUD

Now that I have all my variables up and running in the Game screen, I need to make it look a bit nicer. Earlier on, I had made a 2D image to be applied behind the variables in the HUD to make it stand out a bit more.

Something that should also be noted is that I am working for the resolution 1280 x 720 for my game, since this is a supported HDTV resolution (which would make it compatible with most widescreen televisions). Again, if there is time at the end of the project, I would like to go back and set up scaling for all of the images I am using so that the resolution of the game would not affect its appearance.

To add an image to the gamescreen, a GUITexture gameobject must be added. The asset of the image to be used is assigned as the texture, which can then be scaled and positions using hte Pixel Inset functions. The final HUD can be seen below.

Health Bar

Quickly implemented a healthbar in the top corner. It works by creating a rectangle, with a constant height and the width set to the current health of the car. When the health decreases, so does the reactangle width. The current code for the healthbar is:

healthbarRect = Rect(1032, 42, (health / totalHealth) * 225, 20);

Timer

Next stage of the HUD to do... is the timer. Basically, I am implementing a timer in the format minutes:seconds:milliseconds which tells the user how long they have been racing (and also to work out methods such as lap time).

I found another nice tutorial at:

http://answers.unity3d.com/questions/4009/how-to-make-a-timer-in-the-game

It basically uses the Time function built into unity to get a reading in minutes, seconds etc. The code is written for the OnGUI() method so I needed to convert in so that it runs in the Update method (so that I can pass the timer readings to a GUIText).

The final outcome is below, but there are some problems with the timer at the moment. For instance, the minutes increase when seconds = 30 and not 60. I triend to fix this by doubling the reading of the minutes, but this results in the minutes increasing by 1 after the first 60 seconds, and then again every 120 seconds after.

private var startTime;
var textTime : GUIText;

function Awake() {

startTime = Time.time;

}

function Update() {
var guiTime = Time.time - startTime;

var minutes : int = guiTime / 60;
var seconds : int = guiTime % 60;
var fraction : int = (guiTime * 100) % 100;

textTime.text = String.Format ("{0:00}:{1:00}:{2:00}", minutes, seconds, fraction);

If I find a fix for this then expect an update.

Speed counter

Now that the lap counter was done, I moved next onto the speed counter. My first thoughts were that this would be quite tricky, but then I discovered that the rigidbody attachment for the car comes with a built in velocity component (thank god).

I found a nice tutorial for making a speedometer at:

http://answers.unity3d.com/questions/8120/how-can-i-make-an-on-screen-speedometer

It basically converts the velocity of the rigidbody into a MPH reading. Had to make a few changes though, since the MPH were being printed out as a float and not an integer. To solve this, i added the parseInt() method to the MPH reading to convert it into an integer value. The code is below.

var mph = parseInt(rigidbody.velocity.magnitude * 2.237);
mphDisplay.text = mph + " MPH";

If I have time an the end, I would like to go make and make a needle based speedometer, but is it not the most important thing to impliment at the moment.

Starting the HUD

Now that the driving mechanics (minus the small bugs) and the waypoint system are down, I can now begin to make a start on the HUD. With the waypoint implementation still fresh in my head, I decided to begin with showing the number of laps the user has completed on the screen.

In the waypoints script, I have a static variable names NoLaps. This is the variable I am using to count the number of laps the players has driven round the course. In order to print this onto the screen, I need to introduce a GUIText into the scene.

After adding the GUIText, I needed to edit a few parts of the Waypoints script to print the variable 'NoLaps' to the GUIText. The first thing to do was to add a new variable.

var lapDisplay : GUIText;

This sets up a variable of type GUIText. Then I needed to create an update method and add a line of code to pass this new GUIText variable the interger value of the 'NoLaps' variable.

function Update () {
lapDisplay.text ="Lap " + NoLaps + "/5";
}

This line is pretty much self explanatory. It passes the NoLaps variable as well as some useful HUD text to the text component of the GUIText variable. All that is left is to Assign the GUIText game object to the lapDisplay variable in the script.

Lap System

After much tinkering and a bit of frustration, I have managed to implement a lap system along with waypoints (to make sure the player goes round the track instead of reversing back and forth over the line.

The lap system works by 3 waypoints set along the track (a waypoint being a cube with an attached box collider as a trigger). When the car collides with a waypoint, a boolean value connected that waypoint is set to true. Once all waypoints have been activated, the number of laps is increased by 1 and all booleans are set back to false. I've added the code below:

var Waypoint0Col = false;
var Waypoint1Col = false;
var Waypoint2Col = false;

static var NoLaps = 0;

function OnTriggerEnter(other : Collider)
{
if(other.gameObject.name == "Waypoint_0"){
Waypoint0Col = true;}
if(other.gameObject.name == "Waypoint_1"){
Waypoint1Col = true;}
if(other.gameObject.name == "Waypoint_1"){
Waypoint2Col = true;}
if(Waypoint0Col == true && Waypoint1Col == true && Waypoint2Col == true){
NoLaps += 1;
Waypoint0Col = false;
Waypoint1Col = false;
Waypoint2Col = false;
}
}

The main diffulty I noticed is that most of the code for Unity is written in Javascipt. While I know C# (which is supported in unity), C++ and Java, there are quite a few methods in Java which I need to keep looking up to find out how to run that particular method (in this case, the OnTriggerEnter method). Converting this code into C# would take too much time so its slightly difficult writing new bits of code in a language I am not perficient in. Hopefully, this won't delay my scedule too much, but it is yet another thing I did not account for in my planning.

Car Mechanics Update

Spent a bit more time in tweeking the car mechanics to get it closer to what I want it to handle like. Despite being happy with the handling of the dune buddy, there are still several problems with it. The major problem that is with the dune buggy is that it does not drive in a straight line, and instead veers of slightly to the right. I havev spent a lot of time looking into this problem, such as adjusting the wheel colliders, looking at the script, re-importing the models and also posting on the unity forums for assistance, but still can't seem to get it working correctly.

Another problem that is evident in the dune buggy is the camera. Despite the camera following the car, it has moments when the vue flickers from the back view to the side view of the car. I believe the problem may lie with the camera trouble I encountered earlier, with the camera facing the side of the car and not the back. Again, I have looked at the script and cannot find where the problem lies. If perhaps may be easier to fix if it didn't occur at random moments in the game, leaving me unable to find the source that triggers the problem.

However, I cannot spend much more time on the driving mechanics as I need to make a start on other parts of the game in order to keep a scedule. If there is any time at the end of the debugging then I would like to go back and address this problem.

Track finished (again)

Now that I am using the Unity engine to make the track instead of blender, I have changed the design of the track from the original. The reason being so if that (as far as I know), it is not possible to make a cave in the terrain tool, leading to the removal of this feature. Also, I have changed the layout and appearance of the track to a forest, complete with a waterfall.

The track was made using the terrain tool, and the heights were adjusted using the various height brushes. Foliage such as trees were placed by importing the assets which were included in the 'standad assets folder, and textures were placed using the texture brush. To make the river, a shallow ditch was made using the height mapper, and a water mesh was created using the 'simple water' asset included. Particles were used to create the waterfall, as well as the spray created at the bottom. To help make the track, the following tutorial was referred to:

http://www.unifycommunity.com/wiki/index.php?title=Terrain_tutorial.

Images of the track can be seen below.

Applying the Car Tutorials PT 2

+Another thing I noticed was that the buggy itself was leaning to the left, as if it had a puncture. I suspected that this problem may have lied with the wheel colliders not being configured properly. Sure enough, by adjusting the radius of the wheel colliders, as well as repositioning the colliders so that they were in the dead centres of each wheel, the buggy became level again.

However, the buggy would still fly all over the place, and was prone to flipping over if it took a turn to sharply. To try and find a fix to this, I once again consulted the tutorial on the website. It was here that I noticed the following paragraph:

"I would not recommend changing the asymptote values until you know exactly how they work, it’s much easier to change the “Stiffness” value. This is essentially a multiplier for the curve, when set lower, it decreases both values linearly. You will want this value set fairly low, generally less than 0.1 if you want your car to slide nicely. If the sideways friction stiffness is set too high, you may have some stability issues, the car will stick to the road so much, that when you try to turn at high speeds, your car will quite literally roll off into space."

As it turns out, I still had the stiffness values of my wheel colliders set to the default value of 1. By reducing them down to 0.1, I not only noticed that my car was a lot more stable when driving around, but also that it moved at a low slower speed.

Applying the Car Tutorials

Slightly behind scedule but I've finally made a start to the Unity project. The first stage is to set up a new project and scene. Once this was done, I imported the .blend file of my Dune Buggy model directly into the scene. However, after the model was imported and I dragged it into the scene, the main body of the buggy was out of position. After some rotating, the dune buggy was looking as it should.












After working my way through the tutorial at http://www.gotow.net/andrew/blog/?page_id=78 with my dune buggy model, I needed to import some assets into my project from the website (such as sound and the wheel slip prefab). After I was done with the tutorial, I added a plane below my dune buggy gameobject and previewed the scene. The first thing I noticed was that the camera was looking at my car side on, but the car was successfully driving around on the plane (albeit I couldn't see where I was going).

I had a quick look on the tutorial website to see if anyone had mentioned the problemed but no luck. To fix this problem, I dabbled into the camera 'smooth follow' script myself. A method I found that worked was switching the x and z co-ordinates at every instance in the code. After once again compiling the scene and running the game, I found this did the trick. However, after viewing it from the correct perspective, I noticed a few other glaring mistakes.

Once thing is that the dune buggy had steering problems and would fly into the air if travelling too fast, or reversing. The other more major problem is that the wheels would spin around the wrong axis (creating a most perculiar looking effect). Using a similar method to the camera, I decided to edit the script and flip the x and z co-ordinates around. Sure enough, this did the trick and the wheels worked fine.

Thinking about it some more, it seems that perhaps the x and z co-ordinates of my blender model were the wrong way around, and so unity believes that the front of my dune buggy is infact the side of it. As long as the car runs fine, then this shouldn't be too much of a concern.

Car Tutorial

Carrying on from the post before, I found the car tutorial quite useful. Although some of the coding was already done at the start, the tutorial consisted on setting up a car gameobject, and attaching scripts to control car movement, sound and getting the camera to follow behind the car.

However, the tutorial did not contain any tutorial on setting up wheel colliders, as my dune buggy has a chassis that is considerably different to the one used in the tutorial. No major problems with this tutorial either, but did require a lot of time and effort to set everything up.




































Near the end of finishing the tutorial, I came across another car Unity car tutorial at the site:

http://www.gotow.net/andrew/blog/?page_id=78

The good thing about this tutorial is that it seems a lot more customisable than the other, so that I'd be able to get a good setup for a dune buggy type car. The tutorial also seems to get more to the point about making a car setup, since the one I previously completed relied more on setting up aspects such as sound effects and lighting/shadow.

Starting the Car Mechanics

Now that I am making the track in the Unity engine instead of blender, I made the decision to push back the track modelling and instead focus on getting a car driving around first. My first bit of research took me to youtube, where I searched around to see if any other projects existed which were similar to mine, using the Unity engine.

One set of clips caught my particular attention, posted by the user 3Dnemo who has a website at www.3dnemo.com. His videos consist of various racing games made in the unity engine, some which are quite similar to the outcome I plan on achieving (which I have posted below).

http://www.youtube.com/watch?v=sR8UWWjrskg
http://www.youtube.com/watch?v=XSmDEC1dWPM

Despite having a tutorial section on his website, there is unfortunately not one for setting up a racing car project. After looking at some examples of racing projects done in unity, I began looking for some car tutorials in which I can base my work on. The first one I came across was posted on the unity3d website (http://unity3d.com/support/resources/tutorials/car-tutorial). My results from this tutorial will be posted in a few days.

Wait, Unity has a level editor?

After having many problems with trying to get my track model implemented into the Unity engine (mainly due to collision detection problems and exeedingly high framerates, probably them trees), I discovered that Unity has a build in terrain option where it is extremely easy to make terrain that can be made directly in the engine.

Luckily, my track model was not finished yet (the last model that needed to be done) so it's not a complete loss, but a lot of time has been wasted in modelling the track which could have been used elsewhere.

I had a quick go in the unity terrain editor and the whole process is less time consuming than making terrain using blender (although it may not be as customisable). Previewing the terrain using a simple camera set up also had a big impact on the framerate. I was able to have a lot of trees, bushes and grass in the scene and was still achieving comfortable framerates (60+ FPS).

Unity Tutorials (Part Deux)

After I had completed the first tutorial (GUI essentials), I moved onto the next tutorial provided in the Unity documentation (called Scripting Essentials). The tutorial consisted of writing a javascript to make a light source target the First Person Controller, as if it were a moving spotlight. If the space bar is pushed, the target of the spotlight would change from the controller to a cube in the middle of the plane.

The second part of the tutorial involved writing a script that would instantise a cube prefab whenever the left mouse button was pushed, and setting its position to the current position of the First Person Controller.

Again, the tutorial was rather easy to work through, since using Unity is much easier than performing a similar process in XNA Gamestudio. The only major problems were getting the code right, but any mistakes were shown in the error log. The results can be seen below.

Unity Tutorials

Before going ahead and starting the development of the game, I first wanted to get to know the Unity interface together. To do this, I read through the Unity Basics guide as found in the Unity Manual. Once I had a brief understanding of the Unity interface, I proceeded to work through several tutorials explaining the basic functions of the Unity engine and GUI.

The first tutorial which I completed was the tutorial 'GUI Essentials' which is found in the provided documentals. Working through the tutorial, I was relatively comfortable with how things are done in unity, and the fact that the game view is updated in real time it a nice feature.

The tutorial itself consisted of creating a plain, with a cube placed onto it. The cube was then duplicated several times to form a stack,slightly scewing them so that the stack would fall over. Also, a first controller was added so that the player can navigate the plain, interacting with the cubes. The results from this tutorial have been posted below.

Sound

Had a quick look at sounds to use in the game. The songs I was thinking of implementing for the menu screen is 'Steppenwolf - Born to be Wild' and 'ACDC - Highway to Hell', since both are related to driving. They can be seen below.

http://www.youtube.com/watch?v=xm5DPlNCmtk
http://www.youtube.com/watch?v=a5BjIVS04jk

2D Images

Been working the past couple of days on the images I need for the game, mainly the title screen, menu screen and the HUD. The image from the title screen is a picture of the game 'Sega Rally' and the font is 'Car-Go' . The faded black bar need the bottom is just a black rectangle with Gaussian Blur and the opacity adjusted.

For the HUD, I started with an empty (background) and searched on the internet for some 'splat' brush add-ons for photoshop. I then experimented with different paint splats to see which ones worked the best, before placing them in the desired location. The 'health' symbol was taken from the site http://www.lynncamtv.com/assets/images/health_symbol.jpg, and inverted so that it was white. All images can be seen below.

More modelling

Spent a lot of last night making the track but blender then crashes after an hour and I lost all my work (teaches me not to save my work often). After starting again from scratch, I made the track by using one plane for the grass, and another for the mountains. The mountain plane was subdivided around 5 times, and one of the edges was pulled downwards to form a cliff-face.

The road itself was just another plane, which was continuously extruded into the shape of the track (using the earlier design as a background image for reference). To make the valley, I selected all of vertices of the track and extruded them upwards to form the track, but with a thickness. Then using boolean intersect, I selected the mountain plane and then the track and removed the difference. I then went ahead and deleted the extrusion of the track again so it was once again a flat plane.

From doing some digging around on the internet for some creative common models I can use, I came across a nice set of pine tree models, complete with textures at the site below.

http://www.sharecg.com/v/38106/3D-Model/3-pines-versions?division_id=11

Since these were lightwave objects, then first needed to be imported into the blend project. The textures were attached and then the models werw placed into the scene. Something I did notice however was that the blender scene took a lot longer to render with the trees, which brings up my concern into how the framerate will handle once I import the track into the Unity engine. The track so far can be seen below.

Change of engine

After reasearching different implementation methods, I have decided to change the engine from XNA GameStudio to Unity. The main reason on this decision is that in order to implement all the things I need, I would need a program that would provide alot of functions out of the box, such as rendering objects and handling variables. By switching the engine to unity, the development time would be cut majorly as I would not have to worry about programming an engine myself and could spend more time doing the development that mattered more.

Another good thing about unity is that it can handle .blend files directly without having to convert my models into another format first, its just a case of importing and dropping straight into the scene. The fact that unity can also take game projects and compile into an exectional file is also an added bonus, as well as the reduction on the amount of programming needed to be done.

Dean.

Modelling Update 2

At the moment, I'm pretty close to finishing off the dune buggy model. I managed to save some time by taking most of the components such as the bars and side panels, duplicating them and mirroring them to form the other side of the dune buggy.


Although I would like to put more time into the dune buggy (such as some nice looking tyres), I need to start modelling the track to keep on scedule. I have also not put any suspension on the dune buggy yet as I do not know how the unity engine will manipulate the wheel movement (such as the wheels moving up and down but the suspension remaining stationary).

For the track, I am basign it off the design I made earlier, where half of the track is in open plains/woodland and the other half in a valley where the player also drives through a tunnel.

Modelling Update

Just an update on how my modelling is progressing. Modelling the dune buggy is relatively easy, but there are problems when trying to model parts of the dune buggy that are not shown in the background images. Another problem is that there is not a background image that shows the dune buggy from above or below, which makes it difficult to get the rotation of some shapes correct.

The dune buggy is pretty much made by building the main chassis piece by piece from prefabs. The metal bars are made from extruding circles/cylinders using both background images to get an idea of where they should be placed. The metal panes were made by placing vertices on their corresponding places of the background image, and filling them in to form a plane using a fill.

The problem with using a background image as a viewpoint however is that the photographs of the dune buggy are taken from a perspective viewpoint, in comparison to the orthographic viewpoint in which I am viewing the background images from. This causes problems since I have to take depth into account when sorting out the placement of some components. The model so far can be seen below.

Start of the Modelling

There are two main things that I will need to model for my game, the Dune Buggy racing car and the track that they will race on. I am using blender to model both (since I know how to use blender more than other alternatives) and will import them into Unity when they're done.

Befor I began to model the Dune Buggy, I first needed some reference photos so that I could get the model as close as possible to the actual thing. What I needed were some perspective shots of the front, rear, top of the Dune buggy so that the scale would be constant throughout. In the end, I found some nice images from the website

http://www.emrockatv.com/product_info.php?products_id=612

The final images I have imported into unity (and set as a background image) are included below.

Progress

Now that all the designs have been done, I will start start to look on how to implement these ideas into a working design. I am looking into the XNA Game Studio for the core programming of the game, Blender for the models and Audacity for editing audio.

My reason for using these programmes are that I have used them before, and am relatively comfortable with the interfaces. The next stage will be to try and find reference pictures for the dune buggy model, as well as try and find any tutorials on making a 3D Racer in XNA.

A bit behind scedule at the moment (since I made a mistake on my timetable which caused me to take an extra module in the first semester) but will try to catch up.