To add a little bit of polish I decided to code some scripts that allow me to animate objects that don't require complex animations, such as spinning on the spot, moving up and down etc. I also created slightly more complex movement using customisable targets. This allows me to move any object at runtime between 2 target points. This comes in handy when an object isn't travelling along straight lines. It uses the location of empty objects as target references and then translates between the two.
For this section of the stage, the animations work very well. I may need to add a wait timer to the train, but other than that it works, and brings a bit of life into the scene. Next I need to do the same for the trams in the downtown area, these are a bit more complex in that they will need to have more than point A and B to navigate. It will more likely be points A through D to show them moving properly and turning.
Integrated actual working buttons to the game, these allow for alternate routes to temporarily be activated. In total there are two buttons located in the stage, one at the entrance to the subway and the second in the last strech of the stage. The first moves a block, allowing access to the loop de loop and 2 coins, the other unlocks the giant glass tube allowing access to another coin.
With this implemented alongside coins, the stage has ful functionality in terms of gameplay. All that is left is to do, is model extra walls, props, walkways etc, all comsmetic stuff not entirely needed. And once that is done, just texturing is left and any polishing up such as visual effects!
One thing I had not considered when embarking on this project was realism; or just how much realism would play an important role. Unforeseen issues can occur when translating an older game to a modern source. One such thing is physics. The original game was basic in terms of realism, meaning that vehicle physics were not the same as they are today. Back then, a lot of games could get away with just having a constant force pushing downwards to simulate gravity. Now, advances in Physics have come such a long way; objects behave how you would expect them to in relation to the real world. Because the game I'm remastering doesn't use physics per se, I'm having issues translating the same gameplay to my project. Instead of recreating the game like-for-like, I'm aiming to make it better all round, meaning: visuals, gameplay, interface, physics... etc. In the source game, the player can race at very high speeds almost without any hinderance from the environment, unless colliding head-on with something. In my reproduction, the player can race at high speeds, however due to the nature of the physics in this simulation and that of the real world. If travelling fast enough an object may defy gravity. This might not sound like a deal, but it does in fact gameplay somewhat. Now the issue is that if the player is travelling fast enough and goes around a corner and hugs the outer curve they can and most often will be propelled up the wall.
Whilst this is to be expected, it does break the flow of the game causing annoyance.
Have a look at the video below for an in-game demonstration of the effect in question:
As you can see, the vehicle transitions to the wall due to the curvature forcing the wheels to collide with it pushing the car onto the new surface. In the video above the issue isn't as pronounced because of the car's speed, but can still be seen. If the player is travelling faster the height gained on the transition is much more considerable. As I mentioned before, in the original game this issue is non-existent. Simply because of the difference in engine physics, the older game was a traditional arcade racing game with basic physics, whereas this project is more of a racing simulator. Now I could have just created a similar style engine, making the process a bit easier. But then that would also not be improving the original source as a remaster should. Due to the plethora of high-quality racing games over the last generation, none use classic-style physics. So, this type of engine the project has been built upon is the most relevant within the given context. As such the issue remains and needs resolving. To remedy this a better understanding of physics is required, that and knowledge of driving. I understand the latter very little, due to never have driven before. But after some back and forth between a programmer he arrived at a solution:
"90 degree bank, in the real world, you can drive on it. 91 you cannot."
Which makes complete sense. Because all my wall colliders are 90 degrees and due to the engine, my vehicles were able to 'wall-ride' them. Editing them to add a slight slant in theory would fix the issue. Causing the cars to the hug the corner. After a quick test with basic geometry, we were able to test the theory:
And it worked! As you can see in the image above, a cube has been placed where a wall collider would have been, it has been rotated so it is no longer at 90 degrees and the results were as expected. The next stage is to edit the actual model for the wall colliders in Max and see how the next output works in-game and especially at high speeds. But the logic behind this idea dictates the car should be force downwards.
As you can see from the video, the theory works. The car no longer rides up the wall!
In preperation for testing, I'm finishing up little details for my project to make it look that bit nicer! Here is a short video showing a couple of things I added to make life a bit easier.
All thats needed now is track colliders to prevent unwanted exploration / falling out of bounds and its ready.
