Formula V's Developer diary 1: Building the tracks

Hi backers! While we work on finishing the Visual Studio Code extension in order to being able to present you the tutorials about how to use our tools, we want to give exclusively you some insight into the development process of Formula V, so those of you that are not into software development can have a general picture of what goes into creating a video game (it is a lot!). And for those that would like to use our engine to implement a game, these diaries should give a glimpse of what the tutorials are going to look like.

So, let's start!

Streaming

The first problem that we had to solve to implement our racing game was to have a way to stream the track segments on the fly, given that the Virtual Boy doesn't have enough work nor graphics memory to load simultaneously all track.

Therefore, the track is divided into multiple segments:

VUEngine already has a generic streaming algorithm that loads and unloads game entities into the stage based on their relative positions with respect to the camera (Stage::stream). But given the predictable nature of the camera movement along the track, we could do a less generic, and more efficient algorithm.

So, we implemented a custom class, the TrackStage, that inherits from the Stage class and overrides the stream method. What we do in it is to have loaded only three track segments at any moment, while loading and unloading the next and previous one based on the player's racer's position.

The EntityFactory class takes care of spawning new entities in a deferred manner to avoid overloading the CPU with such a heavy task during a single game frame since it generally involves allocating memory for the entity and its components, that can be many graphics, animations, collision shapes, physical bodies, state machines, etc. And when it is done creating the new entity, it calls the client code back for it to take any further action (ie.: TrackStage::onTrackSetSpawned).

Going around the track

Streaming the track segments is the easy part though and it is not enough for having a racing game. We need a way to figure out things like racers' direction, the amount of laps that they have completed, how to guide the AI racers around the track, how to compute the race positions, etc.

To solve those and other problems, we use a sorted list of points that spatially define the track's layout. Those points are not written by hand though, instead, during the loading of the stage, they are computed on the basis of the track segment's collision shapes.

This way, each point acts like a target that the racers must reach to progress, and when they do so, the next point acts as the target and so on. This provides a mechanism to count laps, assign race positions, to check if a racer is going in the wrong direction, to make the AI to detect that it is approaching a curve for it to position itself correctly in order to brake the less amount possible in order to keep the momentum while avoiding the track's walls, among a lot of other things.

That is it for now!

We hope you enjoy these little insights into the development process of the game. Let us know in the comments below if you would like them to be more technical, maybe by showing more code or by going into more details about each step.