Arvutigraafika - Kursused - Arvutiteaduse instituut

Momentum Racing

Lauri Kongas, Semjon Kravtšenko, Märt Mäemees

Do you like racing games, but they all look too similar? Do you want to feel the pressure and ridiculous tempo of a rythm game while racing? Do you want something... out of this world? Something surreal? We got you covered! Try our fresh and new Momentum Racing! Instant drift, surreal atmosphere, acid colors and physics that do not relate to reality at all. Download our UE4 game now!

Initial concept art. As you can see below, the final product has some of the features, but a number of them were not implemented.

Repository

Demo Video

Builds

Tools used

Unreal Engine 4 (23.1)
Blender 2.8
Krita
Paint.NET
Git

Features in the release

Modeled and textured player ship, which can be controlled by keyboard or mouse. Thrust particles, boost as well as brakes are implemented. Camera loosely follows the ship.
- Keyboard: Arrow keys: basic movement, space: forward boost, left ctrl: brake.
- Mouse: Move left/right: turning, Left click: forward boost, right click: brake.
- R to restart from checkpoint and Esc to get bact to the menu.
Spline-based road, also textured.
Three fully playable maps and menu, to pick a map.
Physics is not realistic nor common at all, just as planned.
Checkpoint system and arrow, leading to the next checkpooint. Lap system and overlay to see lap times as well as total time.
Customized skybox and lightning.
Clouds generated with perlin noise.

Long text about the features

Ship model

It was not an easy task to create ship model with Blender, due to lack of experience. After creating it, we exported the .fbx file and imported it to UE. However, some ship faces were seemingly missing from the game. The solution was to make sure that normals face outwards. Texture was simple, just as the model but it was trial and error to make it fit the UV-mapping.

Physics

The physics simulation of the ship is based on applying torques and forces to the ship and letting UE4 calculate the changes in angular as well as linear velocities resulting from those forces and torques. Linear damping is used to simulate drag and friction. In real life a hovercraft/ship like that would not have much friction, but this is an arcade game so we had some liberty in our choices. We tried to tune the physics to match how we wanted the ship to handle.

The other important aspect of ship physics that we had to deal with was the actual hovering. 4 line traces are used in order to apply an upward force to the hovercraft and allow it to glide over surfaces. The line traces extend beyond the sides of the ship in order to improve stability. Additionally, the center of mass is placed slightly below the ship for additional stability. Damping was implemented for the hover components in order to avoid excessive bouncing.

One issue we had during testing was that the ship could fly into the sky when its nose was pointing upwards. To prevent the player from flying up into the sky we limited the vertical component of thrust. The was also the issue that the ship could get airborne a bit too much after hitting a ramp. The aforementioned solution helped tackle this issue, but additionally a constant downward force was added to the ship.

The game also features a limited but renewable resource called boost. Boost is generated passively and there is a maximum amount. The current amount is shown in the bottom right corner of the screen on the boost bar. Boost can be expended in order to accelerate quicker as well as reach higher top speeds compared to regular forward thrust.

Maps and road

We needed to create some maps for the game. Initial map had no road, only 6 checkpoints. It was fine, but not very interesting. Then we decided that the logical thing to do is to create road with help of splines. This gave us a great degree of freedom with map-making. However, we had many issues with this approach. Happily, we could fix almost all of them. The map-making was very fast; we created 5 maps, 3 are picked to be included in the final product.

Checkpoints

The checkpoint system allows making tracks that are either point A to point B or a circular track with mutliple laps. The track consists of checkpoints which must be passed through in a certain order. The ship has an arrow that shows the direction to the next active checkpoint. If the track has multiple laps, the times of the players last laps (up to 5 latest) are shown in the HUD.

The checkpoint system also allows resetting the player, which puts the player ship to right after the latest passed checkpoint and resets its angular and linear velocity. The reset point and rotation can be changed on a per-checkpoint basis if the need arises due to special track layout.

Clouds

Clouds were created by using perlin noise. We wrote a Python script to generate the texture, it can be found in the Github repository. It uses OpenSimplex package to create noise. Then multiple noise levels are combined. The end result was decided to be binary, so a pixel of an image is white if the corresponding sum is greater than the treshold and black otherwise. Game interprets black as transparent.

Main menu

Finally we needed a main menu for the game since we had multiple levels that we wanted to include. The main menu allows the player to choose from any of the three included levels as well as allows the player to quit the game.

Reflection

As can be seen from our Github repository, most of the work happened mere days before deadlines. We probably could do better if we met together every week or so to discuss, split tasks and make our own deadlines. In this case we were saved by the fact that the work only required 120 hours total, but overall this is a bad practise. However, no official deadlines were broken and we are proud because of this. Strangely enough, our team had no teamleader, and we still managed to cooperate just fine. Everyone picked a task for himself by himself, features to include were proposed by everyone and approved collectively. Cooperation was truthfully amazeing. There were doubts that using Git will not suit our purposes well, because it is hard to resolve merge conflicts between UE4 files. However, there were only minor issues with that. It was hard and sometimes frustrating to learn, how to use UE4 and Blender, but we think it was defenitely worth it, because now we are much better at those tools.