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.
This week I added the ability to import splines from max. We can now create a more complex track design in 3ds Max and line points up more precisely with the other world geometry, then simply export the spline as a .obj file.
Spline viewed in Max:
Generated track viewed in Unity:
Another thing I did this week was attempt to make the player’s velocity constant throughout the track. Before, the player would travel faster or slower depending on how the Bézier spline points were placed. This system is better now, but not quite in a final state yet.
Finally, I made the track width a little more flexible. We used to only be able to set the width of the entire track as a single value. Our artists asked for the ability to tweak the width of the track at certain points, so I added that feature this week as well.
Next week I hope to sort out the player movement, as that is such an important system and needs a good amount of TLC before I’d consider it to be good enough.
This week was mostly spent improving the prototype in various ways. Firstly, we received the feedback that the auto acceleration of the player should be removed, since when you let go of the controls the ship would keep going on its own and it felt like the player didn’t even have to try to succeed.
That was an easy change, and the game did feel much more like an active racing game.
Another thing that I changed was the way your input is mapped to the player’s movement when the player is upside down. Some play testers told us that when upside down it was confusing to have the controls be backwards. After switching around the controls when upside down, we got feedback from other play testers that they liked it better before. Because of this we will likely make this an option you can set before a game starts.
Next I made the projectiles that the player fires move along the track. Before, the player just shot wherever the mouse cursor was – which clearly wasn’t anywhere near good enough. Really, that was only in there because we hadn’t removed it after deciding to ditch mouse controlled shooting. After making this change shooting obstacles became much easier.
Throughout the week I also fixed bugs here and there and made the game in general nicer and more fun to play. I also cleaned up a few scripts to make creating new levels easier for everyone on the team. Part of that was just making scripts find the objects they need a reference to themselves, so that we don’t have to, for example, drag the player ship into 12 different scripts manually on a new level.
Next week I plan on continuing to make the game feel nicer to play and continuing to add additional features along the way.
After adding the ability to twist and curve the track, I needed to update the player movement script to take those changes into account. The player’s position and rotation are now effected by which part of the track they are on, as you can see below.
I also added the ability for the player to dodge left and right by double tapping a direction key.
Finally I added controls for how much acceleration power and braking power the player has. This way we can tweak both values separately and even adjust them in scripts (for example for a speed boost, or for an EMP which disables your brakes momentarily)