The story behind a new game engine project.
If you’ve been around the Blender Game Engine community for a while, you may have heard the name Nyx mentioned recently, or maybe not, lol. I haven’t really written anything about it yet, so this is probably a good time to explain what it is, where it came from, and why I’m working on it.
The short version is that Nyx is a new game engine project evolving from the BGE → UPBGE → Range lineage.
It is not being built from scratch, and it isn’t simply an attempt to create another fork. The idea is to take an existing foundation, understand it deeply, improve it deliberately, and eventually take it in directions that make sense for the project.
But that’s the short version.
The actual story is a little more accidental.
It started with a new PC
I wasn’t planning to build a new game engine. I just had a new working PC.
That’s it. 😅
I wanted to continue using Range 1.6 Rev 2, an engine I’ve been working with and experimenting with, but when I tried to run it on the new machine, things didn’t work the way I expected.
At first, this seemed like a fairly normal compatibility problem. New hardware, older software. Maybe a graphics driver issue, maybe OpenGL, maybe something related to the build, or perhaps something more specific to the hardware.
There was actually a workaround. In the NVIDIA control panel, I could enable a compatibility mode and get the engine running.
So, technically, the problem was solved. Except I wasn’t really convinced that it was.
If an engine only works correctly after forcing a compatibility mode, what exactly is happening underneath? Is the engine actually using the graphics hardware correctly? Are we losing access to capabilities that the newer GPU provides? Is the compatibility layer simply hiding a deeper problem?
I didn’t have enough evidence to answer those questions and I didn’t want to simply assume that “it runs” meant “it works correctly”. That was the point where I decided to stop looking only at the settings around the engine and start looking directly at the engine itself.
So I opened the source code.
I didn’t know it at the time, but that was the moment the direction of the project started to change.
A little bit of history
To understand where Nyx comes from, it helps to understand the family tree behind it.
The story goes roughly like this:
Blender Game Engine
↓UPBGE
↓
Range Engine
↓
Nyx Engine
Each project represents a different stage in the evolution of the idea of using Blender as a foundation for game development.
The Blender Game Engine provided the original foundation. UPBGE continued developing that idea and brought its own improvements and direction. Range continued that lineage with another set of goals, including cleaning up and improving parts of the inherited codebase.
Nyx is the next step I’m exploring from there.
That history is important because Nyx isn’t trying to pretend that everything before it doesn’t exist. Quite the opposite. A significant part of the work is understanding what has already been built, what is worth preserving, what needs improvement, and what eventually needs to change.
Then I opened the source code
This is where things got interesting because when you’re trying to understand why an engine doesn’t work, you quickly discover that the problem may not be where you first expect it to be.
A setting in the interface may be stored somewhere completely different. A value may pass through several systems before it reaches the renderer. A rendering problem may actually originate in the runtime. Something that looks like duplicate code may exist for compatibility reasons. A piece of old code may look unnecessary until you understand what depends on it.
The deeper I went, the more I realized that simply changing things until the engine worked wasn’t going to be enough, I needed to understand the codebase and once I started doing that, the original problem became almost secondary.
From debugging to archaeology
Range has a long history behind it, and that history is visible in the source code. There are systems that have evolved over many years. There are old assumptions, compatibility layers, pieces of legacy behavior and relationships between subsystems that aren’t necessarily obvious from reading a single file.
Eventually, investigating the engine started to feel less like ordinary debugging and more like archaeology.
The question changed from:
“How do I fix this?” to: “How does this actually work?”
That second question turned out to be much more interesting and it also led to an important rule that has become part of the way I approach Nyx:
Don’t fix what you don’t understand.
That doesn’t mean every change needs months of research. Sometimes the answer really is simple. But when you’re dealing with a large, interconnected system, changing something based on an assumption can create a second problem while apparently solving the first one.
So instead of guessing, I started trying to collect evidence.
Following the data
One of the most useful things we started doing was tracing how information moves through the engine.
A seemingly simple property can travel through several layers:
UI ⇒ RNA ⇒ DNA ⇒ Runtime ⇒ Renderer ⇒ GPU
If something is wrong at the end of that chain, the temptation is to immediately blame the renderer. But what if the value was already wrong before it got there? Or what if the renderer received the correct value but another system changed its state afterward?
Following the actual path of the data makes those questions much easier to answer.
This led to a series of focused investigations into different parts of the engine. Some were small. Others became surprisingly deep. We investigated shader binding, renderer state, overlay behavior, draw types, armature matrices and synchronization between different parts of the engine and with every investigation, we learned a little more about the system we were working with.
The investigations became a methodology
Eventually, I realized that we were developing a process of our own. Rather than making a large change and hoping it solved the problem, we would start with a specific hypothesis, design the smallest experiment we could, add just enough instrumentation to observe what was happening, collect the evidence and then document the conclusion.
We started calling these focused investigations Micro-MISILs.
The name is intentionally a little fun, but the concept is serious:
Hypothesis
⇓
Minimal experiment
⇓
Instrumentation
⇓
Observation
⇓
Evidence
⇓
Conclusion
⇓
Documentation
The idea is to reduce a complicated problem into a series of questions that can actually be answered. Sometimes the hypothesis is correct, sometimes it’s completely wrong but both results are useful.
In fact, discovering that your original assumption was wrong can be one of the most valuable results of an investigation.
Documentation became part of the project
As the investigations accumulated, another problem became obvious because we were discovering things that weren’t necessarily written down anywhere. If we found an important relationship between two systems, we needed to record it. If we made an architectural decision, we needed to remember why. If we tried an approach and rejected it, that reasoning shouldn’t disappear.
So documentation became part of the engineering process.
This eventually led to investigation reports, Micro-MISIL traces, Architectural Decision Records, synchronization contracts and other documents that help preserve not only the final decision, but the reasoning behind it.
This is especially important for an engine with a long history because the Code tells you what the computer is doing and documentation can also tell you why we decided to keep doing it that way.
Somewhere along the way, Nyx appeared
At some point, I realized that we were no longer just trying to get Range running on a new PC, we were building a much better understanding of the engine itself.
We had a codebase with a long history. We had started mapping parts of its architecture. We had a methodology for investigating problems. We had begun documenting architectural decisions and identifying areas where the engine could evolve.
And eventually the question became:
What could this foundation become?
That is where Nyx started but not as a grand plan nor as a decision made on day one. It emerged naturally from the investigation.
So, what is Nyx?
The simplest answer right now is:
Nyx is a game engine evolving from the BGE ⇒ UPBGE ⇒ Range lineage, with a focus on understanding the existing foundation, improving it deliberately, and developing a modern architecture around it.
That probably sounds more serious than the actual beginning of the project but remember, this all started because I couldn’t get an old engine to run properly on a new PC. 😂
The compatibility mode gave me a way to run it, but it also raised a more interesting question: was I actually running the engine the way it was intended to run on the new hardware?
I didn’t know, so instead of accepting the workaround as the final answer, I decided to look deeper and that turned out to be a very good decision.
What Nyx is — and what it isn’t
Nyx isn’t an attempt to rewrite everything just because the code is old. It isn’t an attempt to compete with every major commercial game engine, and it isn’t about blindly following the future direction of Range.
Range is the foundation we’re working from, not a roadmap we’re required to follow and it isn’t about throwing away the history of the engine and starting over because there is a lot of valuable technology and knowledge in the codebase we’re inheriting.
The challenge is figuring out what should stay, what should change, what should eventually be replaced, because sometimes legacy code is technical debt, sometimes it’s compatibility, sometimes it represents behavior that users still depend on, and sometimes we simply haven’t understood it well enough yet.
So the rule is simple:
Understand first. Change second.
Why write about it?
Until now, most of this work has happened behind the scenes.
Some of it has been discussed privately, some of it documented internally, and some of it has already started appearing in conversations with people interested in what we’re doing.
But Nyx is becoming a real project, and I think the process is worth sharing, not just the finished features. I want to write about the investigations that lead to them, the things we get wrong, the things we discover, the architectural decisions, the experiments, the problems that turn out to be much harder than expected, and the moments when something finally makes sense.
So this blog will become part development journal, part engineering notebook, and part record of the journey.
Some posts will be technical, some will be about architecture, some others will probably be about mistakes.
And hopefully, some will be about things that actually work. 😄
This is only the beginning
There is still a long way to go, there are renderer systems to investigate, legacy systems to understand, architectural decisions to make, and new systems to design. The material system is already becoming an important part of the project, and there are plenty of other ideas that will have to wait until the foundation is ready.
I don’t know exactly what Nyx will look like years from now and I’m actually okay with that because the project didn’t start with a perfectly defined destination, it started with a question.
Why doesn’t this engine work properly on my new PC?
I opened the source code to find the answer, then I kept digging and somewhere along the way, that investigation became Nyx.
Welcome to the beginning of the journey.
Leave a Reply