After two years, I went back to CppCon this week to give a talk about game engines and my little summer experiment with Soup Raiders (blog series here). But CppCon is more than just talks!

I landed in Denver on Saturday evening after a stopover at Washington Dulles. I woke up at 4am on Sunday and had some time to work on my slides before heading out for the field trip to Red Rocks:

It was really hot, but everybody was still smiling. This field trip is a nice opportunity to meet new people in a small group. I tend to feel uncomfortable when I am suddenly in the presence of a lot of people that I don’t know at all, but we speak the same (programming) language. We then went to see some dinosaur footprints nearby:

We had to hike up a hill to see them, and with the heat, I used my Korean Daiso umbrella to keep the sun off. Conversation topics ranged from the upcoming talks to AI, programming, skiing, and our current jobs. We then went back to the hotel to join the registration reception:

After getting all my swag, I did not stay too long, because the jet lag was hitting hard. Anyway, time for the talks.

On Monday, I went to:

• Are you smarter than a branch predictor by Michelle D’Souza: I will be teaching my students about branch prediction in the coming weeks, so getting a refresher and learning new things was nice.
• The journey to “/W4 /WX”: How hard could it be? by Keith Stockdale: A very interesting talk with lots of short code reviews to showcase all the little bugs and instances of undefined behavior that can creep into a codebase without treating warnings as errors.

• Zero Cost Scripting Languages for Game Engines With C++26 Static Reflection by Koen Samyn: I did not know much about AngelScript, but compiling its bytecode by combining #embed and static reflection was fascinating and gave me ideas.

On Tuesday, with my talk in the afternoon, I missed the Language Designers Panel in the morning. I was still adjusting the slides before the talk. Finally, it was time. This was the room I gave the talk in:

My slides included a few interactive web demos. Fortunately, there was a screen below the stage showing what the attendees were seeing, which let me interact with the demos.

After my talk, I went to Jody Haggins’ talk: C++ in an AI World, but I was still feeling the adrenaline from my own talk, so I will need to rewatch it.

Then I needed to relax and missed a few talks that I really wanted to see (especially Ensuring Code Quality in the Age of AI : More Code, Less Engineering! by Peter Muldoon).

On Wednesday, I went to these talks:

• Awaiters and Awaitables by Mateusz Pusz: Since the networking proposal involves coroutines and my colleague had been experimenting with it, I took the opportunity to learn more about coroutines in Mateusz’s talk. He managed to make a seemingly inaccessible topic accessible.
• How C++26 changes the way we write code by Timur Doumler: The big four: Reflection, Contracts, Execution and SIMD. As a teacher, I will need to play a bit more with std::execution before being convinced. The recording is here.
• Rule of 0,1,2,5,6,7,8,9,10? by Jason Turner: There is always something new to learn from Jason’s talks and this one was no exception. A nice refresher on constructors, destructors, assignment, and some operators.
• Graphics Programming with SDL 3 Part 2 by Mike Shah: I discovered that we can play with shaders in SDL3’s 2D renderer. While my class usually covers graphics programming at a lower level, this could make a nice introduction or first exercise in computer graphics. And Mike Shah is a machine, giving three talks at CppCon this year.
• Lightning Talks: One hour of five-minute talks on various subjects related to C++. Two years ago, I was too tired to follow them, but this year, I was happy to be there. It’s also an opportunity for new speakers to try out material or just to gain speaking experience. I considered giving a lightning talk this year, and I regret not submitting one.

On Thursday, I attended these talks and events:

• The Address is Not The Place: Object Residency in C++26 by Laurie Kirk: Her talk was about breaking this wall that we have with memory. While I could not follow everything, I found it very interesting, especially from a teacher’s point of view who is going to explain how the memory work very soon. The recording is already online for me to rewatch here.
• Meet Guy Davidson: It was an interview with Sherry Sontag where we looked back at Guy’s background and his motivation for serving the community as a convenor. There was an old photo of him with long hair and no beard that I will not put here.
• Meet the Presenters Banquet: After meeting Guy, I got my speaker portrait taken by Jonathan Phillips. Here is what I will look like in my CppCon 2026 thumbnail:

Then I got to meet Guy Davidson again:

And we enjoyed a good dinner in good company, talking about C++ and our different jobs around the table:

• Lightning Talks: Part 2, and I managed to attend again (with some help from caffeine). There is a special energy during the lightning talks. The session lasted until 10:30pm, so with my jet lag, I was exhausted by the end. I’m looking forward to watching them again when they are available in the CppCon archive.

On Friday, I went to these talks:

• Safety in Numbers by Jason Turner: Another talk by Jason Turner, where we reviewed operations on integers smaller than 32 bits, overflow, and all the nice features added to modern C++ to deal with those cases.
• Refactoring C++: Techniques, Smells, and Discussion by Dave Steffen: I really enjoyed the Back to Basics: Testing talk that Dave gave 2 years ago. This was an Open Content session, so it was intentionally incomplete. The discussion of code smells with the audience was interesting, and I’m looking forward to the final talk/book.
• Code You Didn’t Write: Understanding Large and Unfamiliar Codebases by Mike Shah and Chris Croft-White: I approached this talk from the perspective of my students and of a newcomer to an unfamiliar codebase. Now with a lot of projects being vibe-coded, it’s even more daunting to get started on a massive new project. There were some good examples of how to use LLMs effectively in certain situations.
• In Pursuit of a 6,000 FPS Game Boy Emulator by Tom Tesch:

It was the last talk I could attend. This talk was the end of the Tetris Game Boy trilogy. As a fellow teacher, I really relate to the freedom to work on projects we want to make if we can use them in our courses, and to this slide in particular:

The Game Boy was my first console and I had always wanted to go back to it when working in gamedev. I did so a few years ago with Soup Raiders: Jailbreak. But Tom ventured into emulator territory. Quoting him: “To really know something, make an emulator out of it.” A very entertaining talk!

Then it was time to go to the airport to catch my flight. I headed home with my head full of ideas, ready for the future, and keeping in mind that C++ is an expert language.

A port is not simply “the same game in another engine” or “just an emulator”. It is a long series of decisions about what to do with the original content (art, code and audio) to create a new version with its own set of constraints. In this blog post, I will look at three different approaches to porting, then show what I exported from my old Unity demo and how. The next blog post will cover how I imported those assets into my own game engine.

Porting games

You might have heard terms such as remaster, remake or even recompilation. Their meanings can be confusing, and there are nearly as many approaches to porting as there are game ports. Here are three concrete examples and how I personally classify them.

Demon’s Souls PS5 (2020)

For the release of the PS5, Bluepoint Games, with Japan Studio, remade FromSoftware’s PS3 game Demon’s Souls. There is a very good /noclip documentary¹ on the subject, featuring interviews with the team behind the game. In a Digital Foundry interview², the developers at Bluepoint described the port as using two engines. Based on their explanation, I understand the architecture roughly as follows:

This allows the PS5 game to look radically different while its combat feels extraordinarily close to that of the PS3 game. Visually, an enormous amount was rebuilt. On the technical side, Marco Thrush, Bluepoint’s president and an engineer, described starting by compiling the codebase one error at a time, then running the game and fixing one crash at a time. The team did not simply recompile the old code: they also introduced modernised character creation, a photo mode, the mirrored Fractured World, quality-of-life adjustments, much faster loading, updated controls and other changes. Given the amount of work involved, I would classify Demon’s Souls on PS5 as a remake.

Metal Wolf Chaos XD

Metal Wolf Chaos is a hilarious game by FromSoftware, released for the original Xbox only in Japan in December 2004. The player takes the role of the president of the United States, piloting a mech. You can watch a speedrun from SGDQ 2014³, with commentary explaining the gameplay. Funnily enough, Devolver unexpectedly offered to work with FromSoftware to rerelease the game:

Count us in to help Metal Wolf Chaos get out to more gamers if From Software wants some help. #FreeMetalWolf pic.twitter.com/867qay70j8

— Devolver Digital (@devolverdigital) January 27, 2016

And it actually worked!⁴ A General Arcade team consisting of five software engineers, two QA engineers, a producer, an artist and two 3D modellers spent sixteen months on the project, according to its project page⁵. They used a modified version of Sony’s PhyreEngine, C++ and FMOD, with Direct3D 11 on Xbox One and GNM on PlayStation 4.

Because General Arcade describes the project as a modernisation of the original game—upgrading its presentation, controls and platform support rather than rebuilding it as a new game—I would classify Metal Wolf Chaos XD as a remaster, not a remake.

Dusklight

I got a GameCube at the end of its life (you can call me a patient gamer), and one of my favourite games on it—and in general—is The Legend of Zelda: Twilight Princess. Fast-forward a few years and I discovered that the community had created a native version of the game. It was released under the name Dusk in May 2026 and is now called Dusklight⁶.

For Dusklight to exist, another project first had to decompile the original Twilight Princess. This project is ZeldaRET/tp⁷. Its goal is not merely to write code that behaves similarly, but to produce C/C++ code that compiles to the same machine instructions as the original executable.

To reverse-engineer the PowerPC executable, they used decomp-toolkit (or dtk)⁸. This tool analyses the original GameCube/Wii executable, discovers functions, splits the binary into relocatable objects and generates linker information, symbols and splits. This provides the pieces of the “puzzle” that contributors need to recreate the game. For each piece—a compiled .o file—they recreate the C/C++ equivalent, then compile it using the Metrowerks CodeWarrior compilers and linkers used by Nintendo at the time. They compare the newly generated PowerPC .o with the original using objdiff⁹, then repeat the process until the two match.

ZeldaRET is not itself a PC port, but Dusklight builds upon its work. Dusklight uses Aurora¹⁰, a source-level GameCube and Wii compatibility layer, to link the game-derived code, including Nintendo’s JSystem code. This greatly simplifies the recompilation work because the developers do not need to refactor every call to the original GameCube APIs. Aurora uses SDL3 for its application layer and input, while its GX graphics compatibility layer is built on WebGPU. I also use SDL3 in the Soup Raiders native port. In the end, the architecture of Dusklight looks like this:

Because it turns matching decompiled source code into a native application for modern platforms, I would classify Dusklight as a recompilation.

And Soup Raiders?

I started working on Soup Raiders with Unity 2017.4.1f1 in July 2018. I remember it well because we were developing a demo to submit to Pro Helvetia (the Swiss Arts Council) in the hope of securing funding to begin production. At the time, the game looked like this:

And I looked like this:

After cancelling the project in mid-2019, I restarted it in March 2020, just as the COVID pandemic hit Europe. A new prototype began to take shape and looked like this:

The latest vertical slice, which is playable on itch.io, ran on Unity 2022.3.2f1 and featured three levels with three fights, one mini-boss and one boss. This is the view from the beginning of the demo, in the docks of the Red Island:

Many things need to be migrated to my custom engine to reproduce this view, and each component of the demo has its own requirements. Let’s explore the different parts of this porting process. This blog post covers what I export from Unity; the next will cover how I import it into my game engine.

The audio

This is the easiest part of the game to port. In Unity, I used FMOD, middleware that allows a sound designer to add events in the FMOD editor and generate banks for the game to import.

Fortunately, FMOD is not limited to Unity and provides native libraries for PC and Nintendo Switch, as well as other modern platforms such as PS4, PS5 and even HTML5. Porting the audio therefore meant copying the banks and statically linking the libraries provided by FMOD.

3D models

Julie Baechtold did incredible work on Soup Raiders. She created the 3D models in Blender, then placed them in Unity to create the levels. As she was not familiar with git, I created a tool that exported her Unity scene and all its dependencies so that I could import them into my Unity project.

There are several ways to export those models and the layout that Julie created in Unity:

1. Use Unity’s FBX Exporter package.
2. Use Blender as the asset source (exported as .glb) and Unity for level composition.
3. Parse the .unity YAML file in my engine.
4. Build a custom Unity scene exporter that generates glTF 2.0 .glb files.

I went with solution 4. The Unity Editor script ExportLevelGeometry.cs generates a GLB file for the entire level. A GLB file contains two main parts:

• A JSON part describing the glTF asset, scenes, nodes, meshes, accessors, buffers and buffer views.
• A binary part containing the mesh positions, UV coordinates and indices.

Meanwhile, another script, ExportLevelRenderers.cs, exports the materials linked to the renderers—in short, their visibility, textures and related data. These are exported to a simple .json file that references each texture that must also be exported. I use Unity’s GlobalObjectId to match each renderer across the two exports. This allows me to export all the static meshes, including static sprites:

The renderers JSON looks like this:

{
  "version": 6,
  "coordinateSpace": "native_render_x_flipped_from_unity",
  "renderers": [
    {
      "name": "LevelDocks/DOCKS-DETAILS/barrel",
      "id": "GlobalObjectId_V1-2-88d0b98e1cbd76d418edf891b923eadb-
          16941762359777390037-2086583302",
      "type": "MeshRenderer",
      "active": true,
      "position": [-46.179996490478519, -10.490001678466797, -112.6961898803711],
      "center": [-46.16727066040039, -10.471028327941895, -112.69300842285156],
      "materials": [
        {
          "name": "barrel",
          "guid": "bd4b0fa6863613a48b2d6fc9d4a12681",
          "assetPath": "Assets/Materials/Red Island/Props/barrel.mat",
          "mainTexture": "Assets/Textures/Red Island/Docks/barrel.jpg",
          "renderType": "Opaque",
          "shader": "Custom/Toon Shading",
          "alphaCutoff": 0.5,
          "textureScale": [1.0, 1.0],
          "textureOffset": [0.0, 0.0],
          "outlineColor": [0.22745098173618318, 0.10588235408067703, 
              0.06666667014360428, 0.5],
          "outlineWidth": 0.019999999552965165,
          "outlineAngle": 89.0
        }
      ],
      "articulated": "",
      "lookAtCamera": ""
    }
  ]
}

A little note on native_render_x_flipped_from_unity, it just means that positions go (x,y,z) → (-x,y,z) and Euler angles (x,y,z) → (x,-y,-z). I will talk about outlines in a following blog post on the renderer.

However, the brownish water of the Soup is missing! This mesh is a little unusual. It was not created in Blender, but directly in Unity, and uses a specific ToonWater shader rather than a more standard shader like the rest of the static level. It is actually just four quads. Its geometry is also exported by ExportLevelGeometry.cs, because I want to preserve the Unity geometry, but it goes through ExportDocksWater() to generate water_geometry.glb and water_instances.json. Here it is:

Without water With water ↔

Colliders

Visuals are nice, but my main character needs something to walk on. In the Unity demo, I spent a lot of time adjusting each level’s physics shapes to ensure that the main character did not fall through the ground or get stuck in a wall or on the stairs. To reproduce this behaviour in my engine, I also needed to export the colliders. The ExportLevelCoilliders.cs script exports the following shapes:

• Box colliders: emitted as hulls (eight world-space corners).
• Convex mesh colliders: hulls (world-space vertices).
• Non-convex mesh colliders: meshes (vertices and triangles).
• Sphere colliders.
• Capsule colliders.

In addition to the collider geometry, I add the surface type from the GameObject tag: Wood becomes 1, Stairs becomes 2, and so on. The main character’s footsteps differ depending on whether they step on wood or stone. The exporter also excludes specific objects such as moving characters: Dorothy has a collider, but it is not static. In the end, the exported colliders look like this:

Here is how the collider JSON looks like:

{
  "version": 3,
  "coordinateSpace": "native_render_x_flipped_from_unity",
  "shapes": [
    {
      "type": "hull",
      "materialIndex": 1,
      "points": [
        31.5793, 7.09921, 6.9241,
        31.5299, 9.76265, 2.54655,
        37.85232, 7.13064, 6.87243,
        37.80292, 9.79409, 2.49488,
        31.5793, 7.43721, 7.12975,
        31.5299, 10.10066, 2.7522,
        37.85232, 7.46865, 7.07808,
        37.80292, 10.13209, 2.70054
      ]
    }
  ]
}

• typeis one of the box3d shapes that matches the Unity collider

Billboards

Much of Soup Raiders’ charm comes from its animated 2D characters. The main characters were animated by Camille Bovey, while Julie added many seagulls to the levels. They behave like billboards, always facing the camera. The textures were already available for export, but, as with the level’s meshes, I also needed to export the placement of the billboards. This is the job of ExportLevelBillboards.cs, which exports their world position, lossy world scale, flipX value, texture, pixel rectangle, pivot in pixels (where the character’s feet are) and pixels per unit. It also exports the single-frame talk icons used by talkative characters. This is what the billboard JSON looks like in the end:

{
  "version": 2,
  "coordinateSpace": "native_render_x_flipped_from_unity",
  "billboards": [
    {
      "name": "Seagull Talk (1)",
      "position": [-10.2153, 6.30011, -41.96577],
      "parentName": "StaticCharacter_Seagull_05 (5)",
      "parentPosition": [-11.19866, 2.86357, -45.25861],
      "parentOffset": [0, 4.86, 0],
      "scale": [0.3, 0.3],
      "flipX": false,
      "texture": "Assets/Sprites/UI/Level/talk.PNG",
      "rect": [0, 0, 512, 512],
      "pivotPx": [256, 256],
      "pixelsPerUnit": 100
    }
  ]
}

Two characters are missing:

• The player-controlled character.
• Dorothy, who moves during cinematics.

With them, the world is more crowded:

The final detail in this section is animation. Because my Animator clips simply switched sprites at specific frames, their animations were straightforward to export by reading the Unity YAML. Here is what an animation looks like in YAML:

--- !u!74 &7400000
AnimationClip:
  m_Name: WalkSide
  m_SampleRate: 12
  m_PPtrCurves:
  - curve:
    - time: 0
      value: {fileID: 21300000, guid: 3f2a..., type: 3}
    - time: 0.0833333
      value: {fileID: 21300000, guid: 9c41..., type: 3}
    attribute: sprite
    path:
  m_Events:
  - time: 0.25
    functionName: ManageAnimEvent
    intParameter: 1
  m_AnimationClipSettings:
    m_StopTime: 0.5
    m_LoopTime: 1

Although m_PPtrCurves looks like a barbaric name, it contains the times at which the animation changes from one image to another.

Skybox

As the skybox already consists of six textures, it does not need a Unity-side export. I will cover its import into my engine in more detail in the next blog post. Of course, the level looks better with it:

Without skybox With skybox ↔

Snap rails

In Soup Raiders, players do not control the camera. Instead of using Cinemachine—I tend not to use every Unity tool when I can implement something myself—I created a system that interpolates between snap points. Each point stores the camera position and direction, as well as the character position. It also stores the character’s Euler angles, but I do not export them. This allows the camera to move around while following the player. The snap points are exported as-is to a .json file that looks like this:

{
  "version": 1,
  "coordinateSpace": "native_render_x_flipped_from_unity",
  "snapshots": [
    {
      "cameraPos": [-52.23652, -2.154821, -132.7845],
      "cameraAngles": [35.454903, 2.0682678, 0.00016311444],
      "characterPos": [-51.905075, -8.694596, -117.0]
    },
    {
      "cameraPos": [-82.17407, -3.3850465, -141.92406],
      "cameraAngles": [9.106377, 58.706604, 0.0001880661],
      "characterPos": [-51.903656, -9.063084, -123.52415]
    }
  ],
  "transitions": [
    {
      "a": 0,
      "b": 36,
      "radius": 5.0
    }
  ]
}

I had a Play Mode snapshot-recording system that let me move through the level with a free-orbit camera, find a good viewpoint and save the snapshot. The snap system would then connect the nearest points when an unobstructed raycast existed between them. This is what it looks like in Unity, with red spheres representing the snap points and red lines representing the connections between them:

Source code

The Unity demo contains 174 C# files with 18,421 lines of code. While not enormous, it is still a substantial body of code to migrate to C++. One example of a C#-to-C++ migration is the PS Vita port of Bastion:

Bastion was built with XNA, .NET and C#. After porting FEZ to PlayStation platforms, BlitWorks began work on the PS4 and PS Vita versions of Bastion. For the Vita version, the team first tried running the game on its ports of Mono and MonoGame. The beginning of the first level ran at around 30 FPS, with additional stalls caused by Mono’s SGen garbage collector. BlitWorks then created Unsharper, a tool that converts C# features directly into C++ and replaces garbage collection with reference counting. Although it addresses the same broad problem as Unity’s IL2CPP, Unsharper does not rely on .NET intermediate language and generates C++ that resembles the original C# code.¹¹

Another option would be to use Native AOT for the C# behaviour while implementing the core engine in C++. Noel Berry discusses the portability of Native AOT in Making Video Games in 2025 (Without an Engine)¹². In the end, because my C# code was closely tied to Unity’s GameObject and MonoBehaviour model, I decided to migrate all of it manually to a more ECS-like C++ architecture. This also provided a good opportunity to refactor it.

Another consideration is the shader source code. Unity already has its own renderer and pipeline, so much of the shader code is provided by the engine. This is not the case for my game engine, which uses a custom renderer with GLSL. I will discuss its features and specifics in another blog post. Fortunately, Unity’s Built-in Render Pipeline shaders can be found online¹³. Unity uses Cg/HLSL-style shader code, derived from NVIDIA Cg¹⁴, a shader language designed to target both OpenGL and Direct3D. NVIDIA discontinued its development in April 2012.

My renderer instead uses GLSL, which I cross-compile to SPIR-V, HLSL, MSL and WGSL using tools from the Vulkan SDK. It might make sense to switch to Slang¹⁵ in the near future, as a modern successor to NVIDIA Cg.

Dialogue

The dialogue system went through several iterations during the production of the demo. I started with Ink from inkle. The file format looks like this:

That's a painting of Rene Descarps, one of the most famous Philosofishes. #WF
I'm already bored… #BW
"I sink, therefore I am." What an enlightened soul! #WF
Nobody cares... #BW
Actually, now I want to eat some fish! #KR
Well, that's the problem with this world: 
    people are more guided by their stomach, than their mind! #WF
->END

I used hashtags to identify the speaking character (#BW for Black Whiskers, #WF for White Fur and #KR for Krokoss). I hired one of my students, Nicolas Schneider, as an intern to create a tool that integrated Ink into our dialogue scene. He now works at Old Skull Games. The internal tool turned each line into an asset containing additional information, such as the characters’ emotions and placement.

However, as production advanced, the intern’s tool became obsolete. I eventually took matters into my own hands and switched to Yarn Spinner, which is closer to writing dialogue as a program, with conditions and other logic. Its file format looks like this:

title: DocksPhilosophiesLore
---
WhiteFur: That's a painting of Rene Descarps,
    one of the most famous Philosofishes. #line:0063522
BlackWhiskers: I'm already bored...  #line:0b2d361
WhiteFur: "I sink, therefore I am." What an enlightened soul! #line:02a3da8
BlackWhiskers: Nobody cares... #line:0b46948
Krokoss: Actually, now I want to eat some fish! #line:01e0687
WhiteFur: Well, that's the problem with this world:
    people are more guided by their stomach, than their mind! #line:068f343
===

One major advantage is the line ID at the end of each line; this time, I also used each character’s full name to identify the speaker. Another advantage is the ability to put multiple dialogues in one file, whereas I had used a separate Ink file for each dialogue. Exporting all the .yarn scripts—the dialogue files—is straightforward, but Yarn Spinner normally runs them through its C# runtime. In the end, I wrote a simple interpreter for my use case.

Others

I have not covered the ground-battle migration in this blog post. It is a part of the game that relies heavily on 2D animation, with a UI layout that also needs to be exported. For animation, I can use the same technique as before and import the m_PPtrCurves from every animation clip used by the Animator. This allows me to identify all the textures needed to play those animations.

The title screen is fairly simple. Its UI layout is exported as JSON and the rest consists of images. However, it contains a large soup-boat animation made from 105 PNGs, which requires some processing by my engine’s asset compiler. That is a subject for the next blog post.

Conclusion

Porting a game may not be as difficult as starting again from scratch. When restarting a project, it can be tempting to delete everything and import every asset again by hand. I tried something different: because I may still use Unity as an editor, I made deliberate choices about how to export the assets I needed. This demo is substantial enough for the port to be non-trivial, but it is not a AAA game or a game whose executable must be reverse-engineered from another console architecture.

Now that I have all these assets, the next step is the asset compiler, which determines how the exported assets are imported into my game engine.

References

According to VGInsights, about 13% of games released on Steam in 2024 used a custom engine, down from 71% in 2012¹. So looking at this trend, why should anybody try to make their own game engine?

But…

Those games still accounted for 43% of units sold in 2024¹. Even if most were AAA games built with custom engines, the figure shows that developing your own engine can still make business sense. So this blog post is about why you should make a game engine.

However, before answering this question, we need to define what a game engine is. The term is broad enough that Claude Code has even been compared to a small game engine²:

Most people's mental model of Claude Code is that "it's just a TUI" but it should really be closer to "a small game engine".

For each frame our pipeline constructs a scene graph with React then
-> layouts elements
-> rasterizes them to a 2d screen
-> diffs that against the…

— Thariq (@trq212) January 21, 2026

What’s a game engine and what do we mean by custom?

A game engine is a reusable software framework that lets you create and run a computer game. It sits between the actual game code (gameplay logic) and the operating system (Windows, SteamOS, Android):

The game engine’s primary role is to keep the game loop running and handle interactions with the operating system. This game loop runs as follows:

• Event Polling: window resizing, keyboard/mouse/controller input changes, exiting the game…
• Gameplay: physics, calling the gameplay code
• Rendering: generating the commands to be sent to the GPU to then present the new images on the screen

A game engine does much more than this. It also loads and manages the game’s assets: 3D models, animations, sprites, music, and sound. Yet none of these systems implements the game’s specific rules or content. We will go into more detail in the next blog posts about each part and how it is implemented in the Soup Raiders native port.

At the beginning of any game project, then, the question of whether to build a custom engine naturally arises. The goal of commercial game engines like Unreal or Unity is to sell you the game engine so that you only have to focus on making your game, whereas making a custom game engine means building that layer yourself, or at least gluing frameworks and libraries together to do the under-the-hood engineering. Here are some examples:

• I use Unity, but I develop a lot of internal tools <- not a custom game engine.
• I use SDL3 + Assimp to make a 3D game <- this is a custom game engine.
• I use Unreal, but I rewrote the renderer <- not a custom game engine.
• I use SFML to make a simple 2D networking game <- this is a custom game engine.
• I use Godot and extend it with C++ <- not a custom game engine.
• I handwrote the renderer from scratch in DX12 and opened a window with the Windows API <- this is a custom game engine.

It is worth looking at some games built with custom engines. I still remember Indie Game: The Movie³, in which every featured game was built with a custom engine. Many other successful games have also been built with custom engines⁴:

But of course, this does not mean that every successful indie game has its own custom game engine. Unity gained a large share of both the mobile and indie game markets. For example, here is a list of games made with Unity⁵:

But we still repeat the “make a game, not a game engine” advice to computer science students who dream of creating an MMO before they have even finished their bachelor’s degree. Yuri Karabatov makes a similar argument in Make Your Game, Not an Engine⁶. As Tyler Glaiel puts it in How to Make Your Own Game Engine (and Why)⁷:

You think you can just make something better than Unity or Unreal (or Godot or GameMaker) in general. You can’t. It’s possible to make something that is better than these for specific use cases […], but you, as an individual or a tiny team, are not going to compete with these for general purpose stuff. Especially if you have never made your own game engine before.

I really like the approach Noel Berry describes in Making Video Games in 2025 (Without an Engine)⁸. The engine and editor he created let him quickly build the kinds of 2D games he wants to make, drawing on 20 years of game-development experience. His game engine is written in C# and uses SDL3, with Dear ImGui powering its custom level editors. He works mostly on Linux and uses Native AOT to cross-compile for platforms that do not support VMs.

The goal of the Soup Raiders native port is not to compete with Unity or Unreal, but to build an engine specifically for this game, following the game-specific approach T. Glaiel describes here⁹. So now that we know what a custom game engine is, we can try to answer the question of why you would make one.

Curiosity & Learning

T. Glaiel (him again) considers learning how game engines work one of the best reasons to build your own⁷. I started making games by writing my own custom 2D game engine in Python with Pygame. That was in the early 2010s, and Unity was not yet where it is now. For example, here is my first game-jam entry, Trials:

Early in my game-development career, I used Python, Pygame, and Box2D. Later, a colleague from EPFL and I built a C/C++ engine with an embedded Python interpreter that could run my games faster. Finally, for Super Splash Fisticuffs (which became Splash Blast Panic), I switched to Unity 5. Apart from a small Game Boy game that I built in C with GBDK, I did not return to creating game engines until I began teaching.

But why should you learn to make a custom game engine when Unity and Unreal already exist? In fact, I would argue that making your own game engine teaches you a lot about how Unity or Unreal (or Godot) work. For students who want to enter the game industry, building an engine offers insight into proprietary in-house engines that we cannot access in the classroom. So instead of just learning the Unity way or the Unreal way, building a custom engine lets you explore the range of possible game-engine architectures.

In the computer graphics module at SAE Institute Geneva, games-programming students build a 3D scene with OpenGL. I explain why I still teach OpenGL instead of a more modern API in a separate post. Through this exercise, they learn the fundamentals of rasterisation-based rendering. For example, when I introduce shadow mapping, I show them an implementation of cascaded shadow maps.

The three shadow-map cascades appear on the right, while the scene is tinted to show which cascade each pixel uses. Funnily enough, while implementing the first version of Soup Raiders in Unity, I came across this option in the rendering settings:

Faced with such a setting, I have three options:

1. I don’t know what a cascaded shadow map is, so I don’t touch anything.
2. I don’t know what a cascaded shadow map is, so I search online (or ask an LLM), get a sense of what it is, and then change this setting and try to guess how it impacts my performance.
3. I implemented cascaded shadow mapping in an OpenGL sample by hand, so I know exactly what it means and I choose the correct setting accordingly.

For Soup Raiders, I chose a single shadow map with no cascades and applied filtering while drawing the meshes and sprites (I did not really care about the quality of the shadows far away, as this is not an open-world game). A different game and context require different reasoning, and therefore a different decision.

Another example comes from Beach Slap. While I was optimising the game for mobile (I have an old iPad Air 2 from 2014 for that), profiling showed me that a lot of time was spent on occlusion culling, a technique that discards draw calls for objects hidden behind other objects. It’s a very useful technique, for example in games with a lot of geometry that is often hidden. But look at my game:

Because no objects occlude one another, the game does not benefit from occlusion culling. Having implemented the technique for my course, I understand its cost and can confidently disable it.

This experience is not unique. Mathieu Ropert, who worked on Paradox’s custom C++ engine, described a consulting job using UE5¹⁰:

Wrapped up a consulting job on UE5 with no prior engine experience outside hobby interest.
Within hours I had significant performance improvements and found architectural design flaws.
Making CV hard requirements on specific engines is deeply unserious about software engineering.

— Mathieu Ropert (@MatRopert) April 30, 2026

Independence

At the end of 2024, I went through a degoogling phase: I moved most of my files and photos from Google to Proton Drive, cancelled Xbox Game Pass, and left Spotify for Qobuz. I may eventually return to simply buying music or listening on YouTube. Big tech is everywhere, and I still want to get rid of GitHub, Microsoft Windows and Google Calendar, but their convenience is really hard to give up.

Indie developers may be independent from publishers, but they still depend on platform holders (Nintendo, Sony, Microsoft, Valve, Apple) and engine providers (Unity, Unreal, etc.). What about version control? Do you push your code to GitHub, which Microsoft owns? Do you share assets through Google Drive? And which operating system do you use? Many game developers use Windows because important tools and middleware either work only there or support it best; others use macOS.

In Real Reasons (Not) to Build Custom Game Engines in 2024¹¹, Maxim Kiselev identifies three forms of dependency created by third-party engines.

Technical Independence

On technical dependency, M. Kiselev writes¹¹:

If you’re using a third-party engine and encounter a bug or missing feature that impacts your game, you often have no choice but to wait for the engine’s developers to fix it.

This dependency exists with both proprietary and open-source engines, although with an open-source engine you can inspect the code and fix problems yourself. In my view, a third-party engine locks developers into a particular way of implementing their game. That is acceptable for most projects but can become restrictive in unusual cases.

Unity’s transition from OpenGL and DX11 to Vulkan and DX12 illustrates this problem: its modern rendering hardware interface still had to emulate the older model, limiting its potential performance¹².

Vulkan and DX12 was initially slower in Unreal/Unity because their RHIs didn't match the retained mode grouping of Vulkan/DX12. Developers had to add hash maps under the RHI to map dynamic API to retained PSO and descriptor set APIs. Which added complexity and CPU cost a lot.

— Sebastian Aaltonen (@SebAaltonen) January 19, 2025

Of course, Unity could not simply break RHI compatibility between versions. However, a new custom engine designed specifically around Vulkan or DX12 could outperform Unity at the RHI level by matching those APIs more closely. Sebastian Aaltonen actually made a prototype during Unity Hackweek 2019¹³:

When I was working at Unity, we did a simple (4 day) prototype at Hackweek 2019 with fully persistent data and descriptor sets. The performance was super good:https://t.co/NPyXHP3NiM

This is how Vulkan was designed to be used. When you try to emulate DX11 the perf sucks.

— Sebastian Aaltonen (@SebAaltonen) June 4, 2022

With a custom game engine, you have full control over your development process and tech stack.

Legal Independence

You do not own a third-party engine; you use it under a licence that the provider may revoke if it determines that you have violated its terms of service. It has happened several times to developers using Unity:

• Improbable/SpatialOS in 2019¹⁴
• A student who got their licence revoked the day before releasing their game demo in July 2026¹⁵
• Mike Thorn getting his licence revoked - March 2024¹⁶
• License Revoked, Editor Closed, Work Lost - Aug 2023¹⁷

Using a free and open-source engine such as Godot avoids this particular risk. It is released under the permissive MIT licence¹⁸. Unreal is not open source, but it does ship its full source code, which gives a degree of technical independence that Unity’s licence activation system doesn’t necessarily provide.

In the PS2 era, Criterion Games created RenderWare, a cross-platform 3D game engine for PC, PlayStation 2, Xbox and GameCube. The big deal was that each of those consoles had a different CPU architecture (PS2 was MIPS, GameCube was PowerPC, Xbox was x86 like the PC). So a game engine that let you target all those platforms was the Unreal Engine of the PS2 generation. It powered many popular games across different studios¹⁹, including:

However, after EA acquired Criterion in 2004, RenderWare was gradually withdrawn as commercial middleware and had effectively disappeared from the market by 2007 (see EA’s acquisition of Criterion²⁰). According to EA’s William “Bing” Gordon²¹:

Renderware didn’t get the next-gen parts that we needed.

In July 2021, Our Machinery announced a new game engine, “The Machinery”, available by subscription for US$50 per year for independent developers and US$450 per year for industry professionals. The paid subscriptions included every feature, technical support, and source-code access; a free version was also available without the source code. They also published a series of blog posts²² explaining the engine’s development process (the blog goes back to 2017).

However, in August 2022, licensees were abruptly told that development had ended and that they must delete all copies of The Machinery’s source code and binaries, as reported by NME²³. Ryan Fleury discussed the consequences in Ships, Icebergs, Game Engines²⁴:

What becomes of work authored for a project that used The Machinery as its engine? If a game developer is lucky, their investment in The Machinery was kept to a minimum, and their content is largely decoupled from The Machinery technology. That, though, would be a very lucky (or careful) user of The Machinery—what is more likely, for that game developer, is that a hefty majority of the authored content—levels, gameplay code, assets—is, in fact, quite coupled to The Machinery technology, and so the value of that game developer’s content has dropped dramatically close to zero.

In September 2023, Unity announced a runtime fee based on game installs²⁵, scheduled to take effect on January 1, 2024. After an immediate backlash, Unity revised the policy on September 22 with Marc Whitten’s open letter²⁶ but did not cancel the fee entirely until September 2024, when new CEO Matt Bromberg announced its cancellation²⁷.

The controversy had a lasting impact on the indie game-development community, prompting many developers to adopt Godot or build their own engines:

• Kalling Kingdom Engine Port and YouTube Hiatus²⁸. Elega Corporation on leaving Unity after the Runtime Fee controversy and building a proprietary game engine in Rust.
• Godot Private Asset Library — Transitioning from Unity to Godot²⁹. A developer’s experience gradually moving new projects from Unity to Godot following the 2023 announcement.
• From Unity to Godot: My Journey with “No Escape?!”³⁰. A developer recounts rebuilding an existing Unity game from scratch in Godot 4.
• Scrapyard Jam³¹. A game jam created in the aftermath of Unity’s pricing controversy, encouraging developers to build their own engines or experiment with alternatives.

One possible consequence was visible in 2026, when Godot became the most-used engine among submissions to the Game Maker’s Toolkit Game Jam³²:

Well, it finally happened! After 9 years of Unity dominance, Godot was the most used game engine for GMTK Game Jam 2026 submissions. 🤖 Godot - 47% 🎮 Unity - 34% 🛠️GameMaker - 5% 🚀 Unreal Engine - 3% ✨ Other - 11%

[image or embed]

— Game Maker's Toolkit (@gamemakerstoolkit.com) July 27, 2026 at 2:58 PM

Financial Independence

I remember a talk by Rami Ismail at Reboot Develop 2017 where he spoke about this triangle:

His point was that motivation is the most important of the three, because:

• Motivation + Knowledge + No Money = You can work part-time on your game
• Motivation + Money + No Knowledge = You can pay people to make your game
• Money + Knowledge + No Motivation = You do not make a game at all

In So, You Want to Make a Game Engine³³, Nikita Lisitsa writes:

Why not make your own game engine? […] You might find yourself too deep into engine development instead of making an actual game, which can easily lead to a burnout.

This brings us back to the students mentioned earlier who want to build an engine for their ambitious MMO. His warning is simple³³:

It is hard and time-consuming.

But imagine that we have plenty of motivation (or a well-scoped game engine) and the necessary knowledge (or the willingness to learn). If we have no money at all (or no willingness to give away a single penny when the game eventually comes out), then making a custom game engine could be financially better than using a third-party engine. T. Glaiel offers a more cautious view of whether building your own engine saves money⁷:

You most likely won’t (save money). Making an engine takes time, and time=money. […] Using your own engine won’t make you sell more copies of your game automatically. And while you can save time in the long run, this usually means having your engine be good enough to carry you across multiple projects, while also providing you with significant workflow improvements compared to commercial engines. It’s not easy to get this right, and you definitely won’t if its your first try at it (and extremely unlikely if you’re doing 3D instead of 2D).

For context, the following prices are an August 2026 snapshot; pricing and licensing terms may change.

• Unity: Free with Unity Personal for up to US$200,000 in gross revenue and/or funding over the previous 12 months. From US$200,001 to US$24,999,999, Unity Pro is mandatory and costs US$2,310/year/seat or US$210/month/seat. At US$25M or more, Unity Enterprise with custom pricing is mandatory. There is no revenue share or royalty.³⁴
• Unreal Engine 5: Free until a game earns US$1M in lifetime gross revenue, then Epic charges a 5% royalty. Revenue earned through the Epic Games Store is royalty-free.³⁵
• GameMaker: Free for non-commercial use and a US$99.99 one-time fee for commercial games. Console exports require Enterprise, which costs US$79.99/month or US$799.99/year.³⁶
• CRYENGINE: Free upfront, with a 5% royalty after the first US$5,000/year/project. Full source code is included.³⁷
• Godot: Completely free under the MIT licence, with no royalties, subscriptions, or revenue limits.¹⁸

One note from M. Kiselev to finish this section (taking into account that time is money)¹¹:

It’s easy to think that building your own engine will save time and money, but that’s rarely the case. To develop a game using an engine like Unity or Unreal Engine 5, you need to invest time learning them. While this can take a while, it’s still a much smaller time investment compared to building your own engine from scratch and learning the underlying technology needed for it.

Low-Level Control

The Handmade Manifesto³⁸ argues that programmers should understand how computers and their technology stacks work instead of relying on layers of opaque frameworks and dependencies. One of its stated values is “We like to reinvent the wheel.” In a way, creating a custom engine means reimplementing solutions to problems that have already been solved, but tailoring them to the specific needs of our games.

Building some low-level systems yourself does not mean rebuilding everything from scratch. N. Berry⁸ delegates platform, input, and rendering work to SDL3 and uses FMOD for audio. N. Lisitsa also recommends using libraries like SDL, GLFW, SFML or OpenAL³³.

In their Reddit AMA³⁹, the Factorio developers argued that standard engines were unsuitable for their game logic:

‘standard engines’ are so restrictive in what can be done and leave so much performance sitting there that I wouldn’t ever consider using one for something like Factorio.

A custom engine can also dramatically affect compilation times and build sizes. Developers using Unreal or Unity, particularly IL2CPP builds, may be familiar with these problems⁴⁰:

We upgraded a project from Unity 2022.3 to 6.3 and Unity is still the slow , cluncky thing it was before. The builds are as slow. compiling IL2CPP takes 1.5 hours on the machien that compiles UE5 source in 40 mins. It is hard to go back to Unity.

— Ashkan Saeidi Mazdeh (@Ashkan_GC) February 5, 2026

The problem became so severe that I dedicated a separate computer to building Beach Slap for every platform at the end of each development day, using a single .bat script.

Dan Baker argues in A Case for Building Your Own Tech that owning a custom engine can also reduce compilation times⁴¹:

For example, our Nitrous Engine compiles very quickly. The engine compiles in less than 30 seconds. The engine code is clean and modular, so we can implement features in the engine or fix a bug in around a tenth of the time it would take in an off-the-shelf engine. Not only can we do a clean build of Ara in less than 2 minutes, but our debug version of the Ara and Nitrous is so fast that we can still run at 30 fps in full debug.

Sébastien de Graffenried’s custom engine also produces tiny builds compared with default Unity or Unreal builds⁴²:

A nice thing about using your own C engine are the small build sizes.
And I didn't even try that hard to reduce the size! https://t.co/d85Po9ztUU pic.twitter.com/OO2QncB2lk

— Sébastien de Graffenried (@seb_degraff) February 12, 2025

Jonathan Blow also demonstrates the fast compilation times achieved by the compiler for his own programming language⁴³:

I did some work on the compiler that had the side effect of speeding things up! Here are the current compile speeds on my desktop.

Current compiler size: 55,273 lines. pic.twitter.com/HmYKzZ3z3q

— Jonathan Blow (@Jonathan_Blow) January 26, 2021

These three examples show that custom game engines can improve not only your game’s performance but also the performance of your workflow. As T. Glaiel puts it⁷:

it’s nice to just have your own tech, […]. It’s nice to be able to actually debug the internals of your game if something goes wrong.

However, he also warns of the risks⁷:

But it can also suck if you made a couple of bad design choices and everything falls apart entirely, and there’s no resources online to help you. You have full control and full responsibility, and all the pros and cons that come with that.

A custom engine can improve performance and workflow, but poor design choices can still leave you with a C++ project that takes ages to compile. Optimising its compilation times is then your responsibility.

Unique Game Mechanics

Unique or innovative game ideas sometimes require custom technology and the freedom that a custom engine provides. Although general-purpose engines can often support such ideas, working around their constraints may be difficult. For example, in Unity’s GameObject model, creating many objects with separate MonoBehaviour scripts can make the overhead of their Update() calls prohibitively expensive. A common workaround is to use a single manager MonoBehaviour to control all those entities. Unity’s DOTS architecture addresses this limitation, although it introduces a different set of trade-offs.

T. Glaiel uses Noita as an example⁷:

A great example of a justified use of a custom game engine is the well-known Noita. The game has a truly unique concept that likely wouldn’t have worked with any existing proprietary engine, a uniqueness captured in the name of its engine, “Falling Everything.” Yet, Noita doesn’t rely on advanced graphical effects, it’s single-player, and it was built exclusively for one platform — PC.

Noita is a roguelite by Nolla Games in which every pixel is simulated. In his GDC talk⁴⁴, Petri Purho explains that the physics system began with experiments in QuickBASIC: each pixel checked whether there was empty space beneath it and fell accordingly. He developed the system further in Bloody Zombies, eventually adding rigid bodies. Noita then grew out of this existing C++ physics engine.

For Miegakure, an unusual 4D puzzle game, Marc ten Bosch had to reimplement many fundamental systems. As he explained to Vice⁴⁵:

People have very much figured out how to build 2D and 3D games: proof of that is that game engines like Unity exist. In 4D, none of that knowledge exists, and it is more difficult to come up with because you can’t fully visualize it and the math is more complicated. So anything a game developer would take for granted in a 3D game—like collision detection, lighting, sound, modeling props—is a new, difficult problem that has to be figured out. It takes a long time to solve these issues, but it is also extremely fun for me!

Similarly, Dennis Gustafsson explained⁴⁶ that Teardown grew out of his experiments with voxel and destruction technology:

The engine and tool pipeline are created from scratch in C++ for this game specifically, […], but since the game relies on novel technology I don’t think it would have been possible using an off-the-shelf engine.

Specialisation

T. Glaiel lists “I can do better” (than other game engines) as a bad reason for making a game engine. In his own words⁷:

You think you can just make something better than Unity or Unreal (or Godot or GameMaker) in general. You can’t. It’s possible to make something that is better than these for specific use cases […], but you, as an individual or a tiny team, are not going to compete with these for general purpose stuff.

For a custom engine to make sense, it must be specialised for the game, its artistic direction, or the platform’s technical constraints.

Because N. Berry’s artist uses Aseprite, he added direct support for its file format to the engine. He also builds level editors tailored to each game and the team’s workflow⁸. He can do that because he does not need most of the features of a general-purpose game engine.

According to Sam Machkovech’s article on Animal Well⁴⁷, Billy Basso built a custom engine partly because his experience with bloated, sluggish off-the-shelf engines in mobile development had left a “sour taste.” His engine allowed him to combine a rim-lighting shader, which highlights silhouettes in otherwise dark scenes, with a full-screen Navier–Stokes simulation for smoke and water. B. Basso recommends an engine-first approach to game development:

[…] That opens up a lot of unique creative avenues. Once I get a cool system working, then I can play around with it and see what it allows for.

N. Lisitsa makes the point that a custom game engine does not necessarily need complex material graphs, global illumination, advanced 3D physics, multiplayer infrastructure or industrial-scale editor tooling³³. For T. Glaiel, specialisation is almost a requirement for a custom engine. He adds⁷:

[…] you can make your asset pipeline / level editor / whatever way smoother to use when considering your specific use cases instead of needing it to be general purpose.

This is one of the central ideas in Andreas Fredriksson’s Context Is Everything⁴⁸ talk at Handmade Seattle 2021: once you understand your specific context, a custom engine’s low-level control lets you optimise as deeply as necessary.

Specialisation can also provide long-term benefits: a custom engine may support the next game or even an entire series. This was the case for the RED Engine of CD Projekt Red⁴⁹:

• (2007) Aurora Engine: CDPR licensed and heavily modified BioWare’s engine to create The Witcher.
• (2011) REDengine 1: CDPR introduced its own proprietary engine with The Witcher 2.
• (2012) REDengine 2: The engine evolved to support consoles and multiplatform development.
• (2015) REDengine 3: REDengine was redesigned for the large open world of The Witcher 3.
• (2020) REDengine 4: The engine evolved again for the dense urban world of Cyberpunk 2077.
• (2023) REDengine 4 (cont.): Phantom Liberty became the final major release built with REDengine.

CD Projekt Red has since switched to Unreal Engine for The Witcher IV, but the evolution of REDengine still shows how a custom engine’s foundations can support several generations of games.

Multiplatform

When releasing a game on multiple platforms, Unity feels like magic. Even if the result is not perfectly optimised, porting a Unity game to a console can take far less time than implementing the port by hand in a custom engine, especially when the platform is unfamiliar. N. Lisitsa describes the cost of multiplatform support in a custom engine³³:

Supporting multiple platforms adds more pain, since different platforms have different executable file formats, dynamic library formats, etc. You’ll have to compile several different versions of your game, one for each platform.

Compare that with the “time to triangle” (the time required to render an engine’s first triangle on a console) that Mark Cerny discussed for several PlayStation generations at Gamelab 2013⁵⁰:

Custom engines have a clearer advantage on niche and retro platforms. At the time of writing, Unity 6.4 officially supports these consoles⁵¹:

• PlayStation 4 (including PlayStation VR)
• PlayStation 5 (including PlayStation VR2)
• Xbox One
• Xbox Series X
• Xbox Series S
• Nintendo Switch
• Nintendo Switch 2

These are all recent console generations. Targeting older or more unusual hardware often requires a custom engine or specialised tooling. On the Playdate, you are required to program in C or Lua with its SDK. The Arduboy similarly uses C++ through the Arduino ecosystem, under severe hardware constraints.

For GBJam 2016, I made a Game Boy game in C using GBDK, a process I described in a separate post. GB Studio did not exist at the time, so I had to endure the painful process of programming for a system without a debugger (the screen would just be blank at boot when there was a problem).

Similarly, Elias Daler is developing a PS1 game with his own custom engine⁵²:

I started making stuff for PS1 exactly one year ago.

It's been a wild journey since then. I'm thinking of writing a big article about it (and later a video, maybe).

And this is just the beginning of my PS1 journey!
Now that I have a pretty good engine, I can make a real game. pic.twitter.com/fA1cWJfNlp

— Elias Daler (@EliasDaler) July 24, 2025

Commercial engines must follow current technology and console generations, whereas custom engines can continue targeting whichever platforms their developers choose.

Modding

On file management, T. Glaiel writes⁷:

You might want to be able to build mod support or dynamic loading/unloading or whatever off of this, as long as you have the basics here and only ever load files through the file manager, you can easily add whatever other functionality you want into this later.

But what can we load and allow the players to change?

One of the defining games of my teenage years was Civilization IV, whose unusually moddable, data-driven architecture was discussed in the August 2005 issue of Game Developer⁵³. It featured four tiers of moddability:

• In-game WorldBuilder: An in-game map editor for customising terrain and placing units, cities, buildings, and resources.
• XML/data modification: All game variables, text, asset paths, and rules were stored in standard XML files.
• Python scripting: High-level game functionality was exposed to Python, allowing scripts to generate maps, modify the interface, trigger game events, and override AI.
• C++ GameCore DLL SDK: Users could modify, replace, or extend the low-level C++ code that ran the game.

While researching this post, I discovered Realism Invictus⁵⁴, a total-overhaul mod that has remained in development for more than 20 years. It adds over 130 technologies, entire families of distinct units, more than 160 leaders, and 21 additional civics, making it feel almost like Civilization IV 2.0. All this is possible because the game developers spent a lot of time making the game (and thus the engine) moddable.

Bohemia Interactive’s ARMA III offers another example. In his talk THE PANDORA’S BOX OF MODDING IN ‘ARMA’ GAMES⁵⁵, Karel Mořický describes three relationships between games and mods:

• Standard game: Players cannot modify it, so the code’s internal mess remains hidden.
• Improvised modding: Determined players modify the game without official support, often producing messy or unstable results.
• Moddable game: The developer provides an API so mods can add content. At this point, the product becomes a platform.

I find it fascinating that ARMA supports multiple simultaneous mods, dependencies between mods, patch mods that override existing content, and multiplayer-specific server and client mods. At the time of the talk, the community had created 70,174 mods. The game exposes its editors directly through the main menu, and modders can use a development branch alongside the main release to prepare their mods for upcoming updates.

By contrast, the Minecraft: Java Edition modding ecosystem grew largely without an official engine-level API from Mojang. Early modders simply decompiled the game and replaced or modified classes directly inside minecraft.jar. Over time, different communities built shared modding layers. Today, the main ecosystems include Fabric, Forge, NeoForge, and Quilt, alongside server platforms such as Paper and its derivatives. Updates to Minecraft: Java Edition have often been painful for modders. Version 1.13 introduced substantial internal changes, making large mods difficult to port and forcing even Forge itself to undergo a major redesign⁵⁶.

Interestingly, Minecraft: Bedrock Edition experimented with a JavaScript API⁵⁷ in 2018. Its modern Script API⁵⁸ still uses JavaScript or TypeScript, while Molang⁵⁹ serves as a separate expression language embedded in add-on JSON files.

Factorio mods⁶⁰ can run Lua code both during startup and while a map is being played. Because Factorio supports deterministic multiplayer, its developers found that even iterating over a Lua hash table could make a mod nondeterministic and cause desynchronisation⁶¹. Mods can also crash. Initially, Factorio presented mod failures in the same way as game crashes, but the developers later added clearer error reporting⁶² that identified the responsible mod. One of Factorio 2.0’s most significant modding changes was to treat the game itself as a mod⁶³, shipping first-party components through the same dependency infrastructure.

For Beach Slap, we designed the level editor as an in-game tool from the start so that we could share it with players. Levels are stored as JSON files, making them easy to save locally, upload, and download. I do not, however, plan to support modding in the native version of Soup Raiders.

Conclusion

This post grew far beyond my original idea, but I wanted to set out my thoughts on building a custom engine before delving into the technology itself. Building an engine takes time, but it gives us control over how the game loads and updates, removes engine-licence fees, and teaches us about asset compilation, rendering, and optimisation. We can even expose parts of the engine to players, allowing them to improve the game or create mods (and potentially entirely new games) with our technology. After Unity’s runtime-fee announcement, technological independence became an even more important concern for game developers.

The rest of this series will explore the implementation of the Soup Raiders native port and how it targets 60 Hz on Nintendo Switch with loading times below three seconds. One final principle comes from Ted Bendixson’s Better Software Conference 2025 talk⁶⁴: build an actual game with your custom engine, not merely an impressive technical demo. T. Glaiel expresses the same principle more forcefully⁷:

Make a game at the same time as you’re making the engine. This is an unbreakable rule. The only unbreakable rule. Get the basics in as fast as you possibly can and then immediately start making a game on top of it. An engine is nothing without a game.

I will leave you with one final thought on building a game engine with the help of LLMs⁶⁵:

Now is the perfect time to write your own engine. The argument in the past was that you don't have time to write all the less important generic features. Now, the LLM will do that for you. You can focus on things that differentiate your product. https://t.co/ydEaaZOx12

— Sebastian Aaltonen (@SebAaltonen) March 16, 2026

Continue with part 2: Porting the Soup Raiders Demo from Unity.

Further Reading

These are not cited above, but they cover the same ground and are worth your time:

• Rez Graham, Independent Games Summit: A Case for Making Your Own Engine, GDC 2024. https://www.gdcvault.com/play/1034506/Independent-Games-Summit-A-Case
• raysan5, Custom Game Engines: A Small Study. https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74
• Angelo “Encelo” Theodorou, nCine: a world with custom in-house engines is possible. https://encelo.github.io/CustomEnginesPresentation/#1

References

Two weeks ago, I announced that my talk was accepted for CppCon 2026, happening in about a month in Denver (on Tuesday, September 15th, to be more exact). The talk is about building a small but non-trivial C++ game engine and all the nice things modern C++ provides to help with this task; you can find it in the CppCon schedule. I was not very comfortable giving a purely theoretical talk without any practical example to back it up.

The game

Just playing around with a simple game engine was not what I wanted to do during my summer holidays. After working at 6it.dev, I realised that even though I like working on and understanding game engines, my goal is still to make games. And so, to have a manageable but not too trivial project, I decided to resurrect Soup Raiders, which had been on hold since 2024.

So the goal is pretty simple: take my old Unity game and port it to a new custom C++ engine using the Neko3d renderer. Through this process, I can test that the content of my CppCon talk is valid in practice. However, there are a lot of points that I simply will not have time to bring up during my 60-minute talk, so I decided to write a few blog posts about them. I don’t know how big this series is going to be, but I want to write about interesting subjects like load-time optimisation, profiling, GPU optimisation, error handling, and platform porting.

3D renderer

For the 3D renderer, a part of a game engine that can take a lot of time to build, I already have CompGraphEditor, a tool that I use in my course to explain the basic concepts of computer graphics. Behind the scenes, I have been refactoring this project into a new version for next year, renamed Neko3d:

Neko3d uses SDL GPU as its rendering hardware interface (RHI) on top of Vulkan, DirectX, and Metal. Above the RHI, Neko3d adds shaders, pipelines, meshes, models, materials, draw commands, render passes, and scenes that can be customised with C++ “scripts” to control the rendering. The main shader language I use is GLSL (I should probably switch to Slang one day).

The target

I want this game to run on the Nintendo Switch at 60 Hz, with sub-three-second loading times between levels (and menus). The bottlenecks are going to be the GPU and the loading of visual assets. But in the previous Unity version, I managed to get the game running close to this target, and now I have full control over the codebase.

The series

So here begins a whole series about this little summer project of mine: bringing my Soup Raiders demo to a custom game engine.

• (1) What You Gain by Building Your Own Game Engine
• (2) Porting from Unity
• (3) The asset compiler
• (4) Profiling with Tracy
• (5) Level load time
• (6) Rendering optimisation: culling, cutout silhouettes, and depth sharing
• (7) When to use ECS and when not to
• (8) Error handling
• (9) Memory: fixed-capacity containers and heap budgeting
• (10) Porting to a closed platform
• (11) The future of Soup Raiders: Unity as an editor, or my own?

Little C++ OpenGL ES 3.0 sample compiled to the web with emscripten

Introduction

It’s been a few years that I have been giving this Introduction to Computer Graphics module (a trimester) at SAE Institute Geneva and I have always been wondering if and when I would need to transition my course from OpenGL ES 3.0 to more modern API.

Back in November, I was at the Graphics Programming Conference (my blog post here), and this subject reemerged for me during the conversations with people from the industry as well as from the talks. From the Teardown talk (all the conference’s talks are available on the website), the original game worked in OpenGL 3.3 and from the X-Plane talk, the rendering engine was using OpenGL 2.1. But both those talks were about how they transitioned to more modern API to have better graphics. This sounds like the sunset of OpenGL.

Two talks really caught my attention about education for Computer Graphics: the talk Bridging Pixels and Code: Teaching Computer Graphics to Technical Artists from Matthieu Delaere that focus on students creating their own rasterizer from scratch and the talk from Mike Shah that focuses on the next steps after the tutorial. The latter talk actually made me think about if the actual idea to do the transition to modern API for my course made still sense.

What have to be taken into account for a transition is that all the courses need to be translated to this new API/framework and updated depending on the new concept added. So if there is a transition to be made, it needs to be really worth it compare to OpenGL ES 3.0.

The course content

The goal of the introduction in computer graphics module is for the students to implement a 3d scene with a graphics API. What is important to understand is that they should not implement a generic 3d renderer, but specifically a 3d scene, so the final executable is not supposed to be data-driven. For example, it would be completely ok to have such implementation:

void DrawScene(const Pipeline& pipeline, const Camera& camera)
{
  //Cull the scene from the camera POV

  //Draw each 3d object by hand

}

Since when I started to give this module, I have been following the learnopengl.com structure but using OpenGL ES 3.0 instead. Each chapter is like a list of samples that have to be implemented and tested (Hello Triangle, Hello Texture, etc…)

But why specifically this version of OpenGL? OpenGL ES 3.0 is a mobile graphics API, released in August 2012, so about 14 years ago (which is a LONG time in computer graphics). I chose it because it is the most cross-platform version of OpenGL in my opinion, with this version you can run the same C++ program (with some #ifdef) and the same shaders for:

• Windows: while I encountered some driver issues throughout the year, OpenGL ES 3.0 is compatible with OpenGL 4.3, so I just assume OpenGL 4.3 on Windows not to worry.
• Linux: some of my workstations boot on Linux by default, and it is good practice to compile the same C++ code with another compiler.
• Android: this one is a bit complicated as the actual android app boots from Java and calls the native lib containing the code.
• Nintendo Switch: we have two devkits at school and except removing glew or glad and replacing it with the embedding OpenGL wrapper, it works fine.
• WebGL2: my favorite reason of using OpenGL ES 3.0 is that it is compatible with WebGL2 with emscripten (except float color attachment that is an extension…), which allows my students to port their samples to their own website/blog. It is the case with this blog post where I simply put the demo out of emscripten on the web page.
• iOS or MacOSX: unfortunately not supported anymore, but none of my students work on a Mac as this is a Games Programming bachelor.

The same demo but running on the Switch

Compare to more modern API, synchronization is taken care of by the driver in OpenGL. This allows to skip most of the setup of a lot of boilerplate initialization. This is nice, but is paid with the cost of the driver overhead added for this.

However, one of the hassles of the first course is having the students’ laptop chooses the wrong GPU on laptop (using the Intel integrated GPU instead of the Nvidia GPU). Last year, you just needed to set the whole Nvidia configuration to be on “Performant” mode, but with a new Windows update, you need to set individually the application that is to be performant in the Windows settings, not the Nvidia settings anymore. Also, there is this trick for Windows:

#ifdef __cplusplus
extern "C" {
#endif

__declspec(dllexport) DWORD NvOptimusEnablement = 1;
__declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;

#ifdef __cplusplus
}
#endif

And this (supposedely) enables the discrete GPU and not the integrated one (I am happy this is a solved problem in modern API like Vulkan). Let’s see how we tackle other subjects!

Core concepts

Every week, the students need to finish about 2-3 samples on a specific feature (for example: implement a sample that uses SSAO using the previous idea from the deferred rendering sample). When working on their samples, the students usually start to build their own abstractions. This year, we decided to work together and build the abstraction in a common git repository such that those abstraction could be used by all the students of the class as soon as it was implemented. This is something that I want to continue in the next years.

Pipeline

I really dislike OpenGL naming… Pipelines are called program, so when my students comes from learnopengl.com, they name their pipelines shaderProgram. Anyway, we created an abstraction called Pipeline that loads with a vertex shader and a fragment shader (also a specific abstraction) that looks like this:

class Shader
{
public:
//shader target being GL_VERTEX_SHADER or GL_FRAGMENT_SHADER
    void Load(std::string_view path, GLenum shader_target); 
//[...]

class Pipeline
{
public:
    void Load(const Shader& vertex_shader, const Shader& fragment_shader);
//[...]

Shaders are “compiled” with glslangValidator that I configure with CMake. This allows to check for syntax errors during compile-time instead of seeing a weird error in the run-time compilation of the glsl shader by the driver.

Because of OpenGL implementation of uniform buffer, we added a bunch of function to set those uniforms and to retrieve the uniform locations (and cache them for future retrieval):

class Pipeline
{
public:
    //[...]
    void SetInt(std::string_view uniform_name, int new_value);
    void SetFloat(std::string_view uniform_name, float new_value);
    template<typename T>
    requires core::IsVector3<T, float>
    void SetVec3(const std::string_view uniform_name, const T& v) {
        const GLint loc = GetUniformLocation(uniform_name);
        glUniform3f(loc, v.x, v.y, v.z);
    }
private:
    GLint GetUniformLocation(std::string_view name);
    std::unordered_map<std::string, GLint, StringHash, StringEqual> uniform_location_map_;

Several things to unpack here:

• SetVec3 uses the concept IsVector3 that check if the type has the three attributes x, y, z at the correct type.
• StringHash and StringEqual allows the use of std::string_view without the need to create a std::string when trying to find a uniform location in the map.

Vertex inputs

One of the weird thing for me going into OpenGL is how memory is allocated (the glGen, glBind, and then upload the data and probably uplaod at the same time). For example, for a vertex input buffer:

int vbo_;
glGenBuffers(vboCount, &vbo_);
glBindBuffer(GL_ARRAY_BUFFER, vbo_);
glBufferData(GL_ARRAY_BUFFER, vertex_buffer.size, vertex_buffer.data, GL_STATIC_DRAW);

For vertex inputs, you have those buffers that are to be setup in a Vertex Array Object, sort of like a container of vertex buffers, to define how the pipeline is going to read the vertex buffers, with something like this:

int vao_;
glGenVertexArrays(1, &vao_);
glBindVertexArray(vao_);

glBindBuffer(GL_ARRAY_BUFFER, vbo_);

glVertexAttribPointer(
  vertex_input_location, // in the shader (location = 0) 
  vertexAttribData.size, // how many of the primitive: float => 1, vec2 => 2, vec3 => 3, vec4 => 4
  vertexAttribData.type,
  GL_FALSE,
		vertexAttribData.stride,
		(void*)vertexAttribData.offset);
glEnableVertexAttribArray(vertexAttribData.index);
//when using instancing
glVertexDivisor(vertexAttribData.index, 1);

All this is abstracted in the VertexInput class with the Buffer abstraction:

template<GLenum target>
class Buffer {
public:
  void Bind() const;
  void Load();
  /**
   * @brief Allocate and upload the data in the buffer
   */

  template<typename T>
  void UploadRange(std::span<const T> range, GLenum usage = GL_STATIC_DRAW);
  /**
   * @brief Update the data in the buffer (to be used after using UploadRange
   */
  template <typename T>
  void UpdateRange(std::span<const T> range, GLintptr offset = 0, GLenum usage = GL_STATIC_DRAW);
};

using VertexBuffer = Buffer<GL_ARRAY_BUFFER>;
using IndexBuffer = Buffer<GL_ELEMENT_ARRAY_BUFFER>;

struct VertexBufferAttribute {
  GLuint location;
  GLint size;
  GLenum type;
  GLsizei stride;
  size_t offset;
  bool is_instanced = false;
};

class VertexInput {
 public:
  void Load();
  void BindVertexBuffer(const VertexBuffer& vbo, std::span<const VertexBufferAttribute> attributes);
  void BindIndexBuffer(const IndexBuffer& ebo);
  void Bind();
};

• VertexBufferAttribute::is_instanced allows Buffer to be binded as per instance buffer as we don’t have support for SSBO in OpenGL ES 3.0 (section below).

Textures

The logic for texture in OpenGL is counter-intuitive. One has to understand the difference between texture name (the handle given by glGenTextures) and the texture unit (GL_TEXTURE0 for example). It confuses a lot of my students each year. So binding a texture to a uniform sample looks like this:

glUniform1i(uniform_location, 0);
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE2D, my_texture);

This is put in a function in the pipeline to look this:

pipeline_.SetTexture("uniform_name", my_texture, 0);

//with implementation looking like this:
void Pipeline::SetTexture(std::string_view uniform_name, const Texture& texture, int texture_unit)
{
    const auto uniformLocation = GetUniformLocation(uniformName);
    glUniform1i(uniformLocation, textureUnit);
    glActiveTexture(GL_TEXTURE0 + textureUnit);
    texture.Bind(); 
}

For loading, in the beginning of the module, we start with stb_image to load JPG, PNG, BMP, etc… This header-only library decompresses the images such that we can upload them to the GPU, something that looks like this:

image.pixels = stbi_load(imagePath.data(), &image.width, &image.height, &image.comp, 0);
	
glGenTextures(1, &my_texture);
glBindTexture(GL_TEXTURE2D, name_);
switch (image.comp)
	{
	case 3:
		glTexImage2D(GL_TEXTURE2D, 
      0, GL_RGB, image.width, image.height, 
      0, GL_RGB, GL_UNSIGNED_BYTE, image.pixels);
		break;
	case 4:
		glTexImage2D(GL_TEXTURE2D, 
      0, GL_RGBA, image.width, image.height, 
      0, GL_RGBA, GL_UNSIGNED_BYTE, image.pixels);
		break;

All this is course hidden in a Texture abstraction with Load and Bind. Then for cubemaps, we add:

class Texture
{
  public:
  //[...]
  void LoadCubemaps(std::span<const std::string_view, 6> paths);
}

The Texture holds the “target” (GL_TEXTURE2D or GL_TEXTURE_CUBE_MAP, why not texture3d?) and then the Bind will bind the correct target.

Model Loading

We use Assimp as it simplifies the setup of the loading of 3d models and also allows to import and export in a lot of different formats. This would look like this:

void Model::LoadModel(std::string_view path)
{
  Assimp::Importer importer;
  scene = importer.ReadFile(path.data(),
                                aiProcess_Triangulate | aiProcess_FlipUVs |
                                aiProcess_GenNormals |
                                aiProcess_CalcTangentSpace);

  if (!scene || scene->mFlags & AI_SCENE_FLAGS_INCOMPLETE || !scene->mRootNode)
  {
      ...
  }
  ProcessNode(scene->mRootNode, scene);
}

void Model::ProcessNode(aiNode* node, const aiScene* scene)
{
    // process all the node's meshes (if any)
    for (unsigned int i = 0; i < node->mNumMeshes; i++)
    {
        aiMesh* mesh = scene->mMeshes[node->mMeshes[i]];
        meshes_.push_back(ProcessMesh(mesh, scene));
    }
    // then do the same for each of its children
    for (unsigned int i = 0; i < node->mNumChildren; i++)
    {
        ProcessNode(node->mChildren[i], scene);
    }
}

Mesh Model::ProcessMesh(aiMesh* mesh, const aiScene* scene)
{
  // Processing the meshes

It is also used in the same way in learnopengl.com, so the students can have a working implementation to check when they encounter a mistake.

Draw commands

In OpenGL, the driver is adding our commands into its own command buffer. This forbids multi-threading draw commands generation (compare to more modern API) and it gives this feeling that drawing happens immediately. Because of learnopengl.com, most of my students put their draw call in the Mesh contained in their Model. So it looks like this:

void Model::Draw(const Pipeline& pipeline)
{
  pipeline.Bind();
  for(auto& mesh: meshes)
  {
    mesh.Draw(pipeline);
  }
}

void Mesh::Draw(const Pipeline& pipeline)
{
  material_.Bind(pipeline); //binding all textures to their samples
  glDrawElements(GL_TRIANGLES, indices_count, GL_UNSIGNED_INT, nullptr);
  //or depending on the abstraction
  vao_.Draw();
}

After working on my computer graphics editor (I wrote a blog post here), I really prefer a separated approach where a scene has materials (pipeline + texture reference) and meshes, and that models do not exist as scene abstraction. However again, it is not about making a data-driven renderer, but just implement a 3d scene.

Render passes & Framebuffer

Finally, the last big OpenGL core concept is about multi passes. The first half of the module is spent in one pass. Post-processing is the first example of multi-pass, where my students have to use a framebuffer to draw their scene, and then use another pipeline and the render targets as a sampled texture. The first example is several variations of post-processing (like grayscale, inversing the color). Setting a certain framebuffer in OpenGL is starting a new render pass (RenderDoc will usually write it as Color Pass). With the students, we worked out an Framebuffer abstraction that use a FramebufferCreateInfo struct (very similar to Vulkan) with the color attachments and the depth color:

struct ColorAttachmentInfo {
  GLenum target = GL_TEXTURE_2D;
  GLint internal_format = GL_RGB8;
  bool is_active = false;
};

struct DepthAttachmentInfo {
  GLenum target = GL_TEXTURE_2D;
  GLenum internal_format = GL_DEPTH24_STENCIL8;
  bool is_active = false;
  bool is_rbo = true;
};

struct FramebufferCreateInfo {
  //OpenGL has maximum 16 color attachments
  std::array<ColorAttachmentInfo, 16> color_attachment_infos{};
  DepthAttachmentInfo depth_stencil_attachment_info{};
  core::Vec2I size{};
};

class Framebuffer
{
void Load(const FramebufferCreateInfo& info);
void Bind();
static void BindBackbuffer();
const Texture& color_attachments(int index);
const Texture& depth_attachment();
};

• RBO (render buffer object, yet another type of buffers) is sort of like a GPU write-only kind of resource.

Usually, we want one or several color attachments as Texture and a depth-buffer as RBO, except for a shadow pass, where we want a depth-only pass (that outputs to a Texture).

A big step in using framebuffer in the module comes with the introduction to HDR (High-Dynamic Range), basically the fact that we can use color in a bigger range than [0 - 255]. One of such applications is deferred rendering and the creation of G-Buffer (Geometry Buffer that contains position, normals and baseColor for example) to minimize the amount of lighting calculation per pixel. So first, you render a color pass on a G-Buffer with several color attachments each containing important geometry value (position, normal, base color) and then there is a light pass where lighting is calculated per pixel. This technique see a huge performance improvement when drawing a lot of lights on the screen. With our abstraction, you just need to use a HDR type of internal format (for example GL_RGB16F).

Of course, not all monitor outputs HDR, so we need a way to go back to LDR (Low-Dynamic Range, [0 - 255]) and this is done at the end of the lighting pass fragment shader:

//Reinhard tonemapping
vec3 result = lighting / (lighting + vec3(1.0));
FragColor = vec4(result, 1.0);

Missing modern OpenGL features in ES 3.0

Using OpenGL ES 3.0 (to allow use of WebGL 2.0) has still a cost though. Some core concepts of modern rendering are explained in course content but not implemented (except if the students want to get rid of WebGL2 compatibility).

SSBO

As of OpenGL 4.3 and OpenGL ES 3.1, we can define shader storage buffer object. This is useful to remove the need to pass by the vertex inputs when doing instancing. Of course, we need to had another type of buffer that can be binded to an uniform. This would look like this:

//in C++
glBufferData(GL_SHADER_STORAGE_BUFFER, instancing_buffer.size, instancing_buffer.data, GL_DYNAMIC_DRAW);
glBindBufferBase(GL_SHADER_STORAGE_BUFFER, binding_point, ssbo);

//in shader
layout(std430, binding = 3) buffer layoutName
{
    vec4 data_SSBO[];
};

void main()
{
  vec4 instancing_data = data_SSBO[gl_InstanceID];
}

Compute shader

Compute shader only appeared in OpenGL ES 3.1 (so not WebGL2). Coming back to the post-processing example explained before, instead of giving the color attachment of the scene as a sampler2D, we could give it as an image2D and actually do the post-processing in compute. Typically, every the-whole-screen kind of shader are easier to implement with a compute pipeline with a single shader, rather than a graphics pipeline with a plane in NDC (Normal Device Coordinate) going from [-1, 1] just to recover the whole screen in the vertex shader and implementing the transformation in the fragment shader.

SPIR-V

Starting with OpenGL 4.6 (not even available in OpenGL ES 3.2), we can load SPIR-V instead of plain text GLSL. This allow for quick loading of shader as the format is binary and it allows to add a compilation step to shaders (something we sort of do anyway with glslandValidator).

Bindless

Modern OpenGL desktop allows for “bindless” rendering where textures are not binded to a texture unit but can be referenced via a 64-bit handle stored in a buffer (enabling access to virtually an unlimited textures without expensive state changes) with the extension ARB_bindless_texture (supported on Nvidia and AMD, but not on Intel).

For buffers, ARB_buffer_storage (core in OpenGL 4.4 and as an extension EXT_buffer_storage since OpenGL ES 3.1) allows to keep the GPU pointer to enables persistent mapped buffers, avoiding repeated map/unmap cycles.

This is not available in OpenGL ES 3.0, so the workarounds are usually texture atlases or texture arrays, combined with batching (draw calls with different vertex inputs, but the same textures) to avoid the costly switch of textures.

Indirect Drawing

Another powerful feature that is unavailable in OpenGL ES 3.0 is indirect drawing. In our module, the CPU is issuing all the draw calls with glDrawArrays and glDrawElements or their instanced versions. glDrawArraysIndirect and glDrawElementsIndirect are part of core since OpenGL 4.0 and OpenGL ES 3.1 allowing draw parameters to come from a GL_DRAW_INDIRECT_BUFFER. More power comes with Multi-Draw Indirect (core in OpenGL 4.3 and extension EXT_multi_draw_indirect since OpenGL ES 3.1), which allows through glMultiDrawArraysIndirect and glMultiDrawElementsIndirect calls to dispatch entire arrays of draw commands which combined with compute shaders that enables fully GPU-driven rendering pipelines where the GPU performs frustum culling, LOD selection, and occlusion culling. ARB_indirect_parameters allows even the draw count itself be GPU-determined.

Debugging

For my students, what used to be the most time they were spending was with RenderDoc. Now I see more students just using LLM to check their code and see what is wrong (even one of my students who said “they told me there was an error there”). However, the exam explicitly forbids LLM to solve, so my students still have to go through the debugging process by themselves if they want to pass.

Starting with OpenGL 4.3, KHR_debug is part of core and allows to have the driver sends error, warning, debug messages through a callback. As OpenGL 4.3 is fully compatible, I realized while writing this blog post that we could use it on Desktop to have better debug capabilities (registering OpenGL objects with glObjectLabel with a macro for example).

Missing features from Modern API

Sticking with OpenGL means also missing a lot about newer features of modern API like Vulkan and DX12. Of course, modern API are more than just features, they are also another mental model. But let’s focus on the features.

Raytracing

With all their marketing on RTX, Nvidia surely brought raytracing in every gamer’s mouth when talking about computer graphics. Of course, raytracing exists since before the advent of graphics card. However in 2018, DXR was released, allowing for hardware raytracing on the GPU using new kind of shaders (closest-hit, miss, raygen, etc…) and Vulkan followed with the Nvidia extension and then the generic extension.

Most games are still living in a hybrid rendering world where some parts are done in rasterization and some are done in raytracing, with custom options for players. In its State of GPU Hardware, Dmytro “Boolka” Bulatov mentions that only games like Indiana Jones and the Great Circle (released in late 2024) that puts DXR as a requirement. So for me, as a teacher, I still showcase the hardware raytracing API, its advantages and disadvantages, and how the future looks like, but as it is an introduction to computer graphics, I can’t ask all my students to have to implement a hardware raytracing pipeline.

Multithreaded rendering

When thinking about modern CPU architecture, we are living in a multi-core world now, but most of what we program in games is still happening in one thread on one core. To truly unlock the power of our CPU, we can divide our work between several threads. A common pattern is to have a threading model with Game/Cull/Render on the CPU, or having the loading done async and those still work with OpenGL.

However, certain games (like Halo Infinite) require the use of multiple threads to generate all the GPU commands. This is definitely possible with DX12 and Vulkan, but not in OpenGL where the render states are in the driver implementation in one thread.

The results

Here are some of the works of my students during this module over the years:

• Fabian Huber
• Samuel Styles
• Olivier Pachoud
• Constantin Verine
• Remy Lambert
• Maxime Roch

What about a framework?

I love SDL GPU API. I am currently porting my computer graphics editor to it, and it allows to target Vulkan, DirectX and Metal at the same time. However, there is still a bit of bloat for an introduction course for me to use SDL GPU. I heard some good things about bgfx also and raylib as well. WebGPU, on top of adding a new shader language, is very similar to Vulkan 1.0 that caused me more pain that joy.

When having students working on their samples and they do a mistake in OpenGL, it can often be pretty clear why there is a mistake, but facing a framework, the code of the library has also to be taken into account. And my goal is to teach them a graphics API and build abstractions on top of it.

Conclusion

OpenGL ES 3.0 has still a lot of advantages to be taught even in 2026 (especially WebGL2), at the cost of going through the struggle of the legacy of this API. 14 years is a lot of time in Computer Graphics. For example, at the end of his graphics API blog post, Adam Sawicki does not recommend OpenGL as a choice (as it is rarely used anymore).

This course has allowed throughout the years all of my students to discover how graphics programming work. For some of them, it was their first step in their computer graphics career and I am glad that I helped them in that. I want to write another blog post about why we are not yet switching to Vulkan (talking about synchronization, PSO, driver overhead), as I have a few things to say about this specific API. Don’t hesitate to comment on the social media or just send me an e-mail (I am interested to know how other teachers are doing and what people working in the industry want to see from graphics programming students). Here the rotating cubes demo running on Android:

2025 is coming to an end. A lot of things happened for me. I wanted to write a wrap-up and project myself into 2026 with all the new projects.

Working at 6it.dev

After the initial rush of end of 2024 right after CppCon, I needed to rebalance my work-life balance to be able to continue to work at 6it. I can’t really talk about what I am working on, but I could take the time to learn a lot about C++ and API design, as well as production management that I put into practice at SAE Institute with my students.

However, one of the big challenges of the beginning of the year was to not push myself to work too much. When freelancing, as we might get tired, we’re thinking of taking the afternoon off, but a simple multiplication of the hour with the hourly rate gives us a cost of a break. I needed to learn not to take this into consideration and that if I needed a break, I should take that break. I think that I have found the balance that works for me.

ADDON

This year I went again to ADDON in Rennes, France, and for detail, you can read my post about it here. I really enjoyed the time there and to learn new things. I was very thankful to meet Thomas Poulet who famously wrote the frame analysis of Ni No Kuni 2. I gave a translated and updated version of my CppCon 2024 talk about multiplayer game and using rollback. It was also a nice opportunity to take some days off in Paris.

Marathon de Genève

Running a marathon was last year resolution and in the end, I ran the Fribourg by Night trail which was a lot of fun, but also a good realization that after about 2 hours, my body is completely empty and I need a lot of supplies during a long race.

So I registered for the Geneva Marathon in May as a challenge, not really knnowing how it would look like. Maybe one regret is that the training might have not been to the best for a marathon as I was counting on my mental to make me go through.

So fast forward to May the 11th, in the morning, a very sunny day, packed with supplies at the starting line. When the race began, I did not rush, did not try to follow the people too much, trusted my heartbeat and my footstep. All went good, until I crossed the middle mark.

My legs started to cramp, so I needed to slow down, making the struggle for the marathon really start. This race was really emotional, I was switching music style when needed, I could see the Mont Blanc. Except for the feed zone, I would not stop running, even though I was running pretty slowly. The closer that I was from Geneva the harder it got. Finally I could see the lake.

But my pain was not over as they were still a bit less than 10k to run. My gf sheered me up in Genève-Plage. Then N. Siorak ran with me in Bel-Air. The hardest part was the last 2k with a loop in Les Pâquis where I was running with someone that was going just a bit too fast for me. I sprinted to the end! ANd I finished my first marathon. It took me about half an hour to recover (my belly was not happy). And I did 5:09:18, next time better!

Sierre-Zinal

People who train marathon usually have a small downtime or depression after the event, as the main goal of the year is done, but I registered for an even crazier race this year after the marathon, so I could not stop training just yet.

Registration happened in April and because of the amount of people who wants to register, I needed to be ready on time. When the register button appeared, I instantly clicked and needed to wait 1 hour and 15 minutes to be able to register. I finally had the confirmation, so off to the race.

Sierre-Zinal happened on August the 9th, during a heatwave. Fortunately, my race started at 6:45am, so temperature was at around 20°C. I needed to take a train at 2am. When on board, I realized that I forgot my small trail bag that I had during Geneva Marathon… Unfortunately, I could not go back at home to get my bag and nobody could go back to my place to get it for me and bring it to me on time for the race. In the end, I found a way to bring most of my heavy stuff to the arrival, but used my bigger bag to go up for the first part.

The first part of Sierre-Zinal goes from Sierre to Chandolin. It goes up about 1500m so it is considered the first half of the race. The slope is very intense as soon as we leave Niouc. I practice this part with N. Siorak, so I knew what to expect. However, there is a little but important detail…

My mom was expecting to arrive in Chandolin at 9:55, with me leaving at 6:45, I had 3 hours to go up. However, when practicing, it took 3 hours and a half from Sierre train station, and we were walking and taking break. So there was a point during my climb that I needed to slow down, not running, otherwise I would have needed to wait half an hour in Chandolin to give my bag. Like in the hike, I could enjoy the view and the moment.

In the end, I waited about ten minutes, quick supply fill, giving my back, putting some sunscream and I was ready to go. The real race started now. I felt fresh after going pretty slow on the first “half”, but there was still a lot of kilometers to do, and the sun was hitting hard. Fortunaley, we were high in altitude ~2337m for the hotel Weisshorn.

It kept going up! Until finally, it went down, Zinal coming closer. I was feeling much better than the marathon as I was alternating between running and walking. But the hardest part for me was the sudden way down to Zinal. I should definitely practice it for next time. It was so steep and my legs were too sour that I could not go as fast as I wanted. Finally, arriving in the village, I simply sprinted with the slope and arrived after 7:21:40.

I told my mom I would arrive at around 3:30pm, but I arrived at 2:30pm. Like the marathon, I needed half an hour to be able to walk again. After a meal, we finally took the bus to bring us back to Sierre where the heat was waiting for us. You can find the video of my race here.

BIC Fest + awards

A few days after Sierre-Zinal, I took the plane to South Korea, to showcase Beach Slap at BIC festival in Busan (I wrote about it here). Before that, my gf helped me localize the game to korean, so Beach Slap became 해변의 귓방망이 (which sort of translate to “Slap to ear of the beach”). This title made it very successful, as the title is very funny in korean (everytime I tell the title, I get a big laugh out of korean players).

We got the E-sport Excellence Award which is rewarding multiplayer competitive game (and that’s me giving a slap to the public). It was the first award that we ever got at Team KwaKwa which was a first sign for us that we were onto something with Beach Slap. There is still a long way ahead before the release, but getting a recognition is always nice.

Korean trip

I enjoy some good time in Korea afterwards. Thanks to 6it full-remote policy, I could enjoy a half-work half-holiday trip. I went all around Korea, from Gangneug to Gwangju, Gyeongju and Jeonju, of course Seoul. I could buy a few second-hand games, update to the Nintendo Switch 2. The heat was often unbearable, but AC makes it livable, especially to sleep. I ate so much… I saw my first baseball match, went to the sea, did a small hike in Daegu, did countless hours in buses and trains. Looking forward for the next time.

Herofest + SAE convention + Stunfest

In October, we went to showcase Beach Slap at Herofest in Bern and in Rennes for Stunfest. I already wrote about it here. Seeing David Wise was a high point of this year, of course, it reminded me of Soup Raiders and I sohuld probably write about what I think made the project stop (in terms of design). We won a prize again, which surprised us again, but it means that we are onto seomthing with Beach Slap.

I had a week end of October when I took the train to go to Leukerbad, Koln, Geneva, Paris and Rennes. I like travelling by train, but this week was intense. I think what I really like with train’s travel is that I can just take my computer and start to code or write, which is harder for me in a plane. Also I can take a break and just look outside. Stunfest and SAE convention have something of nostalgia for me. I remember the campus in Koln the first year I went to SAE convention being a rookie and Stunfest around the same time when I was starting to showcase Splash Blast Panic. Those two events have a different taste now, we won the SAE awards this year and the talks were all about AI and Stunfest is way smaller in scope than back in 2018.

Graphics Programming Conference

I already wrote about it here, but what I really liked with this conference, compared to other conferences I went to, was that it was pushing my technical boundries. I want to try new things in computer graphics, but I also want to try new things in teaching! As the tech world is changing to more AI and CPU and GPU now adds NPU, I am also questionning how and where I should push my efforts. In the end, I am a game developer and I just want to make new games and sometimes also tell stories. So the new cool tech is only interesting for me from two points of view, as a teacher or a game developer, and both have different means and goals. In the end, I came back home with my head full of ideas.

Spelkollektivet

While my gf was going to see her family during the Winter Holidays, I decided to spend this period at Spelkollektivet, a community of game developers living in the Swedish countryside, sort of like an incubator of game companies. While the perspective of being with complete strangers for one week and half sort of pertrified me, I still decided to go, such that I could spend some time to work on my own projects: Beach Slap and Welcome at Houdini’s.

This was also the opportunity to get back to working out, as there was a gym available and I decided that I would go there everyday. I tried for the first time to run on a treadmill, one time with full incline and one time as flat surface. I did some sword practice as well, which was a lot of fun.

It felt good to be back at the gym, lifting some weights, pushing myself. As I did not need to focus on anything else than my games and the gym, I felt like in paradise. It even snowed.

I was afraid that I would mostly be on my own as I don’t like to mingle anymore. I think that came from my big trip to Japan in 2022 (some photos here). I spent there 5 weeks, mostly by myself and enough though solitude was hard, I kinda got used to be with myself, work on my things ad I feel frustrated when gets on my way. But more recently, I started to question myself and got to spend more time with dear friends, going out of my bubble (Spelkollektivet being one of those decisions). Finally, on the last day when departing, I had a few homies coming to say good bye, and I actually felt happy to have spent some time there. As I said to James: “I was productive and more happy to be at Spelkollektivet than at home.”

Next year?

So that was 2025, what about 2026? I plan to release a few games, Beach Slap being the main one, Welcome at Houdini’s and some other small projects. I think I finally pass the depression period after Soup Raiders. I love making games. I just spent a whole week and a half doing that in Sweden and I could have go on forever (but reality comes back). It will also be a year of change, I don’t know exactly how, but I want to try some things (like this blog here). I need to keep in shape, what is going to be my new objectives, marathon and/or trianthlon of Lausanne? We’ll see.

Conclusion

At the end of 2025, I felt lazy. I did not do enough sport (while I still did a marathon and a mountain race), I did not work hard enough (even though I have technically three jobs) or I did not improve enough. There is a point where I can’t push myself more than what’s possible, so I need to accept my shortcomings. Let me continue to try more for 2026.

This week, I went to Breda to attend the Graphics Programming Conference, thanks to SAE Institute. My goal was to delve into more advanced Computer Graphics before starting the module the week after.

Breda is a lovely city, south of the Netherlands, that you can easily access from Schiphol airport by train. Originally, I wanted to go by train from Lausanne with TGV and Eurostar, but in the end it did not work out with my schedule.

The conference is divided in three days, with very technical talks (which I love), some sponsored talks and some more “academic” talks. Sometimes, some talks are concurrent, but because they are all recorded, it is pretty easy to just go to the one that is most interesting for us. Overall, the quality of the talks is really high.

As a teacher, those were the talks that I was the most interested in:

• Getting to know Slang by Shannon Woods: I am more used to GLSL, so the very HLSL-flavor of SLang does not attract me by default, however the whole struct, generic, interface looks very promising for bigger games/engines.
• Root signatures & shader ISA by Wessel de Groot: Going a bit low-level would help me be on par on the GPU compared to the GPU.
• After the Tutorial: Where to Continue your Graphics Programming Journey by Mike Shah. I really liked how Mike diffirentiate the basics from the more advanced features regarding graphics and how he introduced the different abstractions one after the other along the graphics journey.

Those talks were directly impactful for me for teaching Graphics Programming to my students. I will definitely share them with my students when they are on youtube.

Of course, going to a conference is also a break in the usual day-to-day life and it allows to have the brain breath and find new ideas, so here are the resulting ideas that came out of different talks:

• A Decade of SEED: Lessons from 10 Years of R&D in Games: It made me think of research in the different areas of rendering, computer vision, game ai, physics, and animation. But also EA SEED is part of a big AAA studio and I was wondering what a research lab could look like for indie games. Currently, we mostly rely on Unreal or Unity or Godot (some still have the courage to use custom engine), but the sharing of custom tools and technology could really be improved and it made me think how I could help other devs around me (RGB conf was a try).

• Eras in mobile graphics: ARM is putting NPU in GPU and GPU will start to look more like NPU. Something in me dislikes AI, but another part of me is thinking how AI can help solve a lot of problems. Just maybe not at the price of stealing everybody’s work…

• A Beautiful Hell: Path Tracing in DOOM The Dark Ages: I really want to experiment more with raytracing and path-tracing, maybe try to find solutions at a smaller scale than DOOM, but a fascinating talk.

• Water Simulation & Rendering in Enshrouded: Very interesting approach to simulate and then render water. Now I want to play with procedural content generation and water.

• Battlefield 6: Pushing visual fidelity while optimizing for all hardware. Debug tools! I need to investigate how to make my like programming on the GPU easier. Maybe I can sneak ShaderToHuman in my projects.

• The aircraft of Theseus - Shipping X-Plane for 30 years. I really enjoyed this talk. It is very interesting to see how the team managed to update an OpenGL 2.1 engine with external plugins also using OpenGL 2.1 and updating it to Vulkan with Zink.

• Raytracing Voxels in Teardown and Beyond. Again a very interesting talk that feels closer from home for me. Using OpenGL 3.3 and now updating to Vulkan, what an achievement.

I really enjoyed the ranges of talks and expertises. There were a lot of AAA studios, but also AA and smaller studios with very different problematics to solve. What I think might be missing is the point of view of the students, seeing some student work showcase, as they are the future of our industry in the end.

All in all, I really enjoyed this second Graphics Programming Conference, learned a ton of stuffs, got inspired for a whole bunch of projects and I am ready to teach my computer graphics module next week!

This month was eventful for Beach Slap. First stop was Herofest in Bern. We bought a new TV that we needed to setup on the first day. After this littel rush, we could let the game play. I added a special expo mode in the game that automatically reset the game to the title screen, then after a little while shows a trailer, so I don’t need to manually intervene.

I also got the chance to have the booth right next to a stage where David Wise and his band were playing. David Wise worked on the soundtrack of Soup Raiders (that we unfortunately paused since then) and it was really nice to see him in the real life (instead that on skype). Here is a selfie of both of us:

I was sick most of the weekend, hiding behind my mask and surviving, but I could see the game getting a good reception. Between the game and the music, there was also an indie award. As I was too sick, I asked my colleague to go while I stayed at the booth. He came back with an prize:

With BIC Fest, that’s two awards in a row. I think that with Beach Slap, we finally arrived to an multiplayer arcade game that is not too weird and has a broader appeal (especially compared to Splash Blast Panic). There is still a lot of work to do, but I am looking forward for next year’s release and see the reactions of people playing it.

Later in the month, I went to Stunfest in Rennes, France. Usually, Stunfest used to happen in May. Funny enough, there was a Japanese player that, back in the day, said that he won Stunfest and when people argued his name was not in the winner’s list, he said that he won the fall-edition of the Stunfest, that did not exist. Well now it does! There have been a lot of changes since the first time I went to Stunfest to showcase a game. This year was a new beginning.

The booth was free, we were a lot of indies from all around France (except me from Switzerland). However, being a multiplayer game, I was not given enough space for 4-player so I was always a bit in the way. There was an evening where all the games were presented:

As nobody told me anything, I still went to see the awards, knowing that we probably did not win anything. I was a bit upset that nobody told me there was presentations about all games going on and I only realized while listening to all the presentations that my turn would actually come and it did. In the end, we did not win an award (two out of three is still very good).

Mandatory crepe photo:

This week, my colleague from SAE Geneva and I went to Cologne for the SAE Convention, a gathering of the different SAE in the world. Like last year for Frankfurt, I took the train early. I arrived in Cologne in the early afternoon to have a meeting with the colleagues from the other SAE.

I came at the SAE convention a few years ago (2016 if I am right), so I already knew the campus, located in the industrial area of Mülheim.

Here were the four subjects that I came to share:

1. Common projects: Adding to the 3rd year common project on Unreal with the game arts students, we started to implement a common project from the beginning of the 2nd year on Unity. The goal is to have the Games Programming students learn to work together, production tools and how to manage production on a less ambitious project, before switching to the main project with the game art.
2. Personal work time: Still a big seller of the formation, we had some exchanges with the staffs from Zurich on how their voluntary implementation went compared to our mandatory implementation. We see a huge increase in the quality of our students in Geneva derived from this initiative and each month we see the progress from the first to the last year.
3. Entrance exams: It is always hard to balance between the business want and the quality when new students apply for the formation. Our goal is to have students who know what they signed off for. Our discussion come to the idea of a programming introduction test, than an exam. Our goal is for everything students that start on the first day to know about the content of the next 3 years and to have tried programming beforehand.
4. Use of IA: Our approach is pretty simple. Unlike modern approach that would simply use AI everywhere in game development (at least this is what we are getting sold), our approch is more conservative. It is always important for us that the students understand the output of the AI and not just blindly copy-paste the code. So in the first year, AI is very discouraged (to the point of making the students explain or rewrite functions if necessary) and is tolerated in the second year (except during theory exam).

The next day, there were a bunch of conference at the Palladium, mostly about AI. Nothing mindblowing, we are trying to sell us AI as this revolution, but I see it more like an assistant or a helper currently.

What I was most interested in was the SAE Awards where my students were nominated again this year for the Game Production category with the game Ruby and the Lost Crystals (Play it on Steam!). And they won the prize (again)! I am very proud of their work, but SAE awards are just a internal award and now we need to win awards against other schools. Cheers!

Right after Busan Indie Connect, I spent some times visiting South Korea, starting from Busan:

Then I went to Gyeongju, the capital of the Silla kingdom back in the day:

Next stop was Daegu:

Heading back to Seoul to go to the Seoul Indies meetup, where I presented Beach Slap:

Afterwards, I went eastwards to Gangneung:

After a very long trip with several trains, I arrived in Jeonju:

I joined with my gf in Gwangju:

I visited the penguin village, named after the elders living there that look like penguins walking:

We went to see a baseball match in Daegu:

Then, we went to her hometown of Yeongju:

I even prepared some gimbap:

Before finally, heading to Seoul:

That was it for my trip to Korea. Still a lot of details that I could not put in this post, but looking forward to come back and eat all the food.