This week I mainly worked on making the player movement more consistent along the track, and making the camera movement more fluid.
Up until this week the camera’s position was locked a specified distance behind the player, giving a very rigid feeling. I tried a handful of techniques to make the movement smoother, and went with the best solution.
The main feature I added to achieve this effect was a clamp on the camera’s movement value based on the player’s speed. The faster the player is going, the higher this value can be. Without taking the player’s speed into account here, the player would either zoom off into the distance and leave the camera behind – or the effect would be cancelled out entirely.
Another thing I added to smooth the camera motion is a slight overshoot when the player goes around a corner. The faster the player is going and the sharper the corner, the bigger the overshoot. This really makes the game feel more flowy and fun.
Finally, I moved a ton of string value calculations from Update() to Start() which improved performance wildly.
This week was mostly spent cleaning up scripts and improving the way certain values are calculated in order to have a smoother end-user experience.
The majority of my time on the project this week was spent working on adding the ability to have multiple tracks in a scene. I also added simple teleporters to go back and forth between the tracks. We considered making the tracks smoothly split off into two directions, but this solution is much simpler, and with how little time we have left we thought it was the best choice.
I also spent a while trying to make the player have a constant velocity over the length of the track, regardless of the spline length – a problem we’ve been dealing with since the beginning of the project. To start tackling the problem more efficiently, I decided to add some more info to the screen so I could more easily spot issues.
I displayed the basic movement variables of each player on screen and immediately saw a few things that were off, and fixed them up. As for a constant speed, I have yet to find a clean solution. The problem sounds simple, but there’s something small that I’m missing because it’s still off. Currently we’re multiplying the player’s delta spline value by the ratio between the current segment of the track they are currently on and the total length of the track. I displayed the approximation of the curve lengths to ensure that was working fine.
Hopefully I’ll see the issue soon and can remove the temporary fix thrown in there for now.
I wasn’t able to get as much done this week as usual since I was busy working on a game for the Ludum Dare 72-hour game jam over the weekend.
One thing I did add was a slight speed boost to the second player, to help keep the players closer together. This immediately made the game more fun because you can interact with the other player more often.
I also fixed a few bugs, as usual.
Finally I added a dedicated jump button and disabled the jump pad item. I also started working on allowing for multiple splines to be imported, so that eventually the player will be able to teleport from one to another, and be forced to make active decisions rather than just blindly follow a single track.
I spent a lot of time recently cleaning up scripts and simplifying things, all while removing bugs and improving performance.
- Reverse camera (on button hold)
- Ability to shoot faster by tapping shoot button rather than holding it down
- Camera FOV varying wildly on player acceleration
- Players spawned off the track during countdown timer
- Projectile rate of fire differing between players
- Projectiles not damaging other player on impact
- Performance drop when spline is selected in editor
- Turrets not correctly targeting the player
This week I focused mainly on improving the camera. First, I added three options for the camera’s position, which can be cycled through while playing.
Two new camera views – overhead (left), and reverse (right)
I also spent quite a bit of time trying to figure out how to prevent the player from going off the edge of the screen. Our first pass at the camera script set it to look directly at the player, but when racing quickly, this felt like running while staring at your shoes. So instead, I made the camera look at a point slightly down the track from the player. The problem with that solution was that if the look ahead value was too big, on sharp corners the player would go off the edge of the screen.
To solve this, I retrieved the player’s position in screen space to determine how close to the center of the screen they are. Then I used this value to interpolate between looking at the point down the track, and looking at the player.
The following image represents the player’s “off-centerness”, white being nearly off-screen, and black being fully centered. The higher this value (closer to white), the more the camera takes the player’s position into account.
That’s it for this week.
Last week I added the ability to import spline data from .obj files, but we later found out that you can’t export normal information along with the position data. To get around this, I added an option to import a “normal spline”. I can calculate the normal of each point on the track by just subtracting the points on the normal spline from the points on the original.
I also added a slider to control how many steps of interpolation there are on imported splines.
One issue our artists were having with importing splines was flipping axis systems. To prevent them from having to mirror the spline in Max every time they wanted to export it, I added an option to flip the spline when importing in Unity.
Finally I added a simple jump pad, which launches the player into the air. We’re currently experimenting with how this could effect gameplay – most likely it will be able to be used to avoid slower sections of the track like parts covered in running water.