Big Game Project – Post 1

The second year project that is set to be displayed at the Gotland Game Conference (GGC) has started production, and with that progress blogs every week until the big day, this being the first.

The project is done in teams and my team, called Team GG (The GG stands for Gravity Grind which was the name of the concept) consists of:

Jonas Lundgren as the Producer and Lead Programmer (https://enfisk1994.wordpress.com/)
Laban Melander as the Lead Designer (https://labanmelander.wordpress.com/)
Valdemar Ribbing as the Lead Artist http://valdemarribbing.blogspot.se/
Ludwig Lindstål as Artist and Soundguy (http://luiart.net/)
Simon Brundin as a Level Designer(https://harttago.wordpress.com/)

The game we are making is much like Wipeout and F-Zero with high-speed competitive racing. Our game, however, differentiates from these with having two tracks running mostly parallell that the players can swap between in the race.
It takes place on a scrapyard planet in the future, with broken buildings and debris everywhere, the cars built from whatever the racers could scavenge.
We are doing this using the Unity Engine 5 and coding in C#.

So now to what these blogs are for: weekly updates of my progress in this project.
My main task for this week was to make the vehicles move along the splines as the track twists, flips and turns which is one of the biggest parts of making this game work. The vehicle needs to feel the same to control no matter which way the track is currently running (The tracks and vehicles work with some form of magnetism lorewise which allows this).
Luckily one of the teachers had heard of these problems before and had some very useful links for this exact problem:
http://www.gamasutra.com/view/feature/131997/games_demystified_super_mario_.php
and
http://futuregrind.tumblr.com/post/101354098523/the-math-behind-the-futuregrind-track-editor

After reading these I started working on the task.
The basic solution was always: Raycast from the objects relative down vector and align after the normal of whatever the ray hits first.
That was not as easy as it may sound though, since Unity uses the black magic known as Quaternions that are very hard to control when you for example want to rotate something along a vector.
After searching the web and the Unity reference page I came across a solution, the Quaternion method FromToRotation apparently does this very well.
The method does exactly what we want: rotate a quaternion to a vector, the only thing now was that it didn’t work at all.
I blame the Quaternions.
After digging around some more I found that I also had to multiply this with the current rotation, so now it all looks like this:

Quaternion.FromToRotation(transform.up, hit.normal) * transform.rotation;

transform.up is the local up, which takes into account the transform of the object, it is always the up from the objects perspective.
hit.normal is the normal of the object hit with the raycast, curr is a RayCastHit-object.

Of course this method returns a Quaternion that I have to handle, the resulting quaternion is the final rotation where the vehicle is rotated as it should be along the normal of the mesh below it.
I should also mention that Unity handles the Raycasting brilliantly and if you hit a large mesh the returned collider will only be the triangle below you and not the entire object that you hit, which is exactly what I wanted.
Now I used a Slerp-method to make the rotation smooth and not just snap to the new rotation when a new collider was hit.

Ray ray = new Ray(transform.position, -transform.up);
   if (Physics.Raycast(ray, out hit, 100f))
   {
       m_targetrotation = Quaternion.FromToRotation(transform.up, curr.normal) * transform.rotation;
   }
   transform.rotation = Quaternion.Slerp(transform.rotation, m_targetrotation, Time.deltaTime * m_RotationSmoothing);

I later added another thing to this, making it only update the target rotation when the collider hit is a new one, done using a simple current hit != previous hit statement.

Those simple lines took me several hours to get working as they should, with adjustments being made to everything, and it still does not work the way i want it to, so it is by no means a finished work but it does give a pretty good idea of what the end result is going to look like.

After this I started working on a custom gravity for the same reason, the tracks shifting rotation needs an equally shifting gravitation. I made a temporary solution to this using the same way, the gravity is set to the negative normal of the mesh being hit by the downward raycast. It also checks the distance to the mesh and stops pulling down when close enough to the “ground”, which results in a somewhat functional but not even almost acceptable solution for the final game.

Other than working on design documents and trying out multiple controllers functionality and insanely simple ai just moving towards waypoints that was all I did this week. Thank you for reading and I’ll see you next week!