When working on your own engine you also feel as if 90% of the time is spend on user interface creation if you actually want to have an visual editor.
People don't realize that they will spend 95% of the time on the engine and 5% on the game.
Which is ok if you don't want to make a commercial living out of it.
But unless you are making a game with extremely specific needs (eg Factorio) using your own engine will probably kill you commercially.
Keep it super simple. Or that game will never come out.
So a day on their game wasted over efficiently removing an item from an array of 20 items every 5-10 minutes.
> If I optimize this, how much time is it going to save the whole world? What will be the sum of time saved by everyone who will ever run this code? Is that less than the time required of me to do the optimization? Then, don’t do it!
That question was relevant quite often.
The big optimizations though really mattered. And, required planning before initial implementation to set the system up to be optimizable.
Reminds me of when another subreddit was mocking some legacy code (I think Motorola? Some mobile device stuff) for using bubble sort. Meanwhile, the sort probably wasnt on more than a fee hundred items and the mobile embedded is constrained for space. Bubble sort is easy to read, write and has O(1) space. Performance isn't a concern at the scale being worked at. We're talking maybe microseconds of difference.
It's not necessarily a bad thing that acedemia focuses on theory. But we keep using school to put a square peg into a round hole and wonder why students are so unprepared for actual production.
It's ultimately the company's fault. If you want certain skills, you need to train for it. Your processes aren't public, so you can't just expect candidates to magically know what matters to their role.
----
now acedemically: the answer is to swap an item to the end and reduce the buffer size. I don't think that's taught in acedemia either, but that's a trick you learn on the job. When and if you do need it.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Sometimes the best way to tackle that 3% is upfront when you're deciding on your system architecture.
No - spending a lot of time making tools you don’t need is the problem. You can write your own engine and leverage existing tools.
The key to making no engine work is to make only what you actually need.
I have limited experience scripting Blender, but there is a BPY API to add custom panels, so adding metadata to “entities” and simplifying the export workflow is probably feasible to the point it will be very close to an editor.
And of course since Blender is used for movies, it does scenes well already.
Really depends on the team size, composition, and game. If you have designers on the team who aren't dedicated programmers, I don't think blender will cut it for them.
The demands of a movie differ from a game which is why I'm a bit doubtful. But nothing is impossible to achieve with peope planning, so I'm not dismissing it.
At least when I last tried Blender the UI was a lot harder to use than something like Unreal or Unity editor.
I'd probably look at the Godot editor first.
But I do like the idea of trying to find an existing editor in the same domain and modifying that rather than building from scratch.
> Most people think of a “game engine” as code that is shipped with the game executable. However, that’s only half of it. The other half, which I’d argue is more significant, is the code that is not shipped with the game - level editors, content pipelines, debugging/profiling tools, development workflows, etc.
Writing tools is arguably more boring and tedious compared to writing an engine, and that's where lots of "making a game with custom engine" type of project grinds to a halt
[1] https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
(and the same is becoming more and more true for shader compilers vs 3D APIs - all the interesting stuff is happening in the shader compiler, while the 3D API is just there to kick off shaders and feed them with input data)
Either way, once you get the tooling up and running, the next big step is actually designing a game and creating all the content. :)
This depends a lot on the type of game that you create. For example, if a lot of content is procedurally generated, for example the map editor can be simpler, and you need less kinds of data formats to import. Also, some genres require a lot more "external content" than other genres. Even if you keep the genre constant, you will find games where the "value proposition" lies more in the game engine vs those where the "value proposition" lies in the assets.
In particular for indie games, you can be much more flexible on how you structure your game compared to AAA titles.
I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.
Although come to think of it, you could probably do most of that in Blender, so maybe such an thing already exists.
(1) Build a generic and extensible UI tool which at the core is a 3D scene viewer, object outliner and an asset browser (similar to how VSCode is such a tool for 'mostly text data' for 3D scenes). Implement anything else as engine specific plugins - Blender can be that tool, but it would be important to do a complete UI overhaul to get the modelling and animation features out of the way.
(2) Integrate the editor UI right into your engine, which is quite trivial with Dear Imgui - the tricky part here is that game state data should either be organized for editing, or for runtime performance. Mixing both isn't a good idea (unless moddability is a priority).
About a decade ago I would probably have opted for option (1), nowadays I tend towards option (2).
Unity, Godot, Unreal, Defold and others kind of get away with it, by having editors that work for most game types.
But also: a tool doesn't have to cover all bases, especially a free/FOSS one.
I’ve been doing Game Dev for the better part of 15 years now which is almost all of my career. I’ve been almost solely focused on building Tools and almost always building Editor internals and the interactions with the engine/assets systems.
There’s just so so much nuance to how editing works. You also want to be as close to how the engine will render so there’s also the need to either embed or have an api on your game to edit content live. People need hot reloading, people need things to look and act correct.
Just rendering a model accurately can be a challenge. Don’t get me started on animations
For example for 2d games it is possible to use Tiled as a level editor if you build your game (or some tool) to parse out tiled's file format and turn it into in-game levels.
A more general purpose editor in line with Unity or Godot's that includes the ability to attach functionality to everything would be much harder since the specifics of that will be much more engine specific.
I see one problem (there very likely exist a lot of others) in the fact that a lot of frameworks and engines are "deep ecosystems" that take a lot of effort to get deeply into. Once inside the engine ecosystem, a lot of concepts are "very integrated/intertangled" (though not necessarily in the "best possible way").
So, a lot of implementation time will have to be invested for each individual supported engine so that the editor properly integrates with it.
I would really love something like it.
And there are plenty of libraries and frameworks that can be pulled in to handle things like UI, compression, etc. The OP uses imGUI which is an excellent, small UI library for making in-game editors.
When choosing to go down that path you're not making, "an engine for all games." So there is a ton of work you're not doing.
And every external libary you do pull in, to ease some of the workload, is just waiting to go abandonend next year. So instead of focusing on release by that time, you will now focus on reinplementing that needed functionality that just stopped working.
There’s a spectrum of options here.
That makes no sense. A library being abandoned doesn't mean it suddenly stops working.
Using abandoned tools either means you're very sure all use cases are covered, or that your own engineers are willing to hack around should it not be sufficient. And I think anyone who works with legacy code knows that navigating already written codebases without guidance can take just as long as whipping up a custom implementation.
The web evolves. Lots of features get deprecated all the time and sometimes removed or change behavior in a significant way.
Unreal Engine is really the Unreal Tournament/Gears of War engine at its core.
Good engines are those that are focused on what the game needs. YAGNI/KISS apply here too
Then we added "State machines as Lua exported from Excel". Rows are states, columns are events, cells are code to execute given a state+event combo. I've done this a few times. It makes huge state machines manageable.
Our games were very stats-heavy and our designers liked Excel. So, a new thing we added as "Dynamic data sources as grids of Lua exported from Excel". So, fill out Excel sheets like normal. But, instead of Excel script, every cell is evaluable Lua code. Strings, numbers, bools, functions are all values in Lua. So, a cell might contain a number. Or, it might contain a function checking the contents of two other cells and optionally triggering an event on some other object.
We shipped multiple games on a single executable using this system. Artists could lay out 3D scenes and 2D UIs with hooks for the Lua to control it. And, the designers could populate scenes and UIs from Excel dynamically according to the state of the game. The programmers mostly worked on game-agnostic features in C++, and the heavier side of scripting in Lua for game-specific features.
Aside: Lua is being so dynamically typed makes it not great for large-scale software engineering. But, https://teal-language.org/ might be a good TypeScript-For-Lua. I haven't tried it. Also, are there any Lua debuggers newer than the ancient https://github.com/unknownworlds/decoda that require zero integration? Decoda just need a pdb of your executable and it can automatically debug any scripts passing through the Lua library.
Eventually, we switched to Unity for corporate reasons. As a primary implementer of our custom engine, I think the switch was overall a good thing. Our games had started to outgrow what our little engine team could deliver. The artists reported they felt slightly less productive working in Unity's editor. I switched roles to finding and working around the undocumented bugs in Unity that we ran into. Then later finding which bugs had been fixed without being mentioned in the release notes so I could delete my work-arounds. It was a very boring couple of years until the company burned to the ground because of the same corporate reasons that lead us to switch to Unity :P
Your custom engine sounds interesting, though. I can recognize some thoughts ..
---
Decoda uses your PDB to locate the Lua C library within your .exe and the Win32 API CreateRemoteThread to inject the code into your process to hook the Lua API.
I was the tools lead for "Superman Returns: The Videogame" (the PS2/X630 Superman game, no the N64 one). We did the same thing. All of Metropolis was essentially "modeled" in Maya with plug-ins handling importing and exporting between that and the in-game format.
It was an open world streaming game and it would have killed an artist's machine to try to load the entire city into Maya, so the plug-in would let an artist pick which chunks of the city to load, load them in, let them make changes, and save the results back out.
It worked out fairly well.
Scott Bilas also documents doing something similar for Gabriel Knight 3, one of the “grandfathers” of data-driven engines and bit of an influence on ECS.
Instead of excel however it was comma-separated text files that shipped with the game. During development could edit the files locally and reload the data without recompiling.
Since we’re in a web heavy forum: An sql database and a web editor would also allow for a distributed workflow.
Ok maybe a sheet is fine for a state machine if you don't care about visualizing transitions... Why reference cells when you could have named functions in a source file that could actually parse the syntax? That file would be trivially merged. You want to be loose on types so I guess its fine but you could actually have type safety and linting all the other language features and tooling if you just used a file full of named globals.
The mind boggles
In systems where we used this it was common to have 100+ states x 100+ events. Visualizing that would have been fun, but not useful.
One implementation had layerable sheets. So, you could define a base state sheet and multiple overlay sheet that the game could enable dynamically on major changes.
Within each event column there would be long, broken up runs of "do the same thing" for runs of states. So, you could define a chunk of code in a cell below the main table and reference it in the runs and it would show in the main table.
Almost all functions were trivial. 1 or 2 statements. "Modify a value. TransitionToState X". There would be hundreds of these little snippets in a sheet. Naming each one would double the complexity for no gain. Let alone having function signatures. They'd all be `void randomName(event)`. And, Lua's a dynamic language. You aren't going to get much error checking in an IDE. Better to just keep everything local to the sheet rather than flipping between Excel and VSCode.
And, in the implementation discussed above, most of the cells were full of numeric/string values or references to assets.
https://github.com/luau-lang/luau/ https://github.com/sssooonnnggg/luau-debugger
I'm working on an engine based in C++, Luau, and OpenGL - started almost 2 months ago. I aim for it to me MIT license open source, but it's too early for sharing. When it is, I do plan to post a show HN with the Github link.
> The real meat & potatoes is all the tooling and content and asset pipelines around the engine.
When people talk about engines they often include the asset pipelines and editors by default. Engines today are not just a main loop + 3D API calls. Very few devs will say we're going to use Unity but only for its rendering code.
(Of course I'm not implying as long as you use Unity/Unreal you'll never need to write your own asset tools.)
Already the biggest market is small games on tablets/phones
Now making those games is becoming exponentially faster and easier
Roblox, allowing people to quickly create their own games, was already a huge hit. Now that experience is getting supercharged with AI
The article is about creating video games without an engine, and the top comment is about what is hard about making video games
My comment is about how all of that is changing right now and how the public is reacting to it
You can either use chatgpt or something more basic like openjam.ai or something specialized like rosebud.ai
Maybe the people at rosebud.ai have been doing what you are suggesting to build their platform
And topology isn't even the hard part of asset production. Animating is the next big hurdle after that.
The best indie combo is a programmer plus a designer/artist in my opinion.
Alternatively, you can spend a very long time iterating solo. Most don’t have the runway for this.
This is also why big studios produce technically impressive games with mechanics seen thousands of times before. The production risk is much lower for “make spectacular assets” than for “come up with a novel game mechanic”.
https://github.com/raould/pn0gstr0m https://github.com/raould/sheepgate
The sum of all those parts IS the actual meat of the engine imho.
People mistakenly assume that rendering something and having a Dear ImGui frontend constitute an engine but it's only the tip of iceberg. Actual real world issues, productivity concerns, getting shit done is the meaningful work.
Engines are the easy part.
The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement:
And this is just a small sample of all the features and things that need to be done in order to be able to leverage the engine part.When all this is done you learn that the actual game engine (i.e. the runtime part that implements the game's main loop and the subsystems that go brrr) is actually a rather small part of the whole system.
This is why game studios typically have rather small teams (relatively speaking) working on the engine and hordes of "tools" programmers that can handle all the adjacent work that is super critical for the success of the whole thing.
[1] https://github.com/ensisoft/detonator