Making a Game Engine + Editor

Every developer reading the headline thinks why, let me explain...

Monobit Engine, is what we have been fiddling with for a while and will continue so this year.

This is not official (technically), cause it’s very early stage.
We have been planning and building with the goal to make something that works great for us as a team. We have used Unity extensivly and tried Godot, and I use Unreal proffessionally as well on my day job. So my summary in general is that all engines are good and bad at their own things. The way we work is sometimes at odds with the engine, thats why we decided last year to actually give it a go on making our own and here are a few reasons why.

Reason nr 1

Its fun! Me as a UI/UX designer love a challenge and what larger challenge is there than actually making a program that focuses on efficiency and ease of use. This all is for internal use ofc and we dont have any plans currently to let others have access to it (yet).

Mockup of the editor view showing the different aspects of the engines panels. Note that this is early ideas and things dont nessesarily makes sense.

Reason nr 2

The power of our own choice. We decide what language we use (C#) and what renderer we want to implement (Flexible, but currently DirectX).

Reason nr 3

Integration of LLM use for automated bugtesting and game balancing reports is something that can be integrated into the engine in source and we have used a little AI to help out on actually sorting libraries and helping out on some UI widgets. For example I wanted a color wheel for the color selection widget and to add sliders etc. Instead of kristoffer manually having to find the right library and writing it out by hand the Ai spits out something almost final and then Kristoffer cleans it up and adds the stuff that works, saving us some time in the process. To estimate roughly we have gained 50% efficiency on the code side thanks to this.

This is what color picker looked like after integration.

Reason nr 4

Bloat, Lots of engines contain bloat and we just wanted to integrate the features we wanted and build upon that once we move on. There is a game we are working on in planning stage that serves as a base feature requisite. With bloat comes also optimization control where we want to be able to tewak and change things without being held down by the engine. Last titles we released became quite heavy and hard to manage and the way we want to work doesnt really jell well with whats out there. (maybe godot but it has its flaws too)

Mockup of how timeline will work. Animator asset get fed into the component then in the timeline menu you add what animations that are played within this. Link is set if you want to link to another animation like in a state machine with dependency. No dragging of nodes etc. Transitions are set for blends etc.

Reason nr 5

We acutally have done it before! Kristoffer has knowledge in systems development and engines in general so this is pur joy for him. Kristoffer and I have used our own engine before on Acaratus where we did everything from scrath. This tought us a great deal in what goes well and bad with building your own thing. Sure it takes longer and so on, but personally I want something that we own rather than hoping on someone elses creation.

Acaratus that we developed in our old engine Brimlight.

---

SO now what?

Well we continue having meetings and I’m still updating the workflow documentation because it’s a lot to keep track of. But we have the basics down and are ready to start getting into adding all components, assets and properties needed to make a menu to start with. The 3D will come as well together with shader handling.

Subscribe to this newsletter for more insights into game development. I will try to post as regularly as possible about the process and how things are designed in the editor.

For more info about our company check out

https://nodbrim.com

---

Check out my work