Making Video Games (Without an Engine) in 2025

Keep in mind that when writing your own "engine," you don't need it to be as general as possible to handle every possible kind of game. You just need it to handle your game.

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.

I keep saying that the engine is just that little runtime attachment dangling off the end of the asset pipeline ;)

(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)

At the indie studio I used to work at, we had some folks with engine experience. So, we rolled our own 3D engine and asset pipeline from scratch. But, we didn't have the budget for an editor. Instead we set up the asset pipeline to hot-reload everything. Meshes, scenes, materials and animations from Maya. Textures from Photoshop. Audio as a pile of WAVs. Scripting in Lua. UI layout in XML. Changing the asset files would change the game live.

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

Writing an editor from scratch is a lot of work. That's one reason why I would use an existing editor whenever possible. For example, TrenchBroom (Quake editor) + func_godot seems to be getting more popular among Godot users, and Tiled looks pretty good for 2D games. For game data management I've seen CastleDB (never used it though), which now seems to be integrated into Hide, a full-blown 3D editor.

Either way, once you get the tooling up and running, the next big step is actually designing a game and creating all the content. :)

> The real meat & potatoes is all the tooling and content and asset pipelines around the engine

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 have recently done an engine rewrite for my sequel game and I very much agree with this. In my postmortem[1], I wrote:

> 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

> 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:

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.

It really is a miracle that any video games get shipped at all.

> inverse kinematics and animation blending

Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.

> “boy, am I glad I didn't spend several weeks trying to code that up from scratch".

If your goal is several decades of a career as an independent developer (like OP), what is an investment of a few weeks for a) understanding a topic deeply and b) having source code that you deeply understand, 100% own, and can reuse across future projects?

I was like this in the past. Making my first 3D game: After weeks of implementing all input, object management, culling, model loading, math lib, gfx, normal mapping, SSAA,... I had 0% progress on my game.

However, for my fun hobby 2D projects, I still self roll without dependency in the web canvas. You could call the browser an engine though.

Also using an engine allows us to make progress on the project itself, rather than sinking major time into building infrastructure.

Reinventing the wheel isn't that fun for most people.

My graduation thesis was porting a particles visualization engine from NeXTSTEP/Objective-C into Windows 95/Visual C++, based on OpenGL, with samples like marching cubes.

This is a single bullet point on modern engines feature list.

animation blending isn't that bad. If you have a two poses represented as lists of quaternions and positions, all you have to do slerp between the quaternions and lerp between the positions.

FABRIK IK algo is a ~100 loc function.

>Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor of rolling your own, from a time-spent perspective

I once experimented with creating my own game engine. It took me about a year of building and learning along the way (through trial and error, with many dead ends initially). It featured lots of things you'd typically find in a game (3D rendering with all the bells and whistles, an adaptive UI framework inspired by flexbox, skeletal animation, a save file format, a smart object system, path finding, a scripting language, audio, physics, et cetera, et cetera)

Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.

Knowing every little detail about your game engine was certainly a plus. After the engine was more-less complete, adding a feature, however ambitious it was, took about a couple of hours at most. When something didn't work, I knew exactly what was going on.

However, after a year of building, I was somewhat exhausted, and all my motivation to continue disappeared :)

> But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction?

If you have enough game dev knowledge to make an engine...then it's seriously like a day to learn these things to begin to bang out a prototype.

They take a long time to master but if your goal is to work on the game its not in the same universe of turn around time.

I am not familiar with Unreal, but Unity is much faster than programming from scratch, easily 10x or more.

One obvious example is physics behavior, which you can add to your game in under a minute, but with your own engine you'd need a day or two to properly integrate an external library. All the internal state visualization that Noel's showing off here is already built in by default in Unity. It has nice tools to draw and modify bounding boxes, and in the rare cases where the engine's behavior isn't enough, it's highly extensible (using ImGui or Unity's Yoga-based CSS engine, which I prefer). Unity has countless features like this: a sophisticated particle editor, a high-level "write once, run anywhere" shader language with enormous amounts of complexity abstracted away, systems for streaming and keeping track of modular data, and much, much more.

In an ideal world, I'd want to write these things myself, but time ticks away and unfortunately I'd prefer to prioritize finishing games more quickly.

> Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction?

You've asked two different questions - how long does it take to properly learn Unreal or Unity, and how long does it take so you can have an idea and turn it into a game without friction? If you gave me a half baked idea we could be playing it in a few hours with both tools. Unity requires programming up front, but Unreal you can get well into "I can almost ship a game" (particularly if it's a single player game) with just blueprint.

Here [0] is a 10 minute video where someone prototypes a super hexagon style game in 10 minutes. Obviously, this isn't feasible without knowing exactly what you're building, but I think this shows just how powerful these tools are for building out these game ideas. There's very little unity specific stuff in there, other than components. Everything else is stuff that I would classify as "gamedev agnostic" - input handling, update vs fixedUpdate, vector math, sprites, etc. The prefab for the spawner is about the only unity-specific thing in that video and it takes up about 15 seconds of the 10 minute video. I'm a game developer (Unreal) and I'd wager I could put together a similar prototype in about an hour in Unity, give or take

[0] https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI

>On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea.

I would say its the exact opposite to that. For that genre, its best to roll your own engine, or pick something open-source. The list of problems that i firsthand experienced:

There are lots of features and options in the engines, but they are not all usable at the same time. One feature disables the other. You look at the list of all the nice things the engine can do, but then at some point you figure it can't do (or can't efficiently do) what you absolutely need. All those awesome looking graphics are not practically usable, simply not performant or not compatible to be usable.

There are features that only work in "baked" mode. You "bake" it in the engine editor, and there is no way of changing that at game run time. Unreal is the most limited in this, but Unity is not much better. Some game developers reverse-engineer Unity internal asset formats with a hex-editor, so that they can change feature behavior at runtime. At that point, rolling your own engine makes more sense. One example i saw was a developer reverse engineering the light probe group asset file, so that he could add a new light probe group at runtime.

Engine API's change drastically from version to version. All the code and scripts need refactoring, all the time. You run into a breaking bug, and the only solution is upgrading, but upgrading means breaking your whole codebase.

You need to go trough the engine's abstractions, and bad luck if that can't be done efficiently. An example of this: Unity HDRP applies screen-space ambient occlusion (among other effects). It applies the effect over the whole screen. If there is a third-person view of the character from close or first-person hands/weapons rendered, then even over that. That results in a white halo around the first-person hands/weapon, looks bad. In a custom engine, the solution is simple, apply the full-screen effect before the first-person hands are rendered, then render the hands without the effect. Its a matter of switching the order of a couple of lines of code.

The solution is github and the BSD/MIT/Apache licensed game engines and libraries.

I think there’s a misconception due to the large overlap between games, graphics, and physics engines.

Graphics are anything from rendering 2d, 3d, shaders, scene graph, animation.

Physics and related interact with the scene graph.

The game part allows for dynamic behavior and of course the game logic/triggers.

Add some ui, and resource management, abs lastly of course ai.

Creating your own engine with different architectures is indeed the best way to learn how/why an engine works. But alll the details that come with it. That’s really a lot and probably way too much for one person. You’d be surprised how much is in there (in unreal engine)

> Once your engine is finished

Most likely never?

Obviously understanding what `GameObject.Instantiate(myPrefab, Vector3.zero)` takes several orders of magnitude less than implementing all that is required to properly perform that, even for such a basic operation.

Imagine when it comes to 2D/3D physics, shaders, platform support, etc.

If your goal is to build an engine, build an engine. If your goal is to actually deliver a game, build a game.

From a starting point of having dabbled in making 2D games in the past it took me a few days of working through tutorials and documentation for producing assets to be the bottleneck in building a game in Unreal. In Godot I was at the point of being able to make terrible games within a few hours. The amount of lifting that modern game engines do for you is phenomenal, and I think anyone claiming they can write an engine from scratch quicker than they can implement a game with an existing engine is deluding themselves.

Exactly. If you want your game to look exactly like every other game on Google Play, complete with all the same, long, janky splash screens and rendering hitches and slightly screwy text rendering and random audio glitches, use Unity.

All that might be acceptable for an adware befouled "idle RPG" style game on mobile (and they're all that kind of game these days). But it really galled me that people were using Unity so heavily for VR. It's extremely difficult to get a Unity game to work well on the standalone VR headsets. To hit the performance targets required by the Meta Quest Store, you really have to rewrite large portions of the engine to get around the fact that Unity is a disorganized, single-threaded, allocation-happy mess.

If you want your game to be a quality piece of software, you can't start with a garbage as your foundation.

It’s also refreshing to see what IMO is a very smart selection of technology, when you see so many other people following hype (I’m reminded of the rust gamedev post the other week). C#, SDL3, and some other nice libraries. The thing is, it’s not trivial to get to the point of having enough experience and judgement to know what to choose!

When I start a new game I’m often paralised by the sheer volume of engines out there. When I first started making games all I had was GWBASIC…

> That was a great post. I had no idea modern .NET had hot-reloading built-in like that.

I fully concur, that was a great post. And on full time Linux, just incredible. Definitely it's given me the itch to try a few new things :)