Alvin Philips' Blog

Using Yarn and Italian Music to Design a Racetrack

Sat, 28 Feb 2026 00:00:00 GMT

Overview

Switchgrass arose from one of my Game Level Design assignments. We were tasked with creating a racetrack for an arcade racing game. Later, we used the same racetracks to design and program AI opponents for a programming course.

As I am a massive fan of Burnout 3: Takedown, something that my friends and most of my professors (who referenced it during their slides!!) know all too well, this was one of my favourite level design assignments.

NOTE

This is a modified and expanded version of the project summary for Switchgrass, which I chose to separate due to length.

Brief

We were required to design racetracks in Maya that we brought into Unity, with provided car and camera controls (that we weren't allowed to modify). This assignment also required the use of several, distinct paths, namely:

Regular Path: The longest path, considered the 'default'
Shortcut: A skill-based shortcut that — if executed correctly — allowed for significant time savings.
Alternate/Failure: Either a split from the main/shortcut OR a consequence of failing to perform the shortcut.

Challenges

One aspect that I found immediately limiting (but later appreciated) was the time requirement. A single lap (out of 3) had to be about 30 seconds on the 'regular path'.

Another point of friction was the Maya requirement. I'd been a firm Blenderer since about 2013 (after moving up from SketchUp after several years) and wasn't too fond of paid, subscription-based software. This assignment changed my perspective on it, however, and I grew to really enjoy the workflow, and especially the plethora of vertex manipulation tools. If only it didn't cost one billion dollars.

<center>One of my racetrack iterations, in Maya.</center>

Design Methodology

Arcade racers are like, my thing, so I took this assignment very seriously. Due to two loosely-coincidental factors, the first being that the provided car was red, and the second being that I was watching The Art of Racing in the Rain on repeat, being one of newest comfort movies, I decided early on that the car was going to be a Ferrari. This was of course, not at all asked for in the brief.

Research

Partly due to being in theatre as a kid, and also because I like to really 'immerse' myself into any project I dive into, I started by exploring the feeling I wanted to evoke in the player as they played my racetrack.

Since I'd decided on the Ferrari theme early on, I enqueued my favourite Italian-American songs (Louis Prima, Tony Bennett, Bobby Darin, and Dean Martin). I listened to this playlist on repeat for a couple of days.

I also found two (2) versions of Quando M'Innamoro, the song Humperdinck's A Man Without Love is based on, that I really enjoyed. These were the recordings by The Sandpipers and Anna Identici.

What ensued was five hours of listening to these two songs as I played Burnout 3's Road Rage mode (in a red car, of course). Something that stood out for me immediately is how I felt myself entering a flow state during the turns. I knew I wanted a very flowy racetrack, with curves and undulating 'waves', and this led me to explore more nature-based areas.

Shortcut and Setting

Since I had some yarn (for crochet) at my desk in our lab and like using physical tools to aid my design process, I played around with a piece of string, molding it as I imagined myself driving over it, adding turns at the right moment, with short pauses in between. This was also when I thought of having my shortcut be a jump over one of these curved sections, earning you a decent time-save if you were able to perform it correctly.

Knowing this, the Grand Canyon seemed like a no-brainer, and I imagined driving over some more unpaved roads and also having this long straight bridge section, inspired by designs from state park posters.

We were also given a set of texture-mapped 'base' pieces we could use to build our racetrack. This was like a stripped down modular kit, and being able to quickly try different layouts really helped in my design process.

Level Design Document (LDD)

Given these constraints and a rough idea of what I wanted to do, I submitted the following as my initial LDD:

Constructing the Racetrack (and Iteration)

This part was the longest and most time-consuming, for obvious reasons. The detailed process of going from conceptual design to actual, playable track and the countless hours of playtesting and iteration would require a lot more room than I had planned for this series.

I let the rest of this article marinate as a draft as I considered my options, finally settling on a series of short Challenge -> Solution (or Hack) items, with the hope that some of this may prove useful to you.

Challenge 1: Player Controller and Camera

<center>Our little 'Ferrari'</center> <br />

The first challenge had to do with the provided (and immutable) vehicle controller and camera. If you're familiar with the Three C's (3C) framework of Character, Camera, and Controls, here's my not-at-all biased take on them:

Character (Car): Utterly primitive, all-or-nothing steering and throttle (-1, 0, or 1)
Camera: A simple follow camera with zero collision/clipping avoidance
Controls: Bad enough to make you chuck your gamepad at the wall

The steering was particularly frustrating, because unlike Burnout (or literally any arcade racer post Y2K era), you had very little control over how the car handled. Well almost.

There were two key 'secrets' I discovered:

The controls weren't half bad when using a gamepad. I always have atleast one controller on my desk (usually two, a DualSense and Xbox Controller, from my work playtesting and making a controller-specific glyph sytem for Furlastic Duo).
On keyboard, if you 'feathered' the A and D keys just right, you could take advantage of the vehicle's ability to skid to get a nice feeling turn. However, this did require having a limited collection of angles that felt good to drive on.

These discoveries allowed me to design a level that was playable on either gamepad or keyboard, with slightly varying skill ceilings, while keeping the 'flowy' feel I wanted intact.

Also, the camera limitation ended up being a bit of a nice design constraint. Since I wanted a canyon but clipping into the wall during normal gameplay was unacceptable, I used flat lower sections (near the road) on the canyon meshes, with them tapering upwards. This helped give them a nice look, with very simple, flat-shaded colours.

TL;DR #1: Know your enemies (evil player controllers and cameras)

Challenge 2: Track Length

Second, however, had to do with with the actual lap times. After settling on basic turn metrics, including angles and their respective lengths that felt right, I first made a rough, completely flat 'greybox-ish' version of my primary path to test out timing.

I found that since the controller was both much slower than most arcade games and harder to steer, the initial layout I'd planned on was just too long. I had to shrink a few areas to maintain the thirty second lap target. Many sections had the feel and pacing I wanted in my design so this was a careful craft of picking what was essential to my experience.

Here are some of the changes from the rough yarn prototype to a playable version in Unity:

I was able to keep most of what I cared about, but did have to get rid of the first turn, a choice that had some repercussions later (see Challenge #4).

TL;DR #2: Kill your babies, but know them well enough to keep what's core

Challenge 3: Physics and Collisions

Next, since I dealt with a range of inclines and also had overlapping jumps, my actual track mesh, although low-poly, was simply not enough for my 'walls'. The 'fix' was simply to ensure my walls (from my invisible collision mesh) were tagged as such explicitly and were completely upright, because of how this system was set up.

As a neat side effect, this allowed me to be quite creative with my visual wall geometry (the canyon), specifically using carefully angled faces so that I could get pretty looking lighting despite the extremely low polycount of the meshes and default shaders for this prototype.

Here's the collision mesh, visualized in magenta:

Additionally, I did not want to punish the player too harshly for failing a turn (I'm not THAT evil), so with the exception of the second hairpin (that I wanted to keep as a 'skill test'), I used smooth wall curves with runoff areas, coloured in red.

This prevented stopping the user abruptly mid-race, perhaps the cardinal sin in fast-paced arcade racing games. It wouldn't let them maintain a perfect lap time, but it provided some opportunity to regain lost time.

TL;DR #3: Optimize your collision meshes for players

Challenge 4: First Hairpin Difficulty

Finally, as a consequence of shortening my racetrack to meet the time constraint, I introduced the first hairpin turn much sooner. This turn felt really good, and is probably my favourite turn in the track, because I designed it so that if you follow the racing line just right, you get this nice little view of the bridge.

The issue, however, was that playtest-after-playtest, players complained about this turn being too hard too soon. Suggestions included simplifying the turn, moving the start point, and removing it entirely. These were all fine options, and offered with the bestest of intentions, but my gut told me that I was right about this turn so I kept the track exactly as is.

I just added some tyres. The actual collision mesh did not change at all. Quite remarkably, all complaints about this turn ended after this little change, and I even got praise for the 'improvement'.

TL;DR #4: ~~Ignore Player Feedback because you know better~~ Providing apparent safety is often enough

Conclusion and Next Steps

While I skimmed over the actual creation of the track for brevity, I hope that this expedition into a slightly different design process proves useful to you. Even if you dislike Burnout 3 (i am heartbroken </3) and Italian music, I encourage experimenting with physical media in your creative processes.

I almost always have some yarn, rubber bands, and a deck of cards within an arm's reach, as well as some paper and a nice pencil (I am particular to the now-discontinued Paper Mate American Classic that I own a sizable-but-dwindling supply of).

<center>Look at him zip around!</center> <br />

The next article outlines how I handled the logical racetrack representation for my track so AI vehicles (like the one above) could race on it.

BONUS (Desk Reveal!!)

Thanks for reading! Since you made it all this way, here's a little sneak peek of my desk from around the time I was working on Switchgrass:

<center>Pardon the cable (mis)management :P</center>

Type-safe Templated Vector Math in C++

Sun, 28 Dec 2025 00:00:00 GMT

Overview

I've worked on several game and engine projects over the years, and have often been constrained to not using external libraries (self-imposed or not).

I find myself rewriting a simple math library for almost every such project, usually consisting of Vectors, sometimes Quaternions, and occasionally Matrices. Over the years, I've honed my personal approach, making small improvements with each iteration.

A pain point of mine has been rewriting similar code for my Vectors, based on type (usually floats and some kind of int), and dimension (2D to 4D most of the time).

While working on my current engine project, I wanted to do things differently, using a template-based approach.

Why shouldn't I just use a library?

You probably should.

I recommend and love the popular glm (for C++) and nalgebra for Rust.

The only reasons I can think of where you'd want to do it yourself are:

You've been given a constraint - academic, professional, some funky new hardware or software environment
You want to learn how things work :P

For this project, I found myself in both camps, so allons-y!

Constraints

For this project, the following constraints exist:

No external libraries (anything in the standard library is fair game)
Target C++17, must be cross-platform (Windows and macOS)
Strong type-safety (vector sizes and types should be known at compile time)

To set expectations early, here's what this article is NOT:

A production-ready implementation that can be used as-is (you should really use a library if you can)
A SIMD-focused implementation (although a significant portion was auto-vectorized in my limited analysis on Compiler Explorer)
A step-by-step guide on Templates, Unions, and C++ building blocks

EDIT (2026-01-23): Benchmarking Results

I decided to see how far our little vector library could go, when compared to more battle-worn libraries. Using this benchmark with mostly game-related math libraries, I added a (slightly modified) version of the vector implementation described in this article.

Note that this is a simple (and limited) artificial benchmark and any results should be taken with a grain of salt.

Processor: Intel 285K @ 3.7GHz Platform: Microsoft Windows 11 Home 10.0.26200 N/A Build 26200 Config: AVX2 Release on MSVC

With that disclaimer aside, I was fairly satisfied with the results, as you can see below (iris::math, in bold). Perhaps I'll share the draft I have on my project naming conventions soon. You can also access my fork of the suite and run it for yourself.

<details> <summary>i am prepared</summary>

<center>Vector Math Benchmark Results (AVX2)</center>

ns/op	op/s	err%	total	benchmark
0.45	2,243,542,679.48	4.6%	6.12	Store int (reference 'no-op')
0.58	1,714,369,970.21	0.5%	8.21	SimpleMath::Vector2 addition
0.83	1,206,091,546.38	0.3%	11.64	SimpleMath::Vector3 addition
0.58	1,711,959,270.25	0.5%	8.23	SimpleMath::Vector4 addition
0.40	2,478,077,491.36	0.8%	5.66	glm::vec2 addition
0.58	1,710,846,262.20	0.4%	8.24	glm::vec3 addition
0.40	2,489,337,113.89	0.4%	5.63	glm::vec4 addition
0.40	2,479,973,746.77	0.4%	5.69	iris::math::Vec2 addition
0.59	1,701,580,789.86	0.4%	8.26	iris::math::Vec3 addition
0.59	1,703,061,426.53	0.4%	8.27	iris::math::Vec4 addition
0.41	2,468,506,731.24	0.4%	5.70	iris::math::Vec2d addition
0.78	1,274,161,231.64	0.7%	11.03	iris::math::Vec3d addition
0.59	1,690,558,191.07	0.8%	8.33	iris::math::Vec4d addition
0.58	1,710,549,154.08	0.4%	8.23	DirectX::XMFLOAT2 addition
0.80	1,246,191,237.56	0.4%	11.31	DirectX::XMFLOAT3 addition
0.59	1,702,247,130.14	0.5%	8.25	DirectX::XMFLOAT4 addition without Loads
0.41	2,467,564,988.05	0.8%	5.67	Vectormath::Vector2 addition
0.59	1,702,567,927.81	0.7%	8.27	Vectormath::Vector3 addition
0.58	1,710,337,496.98	0.3%	8.25	Vectormath::Vector4 addition
0.40	2,473,288,209.32	0.3%	5.67	move::vec2f addition (float)
0.58	1,712,618,430.95	0.4%	8.21	move::vec3f addition (float)
0.58	1,710,353,644.71	0.3%	8.23	move::vec4f addition (float)
0.40	2,486,217,379.27	1.1%	5.69	move::vec2d addition (double)
0.59	1,708,940,650.76	0.6%	8.21	move::vec3d addition (double)
0.40	2,502,909,765.89	0.5%	5.62	move::vec4d addition (double)
0.40	2,491,335,068.47	0.9%	5.64	rtm::vector4f addition
0.40	2,479,731,817.11	1.1%	5.64	rtm::vector4d addition
7.94	126,018,873.38	3.9%	113.87	Complex operation 1 with SimpleMath::Vector[x]
0.42	2,395,630,651.46	3.7%	6.01	Complex operation 1 with glm::vec[x]
0.85	1,174,060,624.03	1.5%	12.03	Complex operation 1 with iris::math
0.96	1,036,713,463.00	1.5%	13.75	Complex operation 1 with iris::math (double)
2.74	364,842,903.00	0.5%	38.80	Complex operation 1 with DXM
2.33	430,076,166.48	1.9%	32.65	Complex operation 1 with DXM w/out loads
0.42	2,361,197,614.76	2.0%	6.02	Complex operation 1 with Vectormath
0.60	1,669,618,203.58	0.9%	8.45	Complex operation 1 with move::math (float)
0.92	1,092,631,515.03	1.2%	13.00	Complex operation 1 with move::math (double)
18.87	52,985,662.87	0.8%	264.70	Complex operation 2 with SimpleMath::Vector3
0.58	1,721,804,988.22	0.5%	8.16	Complex operation 2 with glm::vec3
0.58	1,717,131,061.56	0.5%	8.22	Complex operation 2 with iris::math::Vec3
0.58	1,710,832,249.09	0.4%	8.22	Complex operation 2 with iris::math::Vec3d
1.71	586,098,312.20	0.4%	23.99	Complex operation 2 with DXM
0.93	1,073,290,249.20	0.6%	13.11	Complex operation 2 with DXM w/out loads
1.46	683,847,236.76	0.2%	20.56	Complex operation 2 with Vectormath
0.58	1,715,777,345.73	0.7%	8.21	Complex operation 2 with move::math (float)
0.59	1,703,203,829.76	0.5%	8.24	Complex operation 2 with move::math (double)
1.91	524,425,999.70	0.5%	26.87	Complex operation 3 with SimpleMath::Vector4
0.42	2,382,298,606.65	0.6%	5.90	Complex operation 3 with glm::vec4
0.42	2,371,708,204.57	2.3%	6.06	Complex operation 3 with iris::math::Vec4
0.42	2,377,005,412.50	1.2%	6.00	Complex operation 3 with iris::math::Vec4d
0.60	1,668,038,597.81	0.7%	8.42	Complex operation 3 with DXM
0.61	1,644,878,927.85	1.2%	8.64	Complex operation 3 with DXM w/out loads
1.11	898,842,061.20	1.0%	15.76	Complex operation 3 with Vectormath
0.60	1,670,635,891.60	1.9%	8.47	Complex operation 3 with move::math (float)
0.42	2,383,204,561.79	1.2%	5.97	Complex operation 3 with move::math (double)
0.42	2,398,342,589.80	2.4%	5.99	Complex operation 3 with rtm::vector4f
0.60	1,661,089,474.72	1.1%	8.48	Complex operation 3 with rtm::vector4d

</details>

Design

I wanted to approach this from a top-down perspective, focusing on the API I wanted, worrying about the implementation later.

Vec2 a = {2.3f, 4.1f};
Vec2 b = Vec2::UnitX(); // Vec2(1.0f, 0.0f);

a.x // 2.3f
b.y // 0.0f
a.z // ERROR: Vec2 does not have a z-component

Vec2 c = a + b; // Vec2(3.3f, 4.1f);
a += b; // a = Vec2(3.3f, 4.1f);
float d = a.Dot(b); // 3.3f

Vec3 e = {1, 2, 3};
e.z // 3.0f (Fine, e has a z-component)

e += b; // ERROR: You can't add Vec2s and Vec3s directly

Vec2Int f = Vec2Int::UnitY(); // Vec2Int(0, 1);

<center>Example API</center>

What do these (Vec2, Vec3, Vec2Int) all look like then???

If you don't mind spoilers, they're all just aliases, as so:

// Typedefs
using Vec2 = Vector<float, 2>;
using Vec3 = Vector<float, 3>;
using Vec4 = Vector<float, 4>;
using Vec2Int = Vector<int32_t, 2>;
using Vec3Int = Vector<int32_t, 3>;
using Vec4Int = Vector<int32_t, 4>;

I was first exposed to this idea five-or-so years ago, while working on my first sorta-serious game engine project, moon engine.

I was using the nalgebra library, and was surprised to learn that all their vectors (and matrices) were built on top of a single Matrix struct.

Okay... So what's `Vector<???, ???>` like?

While we'll have to modify this signature as we go forward, the basic definition is simply:

template <typename T, size_t N>
struct Vector;

Two things to note here briefly are:

this would technically allow us to create vectors of any type
we can have n-dimensional vectors, where n is a non-negative integer (this would include zero)

While these are definitely fascinating concepts if you're mathematically-inclined, we're focusing on a simple game-specific library where concepts such as a Vec3 of std::string and zero-dimensional vectors aren't too useful, so we'll fix this eventually.

On `constexpr`

Inspired by a rewatch of this talk, another goal for me on this project was maximizing constexpr use where appropriate.

As such, most of the code is constexpr, including all constructors, operators, and most additional operations.

Basic Implementation

Helpers

A small helper to store the size of a Vector called size:

constexpr static size_t size = N;

Storage (a.k.a. I still want access via .x, .y, etc.)

This is one of the bigger gotchas when it comes to switching to a single templated struct to store our vectors. We lose the freedom of having simple element-based access by default.

While separately you could do the following:

struct Vec2 { float x, y; };
struct Vec3 { float x, y, z; };
struct Vec4 { float x, y, z, w; };

There's no easy way to do the same with our shiny new Vector<T, N> struct. Well, kinda.

The trick is to use even more templates!

Instead of handing storage on our Vector directly, we'll use another templated struct, VecData.

What is `VecData`?

VecData is a simple templated struct like this:

template <typename T, size_t N>
struct VecData {
    T data[N];

    constexpr VecData(): data{} {}
    explicit constexpr VecData(const T value) : data{} {
        for (size_t i = 0; i < N; i++) {
            data[i] = value;
        }
    }
};

We then update our Vector definition as such:

template <typename T, size_t N>
struct Vector : VecData<T, N> {
    using storage_type = VecData<T, N>; // another helper
    // magic for now...
};

But that didn't help...?

Although we now have somewhere to store our data, we aren't really any better off in terms of dimension-specific fields.

However, we can make use of Template Specializations!

With the constraint that we'll provide better support for 2-to-4 dimensional vectors, which are what we'll mostly be working with anyway, we can do the following:

// For Vec2, Vec2Int, etc.
template <typename T>
struct VecData<T, 2> {
    union {
        T data[2];
        struct { T x, y; };
    };
    constexpr VecData(): data{static_cast<T>(0), static_cast<T>(0)} {}
    explicit constexpr VecData(const T value): data{value, value} {}
}

// For Vec3, Vec3Int, etc.
template <typename T>
struct VecData<T, 3> {
    union {
        T data[3];
        struct { T x, y, z; };
    };
    constexpr VecData(): data{static_cast<T>(0), static_cast<T>(0), static_cast<T>(0)} {}
    explicit constexpr VecData(const T value): data{value, value, value} {}
}

// For Vec4, Vec4Int, etc.
template <typename T>
struct VecData<T, 4> {
    union {
        T data[4];
        struct { T x, y, z, w; };
    };
    constexpr VecData(): data{static_cast<T>(0), static_cast<T>(0), static_cast<T>(0), static_cast<T>(0)} {}
    explicit constexpr VecData(const T value): data{value, value, value, value} {}
}

Our actual storage occurs via this anonymous union (my beloved <3) of a fixed-size array and nameless struct containing our individual, named values.

NOTE: This is technically UB land (in C++, it's been well-defined in C for ages) but this is extremely common in real-world usage (because of the benefits) and is an extension provided by most of the common compilers. I've tested this on MSVC and clang personally, which fits my needs. Yours may vary.

What about defining all members specifically?

Can't let anything past you, can I? We'll get to this a little later but supporting the following is essential:

Vec2 = {2, 3.2f}; // Exactly two parameters that convert to float
Vec3Int = {4, 12, 32}; // Exactly three parameters that convert to int32_t

It does get into slightly more complicated territory though, so I'm going to hold off on the explanation for now.

Constructors

Our two primary constructs are fairly straightforward, as you'd expect:

struct Vector : VecData<T, N> {
    ...
    constexpr Vector() : storage_type() {}
    explicit constexpr Vector(T value) : storage_type(value) {}
    ...
}

I use our storage_type helper to make things a little easier to read.

We'll get into our third, secret constructor later. Hope you're excited!

Element-wise Accessors

Accessors via the [] operator, both const and not provide index-based access to the underlying data.

constexpr T& operator[](size_t i) { return this->data[i]; }
constexpr const T& operator[](size_t i) const { return this->data[i];}

To keep things simple and fast, there are no checks here.

Arithmetic Operations

At a minimum, I want to support the following operations (where A, B, and C are vectors):

C = A + B; // Addition
C = A - B; // Subtraction
C = A * B; // Element-wise Multiplication
C = A / B; // Element-wise Division
C = A * scalar; // Multiply with a scalar
C = A / scalar; // Division by a scalar

As well as their their in-place cousins (+=, /=, etc.)

This is fairly straightforward, as a simple loop that iterates and operates over each element:

// Add two Vectors
constexpr Vector& operator+=(const Vector& v) {
    for (size_t i = 0; i < size; i++) {
        this->data[i] += v.data[i]; // Similar for -, *, /
    }
    return *this;
}

// Multiply by a scalar of T
constexpr Vector operator*(const T value) const {
    auto result = *this;
    result *= value;
    return result;
}

Dot Product <3

Like many others, I love the Dot product -- it is my favourite vector operation of all time (along with the 2D Wedge product).

Part of its charm lies in how simple it really is:

multiply each corresponding component of two vectors
sum the results
profit

In our library, dot products are performed with a simple:

auto scalar = A.Dot(B);

Implementation isn't much more complicated than the previous operations:

// Inside Vector:
constexpr T Dot(const Vector& v) const {
    auto result = static_cast<T>(0);
    for (size_t i = 0; i < size; i++) {
        result += this->data[i] * v.data[i];
    }

    return result;
}

Cross Product

Unlike the wonderful dot product -- that works for all n-dimensional pairs of vectors (or sequences of numbers) -- the Cross-Product is only defined for 3D ones (and 7D??). Since I can only personally visualize up to six dimensions, implementation of a 7D cross-product is left to the reader.

// OK: 3D Cross Product
using V3 = Vector<T, 3>; // for any type T
V3 A;
V3 B;

V3 C = A.Cross(B);

// NOT OK: 4D Cross Product?
using V4 = Vector<T, 4>; // for any type T
V4 X;
V4 Y;
auto Z = X.Cross(Y); // ERROR: Cross() isn't defined because N != 3

As such, this acts as our first major roadblock. We have a templated Vector that could be of any size, but we only want the Cross Product to be available on Vectors where N (our dimensions) is 3 (and 7 if you're up for it).

template <size_t M = N, typename = std::enable_if_t<M == 3>>
constexpr Vector<T, M> Cross(const Vector<T, M>& other) const {
    static_assert(M <= N); // We allow Vec4.Cross<3>() but NOT Vec2.Cross<3>()
    return {
        this->data[1] * other.data[2] - this->data[2] * other.data[1],
        this->data[2] * other.data[0] - this->data[0] * other.data[2],
        this->data[0] * other.data[1] - this->data[1] * other.data[0]
    };
}

`M`?? `enable_if_t`?? `static_assert`?? What's all this then?

If you're new to the land of template metaprogramming, this can be a bit much at first, but it's fairly straightforward once you understand the individual parts.

First, we add an additional template parameter M that defaults to our own dimensions (N). We then make sure that this is equal to 3.

This takes advantage of SFINAE as such:

auto r1 = vec2.Cross(another_vec2); // NOT allowed, M = N = 2, 2 != 3
auto r2 = vec3.Cross(another_vec3); // Allowed, M = N = 3, 3 == 3
auto r3 = vec4.Cross<3>(another_vec3); // Allowed, M = 3, 3 == 3
// Here the final component of the Vec4 is ignored, acting as if it were a Vec3.
// This is safe because for performance reasons, or otherwise, we may want to use a 4D Vector as if it were a 3D one, ignoring the w

// However, not that the following is not permitted:
auto r3 = vec2.Cross<3>(another_vec3); // NOT allowed, although M = 3, 3 == 3, static_assert fails

Four (or more) component vectors may still use the Cross Product, provided they explicitly override M, ensuring any such usage is intentional. The static_assert simply makes sure that we're not trying to do cross products on a Vector with fewer than three components.

2D Wedge Product

Similarly, I find myself using the 2D Wedge product (a.k.a. perpendicular dot product) frequently, such as in my racetrack sector representation article.

The math for this is quite beautiful:

a.x * b.y - b.x * a.y

The implementation is as such, with similar tricks to the Cross Product:

template <size_t M = N, typename = std::enable_if_t<M == 2>>
constexpr T Wedge(const Vector<T, M>& other) const {
    static_assert(M <= N);
    return this->data[0] * other.data[1] - this->data[1] * other.data[0];
}

Length and Normalizing

Finally, the other common operations we need to handle have to do with size and normalizing.

Things get a little challenging here, for a few key reasons.

Firstly, the idea of normalizing (scaling a vector by the inverse of its length), ensuring that all elements fall within the -1 to 1 range only really makes sense if we can represent such values. As such, the idea of normalizing Vec2Ints and such needs some addressing.

Normalized Types

There's rarely a perfect solution and my choice was to convert Vectors to a type that can represent these values when normalizing.

As such it means the following:

original type	normalized type
float	float
double	double
anything else	float

Hence, a Vec3Int would transform into a Vec3 when normalized.

So, we need a way to represent this programmatically. Taking advantage of another type trait, we can use the following as another helper in our Vector:

using normalized_t_type = std::conditional_t<std::is_floating_point_v<T>, T, float>;
using normalized_type = Vector<normalized_t_type, N>;

Here, if T is a floating-point value (such as float or double), it keeps the same type, defaulting to float if not for all other types.

normalized_t_type and normalized_type are simple aliases that make expressing this a lot easier.

Measuring Length

Since the length of a vector is simply the square root of the sum of it's squared elements (which is analogous to a dot product with itself), we can separate the two steps, in a sense:

LengthSquared() that performs the Dot product with itself and retains its type
Length() that performs the square root and returns a normalized_t_type

LengthSquared()

For this library, I chose to not handle overflow, to keep things simple, but you may need to. Since our beloved Dot product already handles the logic, we can simply use:

constexpr T LengthSquared() const {
    return Dot(*this);
}

The squared length is often useful in its own right, since square roots can be expensive. It's often used in circle-to-circle collision detection, for example, where squared distances are sufficient.

Length()

Now, all we need is a Length function that takes the square root right?

Well, yeah, but we run into a particularly frustrating problem here: std::sqrt is not constexpr. Not in C++17, and not until C++26?!?!

This trickles up, so normalizing and everything else that requires the length can no longer be constexpr, unless we write our own square root function that is. I chose not to for this specific project, largely to ensure the implementation was technically sound and identical to std::sqrt for all valid cases (float, double, and long double?).

With a solemn disposition, here's our function. The disgraceful, non-constexpr member of the family:

normalized_t_type Length() const {
    // NOTE: std::sqrt is NOT constexpr in C++17
    return std::sqrt(static_cast<normalized_t_type>(this->LengthSquared()));
}

Normalize, Finally

We have all the tools to normalize vectors now:

normalized_type Normalize() const {
    normalized_type result = *this;
    normalized_t_type length = Length();

    if (length == static_cast<normalized_t_type>(0)) {
        return result;
    }

    return result / length;
}

Note that because our Length() isn't constexpr, this won't be either. The zero-check is simply to avoid pesky division-by-zero errors.

With that we're done with the core of our vector implementation!

Practical Improvements

Gatekeeping Vectors

As mentioned previously, we don't actually want anything to be a Vector. We can achieve this protection by using a similar trick to our earlier approach with Cross products.

First, we add the following helper:

template <typename T, size_t N>
using is_valid_vec_t = std::enable_if_t<std::is_arithmetic_v<T> && (N > 0)>;

We then update our structs as follows:

// Declaration
template <typename T, size_t N, typename = is_valid_vec_t<T, N>>
struct VecData;

// Definition
template <typename T, size_t N, typename>
struct VecData { ... }

// Specializations for 2D, 3D, and 4D Vectors
template <typename T>
struct VecData<T, 2, is_valid_vec_t<T, 2>> // similarly for 3-and-4D Vectors
{...}

// Vector Implementation
template <typename T, size_t N, typename = is_valid_vec_t<T, N>>
struct Vector : VecData<T, N> { ... }

So no more Vector<std::string, 0>.

Secret Constructor

It's finally here!!

Keep in mind that we'll still have to do the actual work in VecData, and we have a helper structure called Initializer to set things up. We'll go over it after we look at the constructor on our Vector.

It can look fairly complicated, so I'll break it down once you've had a minute to take all of it in:

template <typename... Args, typename = std::enable_if_t<sizeof...(Args) == N
    && (std::is_convertible_v<Args, T> && ...)
    && (std::is_floating_point_v<T> || (!std::is_floating_point_v<Args> && ...))>>
constexpr Vector(Args... args)
    : storage_type(typename storage_type::Initializer({static_cast<T>(args)...})) {}

That's a lot of dot dot dots

Unlike in Mamma Mia!, the ...'s here serve a very different purpose.

Here, they're used in a few key ways, depending on context:

`typename... Args`

This is a variadic template parameter that allows multiple arguments to be packed into Args.

This allows us to pass in as many arguments as we'd like. However, this isn't quite what we want.

We want to ensure the following as well:

We accept exactly as many parameters as elements we can hold (that is count(args) == N)
We only accept values that are either T or can be converted to T (like ints can be converted to floats, for example).
We don't allow a double to be passed in for int (but we allow the converse).

`sizeof...(Args)`

The first piece in our std::enable_if_t ensure that we have exactly N parameters, like we wanted.

The sizeof... operator, like its cousin sizeof (that returns sizes of types in bytes) gives us the count of the variadic template argument pack, Args.

`(std::is_convertible_v<Args, T> && ...)`

This is a fold expression, available since C++17 that makes all of this a lot easier to work with.

We check each parameter in Args to make sure it is convertible to T, and logically AND the results.

`(std::is_floating_point_v<T> || (!std::is_floating_point_v<Args> && ...))`

Similarly, if we're not a floating point type, we require all arguments to also not be floating point values.

With these pieces in place, we can now accept the right number and kind of arguments in our constructor.

`static_cast<T>(args)...`

Here we use another fold expression to cast all of our arguments to T.

Well what's `storage_type::Initializer` really?

Okay, I guess it's time to raise the curtains. The final piece of our secret constructor magic lies in our VecData structs.

The primary template contains the following:

struct Initializer { T data[N]; };
explicit constexpr VecData(Initializer init) : data{} {
    for (size_t i = 0; i < N; i++) {
        this->data[i] = init.data[i];
    }
}

Fairly straightforward, an array of N elements that we accept as a parameter. Similarly, the specializations are updated as follows:

// VecData<T, 2, is_valid_vec<T, 2>>
struct Initializer { T x, y; };
explicit constexpr VecData(Initializer init) : data{init.x, init.y} {}

// VecData<T, 3, is_valid_vec<T, 3>>
struct Initializer { T x, y, z; };
explicit constexpr VecData(Initializer init) : data{init.x, init.y, init.z} {}

// VecData<T, 4, is_valid_vec<T, 4>>
struct Initializer { T x, y, z, w; };
explicit constexpr VecData(Initializer init) : data{init.x, init.y, init.z, init.w} {}

We forward our Args, each casted to T, into our VecData<T, N>::Initializer ensuring we use the correct constructor.

Constants

If you recall our initial API, you might recall the use of Vec2::UnitX() and Vec2Int::UnitY() and such.

I find these particularly useful to express the following: 0. Zero Vector (all elements are zero)

One Vector (all elements are one)
Unit Vectors for each available Axis
Direction Vectors (Up, Down, Right, Forward, etc.)

The Zero and One Vectors are straightforward and simply:

static constexpr Vector Zero() { return Vector(); }
static constexpr Vector One() { return Vector(static_cast<T>(1)); }

The direction vectors prove challenging due to their reliance on dimensionality, yet again:

Vec2::UnitX() // Vec2(1, 0);
Vec2::UnitZ() // ERROR: No z-component

While we could've technically used more conditional template magic here, I wanted a simple, clean approach that didn't muddy our beloved Vector struct with a host of conditional logic. I also knew that I wanted these to be static and constexpr.

Hence the following:

template <typename T, size_t N, typename Vec>
struct VecDirections {};

template <typename T, typename Vec>
struct VecDirections<T, 2, Vec> {
    static constexpr Vec UnitX() { return Vec{static_cast<T>(1), static_cast<T>(0)}; }
    static constexpr Vec UnitY() { return Vec{static_cast<T>(0), static_cast<T>(1)}; }

    static constexpr Vec Right() { return UnitX(); }
    static constexpr Vec Left() { return -UnitX(); }
    static constexpr Vec Up() { return UnitY(); }
    static constexpr Vec Down() { return -UnitY(); }
};

template <typename T, typename Vec>
struct VecDirections<T, 3, Vec> {
    static constexpr Vec UnitX() { return Vec{static_cast<T>(1), static_cast<T>(0), static_cast<T>(0)}; }
    static constexpr Vec UnitY() { return Vec{static_cast<T>(0), static_cast<T>(1), static_cast<T>(0)}; }
    static constexpr Vec UnitZ() { return Vec{static_cast<T>(0), static_cast<T>(0), static_cast<T>(1)}; }

    static constexpr Vec Right() { return UnitX(); }
    static constexpr Vec Left() { return -UnitX(); }
    static constexpr Vec Up() { return UnitY(); }
    static constexpr Vec Down() { return -UnitY(); }
    static constexpr Vec Forward() { return UnitZ(); }
    static constexpr Vec Back() { return -UnitZ(); }
};

So we can now do VecDirections<float, 3, Vector<float, 3>>::Forward() and it works!!

Well, that's annoying to type out and not quite the lovely Vec3::Forward() we wanted though...

We can finally update our Vector struct definition (for the last time, I promise) as such:

template <typename T, size_t N, typename = is_valid_vec_t<T, N>>
struct Vector : VecData<T, N>, VecDirections<T, N, Vector<T, N>>

The observant few of you may notice that we're passing in itself(?) to its parent VecDirections. This is a case of Curiously Recurring Template Pattern (CRTP), a name I only recently discovered, despite using the pattern in my work for several years now. It lets us use the templated Vector in VecDirections without creating a circular dependency.

Converting, Truncating, Projecting, and Expanding

For our final stretch, I wanted to go over a few common helper methods I added to my Vector.

Converting Types

A common use case might be to convert a Vec3 to a Vec3Int or vice-versa, and it helps to have an easy way to do so.

We use some more template magic and checking to do so:

template <typename U, typename = std::enable_if_t<std::is_convertible_v<T, U>>>
explicit constexpr operator Vector<U, N>() const {
    Vector<U, N> result;
    for (size_t i = 0; i < N; i++) {
        result[i] = static_cast<U>(this->data[i]);
    }
    return result;
}

Truncating Vectors

Another common operation is creating a 3D Vector from a 4D one. This is useful if we are multiplying 3D vectors via 4x4 homogeneous transformation matrices, for example.

Here's what that looks like:

template <size_t M = N - 1, typename = std::enable_if_t<(M > 1)>>
constexpr Vector<T, M> Truncate() const {
    static_assert(M <= N); // Ensure we're not going out-of-range
    Vector<T, M> result;

    for (size_t i = 0; i < M; i++) {
        result[i] = this->data[i];
    }

    return result;
}

Defaulting to one dimension less, we allow truncating a larger vector to a positive integer M, such that 0 < M <= N.

Projecting Vectors

Similarly common is transforming a 4D vector into a 3D one by taking its last component (the w) and dividing each of the other elements with it.

It's implemented similarly to truncating:

template <size_t M = N - 1, typename = std::enable_if_t<(M > 0)>>
constexpr Vector<T, M> Project() const {
    static_assert(M < N); // Ensure we're smaller
    Vector<T, M> result;
    const auto w = this->data[size - 1];

    const auto inv_w = w == static_cast<T>(0) ? static_cast<T>(0) : static_cast<T>(1) / w;

    for (size_t i = 0; i < M; i++) {
        result[i] = this->data[i] * inv_w;
    }

    return result;
}

We similarly allow projecting to a smaller vector, of size M, such that 0 < M < N. Note that I could have defined this purely for 4D vectors (like we did the Cross product), but chose to keep this one generalizable.

Expanding Vectors

Similar to truncating, I find myself needing to expand a smaller dimensional vector to a larger one frequently. This time I chose to make it a single element larger, always.

Here's the code:

constexpr Vector<T, N + 1> Expand(const T value = static_cast<T>(0)) const {
    Vector<T, N + 1> result;

    for (size_t i = 0; i < size; i++) {
        result[i] = this->data[i];
    }
    result[size] = value;

    return result;
}

Closing Remarks

That was quite the journey, and I thank you for reading if you made it all the way. Reach out if you find any errors, want to suggest improvements or suggestions (I'm always looking for more to dive into), or just to liven my inbox.

I may get around to making this a bit of a series, with articles such as Quaternions, Matrices, and more.

Till we meet again,

Fin.

Stack-based Menu Systems

Fri, 03 Oct 2025 00:00:00 GMT

Overview

UI layout and rendering has always fascinated me, and one of the patterns I seem to always return to while making my games is the good-old Stack-based Menu system.

I've used this in several of my games, including Furlastic Duo, Axis Shift, and most recently, JellyFish, as well as several personal projects.

What's a Stack?

A Stack is a linear data structure that uses a Last In First Out (LIFO) methodology. That is, the last element in is the first that's removed. A stack of plates is a commonly cited analogy. The last element is also called the top of the stack.

Adding and Removing elements are called Pushing and Popping, respectively. If represented as an array, a Push would (assuming there's space) add an element to the end of the array, after the current last element. Similarly, a Pop operation (assuming it's not empty) would remove this last element, returning it.

There's a third common operation, Peek, which as the name implies, allows you to check the last element sneakily (not really) without removing it from memory. This ends up being extremely useful.

Why a Stack?

A Stack ends up representing most common UI navigation patterns extremely well. Navigating to another page, for example, is as simple as Push-ing a new page on the stack. Similarly, returning to a previous one is a simple Pop.

As long as a single menu is interactable at a given time (the menu on top of the stack), this makes for a simple but fairly versatile system.

For similar reasons, stacks are also often used to track Undo/Redo states, page navigation at both the browser and sometimes website level, and windowing systems.

Why make a Menu System to begin with?

Well, there's a few reasons:

I like having a central system for most of my menus (HUD is usually separate) as it makes tracking things extremely easy.
Separate menus that share a common interface promote less rigid patterns with dozens of references all over the place.
I want each Menu to handle a single, presentation-related task, rather than core logic directly.
Debugging Menu state is as easy as logging current Menu stack.

Implementation Overview

Over time, I've developed a rough framework for how I like to set up my menu systems. For the purposes of this article, I'll focus on a concrete Unity implementation, but it's pretty similar in whatever.

To ensure brevity, I'll work within the following constraints:

UI Toolkit: exclusively target Unity's 'modern' (albeit half-baked) UI solution
Singleton-based MenuManager: while Singleton hate is often warranted, I know that this will truly be a single instance deal
Base Menu Class: common functionality is shared/abstracted

[RequireComponent(typeof(UIDocument))]
public abstract class Menu : MonoBehaviour
{
    [SerializeField] protected StyleSheet style;

    protected UIDocument Document { get; private set; }
    protected VisualElement Root => Document.rootVisualElement;

    private bool _isInitialized;

    private void Initialize()
    {
        if (_isInitialized) return;
        Document = GetComponent<UIDocument>();
        if (style is not null && !Root.styleSheets.Contains(style))
        {
            Root.styleSheets.Add(style);
        }
        _isInitialized = true;
    }
    ...
}

The RequireComponent makes Editor setup easier, and prevents misconfiguration. I tend to use the RequireComponent + GetComponent pattern fairly frequently in my work.

Refresh

To ensure up-to-date information is displayed, Menus have a public Refresh() method that rebuilds UI after initializing the Menu, if required.

public void Refresh()
{
    Initialize();
    BuildUI();
}

Showing and Hiding Menus

Showing and hiding Menus is similarly straightforward, although I like having Unity Events (that I can configure in-editor) for when I show or hide a Menu.

public virtual void Show()
{
    var wasActive = gameObject.activeSelf;
    gameObject.SetActive(true);
    Refresh();

    if (wasActive) return;
    onMenuShow?.Invoke();
}

public virtual void Hide()
{
    if (!gameObject.activeSelf) return;

    gameObject.SetActive(false);
    onMenuHide?.Invoke();
}

MenuManager

At it's core, the MenuManager is basically just:

public class MenuManager : PersistentSingleton<MenuManager>
{
    private const int MAX_MENU_STACK_DEPTH = 32;
    private readonly Stack<Menu> _menuStack = new(MAX_MENU_STACK_DEPTH);

    public void Push(Menu menu) { }
    public bool Pop() { }
}

PersistentSingleton?

When I do use Singletons, I like having a single (or a few, in this case) templated Singleton implementations for consistent access.

This is what my PersistentSingleton looks like in Axis Shift:

public abstract class PersistentSingleton<T> : Singleton<T> where T : Component
{
    protected override void Awake()
    {
        if (_instance is null)
        {
            _instance = this as T;
            DontDestroyOnLoad(gameObject);
        }
        else if (_instance != this)
        {
            Debug.LogWarning($"Duplicate instance of {typeof(T)} destroyed!", this);
            Destroy(gameObject);
        }
    }
}

Similarly, Singleton:

public abstract class Singleton<T> : MonoBehaviour where T : Component
{
    protected static T _instance;

    public static T Instance
    {
        get
        {
            _instance ??= FindAnyObjectByType<T>();
            if (_instance is not null) return _instance;

            var go = new GameObject(typeof(T).Name);
            _instance = go.AddComponent<T>();
            return _instance;
        }
    }

    public static bool HasInstance() => _instance is not null;

    protected virtual void Awake()
    {
        if (_instance is null)
        {
            _instance = this as T;
        }
        else if (_instance != this)
        {
            Debug.LogWarning($"Duplicate instance of {typeof(T)} destroyed!", this);
            Destroy(gameObject);
        }
    }

    protected void OnDestroy()
    {
        if (_instance == this) _instance = null;
    }
}

Showing a new Menu

Pushing a Menu simply adds it on top of the Stack, if there's space, and shows it, hiding the menu underneath:

public void PushMenu(Menu menu)
{
    if (_menuStack.Count >= MAX_MENU_STACK_DEPTH)
    {
        Debug.LogWarning($"Menu stack limit reached! Cannot push new menu {menu}");
        return;
    }

    menu.Show();

    if (_menuStack.TryPeek(out var currentMenu))
    {
        currentMenu.Hide();
    }

    _menuStack.Push(menu);
}

Notably, I Show() the new Menu before calling Hide() on the previous one to prevent popping. An intermediary screen (I've used a full-screen Canvas in the past) or a transition could also go here.

Returning to a Previous Menu

Similarly, Popping the newest Menu off the Stack returns us to the previous state.

public bool Pop()
{
    if (!_menuStack.TryPop(out var oldMenu)) return false;

    if (_menuStack.TryPeek(out var currentMenu)) currentMenu.Show();

    oldMenu.Hide();
    return true;
}

It also returns a boolean, indicating whether the operation was successful.

Creating a Menu

Here's a simplified Main Menu:

public class MainMenu : Menu
{
    protected override void BuildUI()
    {
        var buttons = Root.Q("Buttons");
        buttons.Clear();

        var newGameButton = CreateMainMenuButton(buttons, "START GAME", "Start a New Game");
        newGameButton.Focus();
        newGameButton.ApplyClickCallbacks(_ =>
        {
            GameManager.Instance.ChangeState(new PlayState());
            newGameButton.SetEnabled(false);
        });

        var optionsButton = CreateMainMenuButton(buttons, "SETTINGS", "Modify Game Settings");
        optionsButton.SetEnabled(false);

        var creditsButton = CreateMainMenuButton(buttons, "CREDITS", "Game Credits");
        creditsButton.SetEnabled(false);

        var quitButton = CreateMainMenuButton(buttons, "EXIT TO DESKTOP", "Quit Game");
        quitButton.ApplyClickCallbacks(_ => Application.Quit());
    }

    private Button CreateMainMenuButton(VisualElement buttonContainer, string label, string tooltip = null)
    {
        var buttonHelp = Root.Q<Label>("ButtonHelp");

        var button = buttonContainer.Create<Button>("main-menu_option");
        button.text = label;

        button.RegisterCallback<FocusEvent>(_ => buttonHelp.text = tooltip);

        return button;
    }
}

The callbacks do need to be tracked and discarded when required to prevent a memory leak, but this makes for a pretty flexible system overall.

Is that it?

Well, not quite. It varies by game, and I do slightly different things each time, like Build Version Text for Axis Shift and Adaptive Controller-aware Sprites for Furlastic Duo. I also usually allow optional async (via UniTask).

Adding async capabilities (and making it thread-safe) are left as exercises to the reader.

Representing Racetracks with Sectors

Sun, 26 Jan 2025 00:00:00 GMT

Overview

For Switchgrass, I wanted to use a simple, sector-based approach to represent a model of the track for our AI-driven friends (or enemies) to follow.

As I was designing both the racetrack and the AI, I had a fair bit of control over the entire process. For the AI implementation, I first skimmed my copy of Game AI Pro (I'd been gifted the harcover versions by my old professor!!), specifically the overview on Racing AI Architecture which gave me a good starting point for this project.

After some light reading and exploring a few common solutions, I settled on the following constraints:

2D Track Representation: simplifies math required while sufficient for my racetrack
Piecewise-Linear Racing Line: this gave good results, partly due to the way AI forces were being applied
Player-based Learning: I wanted to leverage a Player's 'run' data to find an optimal line
Simple Editor Tooling: my racetrack was still in progress and I needed to be able to make changes

Racetrack Representation

Here's what the track representation I ended up using looks like in practice. For simpilicity's sake, this only covers the primary path (so no shortcuts!) and also visualizes the optimal racing line generated from my personal runs.

Sectors are outlined in white, with the blue racing line overlaid.

</center>

Note that the physical (mesh) track and logical racetrack used by AI are separate but overlaid. This is to achieve maximum control without having to rely on complex face-tagging systems and also being independent of mesh density.

TrackNode

A TrackNode consists of a single 'node' of the track. It stores a width and the point of the 'racing line' on it.

public class TrackNode : MonoBehaviour
{
    public float width = 10;
    [Range(-1, 1)] public float racingLine;
    public TrackNode next;
    public TrackNode prev;
}

This component is assigned to GameObjects and their Transforms are used to represent the Track.

TrackNodes form a doubly-linked list and include utilities to calculate length recursively, and 2D point-in-Quad testing.

EDIT (2025-02-13): Linked Lists Galore

As I was editing this article to add support for an ordered sequence of articles (see links at the bottom of this page), I used a similar approach to represent this relation:
interface ArticleSchema {
    // ...
    prevArticle?: string; // slug of the previous article
    nextArticle?: string; // slug of the next article
}
Linked lists are really neat in this aspect, and they've saved me more than once in a pinch.

Calculate Track Length

I wanted to dynamically calculate track length so I had greater flexibility with shortcuts later, as well as to avoid accidentally using old, invalid data.

public void CalculateLength()
{
    // Start Node
    if (prev is null)
    {
        length = 0;
        return;
    }

    // Need to (re)calculate the length of previous nodes
    if (prev.length < 0)
    {
        prev.CalculateLength();
    }

    var toPrev = Vector3.Distance(GetRacingLinePoint(), prev.GetRacingLinePoint());
    length = prev.length + toPrev;
}

The member variable length was initialized to -1 and updated as necessary.

The performance-junkies among you may grumble, since this is obviously inferior to a linear approach and could exceed the maximum stack depth on sufficiently complicated tracks. As someone who also enjoys pushing hardware and tools to their limit, these are valid complaints.

For this prototype, however, I chose to use it regardless due to the ease of use, especially trivial track modifications and having shortcuts that 'just work'. Also, since the racing line could be player-defined, via tracking a 'run', this recursive approach gave me good results.

Sectors

A 'Sector' is defined as the area between the current TrackNode and the previous one. To track which sector an AI racer (or the Player) was in, I used a simple point in quad check.

For this simple approach to work, however, meant track sectors (the space between two consecutive TrackNodes) were limited to being convex. This was fine, as concave track sectors would provide subpar results for AI steering logic, anyway.

public bool SectorContains(Vector3 testPosition)
{
    // Get corner points (top left, top right, bottom left, bottom right) and test point in 2D
    ....

    // Calculate edge vectors
    var left = tl2D - bl2D;
    var right = tr2D - br2D;
    var top = tr2D - tl2D;
    var bottom = br2D - bl2D;

    // Bounds check using 2D 'Cross' (Wedge) product
    return left.Cross(test2D - bl2D) < 0
            && right.Cross(test2D - tr2D) > 0
            && top.Cross(test2D - tr2D) < 0
            && bottom.Cross(test2D - br2D) > 0;
}

Alternate Paths and Shortcuts

To implement 'fairer' AI behaviour, I used the simplest trick in the book -- a railroad-lever style shortcut. This is only activated when the Player has a sufficient lead, ensuring fairer-feeling gameplay. Since the AI was trained on player runs (mine, in particular), it was a fairly fearsome opponent.

Branched Track Node

A variant of TrackNode that holds both a 'normal' and 'alternate' next node. The next node can then be toggled on-demand.

public override bool TryGetNextNode(out TrackNode nextNode)
{
    if (!_useAlternate || alternate is null)
    {
        return base.TryGetNextNode(out nextNode);
    }

    nextNode = alternate;
    return true;
}

Other than some helpful gizmo overrides, it was fairly simple.

Probabilistic Track Node

I also wanted to support a 'failure' path, since the payoff from the shortcut was too good, this would make it a more high-risk situation.

This was simply a BranchedTrackNode with fuzzy logic. Uses a simple cutoff to decide whether to use the regular or alternate next node.

public override bool TryGetNextNode(out TrackNode nextNode)
{
    // When asked for the next node, pick either the 'regular' one or alternate, based on a set probability.
    SetUseAlternate(Random.value < alternateProbability);
    return base.TryGetNextNode(out nextNode);
}

Editor Tooling

A combination of vertex snapping and custom editor tooling made setting up this track relatively easy.

The Track Node Editor tool has the following:

Extend the track by holding E at the end node
Insert a node between two selected nodes by pressing I.

To make development easier, I bound this tool to the T key (if a TrackNode was selected).

Closing Thoughts

I enjoyed dipping my toes into racetrack-representation, and it serves as a possible precursor to my eventual Burnout 3: Takedown inspired spiritual successor. The decision to spend some time making a simple editor tool paid off, and it's something I plan to do a lot more of in the future.

As you can see, we have a fair bit to implement in order to actually have our AI drivers do more than do donuts. I plan to write a third (and final?) post to complete this series.

Until then,

Ciao.

References

G. Biasillo. “Representing a race track for AI.” In AI Game Programming Wisdom, edited by Steve Rabin
Simon Tomlinson and Nic Melder. "An Architecture Overview for AI in Racing Games." In Game AI Pro, edited by Steve Rabin

Alvin Philips' Blog

Using Yarn and Italian Music to Design a Racetrack

Overview

Brief

Challenges

Design Methodology

Research

Shortcut and Setting

Level Design Document (LDD)

Constructing the Racetrack (and Iteration)

Challenge 1: Player Controller and Camera

Challenge 2: Track Length

Challenge 3: Physics and Collisions

Challenge 4: First Hairpin Difficulty

Conclusion and Next Steps

BONUS (Desk Reveal!!)

Type-safe Templated Vector Math in C++

Overview

Why shouldn't I just use a library?

Constraints

EDIT (2026-01-23): Benchmarking Results

<center>Vector Math Benchmark Results (AVX2)</center>

Design

What do these (Vec2, Vec3, Vec2Int) all look like then???

Okay... So what's Vector<???, ???> like?

On constexpr

Basic Implementation

Helpers

Storage (a.k.a. I still want access via .x, .y, etc.)

What is VecData?

But that didn't help...?

What about defining all members specifically?

Constructors

Element-wise Accessors

Arithmetic Operations

Dot Product <3

Cross Product

M?? enable_if_t?? static_assert?? What's all this then?

2D Wedge Product

Length and Normalizing

Normalized Types

Measuring Length

LengthSquared()

Length()

Normalize, Finally

Practical Improvements

Gatekeeping Vectors

Secret Constructor

That's a lot of dot dot dots

typename... Args

sizeof...(Args)

(std::is_convertible_v<Args, T> && ...)

(std::is_floating_point_v<T> || (!std::is_floating_point_v<Args> && ...))

static_cast<T>(args)...

Well what's storage_type::Initializer really?

Constants

Converting, Truncating, Projecting, and Expanding

Converting Types

Truncating Vectors

Projecting Vectors

Expanding Vectors

Closing Remarks

Fin.

Stack-based Menu Systems

Overview

What's a Stack?

Why a Stack?

Why make a Menu System to begin with?

Implementation Overview

Menu

Initialization

Refresh

Showing and Hiding Menus

MenuManager

PersistentSingleton?

Showing a new Menu

Returning to a Previous Menu

Creating a Menu

Is that it?

Representing Racetracks with Sectors

Okay... So what's `Vector<???, ???>` like?

On `constexpr`

What is `VecData`?

`M`?? `enable_if_t`?? `static_assert`?? What's all this then?

`typename... Args`

`sizeof...(Args)`

`(std::is_convertible_v<Args, T> && ...)`

`(std::is_floating_point_v<T> || (!std::is_floating_point_v<Args> && ...))`

`static_cast<T>(args)...`

Well what's `storage_type::Initializer` really?