Building a car racing game with the Untold Engine - Part II

I've been building a video game with the Untold Engine, a game engine I developed. I wanted to create a racing car video game for my kids. I figured that it would make them happy. You can read part I here.

I showed the current state of the game to my kids. To my surprise, they didn't like the direction of the game.

 
 

I was wrong in assuming they would like a cartoonish type of video game. I asked my son what he didn't like, and he replied that he wanted the car to be more real and to look like an F1 car. I was a bit "hurt" (lol) and also surprised. I guess they have better taste than I do.

So, we went to cgtrader.com and found a car they loved. Here the F1 car he chose. The video below shows the F1 car in a PBR renderer a made a while back.

 
 

Now that I knew what my kids wanted, I tried to render the car in the Untold Engine, and it failed to load. The reason is that the engine associates one entity id to one mesh. The model had several meshes. So, I modified the engine to handle one-to-many relationships, i.e. one entity can have many meshes. After doing so, the Untold Engine was able to render the F1 car.

 
 

What I did next was to buy a race-track asset for the game. I added control points (path) to help my kids drive the car; I call it "AI Assist" lol.

 
 

However, once I hit play, I realized several things were missing in the engine:

  • The wheels are not rotating.
  • The car's steering sucks.
 
 

Ideally, we want the car to be the parent entity and the wheels and the steering to be child entities. By doing so, the wheels can rotate independently as the car drives. However, the engine does not have a concept of "Transform Hierarchies". I need to figure out how to do so in an ECS architecture.

If you have any ideas, let me know.

Thanks for reading.

Building a City Driving Game with the Untold Engine - Part I

As stated in my previous post, my goal is to improve the robustness of the Untold Engine by focusing on developing various games.

I was thinking of a game to make, and I thought about how much my kids love car games. So, I decided to develop one.

I went to BlenderMarket to check out any car assets I could use, and I found a nice City asset.

 
 

My idea is for the car to drive around the city. Since this game is mainly for my kids, I figured that it would be a good idea to add some AI assistance for them. By AI assist, I simply mean a path the car will follow throughout the game. That way, my kids do not have to worry about driving, and just enjoy the game as the car speeds throughout the city.

So, I opened up Blender and added control points representing the path. I then wrote a simple script to export the control points into an array that the Untold Engine can use as waypoints.

 
 

Since the Untold Engine has a Steering System in place, it didn’t take long to hook up the car object and make it follow a path; it took only one function call.

I wanted a camera to follow the car. This was also simple to do. The Untold Engine has a function that allows for a camera to follow a model at a determined offset.

In no time, the car was driving around the city following a determined path.

 
 

So, now is time to make the game entertaining. I’m thinking of adding power-ups throughout the city which will make the car go faster. Such mechanics would be perfect for testing the collision system, which I have yet to develop. I also want the game to be played on the Apple TV. However, for this to happen, I need to make the game educational so that my wife approves of it. lol.

So, what issues did find?

Even though the setup took a few minutes, I saw problems right away. For example,

  1. the engine does not have any culling mechanism.
  2. Loading times were too long and
  3. Z-fighting was apparent.

Stay tuned for part-II

Rebuilding the Untold Engine: Two Years of Progress and What’s Next

Hey everyone,

It has been two years since I began rewriting my game engine, and while development has been slow, it has been steady. In this post, I want to share the current status of the Untold Engine.

What is the Untold Engine?

For those who are unaware, the Untold Engine is a 3D game engine designed for macOS and iOS devices, which I started developing in 2013. The original version was built using C++ and Metal, following an object-oriented approach.

What has changed?

Fast forward to today, and the Untold Engine has transitioned to an Entity-Component-System (ECS) architecture, with its primary languages now being Swift and Metal. The engine includes the following systems:

  • Rendering System
  • Physics System
  • Steering System
  • Animation System
  • Collision System (coming soon)
  • PBR (Physically-Based Rendering) support
 
 

Although the rewrite is not yet complete, the Untold Engine has reached a stage where you can create simple games. One significant improvement in the new Untold Engine is its documentation. I have made it a priority to keep the GitHub Readme thoroughly documented and up-to-date.

What’s next?

Development of the engine will continue, but my main focus will be on creating simple games and tutorials to help developers get acquainted with the Untold Engine. One of the reasons the first version of the engine had so many bugs was due to insufficient testing with actual games. This time around, that won't be an issue.

Where can I get the Untold Engine?

The Untold Engine is open-source and you can get it from our Githup repo:

https://github.com/untoldengine/UntoldEngine

Thank you for reading!

Nearing the Finish Line: Rewriting the Untold Engine

I’ve been knee-deep in rewriting the Untold Engine, transitioning it from C++ to Swift. After months of coding, tweaking, and testing, I’m thrilled to share that the rewrite is almost done. Moving to Swift has been a game-changer, making the engine not only faster and more modern but much easier to work with.


Built on ECS Architecture

The Untold Engine is powered by Entity-Component-System (ECS) architecture. This design keeps the engine modular and scalable, separating the game logic into three straightforward parts:

Entities: These are the game objects (think players, cars, obstacles). Components: The data attached to entities, like meshes, physics, or animations. Systems: These handle the logic, such as rendering, animations, or physics calculations. This modular approach keeps everything clean and efficient, allowing developers to focus on their game logic instead of wrestling with tangled code.


Simplicity is Key: The API

When I started this rewrite, one of my biggest goals was to make the API as easy as possible to use. I’ve always believed that developers shouldn’t have to fight with the tools—they should just work.

With the new API, everything is intuitive and consistent. If you can remember createEntity() and setEntityMesh(), you can pretty much guess how the rest of the API works.

Here’s how you might set up a playable character:

// Step 1: Create the entity
let player = createEntity()

// Step 2: Add a mesh for the player
setEntityMesh(entityId: player, filename: "playerModel", withExtension: "usdc")

// Step 3: Enable physics for movement and gravity
setEntityKinetics(entityId: player)

// Step 4: Add collision detection
setEntityCollision(entityId: player)

// Step 5: Add animations for walking and running
setEntityAnimations(entityId: player, filename: "walkAnimation", withExtension: "usdc", name: "walking")
setEntityAnimations(entityId: player, filename: "runAnimation", withExtension: "usdc", name: "running")

The API is intentionally predictable. Want to add physics? setEntityKinetics(). Want collision? setEntityCollision(). It’s all designed to make game development as smooth as possible.


One Last Piece: The Collision System

With almost every system in place, I’m now working on the Collision System—the last big piece of this rewrite. This system will handle detecting interactions between entities, like when a player hits an obstacle or collides with another object.

Once the Collision System is complete, the engine will have everything it needs to handle realistic interactions, complementing the existing Physics System seamlessly.


What’s Next?

After wrapping up the Collision System, my focus will shift to finalizing the documentation and writing tutorials. I want to ensure that anyone—even those new to game development—can pick up the Untold Engine and start creating right away.

Rewriting this engine has been a long, challenging process, but it’s been worth every line of code. Moving to Swift has made the engine simpler, faster, and a joy to work with. I can’t wait to see what developers will create with it.

Stay tuned—big things are coming!

Check out the Untold Engine

Thanks for reading

Making my PBR Renderer more user-friendly - Part II

Last week, I wrote an article about making my renderer more user-friendly. If you haven't had a chance to read any of my previous two articles, here are some videos to catch you up.

 
 

This week, I decided to work on the Lights User-Interface. I was unhappy with how the lights were added or manipulated in the scene, so I worked on them this week.

One of the first things I did was to make the Lights an ECS component. I also implemented a Light System that manages different types of lights, such as Directional, Points, Spot, and Area Lights.

I then removed the previous Light UI implementation and started all over again. I added a drop-down menu that allows the user to add a particular light type, such as Directional and Point Lights.

For Directional Light, I added visual feedback so the user can determine the direction of the light. I also allow the user to set the light's intensity through a slider.

For Point Light, I allow the user to set its intensity radius. And of course, you can manipulate the transformations and rotation through sliders.

So, here is what I have as of now:

 
 

So, what's next?

As you noticed in the video above, the point lights are not casting any shadows. Some bugs need fixing. I'm also wondering if I should add a Gizmo for translation/rotation. But my main objective is to add Ray-Tracing to the renderer. That is where I'm heading. For the time being, I want to focus on setting up a user-friendly UI. So, be ready for a part III.