Building My Own Car Racing Simulator with DirectX 12

A Deep Dive into Custom Engines, Physics, and Tools

In the last time, I’ve been developing my own car racing simulator from scratch — using DirectX 12, a fully custom engine, and a suite of in-house terrain, physics, and rendering tools.

It’s been both an enormous challenge and one of the most rewarding experiences of my career as a game developer.

Why Build Everything Myself?

I could have started from Unreal or Unity, but I wanted complete control over every aspect of the pipeline — from low-level rendering and GPU synchronization to the way the physics interacts with the track surface.

DirectX 12’s explicit control over resources and command queues made it perfect for this type of project, even if it meant writing thousands of lines of boilerplate to get the first triangle on screen.

The goal wasn’t just to make a racing game, but to build the foundation of a simulation framework I can extend into other genres later — flight, off-road, open-world driving.

The Rendering Pipeline

The engine uses a fully deferred renderer built on DirectX 12, supporting:

HDR output with Rec.2020 + PQ (ST.2084) color encoding

ACES tone mapping

Physically based materials (PBR) with image-based lighting

Real-time reflections using screen-space tracing blended with planar probes

One of the biggest technical hurdles was managing GPU memory efficiently. DirectX 12’s manual resource state transitions forced me to write a custom resource tracker that validates barriers at runtime and optimizes state changes per frame.

For terrain and world data, I rely on my own Gaea-inspired terrain system, exporting 32-bit heightmaps and procedural masks that define materials like asphalt, gravel, and grass.

Physics and Vehicle Dynamics

The simulator uses a custom vehicle physics model, written in C++.

Each wheel simulates:

Suspension compression

Tire slip and grip

Brake and throttle torque

Dynamic friction against the terrain surface

The result feels raw and mechanical — the car doesn’t just slide; it communicates through weight transfer, grip loss, and body roll.

I also implemented aerodynamic drag and downforce.

Custom Tools and Workflow

To speed up development, I built several companion tools:

Terrain Editor: imports 32-bit heightmaps and blends masks directly from Gaea.

Material Graph Editor: node-based PBR material creation with live viewport updates.

Track Layout Tool: spline-based editor for track curves, banking, and elevation.

Each tool shares a unified data format with the game engine, allowing near-instant iteration between editing and testing — no import/export bottlenecks.

DirectX 12 Challenges

Working at such a low level is rewarding but brutal. Some of the biggest issues I faced:

Debugging GPU synchronization and fence deadlocks.

Managing descriptor heaps efficiently for thousands of draw calls.

Writing my shaders.

Handling HDR color calibration across displays.

Despite the complexity, DirectX 12 gave me predictability and raw power — the game now runs in 4K HDR, with volumetric lighting and motion blur enabled.

October 19, 2025

Building My Game from Scratch: The Journey of a Custom Engine

When most developers start a new project, they reach for Unity, Unreal, or Godot. These engines are powerful, well-supported, and time-tested. So why would anyone decide to go down the long, winding road of writing their own engine?

For me, it wasn’t about reinventing the wheel—it was about understanding how the wheel works, and then shaping it exactly to fit the kind of game I wanted to build.

Why a Custom Engine?

The short answer: control.

I wanted the freedom to experiment with rendering techniques, terrain generation, and simulation systems without having to fight against a pre-existing framework.

Commercial engines give you speed, but they also come with assumptions baked in—assumptions that don’t always line up with unusual game ideas.

By building my own engine, I could:

Design the rendering pipeline specifically for HDR and physically based lighting.

Experiment with custom terrain systems (like heightmap streaming and erosion-based generation).

Write my own multithreaded job system tuned for the workloads my game needs.

Sure, it’s slower at first, but the creative possibilities open up over time.

The First Milestone: Rendering Something

The first time I got my terrain on screen in DirectX 9, it felt like magic. That terrain eventually turned into:

A robust swapchain that supports HDR10 (Rec.2020 PQ).

A deferred renderer with physically based shading.

A custom post-processing pipeline with ACES tonemapping.

The entire code and shaders are written now in DirectX 12.

Every new effect—from bloom to atmospheric scattering—wasn’t just about “adding a feature.” It was about learning how modern graphics work under the hood.

Tools and Pipelines

Game engines aren’t just about graphics. They’re about content pipelines.

I built importers for:

Models.

Heightmaps for terrain (from tools like Gaea and World Creator).

Textures with automatic mipmap + compression.

The asset system is still basic, but it’s mine. I know exactly how it loads, caches, and streams data, which makes debugging so much easier.

The Challenges

Let’s be real: building a custom engine is hard.

Time cost: Every feature takes longer. There’s no marketplace of ready-made shaders.

Debugging: Sometimes the engine breaks in ways I never imagined—because I’m the one who wrote the rules.

Temptation to over-engineer: It’s easy to get lost optimizing the engine instead of making the actual game.

But the flip side is that each hurdle teaches me something I never would’ve learned if I’d stayed inside Unity or Unreal.

Where the Game Stands Now

Right now, the game itself is a mix of prototype and playable experiment. It’s got:

Streaming terrain with ocean, lakes and rivers carved procedurally.

A working day-night cycle with physically-based sky rendering.

Basic gameplay systems layered on top of the tech.

It’s not polished yet, but it feels alive—because it grew from the ground up.

Lessons Learned

If you’re considering writing your own engine, here’s my advice:

Start small. Get a window open, get a triangle drawn. Build layer by layer.

Focus on your game. An engine is only a tool; don’t lose sight of why you’re building it.

Embrace the slow grind. Progress feels slower than using Unity—but every milestone is yours.

Final Thoughts

Creating a custom engine is a strange mix of masochism and passion. It’s not the fastest way to make a game, but it’s the most rewarding if you want to deeply understand what’s happening under the hood.

My project is still evolving, and I don’t know exactly where it’ll end up—but that’s part of the fun.

After all, it’s not just about making a game. It’s about building the world, the rules, and the tools with your own hands.

September 20, 2025

Most of my focus during the last month has been on terrain generation.

I experimented with new heightmap workflows, such as exporting in 32-bit precision to keep maximum detail.

This let me generate smoother mountain ridges and more natural valleys.

I also worked on a river detection pass using flow maps — the next step is smoothing out riverbeds automatically inside the level editor.

Engine Improvements

On the technical side, I’ve been adding new DirectX 12 compute shaders and improved the existing shaders.

Tools & Pipeline

I integrated OpenCV for contour detection inside heightmaps, which makes it easier to extract geometry for lakes.

August 18, 2025

It’s time for another development update.

Meantime, I tweaked the environment design (including biomes), lighting and atmosphere.

Also, code refactoring was done (also for shaders), in order to improve the visual quality and game stability.

More to follow in the next period.

July 16, 2025