The track generator in the first prototype of my procedural racing game works like a treadmill. The road is generated ahead of you and disappears behind you as you drive. Constantly creating and destroying objects in a game is bad practice, so I use what is known as an object pool. Rather than constantly spawning new track segments, the ones that disappear behind you are “recycled” back to the front.
The problem with this is that the object I was using as a track segment contained the mesh, the parameters that define the shape of the arc, and the methods for reasoning about the arc. This is a problem for two reasons. The first is that building huge classes with too much functionality is a bad coding habit in general. The second and more specific reason is that when a section of track is “recycled” we permanently lose all data about its previous life. It is impossible to travel backwards or to view the entirety of the track.
I’ve written a new and improved track generator that keeps data and meshes separate. I’ve also made it more customizable and able to produce different styles of tracks. Here are two examples:
These settings produce constantly winding roads similar to the first prototype.
These settings make long straight sections punctuated by sharp turns.
The next problem to solve is preventing the track from intersecting itself when it makes loops. In the first prototype I cheated and made the track constantly slope downwards so it would never cross itself. My work-in-progress solution involves dividing the world into a 2D grid, counting the amount of times the track passes through each section of the grid, and where several tracks pass through the same section, separating them by a minimum height. The green tiles in the above images are a visualization of that grid.
I’ve also been modelling a proper vehicle for the game to replace the lovely capsule primitive that currently fills that role. Think hovercar that looks like a 1980s sports car.