After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious.
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:
- importing data from various sources and formats, textures, audio, model files such as gltf, fbx, animations etc etc.
- editor app with all the expected standard editing features, cut, copy, paste, undo, redo, save, delete etc.
- all the visualizations and operations that let the game developer use the editor to actually create and manipulate data, entities, animations, scenes, audio graphs, scripting support etc. etc.
- all the data packaging and baking such as baking static geometries, compiling shaders, resampling and packing textures, audio, creating game content asset packs etc
- etc etc.
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.
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)
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.
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.
The library would continue to work but may no longer be usable if other dependencies require a later version of "n" that the abandoned library is incompatible with. Ruby or Python runtimes are the classic example.
Support for any studio larger than a few people is the most important part of 3rd party tools. If (and inevitably, when) a tool has a bug or can't do something you need, there's reassurance being able to tell someone else to fix the problem.
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.
Definitely, it’s a trade off. Pulling in dubious dependencies can be a risk. Might be worth writing your own library or forking the dependency and vendoring it in your source.
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
> 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.)
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. :)
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
> 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.
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.
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 usage of Excel is so hilariously cursed I can't stop thinking about it. Its just raw memory address look ups with extra steps. How did you merge the Excel file? Did you actually have source control on this?
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.
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.
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.
There's the Local Lua Debugger [0]. I don't know how it compares to decoda, but I experimented a bit with this debugger last weekend and it seems nice enough - well integrated into VS Code.
The magic of Decoda is that you can download the debugger and immediately start debugging your existing program with no modifications. No libraries. No sockets. No changes at all.
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.
>
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.
> 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:
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.
When I was a game dev I spent way more time on tools than on the engine. Those days of small teams are gone now, so at least in a professional setting you are likely to be able to concentrate on the engine while some other person has to build the editors.
I somewhat agree. Good game design requires a great idea, but more than that a lot of iteration. If you are working solo you need to hold the implementation and design in your head, which is incredibly difficult. Iteration is slow. You need someone to bounce ideas off of.
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”.
Impossible but necessary. It's the big difference between an engine programmer and an indie dev. The latter needs to wear multiple hats to get something out while the former can specialize and work within a team of other specialists.
Word! i've done some ground-up 2D games with no engine library. So i hand-rolled resources, frame rate, collision, simple physics, etc. One has no graphics assets. Another other does.
> 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.
The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making. A 2D pixel-art platformer, a multiplayer FPS, a top-down strategy sim, and a puzzle game are all going to require completely different types of assets with unique design requirements. You’d need an all-singing-and-dancing tool that probably wouldn’t be as good at any one thing as the existing specialized tools, FOSS or otherwise.
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).
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.
Some of the other commenters have pointed this out. But this just doesn’t quite work.
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
>
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.
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 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.
Even without scripting Blender, GLTF is a "scene" format. GLTF files hold information about models, textures, lights, etc... So you can create your scene then import straight into your game with GLTF (open source, super common).
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.
Yes, but most artists can't script. The scripting is for tech artists or programmers to build tools/pipelines on top of Blender.
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.
Visual editing is how all UI is designed. It's not a waste of time. Visual editing is the primary way to prototype, which means it's heavily used at the beginning and less as development goes forward. Projects have some process to translate the prototypes into scaffolding UI in the Editor, then modify with state where necessary. This pipeline is common across all types of software.
Sorry, I thought the context was clear given the parent. Making your own visual editor is a waste of time when ones exist that will output a format you can simply put into your game.
Just the other day on reddit I saw someone asking about efficiently removing an item from an array for the game they’re working on. It became this whole CS debate and then someone asked how big the array is and how often do you remove items. The OP responded that it’s just a list of levels in their game, so not more than 20 items or so and is modified once every 5-10 minutes…
So a day on their game wasted over efficiently removing an item from an array of 20 items every 5-10 minutes.
I used to make 3D engines and asset pipelines professionally. High performance really is critical in both. So, I’d have to check myself frequently:
> 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.
Really highlights the divide between industry and acedemia.
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.
100% of hobby game devs do it as a hobby. The learning process is the fun part. Which is also why 99% give up on their game when they see more learning potential in another area.
I think you are missing the point. The larger the scale is, the more things may be optimized and the more you need to be careful to focus on the important "3%". That said, it doesn't hurt to analyse in advance which parts might be critical and steer the architecture based on those observations.
Not saying it's a lot less work, it's still a ton of work, but you could always build your tooling around a DCC application by either extending it with scripts or modifying or attaching parts to it like Blender, Maya, etc. Maybe even flat out game engine editors like Godot, Unity, Unreal to build stuff and export out to be used by your own engine.
Until AI can actually generate proper topology for meshes, I'm negatively worried about any Vibe coders flooding the market anymore than the market already is. The code is the least valuable part of a game in the eyes of a consumer.
And topology isn't even the hard part of asset production. Animating is the next big hurdle after that.
Even if you vibe code a game engine your best llm will need to do the work of world class technical team of like 12 people, you’ll need to get 10-20 teams to be able to find that dataset. Each run costing a few million usd.
Not sure what that use case is. Why would you need all of that? As an individual, if you are just trying to build a basic game with your kids you don't need to build a whole engine nor a world class technical team or a huge dataset
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
This is basically what I did a couple years ago [1]. SDL2 and a bit of C++ to create a "sprite" class. Some collision code in the sprite class...
If you want to call what I added an "engine" it was more like a pedal-assist bike.
Too often I find "engines" end up driving the project/game. That is, you end up writing the game to the engine. It's why I've avoided Unity, etc. — high-level engines like that seem to guide you to writing the same game everyone else is writing — just with different assets.
Never mind you spend too much time, in my opinion, learning the engine and not getting the game written. To be sure there was a learning curve just pulling in SDL, but the curve was slight and it seemed more universally useful to know SDL as it can be employed in other cross-platform projects I might undertake — not just games.
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.
The more unique and niche your game is, the more true this is. Stumbling around Unreal's horrid UI for 3 months just to realize that the thing you want to do is barely even possible due to how general and off-the-shelf the engine is, is not a good experience. 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 also believe that even if it's not always the most efficient thing to do, placing limitations on yourself by using a custom-made specialized engine makes the creativity really flow, and your game, even if not the most advanced, will be a lot more unique as a result of that.
>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 :)
> 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.
Not necessarily.
You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).
Feels like fiddling with snapshotting raw C++ memory is a can of worms (you listed some of the pitfalls yourself). Most of my snapshotting happened at the scripting runtime level, where everything is well-defined and well-understood: I manually snapshotted the VM's heap memory, the green threads' stack memory, the current instruction pointer of every green thread etc. I could safely validate those snapshots without segfaulting on a corrupted savefile, because it was a well-defined file format. The same code worked both as a time-travel snapshotter and as a general savefile format.
I think this is dangerous and can lead to remote execution attacks:
>The snapshot could even be exchanged over the network, assuming the receiving side has the same endianness, the same pointer size, is running the same binary, and can mmap the same memory location.
For physics, I needed to restore all those remembered motion vectors; for audio - current playback time, etc. Same as yours:
>The rest of the memory (the textures, the 3D models, the audio, the UI, etc...) should be allocated by your usual non-snapshotting allocator"
> 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)
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.
At this point using any engine instead of unity is better. Unity has demonstrated time and again that they cannot be trusted and that you cannot build a game (or business) around them.
Sometimes you have to do business with counterparties you don't trust. It's not mature or practical to take an "all-or-nothing" approach while the engine has virtually no competition for many classes of games.
I mean I’ve been using Unity since 2008. I do trust them to be around more than most other tooling/saas companies? Even if they have mode some unsound business decisions
Do you have any developer retrospectives around this? Plenty of my favorite games ever made were made with Unity, I wouldn't call those games failures by any means (Cities: Skylines, Overcooked are immediate examples)
The tech is fine, it's more that the last few years has shown some instability over retroactive license changes, questionable acquisitions, and general sentiments over years of seemingly abandoned support in key subsystems.
At least as far as platformers go, physics feel is a crucial part of the whole experience, and outsourcing to an engine has a good chance of making your game feel cookie-cutter.
> I am not familiar with Unreal, but Unity is much faster than programming from scratch, easily 10x or more.
With the caveat that the editor for Unreal is massive and getting it running requires more resources than Unity, Unreal's Blueprint is a great way of writing gameplay logic. It's accessible to people who don't know C++ or C#, and is a really nice abstraction for async/event driven code. It's a really good place to start with IMO.
>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 you'd probably want a different render layer with different post effect settings so your weapons can have post-processing as well. I think you can do this in the editor with gui configs instead of changing code.
I'm pretty sure all of SRP is in C# and is "open source" as in source available and editable.
The problem with GUI settings is that the result is not apparent, and there might be side effects. I do not find spending half day on trying out setting combinations as productive work.
I have looked into SRP and i do still consider that as an option, and also replacing the shaders. But i have doubts regarding the SRP, for example i have looked at the code that sorts lights in Forward+. The individual light calculations are not much, but its still done trough the job system. I imagine if there are hundreds of lights, then that would make sense, but for 2-5 lights, it seems like a waste. So it might be optimised to scale, but not for my case.
Is the effort of replacing the SRP worth it, and is the performance comparable to putting together/reusing an engine in C++? It is also a bigger commitment, as it needs to be coded on a different level and in a way very specific to the engine. Better than having to reverse asset file formats, but still very specific to the engine.
> 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
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.
Games like Antichamber do non-euclidean space and rendering in Unreal (3). Enera (an upcoming action game) manages time rewinding (a la braid), in Unreal. Superhot is Unity, etc.
The best tool is the one you know, even if your vision is weird or niche. At the end of the day, you can always ignore all the bits and pieces unity gives to you and just write custom logic in your MonoBehaviour scripts and use it as a platform toolkit, input handler, content pipeline, scriptable editor, and renderer. There's a lot to be said for the features you get from that especially in the long term as you said.
I think my point was more that if your vision diverges heavily from the "normal" flow of those engines, sometimes it's just less friction to build your own
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)
There's a lot of nice things you get for free in a big engine that are a hassle doing it yourself. Esp with the unity store etc.
I love LibGDX for personal projects but for serious development where deadlines matter having stuff like dialog trees, UI, etc. that just work out of the box and have the edge cases polished is Very Nice.
And ofc, cross platform with consoles is way harder rolling your own and that's often a big deal.
That sorta thing is why Slay the Spire switched to Unity/Godot for the sequel
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.
I can have an engine ready for you that allows you to render arbitrary 2D sprites, levels of them, etc. or whatever in a day. People gamejam more interesting and advanced stuff than you're talking about. The mechanics of just shoving together some 2D sprites is not some big undertaking even if you write your engine from scratch, it's making something actually fun and interesting from it that takes time and effort.
> 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.
If the game fits a rather "standardized" template, this is likely true. But the more you move away from these "mainstream structures", the less true the second part of your claim becomes.
I think reaching for the delusion card without considering people's preferences, experiences, expertise and philosophy is completely disingenuous and shows that you don't look at game development holistically. Yes, existing engines do a lot of lifting, especially in 3D rendering and physics. But what about games that don't have physics? Or have completely different physics than you would expect? You mentioned assets being the bottleneck, but what about games that don't use any assets at all? It's nice to have 3D solved, but what if your game attempts to emulate 4D? What if you just hate GUI and it slows you down?
For a more concrete argument. You also said learning Unreal using tutorials took a few days, which is certainly not possible, unless we are talking only about a very basic understanding. In the same vein, it also takes a few days to make a very basic engine built on top of OpenGL.
Here's the thing: you try to counter someone arguing against a patently false statement about development speed with a bunch of preferences and what-abouts that do not necessarily make your stance true anyway - for instance if my game attempts to emulate 4D, my own engine STILL needs to do everything else too, we're not talking dev time for 4D in, say, Godot vs 4D in foo engine, we're talking 4D in Godot vs 4D and graphics and input and audio and physics and... in foo engine.
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide.
At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending in Unreal - I've come away thinking "boy, am I glad I didn't spend several weeks trying to code that up from scratch".
There's definitely an argument to be made for minimalism and anti-bloat, but the reason engines are popular is that they really do some heavy lifting for you.
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.
> “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?
It's worth remembering when deciding on rolling out your own engine that this is a multi-layer trade-off as well, I have an anecdote on this.
I have decided a couple years back that my setup will have a hand-rolled physics engine, specifically for the reasons you outlined - having complete understanding over what the code does, how it's structured and how it manages data - but after starting actually-not-so-arduous process of getting it together, it quickly became rather clear that whatever I could implement would pale in comparison to solutions that are robust, field-tested and generally created by professionals.
Physics development in particular is known for wonky nonsense, but there are better and worse heuristics and ways to deal with their shortcomings; a handful of books and Youtube presentations still couldn't prepare me for the actual depth of the problems ahead. What I have now works, is relatively stable in initial demos and I am proud of it, I'm going to tweak and use it in the game I'm working on. It is however pretty obvious already that a lot of time is yet to be spent on massaging jank out of the equations.
I wholeheartedly recommend spending more than several weeks on implementing various subsystems if one either is generally interested in how these things work or silently wishes for that badge of honour (it shines brightly). However, as they say, if you want to make games, do NOT make an engine. Not just because of the time it takes - it doesn't have to take that much (even though it usually does) - but also because along with total control over the medium for expressing your creative vision, it gives you total responsibility for it as well. Sometimes it's better to work in the confines of rules set out by actual engine developers.
But it's tightly scoped, there is only really one thing that needs to be dynamic, although it worked admirably with more. We wanted big impulses so could get away from questionable cases easily and could deal with crushing cases simply by exploding the ship.
Likewise the players on the ship running around and the players when they're jetpacking about are all different sub-sets of code implementing that specific behavior.
A lot of "make a game, not an engine" is working out what the minimal thing you need to build is rather than making everything extremely generalized.
I'm in the same demographic (less successful than Noel, but I have made my living from game dev for the last 15 years, a lot if from my own indie games). I've used multiple engines throughout that time as they seem to have a lifespan before either tech or business reasons obsolete them (e.g. my first commercial release was made with Flash).
My only regret were the times I tried to roll my own, I would have saved a lot of time and effort focusing on picking the best tool for the job that saved me as much work as possible.
At the end I want to make games and not engines, and only do as much programming as I have to. All those person-millennia spent at epic/unity/etc actually spent doing a lot of stuff (even if you don't need 90% of it, 10% 1000s of people working for decades is still a lot).
Lots of things I don’t know how to do and can spend time learning, many will be better use of that time and effort than reimplementing a game engine from scratch vs using middleware.
I get the argument, and sure, it's viable in certain circumstances. But it's a few weeks _per area / topic_. In my opinion there are enough areas in a typical engine that you could study them for a year and not get through the material. There's graphics, audio, networking, physics, etc. I think the sweetspot is to understand each well enough that you have some insight into what the engine is doing for you, not necessarily to be able to (re-)implement it.
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.
On the contrary, lots of people enjoy the reinventing the wheel part as a means of avoiding all the tricky creative choices and risk of actually shipping a completed game.
It does feel like for many people, it's a form of procrastination and escapism. I'm still working on the game, I just need to do this and this and this first.
Of course - sometimes you just need to learn how it works below, but if your goal is to ship, and you don't have a lot of time, then what I said strikes true to me.
This happens absolutely everywhere. Many B2B SaaS products could have been a single T-SQL script in MSSQL or some other paid/non-OSS/evil capitalist equivalent.
I think a lot of developers lean on ideological angles to deflect rational criticism of their lack of progress and direction.
Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.
>
Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.
If your game idea fits well into the structure of these engines: perhaps.
But I can tell you that lot of ideas that I have for games ("games" is to be understood in a somewhat more broader sense) don't fit these structures well. So I am very certain that for the game ideas that I have in mind, writing an own game engine would very likely be the better choice.
Heh, I contribute to a FOSS social vr project called https://github.com/v-sekai and the majority of the multi year effort was asset pipeline, ik and animation blending. Yes we donated the code to Godot Engine but we choose working on the tooling problem rather than the game… The V-Sekai game is in limbo / not a game. We made godot-vrm which does 3d avatars, with basic animations, look at, jiggle and copy constraints. Since we’re unable to use the unity ecosystem’s finalik or unreal engine’s control rig we have to code to the same level of professional quality with no budget. Features like stable multi-joint y-branching rotation and position constraints are hard. Feel free to chat in V-Sekai discord. I’m iFire.
This is table stakes for any 3D animation, these days. Anim pop is embarrassing and almost certainly you'll want look IK let alone any of the more complex usage.
If you have any animations you're going to want to blend them. If you don't want to make a lot of animations you're probably going to want to use IK for procedural animation.
If you use an engine, you won't be forced to spend time and make it a defacto central feature (because you wont have time for other features). You'll just have access to it.
Evan a 2.5D platformer, a common indie genre, would want animation blending and foot IK without innovating on it.
> If you have any animations you're going to want to blend them.
Yes, if 3d skeletal animation is a central feature of your game it’s not a big deal to spend time making a good system that works for you.
> you're probably going to want to use IK
Plenty of 3D games with 3d animation don’t have IK
> for procedural animation.
Wow your game has 3d procedural animation! That better be the main feature right?
The reason I’m so skeptical is a feature has cost whether it’s written in the engine you use or not. You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that.
For most games, spending time tweaking rigs for IK is not going to make your product better.
> You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that.
This is the entire point of using an engine. You can spend time on the content instead of coding features that aren't unique. Suddenly many types of content are far less costly.
It's just so wrong. These things are very standardized, and you often just want the common implementation that everyone is using. Writing these in most cases is like writing your own SHA256.
Or those features can be nice-to-haves that are worth it if they're not too much effort, such as if, say, I don't know, an engine handles them for you. Come on, real life rarely justifies such easy, simple decisions. And polish can matter a lot for games.
Sure I’m expressing a value judgment, a design preference - not an eternal truth. And the principle is I want to spent the effort on the most important features in which case it’s not a big deal to write them. Your best features become better than if they were cobbled together in Unity.
That is, to be generous, a rather extreme and niche value judgement that corresponds to no utility I can think of. Real life has a spectrum of "important features" and a corresponding spectrum of justified effort. If that's your idea of artistic integrity, then you do you, but for anyone else it's probably nonsense.
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.
Agreed, though getting to that point of understanding is what takes time. Also, there are literally dozens of similar topics where a solo dev should be happy to take any help they can get, IMHO. I'm sure audio is similarly easy, as is input, pathfinding, AI decision trees, physics, etc, etc.
physics is not easy. its pretty challenging and has unending scope.
audio can also have unending scope if you want to do physically simulated Spatial Audio.
Im not sure if AI/pathfinding are worth developing as part of an engine. I feel like their implementation is heavily dependant on the game type, engine implementations often get in the way, rather than helping.
rendering is a beast, especially if you need a long draw distance and have a world that doesnt fit into gpu memory.
The whole task of putting all the pieces together into a cohesive package is a huge undertaking as well.
I am always super curious to read such posts. They make me happy for no reason. I do not make games these days, but I love to read about excited and happy people explaining the process they love to do. At the same time I learn new perspectives to understand what is going on in the world of indie games. I keep this (not so) secret wish in the back of my head because I have to work for some money to support my family and my country (Ukraine). Maybe some time later I will do more of games...
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…
My take away with the final statement of rolling it yourself if it sounds fun is to pick whatever technology that gets your pen on the paper so to speak.
If unity gets you making the thing or making the engine gets you making the thing, most important thing is motion.
You gotta avoid the paralysis and just pick the thing that seems feasible and start typing ;).
I use Lua & Love2D to make games with a similar ethos. Being able to set my own constraints is fun, and that's what game dev is about for me. As soon as something stops being fun, I know I'm doing it wrong and there must be a better way.
My game YOYOZO is a tiny 39KB but made it to Ars Technica's "Best Games of 2023" list alongside heavyweights like Super Mario Wonder and Tears of the Kingdom! https://news.ycombinator.com/item?id=38372936
I've had my Playdate for a couple years but it was only this past weekend I finally got inspired to start playing around with the SDK like I've been telling myself I would since I bought the thing.
I had never used Lua prior to now so that's also part of the learning experience. I'd really like some strong typing and some other language safety features, but it's good for what it needs to do. So far all I've made is a little tech demo of text that rotates around in fake 3D space in relation to the crank, like the iOS options picker. Clip here:
The other thing I learned from this project is I forgot more trigonometry skills than I thought in my years of CRUD/webapp development.
One of the best things about developing for Playdate is how freeing it is to have a fixed canvas that you're drawing to. I'm so used to having to make all my UIs responsive, I love being able to just position something at a pixel value and know it'll work on everyone's device.
For anything I have ever tried to make, I always find myself fighting the engine. Whether it is Godot, Unity or Unreal.
They all feel like a ready made game that you add assets and mod. The problem for me is that I mostly don't want to make that game.
An analogy that comes to mind from the web dev world, it feels like the engines are like wordpress. Prebaked and ready to show content, but the moment your objective does not completely align with their preconfiguration you have to do a huge amount of hacking and workarounds.
And if you open Steam games and go to the newest, you see that nearly half of the releases is some version of a generic Unity/Unreal template game in a slightly altered "skin":
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.
There are games in many different genres, many different aesthetics, many different amounts of polish, and many diffrent levels of performance… all made with Unity. It’s true that they provide a bunch of baseline stuff so that low effort games look and feel similar, but it’s not that hard to end up with game made in Unity that feel unique.
Made me realize that most of the games I really enjoyed have their own custom engines (made for a single game or franchise): Starbound, Stardew Valley, Minecraft, Factorio, RollerCoaster Tycoon, Empire Earth, The Sims, Project Zomboid ...
Only exception might be Portal, but even that is using an in-house solution mostly for developed for one franchise.
Like with most things: If you are new and have to learn everything or if you actually need to pump titles out you should prefer quantity over quality and the major game engines are the way to go. But, if you really want to polish something it will require a long long time and then investing in engine development can pay off. The trap is starting with the later if you haven't made a few dozen games yet and never shipped anything. Then it will stay that way.
Just to clarify, are you saying that if you've never shipped any games then you should start with an established engine and only go artisanal once you have that experience?
Yes, pretty much. I don't say the custom engine first path can't work, heck I did ship my own games on custom engines first myself, but it is probably not the path of least resistance.
This... I don't think I've ever truly enjoyed a Unity game. Maybe KSP, but it runs like shit and isn't a good advertisement for that engine. Even Unreal Engine: I've only enjoyed Unreal itself.
There are definitely some Unity games I've really liked - the Ori games, Hollow Knight - but the engine has never been a positive of my experience with the game. They're full of jank and physics bugs, and in a weird hard to describe way kind of feel "alike". You know you're playing a Unity game, which is bizarre for a part of the game experience that's so low level.
I agree with a lot of this, and am similarily working on my own code-only C# game framework meant as a spiritual successfor to XNA/Monogame (using Sokol instead of SDL):
In OP's post as well he brings up some of the main factors that make modern C# incredible:
- Cross platform development (and runtime).
- NativeAOT Compiling (great for consoles, provided you have backend headers).
- Native Hot-reloading.
- Reflection
I'd also add:
- Source Generators
Modern C# is incredible. I think people still discount it due to its admittedly bad legacy, but the past five years of C# and CoreCLR development make me feel like it's truly a language that has everything necessary but isn't baroque or overburdened. My only major request, Union types, is also in proposal and will (hopefully) come in the next year or so:
Out of curiosity, do you have some pointers for getting into C# for these kinds of projects? I've only used C# for standalone win32 applications and inside of Unity.
I am familiar with low-level game engine stuff in C/C++, but always discarded C# as not being viable for cross-platform projects (as in game consoles). Guess I was wrong. :)
I like to start all my software projects from scratch. Everyone who are used to working on large software projects know that it's very slow. But starting from scratch is fast! You just implement the bare minimum. But also on later stages of the development when you have abstractions going, then it becomes even faster to implement new features. Working on an enterprise software project and your own engine that you've written from scratch is nothing alike, you can work 1000x faster when you have written the thing yourself and can just cut out and refactor everything you want. This is why I advocate micro service architecture and small teams. Things are much smoother when you do it yourself and from scratch. There are however landmines you have to hit and it will take years of trail and error until you get a feeling for what architecture and abstractions work and which doesn't as well as learning the in and outs of the language and platform you are working on.
I'm an indie game developer with over 10 years of experience. I'm not using Unity or Unreal, but I do have some frameworks that handle things like rendering graphics or playing audio. However, I write all the game logic, data manipulation, and entity management from scratch for each game I make. It seems to be the smoothest option for me, since I have full control over how my games actually operate, but I don't have to reinvent the wheel as far as the low-level architecture goes.
Game engine is an art tool in the same way like Blender or Photoshop are. You have to learn its tips and tricks the same way artists do. Usually programmers consider anything that does not have a dedicated UI as fatal flaw hence all the bias towards big engines.
For example, you want to make and thumbnail picture of a 3d model/character. My first thought as a programmer on "correct" approach to that in UE was like well I need to setup a separate world with brand new lightning and have some renderer features off. The perfect "hack" for this is to have a separate "dressing room" under the level where the model teleports into and then back during single frame. Hundreds of such nuances can be only learned.
That was a great post. I had no idea modern .NET had hot-reloading built-in like that. From my experience programming games, that's the biggest time saver you can ask for. Does it work well (or at all) with Godot/C#?
A few years ago, a notorious developer in the GameMaker community wrote a tool that added live reloading to it, and immediately it got widely adopted by big projects.
In terms of prototyping, I think an 'ideal' engine for extremely fast iteration would be something like GameMaker 8.1, but with hot reloading and slightly better window management inside the editor itself.
I don't share the core needs of the author though, I prefer using an engine with a built-in editor, specially in the beginning of a project. I really wanted to like Godot, by the abstractions it provides never 'clicked' with me. I can't think of a game like a bunch of nodes. That's unfortunate for me as Godot it the most popular free game engine AFAIK, with all the goods that comes with that.
I also really don't want to spend years mastering a proprietary tool again.
- If you're building an engine without a game in mind, you're just going to end up with tools you don't use.
- If you have a game you want to see to the end, and make an engine for it, you're going to build exactly what you need and nothing else. With the bonus of having lots of code you can reuse for the next project.
All that said I'm sticking with Godot since I have limited time, and if I want to bang out a quick gameplay idea to see if it even works, I don't want to start from nothing. (I say all this after building a 2.5D-ish engine with c# and monogame)
From the limited game dev experience I have/had, my recommendation is to introspect whether building the tech is just fun escapism from working on the really hard part of game dev: designing something that's really fun to play.
Building your own engine may "feel" like progress but it isn't. A fun game loop implemented with the most rudimentary frameworks, (or sometimes even pen and paper!) is more valuable than just a fancy custom engine implementation without a fun game mechanic.
Very often I find some friends of mine still in gamedev getting sidetracked by the intellectual stimulation that building tech gives them (because they are programmers) and burn out before they actually design/discover a fun game mechanic that they can actually ship a game with.
All this is ofcourse assuming you want to make money off your game. If you are just having fun with a hobby project or doing it to hone your programming skills, go nuts with the custom game engine code; more power to you!
It really feels like all the open-source projects are getting more and more capable. I recently went back to fedora linux on my desktop and the nvidia support is so much better on there than it was even a year or two ago. Hyprland is such a smooth wm that wasn't around even a few years ago. I've been using wgpu for cross-platform GPU rendering, but I've heard about SDL3's recent official release, and I really want to try out those GPU rendering capabilities. What a time to be alive.
I believe a majority of prospective game developers got into it because of interest in game engine development. For such people, Unreal/Unity/Godot take all the fun out of game dev.
This is what happened to me a long time ago - I used to write software 3D engines, then 3D cards (3DFX in particular) happened. I remember losing interest at that time ( I eventually figured out that there was still work to do but still…)
Now that I’m quite a bit older, I have come to appreciate the game part a lot more - it’s maybe less techie, but it’s actually also why people make games. When I play with my kids then don’t see the tech - they see the game !
I'm constantly split on it. Especially since there's two considerations for me
1. In terms of industry, potential employers do want to see my tech. So there's benefit to showing that I don't need to rely on big tools to deliver features... Unless they are a dedicated Unity/Unreal shop and then they do want someone used to the engine. It's pretty hard to win here, especially with the industry as of now being a disaster to apply into.
2. But I also want to make my own games one day. As such I will eventually need to think as a generalist and focus on shipping. But all those skills may not be what actually pays the bills in the meantime.
I like both, but I also gotta eat and I realize that going straight towards my end goal isn't guaranteed to let me keep a roof over my head.
It's refreshing to see someone advocate for small, custom tooling not from a "purist”"standpoint but because it's actually fun and practical for their workflow
Game dev here, building a game using the "engine-only" version of PlayCanvas (a 3d engine). Asset loading, rendering, physics, object management, update loops, raycasting is all handled by the engine (js). My code is everything else, including a low-tech drag and drop scene editor.
I've got to say it's the deepest I've ever been in the abstraction stack for building a game. I have to hand build everything. I definitely wouldn't want to write engine code itself unless I was building an engine; building a good engine takes heaps of engineering and time which I don't have.
I will say though, I absolutely love the level of fine control I have over every aspect of my game (when compared say to a Unity game or even a PlayCanvas game built by their editor).
That was a very fun read! While I’m using Godot for my hacking simulator game, Botnet of Ares [0] I think the native C# approach is very much justified in this case, and Noel clearly has had massive success with Celeste.
I like Godot because of the UI primitives built into the engine. For a UI heavy simulation game like mine, the game engine does a lot of the heavy lifting. Sure, I don’t use 90% of the 2D/3D features of the engine, but that’s okay.
I really miss the days of Flash when I could write lots of mini-engines as needed (e.g. platformers or side scrollers or 2.5D, multiplayer, chat ... all hand coded but reusable) and rely on being able to mix lots of different pipelines for vector art, bitmaps, 3D, audio and UI. There's nothing like that now. I tried to reinvent a few wheels. But at this point... a fairly low level (for script) rendering library like PixiJS is really the best we have. No frameworks, please.
That being said, games are kind of dead. The idea of spending another year or two on another indie game that barely cracks the top 50 for a couple days on an app store is... depressing. Going through the bureaucratic hoops to even get it there and maintain it seems like an exercise in self-torture. I'm kinda back to just making art in my spare time - screen savers, weird web experiences, one-off toys. I think having all my mini-engines in Flash suddenly deleted forever just made me realize how pointless it all was.
Maybe I just spent 20 years getting to be great at the wrong thing. I don't know of a historical parallel of someone spending their life perfecting an art that literally was burned down and blackholed overnight, in quite the same way. I imagine the scribes at Alexandria could at least have gone and scriven somewhere else the following year. So screw it, when I started learning code I was 8 and my brother was a CS major, he gave me his laptop to learn BASIC, and he said "we're just writing on sand." I finally learned that was true.
I got sour on games for a while but I think there are good things awaiting them, because we're starting to get past the hurdle of "new technology usurps the old" actually being germane to the artistic processes that go into game design. Like, it still exists because the devices are so locked down, but it's stopped being a tech-driven business - there's little interest in AAA now, and the broader trends are shaken up too; there's more of a symbiotic pipeline of "make a game that helps people make video content" taking hold, one which has little relationship to recency or production values.
That said I have been pursuing the sustainable elements of gaming for years at this point, seeing the same issues - and for me what it comes down to is what I summarize as "the terrarium problem" - the bigger the software ecosystem you build the game over, the more of the jungle you have to port to the next platform du jour. When we approach gaming as a software problem it's just impossible, we can't support all the hardware and all the platforms.
But within that there are elements of "I can plan for this". Using tech that is already old is one way; Flash, for example, is emulated now. But if you go back to an earlier console generation or retro computers, you can find even more accuracy, better preservation. I took the compromise of "neo retro", since there are several SBCs around that mix old chips with new stuff - those have much more comfy specs to tinker with, while building on some old ideas. Tech that assumes less of a platform is another: I've taken up Forth, because Forth is the language that assumes you have to DIY everything, so it perpetuates ground-up honesty within your software, especially within a retro environment where there's no API layer to speak of and you have full control. And tech that has more of a standardized element is good: if something is "data structure portable", it's easier to recreate(this is why there are many homebrew ports of "Another World" - it's all bytecode).
The last piece of the puzzle in it is - okay, if I take things in that direction, how do I still make it fun to develop with? And that's the part I've been working on lately. I think the tools can be fun. Flash found some fun in it. But Flash as a model is too complex, too situated in just supplying every feature. PICO-8 is also fun, but very focused on a specific aesthetic. I think it's related to data models, conventions and defaults. Getting those things right clears the way.
I'm not saying there isn't a ton of brilliant creativity in the field. But there's no path to success in either of those fields. If there ever was, it was when spending 2 years perfecting a game or an album could separate you from the pack, if you were talented. To some extent, the work you did could stand up for itself, without everything being contingent on luck and how much you were willing to make yourself a social media tool. I didn't mean games and music are "dead" in the sense that no one is innovating. Lots of people are. I mean that for people who need to know that they aren't going to waste years building something beautiful that will be forgotten ten seconds later, indie games are no longer a lucrative area unless you have a fat bank account and can afford to waste a couple years of your life.
As a creative outlet, I'll always love making games that no one will ever play, but that's a hobby and not a job.
Good example of game with custom game engine is Factorio.
They also documented their development a lot on their website and I think they have no problem to answer anything regarding developing own engine in their forum.
One of my first bigger programming projects was a side-scroller in Processing. Processing.org was an amazing way to get into programming since you could draw onto the screen with minimal code.
So I essentially had to write my own physics, collisions, trigger functionality, ways of describing levels, enemies etc. The resulting game wasn't really fun, but I loved the process and the lessons learned.
Turns out writing your own game engine is a pretty good way of learning to understand existing ones.
As a "for fun" side project, I've started building clones of retro classics in Pygame as a way to help beginners gain knowledge of procedural game dev fundamentals.
Python seems like a nice entry point and Pygame works well for the 2D classics like Frogger or Defender or Dig Dug or whatever. It's a lot of fun, but, woah! It's a lot more work than I was expecting.
Since you've been making games for 20 years, I'm guessing you're at least in your thirties. Just curious - do you develop games purely as a hobby, or are you able to make a living from it?
If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
I don’t know Berry’s game dev history, but Celeste designer Maddy Thorson has been making fantastic 2D platformers since, essentially, the very beginning of Western indie games. (Jumper 1 was released in 2004!)
In other words, I think Celeste required decades of preliminary work and industry presence to end up as good as it did. If you build it for a long-ass time, maybe they will eventually come!
I recently wrote a game in Javascript (2D; Canvas). I was amazed at how simple it was and how performant plain-old-Javascript and Javascript objects were. Despite thousands of animating things moving on screen, and animated stereo audio, I couldn't get the frame rate to spill over an animation frame.
If you're serious about making video games, you should probably be using a commercial engine. Period. No exceptions. Unless you're EA or Microsoft, you're just not going to develop a custom engine that can compete with Unity and Unreal. You may be able to write a good basic rendering pipeline and event loop, but the major engines have enormous ecosystems of tooling and talent, ready to go, and they're available across all major platforms including proprietary consoles. Things will go much, much easier for you if you just use those.
If you're just fucking around, do what you want, but if you actually want to ship, it's Unity or Unreal all the way.
And no, I don't think Godot is "there" yet. If Unreal is Photoshop, then Unity is Photopea and Godot is GIMP.
Just off the top of my head, Celeste, Super Meat Boy, Fez, Spelunky, Dead Cells, Braid, and The Witness all use custom engines and are widely considered some of the best indie games of all time. Moreover, I think much of their charm and uniqueness stem directly from the amount of custom engine work involved. Writing your own engine lets you focus on the details that make your game stand out in a crowded field.
I really liked this post. I've recently been learning OpenGL and C++, and the libraries surrounding it, like ImGui, which I like using a lot !
But for my projects I think I'll keep using Godot. I really want to make a game, and not the tooling required to make a game. That said, I've dabbled in GDExtension, and if I really need to have something performant, I'll use that.
I've got huge amounts of respect for people doing it this way though. They have a level of control over their work that a Unity or even Godot developer cannot hope to have. It has, like any game dev approach, it's pros and cons
The one thing that perplexes me is that there are some annoying warts of Godot that make developing a game in it different than making a game yourself and nobody thinks "hey wouldn't it be easier to make Godot work in this way, than to do everything from scratch?"
The key difference is the code driven development workflow that makes it easy to keep different concerns like visual assets, collision boxes, navigation, etc separate.
If you do this in Godot, the standard editor features become meaningless, because they are optimized for throwaway workflows with extremely tight coupling (e.g. a player character IS a node containing subnodes, rather than the player character being a high level concept, whose nodes merely represent the player character).
I mean, you can do Godot this way - just make your player a scene with Node2D or 3D as the root instead of a PlayerCharacter and have it respond to input
The author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue.
Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slowing down your game unexpectedly? Is it only a problem for a certain class of games?
There’s a recent promising development relevant to the GC pause issue. It seems couple weeks ago some smart developer working for Microsoft has made a version of GC called “Satori” which pretty much solved these GC pauses for many real-world use cases.
Yes, C# has had low-level primitives since 1.0 and it has only gotten better in this regard. This means that it's worse than Java at things like devirtualizing calls, but you can write allocation-free hot loops in C# these days.
It's also cross-platform and has multiple deployment modes: you can ship the runtime and the program separately (good when you control the end-user machines, like in an enterprise settings), you can tree-shake the runtime and ship it with the program, or you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary.
The JIT compiler is still better for long-running processes like servers, but for one-shot programs where the startup time is critical, like CLI tools and FaaS, the AOT compiler is really great.
> you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary.
The OP talks about doing this for mobile platforms, but could I take e.g. the OP's source code (he co-wrote Celeste) and trivially compile an AOT native binary for x86_64, or would more work be required to make that possible?
(Interestingly, Celeste on Linux doesn't use the dotnet runtime, but instead a portable Mono runtime which I believe is based on MonoKickstart. [1])
That's kind of an engine though ? An engine is just a bunch of low level types, DS, algos that go onto build mid level abstractions that go onto form systems. In this case you can argue the game itself (aka the runtime) is the game engine?
As others say, getting data (Assets) in/out of the engine is the hard part. Especially as they are the real contribution to the shipped game been so large (unless smart compression, delivery optimisation is used, sadly not common).
Making a video game "without an engine" is basically another way to say "making your own game engine". Which is a fine thing to do, but you're "just" making a bespoke engine for one game (or series of games). Sometimes those engines get large enough to be used by others. That's why it's called "Unreal Engine", because it has heritage in the Unreal games.
A lot of the time the indie game developer is a former professional programmer. This of course affects how they interact with the game development process.
Someone who's coming from a different walk of life (say, an artist or a TTRPG designer trying to make a game) will obviously be much more productive with an off-the-shelf engine like GameMaker or Unity. They accept the engine with its editor as the only way to make a game and get cracking.
A programmer opens the editor and is presented with the 3D scene editor. "Nonono, where's main()?" they immediately ask. "Why is there a 3D scene editor if I want to procgen my levels?" "How do mods work?" "Who told you I needed physics simulation in my game by default?" "Running the game inside the editor is cool and all that, but I'd rather run the editor inside the game."
there is a minor mistake in this.." their minds jump to what it looked like circa 2003 - a closed source, interpreted, verbose...", C# was never interpreted. From the beginning, C# code has always been compiled to Intermediate Language (IL), which is then JIT-compiled by the .NET CLR at runtime.
I've never delivered a game anyone's really paid for, so take with a grain of salt, but imho the big win when you are writing your own stuff is you get to decide what not to include.
That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on - but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine.
Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right.
The list goes on and on... maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way.
Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc.
I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)
> Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
When you're making an engine it's perfectly fine to bake in constraints. Probably most famously PICO-8 does that very intentionally and is written by just one person. Similarly RPGMaker and a bunch of other 'genre specific' game engines also do this. It's just that everyone tries to make something super general purpose which is really a Sisyphean task.
Isn't that a huge effort? I remember few games which developed their own game engines from scratch (factorio, limbo, bg3). But, wouldn't it be easier and better to use game engines like godot?
Engine these days implies one of those IDEs with everything included (scene editor etc). I don't know how or why, but language drifted in the last 20 years or so.
Please help me figure out the best way to share code between Github repositories...
I love C#, and I acknowledge Github as the king of source control.
I make a new Repository a couple times a week, and use Visual Studio Code to clone it, and open a terminal and "dotnet new gitignore" and then use dotnet to make new projects all over the place...
On multiple machines, even. On a VM on my NAS. On my Windows machine. On my Windows laptop. On a VPS.
And I'm happy.
But how in the holy hell am I supposed to share code from one repository to another?
I want to make VikingCoderLib as a C# library (classlib), and drop in all of my favorite Extensions for generics and strings, and etc.
And then make another classlib for some of my Protocol Buffer utilities. And another classlib for setting up a terminal.js console for an app. And...
What's the best way to do that?
Submodules?
They really seem to suck. I can't easily make changes here, and use them there, without it being a huge pain in the rear.
I don't mind submodules much. I mean when I first used them I thought it was sucked, but now I use it all the time for personal projects. I like to make small Lua libs or fork existing Lua libs and include those in a lib directory in my LÖVE / LÖVR projects. Works fine for me.
Perhaps the only thing that sucks a bit about submodules, might be if you work with multiple people and some reference of a submodule is updated and you need to go into the submodule directory to update the reference locally. But I think that's the only thing, no big deal. I don't think you deal with this issue much when you work by yourself on a solo project, on a single machine.
How does any other language do this? I bounce between submodules and monorepo for hobby projects and both approaches have some issues. I'm not a git expert so working with monorepos are a little easier to work with for me.
Yes you would set up your own nuget feed and publish as part of your build. You can set up the nuget feed on your own machine, use something like Teamcity or GitHub packages.
It feels like there should be a good way to have a dotnet classlib in one repository, and use it from others, but it just doesn't feel like they fit together the way they should.
You can also see my workflow for patching godot engine so it's mergable on a rebased master or stable release.
> This project uses git-assembler to simplify merging patches on top of the latest stable release by allowing each patch to be in a separate branch, so they can all be merged into a fresh branch without complicating the revision history.
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious.
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
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)
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.
It is still a lot of work.
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.
> So instead of focusing on release by that time, you will now focus on reinplementing that needed functionality that just stopped working.
That makes no sense. A library being abandoned doesn't mean it suddenly stops working.
I wish that would be the case, but on the web stack, it happened more than once to me.
The web evolves. Lots of features get deprecated all the time and sometimes removed or change behavior in a significant way.
The library would continue to work but may no longer be usable if other dependencies require a later version of "n" that the abandoned library is incompatible with. Ruby or Python runtimes are the classic example.
Support for any studio larger than a few people is the most important part of 3rd party tools. If (and inevitably, when) a tool has a bug or can't do something you need, there's reassurance being able to tell someone else to fix the problem.
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.
Definitely, it’s a trade off. Pulling in dubious dependencies can be a risk. Might be worth writing your own library or forking the dependency and vendoring it in your source.
There’s a spectrum of options here.
This is really the case for all engines. Unity is a bit of of an outlier, though took a long time to get where it is.
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
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
So that’s where Chris Robert’s billion dollar went.
> Engines are the easy part.
> 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.)
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. :)
It really is a miracle that any video games get shipped at all.
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
> 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.
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.
Have you tried Luau - Roblox's open source compiled Lua with Types? Someone made a debugger for it that plugs into Visual Studio Code.
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.
I have not, but it looks great!
The usage of Excel is so hilariously cursed I can't stop thinking about it. Its just raw memory address look ups with extra steps. How did you merge the Excel file? Did you actually have source control on this?
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
> visualizing transitions
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.
I guess the main disadvantage with a custom engine vs Unity, is that you must train new people in it all, vs hiring experts in the tools.
Your custom engine sounds interesting, though. I can recognize some thoughts ..
This is so cool and clever!
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.
There's the Local Lua Debugger [0]. I don't know how it compares to decoda, but I experimented a bit with this debugger last weekend and it seems nice enough - well integrated into VS Code.
---
[0]: https://github.com/tomblind/local-lua-debugger-vscode
The magic of Decoda is that you can download the debugger and immediately start debugging your existing program with no modifications. No libraries. No sockets. No changes at all.
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.
> 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.
> 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:
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.
When I was a game dev I spent way more time on tools than on the engine. Those days of small teams are gone now, so at least in a professional setting you are likely to be able to concentrate on the engine while some other person has to build the editors.
The engine is the fun part. Assets and game design are near impossible as a solo dev
I somewhat agree. Good game design requires a great idea, but more than that a lot of iteration. If you are working solo you need to hold the implementation and design in your head, which is incredibly difficult. Iteration is slow. You need someone to bounce ideas off of.
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”.
Impossible but necessary. It's the big difference between an engine programmer and an indie dev. The latter needs to wear multiple hats to get something out while the former can specialize and work within a team of other specialists.
Word! i've done some ground-up 2D games with no engine library. So i hand-rolled resources, frame rate, collision, simple physics, etc. One has no graphics assets. Another other does.
https://github.com/raould/pn0gstr0m https://github.com/raould/sheepgate
> 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.
The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making. A 2D pixel-art platformer, a multiplayer FPS, a top-down strategy sim, and a puzzle game are all going to require completely different types of assets with unique design requirements. You’d need an all-singing-and-dancing tool that probably wouldn’t be as good at any one thing as the existing specialized tools, FOSS or otherwise.
Although come to think of it, you could probably do most of that in Blender, so maybe such an thing already exists.
There's basically two paths:
(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).
I feel like path #1 would also run into the same problems as #2 as soon as there was any need for real-time editing of scenes.
> The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making
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.
To some degree subsets of this exist.
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.
Some of the other commenters have pointed this out. But this just doesn’t quite work.
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
> 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.
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.
As a "potential customer" for such thing:
I would really love something like it.
Yep, the tooling is where the real grind (and magic) happens
This.
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.
Visual editors are a waste of time. For 2D, lots of solutions exist (Tiled for example). For 3D, you can use Blender as your editor.
The key to making no engine work is to make only what you actually need.
That’s a great idea.
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.
Even without scripting Blender, GLTF is a "scene" format. GLTF files hold information about models, textures, lights, etc... So you can create your scene then import straight into your game with GLTF (open source, super common).
And of course since Blender is used for movies, it does scenes well already.
> For 3D, you can use Blender as your editor.
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.
??? Blender has scripting but it's for artists... Like, artists make movies with it... Movies that have scenes with dozens of artists working on it...
The people who are used to making models are probably not the same as are building levels.
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.
Yes, but most artists can't script. The scripting is for tech artists or programmers to build tools/pipelines on top of Blender.
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.
Visual editing is how all UI is designed. It's not a waste of time. Visual editing is the primary way to prototype, which means it's heavily used at the beginning and less as development goes forward. Projects have some process to translate the prototypes into scaffolding UI in the Editor, then modify with state where necessary. This pipeline is common across all types of software.
Sorry, I thought the context was clear given the parent. Making your own visual editor is a waste of time when ones exist that will output a format you can simply put into your game.
> using your own engine will probably kill you commercially.
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.
Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)
Yep, people forget one of the core notions of development which is not to prematurely optimise stuff. Especially something as complex as a game.
Keep it super simple. Or that game will never come out.
Just the other day on reddit I saw someone asking about efficiently removing an item from an array for the game they’re working on. It became this whole CS debate and then someone asked how big the array is and how often do you remove items. The OP responded that it’s just a list of levels in their game, so not more than 20 items or so and is modified once every 5-10 minutes…
So a day on their game wasted over efficiently removing an item from an array of 20 items every 5-10 minutes.
I used to make 3D engines and asset pipelines professionally. High performance really is critical in both. So, I’d have to check myself frequently:
> 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.
Really highlights the divide between industry and acedemia.
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.
The full quote is:
> 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.
some games require a certain level of scale and for those games you should optimize in the pre-planning stage.
Statistically speaking, 99% of game devs won't ever make a game like that. And if they do, they will probably know ahead of time they are making it.
100% of hobby game devs do it as a hobby. The learning process is the fun part. Which is also why 99% give up on their game when they see more learning potential in another area.
I think you are missing the point. The larger the scale is, the more things may be optimized and the more you need to be careful to focus on the important "3%". That said, it doesn't hurt to analyse in advance which parts might be critical and steer the architecture based on those observations.
Not saying it's a lot less work, it's still a ton of work, but you could always build your tooling around a DCC application by either extending it with scripts or modifying or attaching parts to it like Blender, Maya, etc. Maybe even flat out game engine editors like Godot, Unity, Unreal to build stuff and export out to be used by your own engine.
Vibecoding is probably going to take this whole industry by storm
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
Until AI can actually generate proper topology for meshes, I'm negatively worried about any Vibe coders flooding the market anymore than the market already is. The code is the least valuable part of a game in the eyes of a consumer.
And topology isn't even the hard part of asset production. Animating is the next big hurdle after that.
[flagged]
Such a hostile comment. Just trying to open up the conversation. No need for snark or aggressive name calling
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
Nah he's right, people are fed up of hearing about AI all the time, it's off topic here.
Even if you vibe code a game engine your best llm will need to do the work of world class technical team of like 12 people, you’ll need to get 10-20 teams to be able to find that dataset. Each run costing a few million usd.
Not sure what that use case is. Why would you need all of that? As an individual, if you are just trying to build a basic game with your kids you don't need to build a whole engine nor a world class technical team or a huge dataset
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
Not everyone wants the biggest technology companies to own the process.
This is basically what I did a couple years ago [1]. SDL2 and a bit of C++ to create a "sprite" class. Some collision code in the sprite class...
If you want to call what I added an "engine" it was more like a pedal-assist bike.
Too often I find "engines" end up driving the project/game. That is, you end up writing the game to the engine. It's why I've avoided Unity, etc. — high-level engines like that seem to guide you to writing the same game everyone else is writing — just with different assets.
Never mind you spend too much time, in my opinion, learning the engine and not getting the game written. To be sure there was a learning curve just pulling in SDL, but the curve was slight and it seemed more universally useful to know SDL as it can be employed in other cross-platform projects I might undertake — not just games.
[1] https://store.steampowered.com/app/2318420/Glypha_Vintage/
Just wanted to say that I remember playing your game as a kid on the family Mac IIci. Thanks for the fun memories, and best wishes.
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.
The more unique and niche your game is, the more true this is. Stumbling around Unreal's horrid UI for 3 months just to realize that the thing you want to do is barely even possible due to how general and off-the-shelf the engine is, is not a good experience. 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 also believe that even if it's not always the most efficient thing to do, placing limitations on yourself by using a custom-made specialized engine makes the creativity really flow, and your game, even if not the most advanced, will be a lot more unique as a result of that.
>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 :)
> 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.
Not necessarily. You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).
I wrote about it in https://www.jfgeyelin.com/2021/02/a-general-state-rollback-t...
Feels like fiddling with snapshotting raw C++ memory is a can of worms (you listed some of the pitfalls yourself). Most of my snapshotting happened at the scripting runtime level, where everything is well-defined and well-understood: I manually snapshotted the VM's heap memory, the green threads' stack memory, the current instruction pointer of every green thread etc. I could safely validate those snapshots without segfaulting on a corrupted savefile, because it was a well-defined file format. The same code worked both as a time-travel snapshotter and as a general savefile format.
I think this is dangerous and can lead to remote execution attacks:
>The snapshot could even be exchanged over the network, assuming the receiving side has the same endianness, the same pointer size, is running the same binary, and can mmap the same memory location.
For physics, I needed to restore all those remembered motion vectors; for audio - current playback time, etc. Same as yours:
>The rest of the memory (the textures, the 3D models, the audio, the UI, etc...) should be allocated by your usual non-snapshotting allocator"
> 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)
But did you actually need all of those things?
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.
At this point using any engine instead of unity is better. Unity has demonstrated time and again that they cannot be trusted and that you cannot build a game (or business) around them.
Sometimes you have to do business with counterparties you don't trust. It's not mature or practical to take an "all-or-nothing" approach while the engine has virtually no competition for many classes of games.
Building a business fully depending on a party you don't trust sounds kinda delusional.
I mean I’ve been using Unity since 2008. I do trust them to be around more than most other tooling/saas companies? Even if they have mode some unsound business decisions
Do you have any developer retrospectives around this? Plenty of my favorite games ever made were made with Unity, I wouldn't call those games failures by any means (Cities: Skylines, Overcooked are immediate examples)
The tech is fine, it's more that the last few years has shown some instability over retroactive license changes, questionable acquisitions, and general sentiments over years of seemingly abandoned support in key subsystems.
Disclosure: I used to work at Unity.
At least as far as platformers go, physics feel is a crucial part of the whole experience, and outsourcing to an engine has a good chance of making your game feel cookie-cutter.
> I am not familiar with Unreal, but Unity is much faster than programming from scratch, easily 10x or more.
With the caveat that the editor for Unreal is massive and getting it running requires more resources than Unity, Unreal's Blueprint is a great way of writing gameplay logic. It's accessible to people who don't know C++ or C#, and is a really nice abstraction for async/event driven code. It's a really good place to start with IMO.
>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 you'd probably want a different render layer with different post effect settings so your weapons can have post-processing as well. I think you can do this in the editor with gui configs instead of changing code.
I'm pretty sure all of SRP is in C# and is "open source" as in source available and editable.
https://github.com/Unity-Technologies/Graphics/tree/master/P...
The problem with GUI settings is that the result is not apparent, and there might be side effects. I do not find spending half day on trying out setting combinations as productive work.
I have looked into SRP and i do still consider that as an option, and also replacing the shaders. But i have doubts regarding the SRP, for example i have looked at the code that sorts lights in Forward+. The individual light calculations are not much, but its still done trough the job system. I imagine if there are hundreds of lights, then that would make sense, but for 2-5 lights, it seems like a waste. So it might be optimised to scale, but not for my case.
Is the effort of replacing the SRP worth it, and is the performance comparable to putting together/reusing an engine in C++? It is also a bigger commitment, as it needs to be coded on a different level and in a way very specific to the engine. Better than having to reverse asset file formats, but still very specific to the engine.
> 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
> 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.
> 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.
If your vision is weird or niche, building a toolset around that from day one can be way more efficient in the long run
Games like Antichamber do non-euclidean space and rendering in Unreal (3). Enera (an upcoming action game) manages time rewinding (a la braid), in Unreal. Superhot is Unity, etc.
The best tool is the one you know, even if your vision is weird or niche. At the end of the day, you can always ignore all the bits and pieces unity gives to you and just write custom logic in your MonoBehaviour scripts and use it as a platform toolkit, input handler, content pipeline, scriptable editor, and renderer. There's a lot to be said for the features you get from that especially in the long term as you said.
I think my point was more that if your vision diverges heavily from the "normal" flow of those engines, sometimes it's just less friction to build your own
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)
There's a lot of nice things you get for free in a big engine that are a hassle doing it yourself. Esp with the unity store etc.
I love LibGDX for personal projects but for serious development where deadlines matter having stuff like dialog trees, UI, etc. that just work out of the box and have the edge cases polished is Very Nice.
And ofc, cross platform with consoles is way harder rolling your own and that's often a big deal.
That sorta thing is why Slay the Spire switched to Unity/Godot for the sequel
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.
I can have an engine ready for you that allows you to render arbitrary 2D sprites, levels of them, etc. or whatever in a day. People gamejam more interesting and advanced stuff than you're talking about. The mechanics of just shoving together some 2D sprites is not some big undertaking even if you write your engine from scratch, it's making something actually fun and interesting from it that takes time and effort.
> 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.
If the game fits a rather "standardized" template, this is likely true. But the more you move away from these "mainstream structures", the less true the second part of your claim becomes.
I think reaching for the delusion card without considering people's preferences, experiences, expertise and philosophy is completely disingenuous and shows that you don't look at game development holistically. Yes, existing engines do a lot of lifting, especially in 3D rendering and physics. But what about games that don't have physics? Or have completely different physics than you would expect? You mentioned assets being the bottleneck, but what about games that don't use any assets at all? It's nice to have 3D solved, but what if your game attempts to emulate 4D? What if you just hate GUI and it slows you down?
For a more concrete argument. You also said learning Unreal using tutorials took a few days, which is certainly not possible, unless we are talking only about a very basic understanding. In the same vein, it also takes a few days to make a very basic engine built on top of OpenGL.
Here's the thing: you try to counter someone arguing against a patently false statement about development speed with a bunch of preferences and what-abouts that do not necessarily make your stance true anyway - for instance if my game attempts to emulate 4D, my own engine STILL needs to do everything else too, we're not talking dev time for 4D in, say, Godot vs 4D in foo engine, we're talking 4D in Godot vs 4D and graphics and input and audio and physics and... in foo engine.
My friend demo'ed 4d in Godot Engine funny enough. https://github.com/godot-dimensions/godot-4d
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide.
At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending in Unreal - I've come away thinking "boy, am I glad I didn't spend several weeks trying to code that up from scratch".
There's definitely an argument to be made for minimalism and anti-bloat, but the reason engines are popular is that they really do some heavy lifting for you.
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.
> “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?
It's worth remembering when deciding on rolling out your own engine that this is a multi-layer trade-off as well, I have an anecdote on this.
I have decided a couple years back that my setup will have a hand-rolled physics engine, specifically for the reasons you outlined - having complete understanding over what the code does, how it's structured and how it manages data - but after starting actually-not-so-arduous process of getting it together, it quickly became rather clear that whatever I could implement would pale in comparison to solutions that are robust, field-tested and generally created by professionals.
Physics development in particular is known for wonky nonsense, but there are better and worse heuristics and ways to deal with their shortcomings; a handful of books and Youtube presentations still couldn't prepare me for the actual depth of the problems ahead. What I have now works, is relatively stable in initial demos and I am proud of it, I'm going to tweak and use it in the game I'm working on. It is however pretty obvious already that a lot of time is yet to be spent on massaging jank out of the equations.
I wholeheartedly recommend spending more than several weeks on implementing various subsystems if one either is generally interested in how these things work or silently wishes for that badge of honour (it shines brightly). However, as they say, if you want to make games, do NOT make an engine. Not just because of the time it takes - it doesn't have to take that much (even though it usually does) - but also because along with total control over the medium for expressing your creative vision, it gives you total responsibility for it as well. Sometimes it's better to work in the confines of rules set out by actual engine developers.
There's levels to that though. For example it took me all of a week to write the 2D rigidbody physics system that runs this game:
https://www.youtube.com/watch?v=zVmd2vmZrVA
But it's tightly scoped, there is only really one thing that needs to be dynamic, although it worked admirably with more. We wanted big impulses so could get away from questionable cases easily and could deal with crushing cases simply by exploding the ship.
Likewise the players on the ship running around and the players when they're jetpacking about are all different sub-sets of code implementing that specific behavior.
A lot of "make a game, not an engine" is working out what the minimal thing you need to build is rather than making everything extremely generalized.
I'm in the same demographic (less successful than Noel, but I have made my living from game dev for the last 15 years, a lot if from my own indie games). I've used multiple engines throughout that time as they seem to have a lifespan before either tech or business reasons obsolete them (e.g. my first commercial release was made with Flash).
My only regret were the times I tried to roll my own, I would have saved a lot of time and effort focusing on picking the best tool for the job that saved me as much work as possible.
At the end I want to make games and not engines, and only do as much programming as I have to. All those person-millennia spent at epic/unity/etc actually spent doing a lot of stuff (even if you don't need 90% of it, 10% 1000s of people working for decades is still a lot).
Face it, you just don't know how to do it and are trying to convince yourself that you don't need to learn how to
Lots of things I don’t know how to do and can spend time learning, many will be better use of that time and effort than reimplementing a game engine from scratch vs using middleware.
I get the argument, and sure, it's viable in certain circumstances. But it's a few weeks _per area / topic_. In my opinion there are enough areas in a typical engine that you could study them for a year and not get through the material. There's graphics, audio, networking, physics, etc. I think the sweetspot is to understand each well enough that you have some insight into what the engine is doing for you, not necessarily to be able to (re-)implement it.
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.
And now that you’ve done it, you could probably reimplement it better in a fraction of the time.
Except that I wouldn't, because most of that stuff would be a shader nowdays, and depending on the API version, not the same kind of shader.
This kind of stuff is fun, if the end goal is to become a game engine or tools engineer, if the goal is to make a game, it is mostly yak shaving.
[dead]
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.
On the contrary, lots of people enjoy the reinventing the wheel part as a means of avoiding all the tricky creative choices and risk of actually shipping a completed game.
It does feel like for many people, it's a form of procrastination and escapism. I'm still working on the game, I just need to do this and this and this first.
Of course - sometimes you just need to learn how it works below, but if your goal is to ship, and you don't have a lot of time, then what I said strikes true to me.
Me, too many times.
I think this is also true beyond games, e.g. for all the different UI libraries.
This happens absolutely everywhere. Many B2B SaaS products could have been a single T-SQL script in MSSQL or some other paid/non-OSS/evil capitalist equivalent.
I think a lot of developers lean on ideological angles to deflect rational criticism of their lack of progress and direction.
Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.
> Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.
If your game idea fits well into the structure of these engines: perhaps.
But I can tell you that lot of ideas that I have for games ("games" is to be understood in a somewhat more broader sense) don't fit these structures well. So I am very certain that for the game ideas that I have in mind, writing an own game engine would very likely be the better choice.
I’m not doubting you, but the vast majority of ideas people have for games are largely derivative and could quite easily be implemented in Unity.
> 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.
Heh, I contribute to a FOSS social vr project called https://github.com/v-sekai and the majority of the multi year effort was asset pipeline, ik and animation blending. Yes we donated the code to Godot Engine but we choose working on the tooling problem rather than the game… The V-Sekai game is in limbo / not a game. We made godot-vrm which does 3d avatars, with basic animations, look at, jiggle and copy constraints. Since we’re unable to use the unity ecosystem’s finalik or unreal engine’s control rig we have to code to the same level of professional quality with no budget. Features like stable multi-joint y-branching rotation and position constraints are hard. Feel free to chat in V-Sekai discord. I’m iFire.
Using Godot for my big project, thank you for donating the IK stuff to godot!
This is table stakes for any 3D animation, these days. Anim pop is embarrassing and almost certainly you'll want look IK let alone any of the more complex usage.
> This is table stakes for any 3D animation
You’re doing 3d skeletal animation for your indie game? How many skeletons and animations are you going to make?
And you don’t consider it a central feature?
If you have any animations you're going to want to blend them. If you don't want to make a lot of animations you're probably going to want to use IK for procedural animation.
If you use an engine, you won't be forced to spend time and make it a defacto central feature (because you wont have time for other features). You'll just have access to it.
Evan a 2.5D platformer, a common indie genre, would want animation blending and foot IK without innovating on it.
> If you have any animations you're going to want to blend them.
Yes, if 3d skeletal animation is a central feature of your game it’s not a big deal to spend time making a good system that works for you.
> you're probably going to want to use IK
Plenty of 3D games with 3d animation don’t have IK
> for procedural animation.
Wow your game has 3d procedural animation! That better be the main feature right?
The reason I’m so skeptical is a feature has cost whether it’s written in the engine you use or not. You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that.
For most games, spending time tweaking rigs for IK is not going to make your product better.
> You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that.
This is the entire point of using an engine. You can spend time on the content instead of coding features that aren't unique. Suddenly many types of content are far less costly.
I’m saying the real cost is the content.
It’s not hard to implement any of these features, you just don’t have time to do them all.
I agree an engine can be a good prototyping tool.
It's just so wrong. These things are very standardized, and you often just want the common implementation that everyone is using. Writing these in most cases is like writing your own SHA256.
Is your indie game more complex than quake 3?
Blatantly false dichotomy.
Or You simply aren’t ruthless enough about how much time you have on an indie project.
Or those features can be nice-to-haves that are worth it if they're not too much effort, such as if, say, I don't know, an engine handles them for you. Come on, real life rarely justifies such easy, simple decisions. And polish can matter a lot for games.
Sure I’m expressing a value judgment, a design preference - not an eternal truth. And the principle is I want to spent the effort on the most important features in which case it’s not a big deal to write them. Your best features become better than if they were cobbled together in Unity.
That is, to be generous, a rather extreme and niche value judgement that corresponds to no utility I can think of. Real life has a spectrum of "important features" and a corresponding spectrum of justified effort. If that's your idea of artistic integrity, then you do you, but for anyone else it's probably nonsense.
> to be generous, a rather extreme and niche value judgement that corresponds to no utility I can think of
Ok, well I look forward to seeing your games then, as I’m sure you’re skilled at shipping.
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.
Agreed, though getting to that point of understanding is what takes time. Also, there are literally dozens of similar topics where a solo dev should be happy to take any help they can get, IMHO. I'm sure audio is similarly easy, as is input, pathfinding, AI decision trees, physics, etc, etc.
physics is not easy. its pretty challenging and has unending scope.
audio can also have unending scope if you want to do physically simulated Spatial Audio.
Im not sure if AI/pathfinding are worth developing as part of an engine. I feel like their implementation is heavily dependant on the game type, engine implementations often get in the way, rather than helping.
rendering is a beast, especially if you need a long draw distance and have a world that doesnt fit into gpu memory.
The whole task of putting all the pieces together into a cohesive package is a huge undertaking as well.
I am always super curious to read such posts. They make me happy for no reason. I do not make games these days, but I love to read about excited and happy people explaining the process they love to do. At the same time I learn new perspectives to understand what is going on in the world of indie games. I keep this (not so) secret wish in the back of my head because I have to work for some money to support my family and my country (Ukraine). Maybe some time later I will do more of games...
Thank you for writing this post, Noel!
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…
My take away with the final statement of rolling it yourself if it sounds fun is to pick whatever technology that gets your pen on the paper so to speak.
If unity gets you making the thing or making the engine gets you making the thing, most important thing is motion.
You gotta avoid the paralysis and just pick the thing that seems feasible and start typing ;).
I use Lua & Love2D to make games with a similar ethos. Being able to set my own constraints is fun, and that's what game dev is about for me. As soon as something stops being fun, I know I'm doing it wrong and there must be a better way.
My game YOYOZO is a tiny 39KB but made it to Ars Technica's "Best Games of 2023" list alongside heavyweights like Super Mario Wonder and Tears of the Kingdom! https://news.ycombinator.com/item?id=38372936
Hey I recognize that game, great work!
I've had my Playdate for a couple years but it was only this past weekend I finally got inspired to start playing around with the SDK like I've been telling myself I would since I bought the thing.
I had never used Lua prior to now so that's also part of the learning experience. I'd really like some strong typing and some other language safety features, but it's good for what it needs to do. So far all I've made is a little tech demo of text that rotates around in fake 3D space in relation to the crank, like the iOS options picker. Clip here:
https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
The other thing I learned from this project is I forgot more trigonometry skills than I thought in my years of CRUD/webapp development.
One of the best things about developing for Playdate is how freeing it is to have a fixed canvas that you're drawing to. I'm so used to having to make all my UIs responsive, I love being able to just position something at a pixel value and know it'll work on everyone's device.
Congratulations man, great work.
Thanks so much, it's appreciated.
For anything I have ever tried to make, I always find myself fighting the engine. Whether it is Godot, Unity or Unreal.
They all feel like a ready made game that you add assets and mod. The problem for me is that I mostly don't want to make that game.
An analogy that comes to mind from the web dev world, it feels like the engines are like wordpress. Prebaked and ready to show content, but the moment your objective does not completely align with their preconfiguration you have to do a huge amount of hacking and workarounds.
What adds oil to the flame is a bunch of "game templates" that you can buy and make your own game just by replacing the title screen and some models. E.g. https://assetstore.unity.com/packages/templates/systems/stor...
And if you open Steam games and go to the newest, you see that nearly half of the releases is some version of a generic Unity/Unreal template game in a slightly altered "skin":
https://store.steampowered.com/app/2488370/Cash_Cleaner_Simu...
https://store.steampowered.com/app/2073910/A_Webbing_Journey...
https://store.steampowered.com/app/3498270/Better_Mart/
https://store.steampowered.com/app/2625420/Drive_Beyond_Hori...
https://store.steampowered.com/app/3163790/Toy_Shop_Simulato...
https://store.steampowered.com/app/3023600/Horse_Farm_Simula...
https://store.steampowered.com/app/3124550/Liquor_Store_Simu...
Ha, if I remember correctly the squad military sim was a reskinned first person demo from epic games.
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.
There are games in many different genres, many different aesthetics, many different amounts of polish, and many diffrent levels of performance… all made with Unity. It’s true that they provide a bunch of baseline stuff so that low effort games look and feel similar, but it’s not that hard to end up with game made in Unity that feel unique.
Just to note that the author wrote this game, >3 million copies sold: https://en.wikipedia.org/wiki/Celeste_(video_game)
Made me realize that most of the games I really enjoyed have their own custom engines (made for a single game or franchise): Starbound, Stardew Valley, Minecraft, Factorio, RollerCoaster Tycoon, Empire Earth, The Sims, Project Zomboid ...
Only exception might be Portal, but even that is using an in-house solution mostly for developed for one franchise.
Like with most things: If you are new and have to learn everything or if you actually need to pump titles out you should prefer quantity over quality and the major game engines are the way to go. But, if you really want to polish something it will require a long long time and then investing in engine development can pay off. The trap is starting with the later if you haven't made a few dozen games yet and never shipped anything. Then it will stay that way.
Just to clarify, are you saying that if you've never shipped any games then you should start with an established engine and only go artisanal once you have that experience?
Yes, pretty much. I don't say the custom engine first path can't work, heck I did ship my own games on custom engines first myself, but it is probably not the path of least resistance.
This... I don't think I've ever truly enjoyed a Unity game. Maybe KSP, but it runs like shit and isn't a good advertisement for that engine. Even Unreal Engine: I've only enjoyed Unreal itself.
There are definitely some Unity games I've really liked - the Ori games, Hollow Knight - but the engine has never been a positive of my experience with the game. They're full of jank and physics bugs, and in a weird hard to describe way kind of feel "alike". You know you're playing a Unity game, which is bizarre for a part of the game experience that's so low level.
I agree with a lot of this, and am similarily working on my own code-only C# game framework meant as a spiritual successfor to XNA/Monogame (using Sokol instead of SDL):
https://zinc.graphics/
In OP's post as well he brings up some of the main factors that make modern C# incredible:
- Cross platform development (and runtime).
- NativeAOT Compiling (great for consoles, provided you have backend headers).
- Native Hot-reloading.
- Reflection
I'd also add:
- Source Generators
Modern C# is incredible. I think people still discount it due to its admittedly bad legacy, but the past five years of C# and CoreCLR development make me feel like it's truly a language that has everything necessary but isn't baroque or overburdened. My only major request, Union types, is also in proposal and will (hopefully) come in the next year or so:
https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
Out of curiosity, do you have some pointers for getting into C# for these kinds of projects? I've only used C# for standalone win32 applications and inside of Unity.
I am familiar with low-level game engine stuff in C/C++, but always discarded C# as not being viable for cross-platform projects (as in game consoles). Guess I was wrong. :)
I like to start all my software projects from scratch. Everyone who are used to working on large software projects know that it's very slow. But starting from scratch is fast! You just implement the bare minimum. But also on later stages of the development when you have abstractions going, then it becomes even faster to implement new features. Working on an enterprise software project and your own engine that you've written from scratch is nothing alike, you can work 1000x faster when you have written the thing yourself and can just cut out and refactor everything you want. This is why I advocate micro service architecture and small teams. Things are much smoother when you do it yourself and from scratch. There are however landmines you have to hit and it will take years of trail and error until you get a feeling for what architecture and abstractions work and which doesn't as well as learning the in and outs of the language and platform you are working on.
I'm an indie game developer with over 10 years of experience. I'm not using Unity or Unreal, but I do have some frameworks that handle things like rendering graphics or playing audio. However, I write all the game logic, data manipulation, and entity management from scratch for each game I make. It seems to be the smoothest option for me, since I have full control over how my games actually operate, but I don't have to reinvent the wheel as far as the low-level architecture goes.
Game engine is an art tool in the same way like Blender or Photoshop are. You have to learn its tips and tricks the same way artists do. Usually programmers consider anything that does not have a dedicated UI as fatal flaw hence all the bias towards big engines.
For example, you want to make and thumbnail picture of a 3d model/character. My first thought as a programmer on "correct" approach to that in UE was like well I need to setup a separate world with brand new lightning and have some renderer features off. The perfect "hack" for this is to have a separate "dressing room" under the level where the model teleports into and then back during single frame. Hundreds of such nuances can be only learned.
That was a great post. I had no idea modern .NET had hot-reloading built-in like that. From my experience programming games, that's the biggest time saver you can ask for. Does it work well (or at all) with Godot/C#?
A few years ago, a notorious developer in the GameMaker community wrote a tool that added live reloading to it, and immediately it got widely adopted by big projects.
In terms of prototyping, I think an 'ideal' engine for extremely fast iteration would be something like GameMaker 8.1, but with hot reloading and slightly better window management inside the editor itself.
I don't share the core needs of the author though, I prefer using an engine with a built-in editor, specially in the beginning of a project. I really wanted to like Godot, by the abstractions it provides never 'clicked' with me. I can't think of a game like a bunch of nodes. That's unfortunate for me as Godot it the most popular free game engine AFAIK, with all the goods that comes with that.
I also really don't want to spend years mastering a proprietary tool again.
> 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 :)
I always saw it like this:
- If you're building an engine without a game in mind, you're just going to end up with tools you don't use.
- If you have a game you want to see to the end, and make an engine for it, you're going to build exactly what you need and nothing else. With the bonus of having lots of code you can reuse for the next project.
All that said I'm sticking with Godot since I have limited time, and if I want to bang out a quick gameplay idea to see if it even works, I don't want to start from nothing. (I say all this after building a 2.5D-ish engine with c# and monogame)
From the limited game dev experience I have/had, my recommendation is to introspect whether building the tech is just fun escapism from working on the really hard part of game dev: designing something that's really fun to play.
Building your own engine may "feel" like progress but it isn't. A fun game loop implemented with the most rudimentary frameworks, (or sometimes even pen and paper!) is more valuable than just a fancy custom engine implementation without a fun game mechanic.
Very often I find some friends of mine still in gamedev getting sidetracked by the intellectual stimulation that building tech gives them (because they are programmers) and burn out before they actually design/discover a fun game mechanic that they can actually ship a game with.
All this is ofcourse assuming you want to make money off your game. If you are just having fun with a hobby project or doing it to hone your programming skills, go nuts with the custom game engine code; more power to you!
It really feels like all the open-source projects are getting more and more capable. I recently went back to fedora linux on my desktop and the nvidia support is so much better on there than it was even a year or two ago. Hyprland is such a smooth wm that wasn't around even a few years ago. I've been using wgpu for cross-platform GPU rendering, but I've heard about SDL3's recent official release, and I really want to try out those GPU rendering capabilities. What a time to be alive.
I believe a majority of prospective game developers got into it because of interest in game engine development. For such people, Unreal/Unity/Godot take all the fun out of game dev.
This is what happened to me a long time ago - I used to write software 3D engines, then 3D cards (3DFX in particular) happened. I remember losing interest at that time ( I eventually figured out that there was still work to do but still…)
Now that I’m quite a bit older, I have come to appreciate the game part a lot more - it’s maybe less techie, but it’s actually also why people make games. When I play with my kids then don’t see the tech - they see the game !
I'm constantly split on it. Especially since there's two considerations for me
1. In terms of industry, potential employers do want to see my tech. So there's benefit to showing that I don't need to rely on big tools to deliver features... Unless they are a dedicated Unity/Unreal shop and then they do want someone used to the engine. It's pretty hard to win here, especially with the industry as of now being a disaster to apply into.
2. But I also want to make my own games one day. As such I will eventually need to think as a generalist and focus on shipping. But all those skills may not be what actually pays the bills in the meantime.
I like both, but I also gotta eat and I realize that going straight towards my end goal isn't guaranteed to let me keep a roof over my head.
That always has been my Achilles' heel - I don't play games, I think that it's a waste of time. So just enjoying the tech side of it.
It's refreshing to see someone advocate for small, custom tooling not from a "purist”"standpoint but because it's actually fun and practical for their workflow
Game dev here, building a game using the "engine-only" version of PlayCanvas (a 3d engine). Asset loading, rendering, physics, object management, update loops, raycasting is all handled by the engine (js). My code is everything else, including a low-tech drag and drop scene editor.
I've got to say it's the deepest I've ever been in the abstraction stack for building a game. I have to hand build everything. I definitely wouldn't want to write engine code itself unless I was building an engine; building a good engine takes heaps of engineering and time which I don't have.
I will say though, I absolutely love the level of fine control I have over every aspect of my game (when compared say to a Unity game or even a PlayCanvas game built by their editor).
That was a very fun read! While I’m using Godot for my hacking simulator game, Botnet of Ares [0] I think the native C# approach is very much justified in this case, and Noel clearly has had massive success with Celeste.
I like Godot because of the UI primitives built into the engine. For a UI heavy simulation game like mine, the game engine does a lot of the heavy lifting. Sure, I don’t use 90% of the 2D/3D features of the engine, but that’s okay.
[0] https://store.steampowered.com/app/3627290/Botnet_of_Ares/
Oh wow - I wanted to build a game just like this not too long ago but never found the time. Wishlisted!
I really miss the days of Flash when I could write lots of mini-engines as needed (e.g. platformers or side scrollers or 2.5D, multiplayer, chat ... all hand coded but reusable) and rely on being able to mix lots of different pipelines for vector art, bitmaps, 3D, audio and UI. There's nothing like that now. I tried to reinvent a few wheels. But at this point... a fairly low level (for script) rendering library like PixiJS is really the best we have. No frameworks, please.
That being said, games are kind of dead. The idea of spending another year or two on another indie game that barely cracks the top 50 for a couple days on an app store is... depressing. Going through the bureaucratic hoops to even get it there and maintain it seems like an exercise in self-torture. I'm kinda back to just making art in my spare time - screen savers, weird web experiences, one-off toys. I think having all my mini-engines in Flash suddenly deleted forever just made me realize how pointless it all was.
Maybe I just spent 20 years getting to be great at the wrong thing. I don't know of a historical parallel of someone spending their life perfecting an art that literally was burned down and blackholed overnight, in quite the same way. I imagine the scribes at Alexandria could at least have gone and scriven somewhere else the following year. So screw it, when I started learning code I was 8 and my brother was a CS major, he gave me his laptop to learn BASIC, and he said "we're just writing on sand." I finally learned that was true.
I got sour on games for a while but I think there are good things awaiting them, because we're starting to get past the hurdle of "new technology usurps the old" actually being germane to the artistic processes that go into game design. Like, it still exists because the devices are so locked down, but it's stopped being a tech-driven business - there's little interest in AAA now, and the broader trends are shaken up too; there's more of a symbiotic pipeline of "make a game that helps people make video content" taking hold, one which has little relationship to recency or production values.
That said I have been pursuing the sustainable elements of gaming for years at this point, seeing the same issues - and for me what it comes down to is what I summarize as "the terrarium problem" - the bigger the software ecosystem you build the game over, the more of the jungle you have to port to the next platform du jour. When we approach gaming as a software problem it's just impossible, we can't support all the hardware and all the platforms.
But within that there are elements of "I can plan for this". Using tech that is already old is one way; Flash, for example, is emulated now. But if you go back to an earlier console generation or retro computers, you can find even more accuracy, better preservation. I took the compromise of "neo retro", since there are several SBCs around that mix old chips with new stuff - those have much more comfy specs to tinker with, while building on some old ideas. Tech that assumes less of a platform is another: I've taken up Forth, because Forth is the language that assumes you have to DIY everything, so it perpetuates ground-up honesty within your software, especially within a retro environment where there's no API layer to speak of and you have full control. And tech that has more of a standardized element is good: if something is "data structure portable", it's easier to recreate(this is why there are many homebrew ports of "Another World" - it's all bytecode).
The last piece of the puzzle in it is - okay, if I take things in that direction, how do I still make it fun to develop with? And that's the part I've been working on lately. I think the tools can be fun. Flash found some fun in it. But Flash as a model is too complex, too situated in just supplying every feature. PICO-8 is also fun, but very focused on a specific aesthetic. I think it's related to data models, conventions and defaults. Getting those things right clears the way.
Games are “dead” in the same way that music is “dead.”
I'm not saying there isn't a ton of brilliant creativity in the field. But there's no path to success in either of those fields. If there ever was, it was when spending 2 years perfecting a game or an album could separate you from the pack, if you were talented. To some extent, the work you did could stand up for itself, without everything being contingent on luck and how much you were willing to make yourself a social media tool. I didn't mean games and music are "dead" in the sense that no one is innovating. Lots of people are. I mean that for people who need to know that they aren't going to waste years building something beautiful that will be forgotten ten seconds later, indie games are no longer a lucrative area unless you have a fat bank account and can afford to waste a couple years of your life.
As a creative outlet, I'll always love making games that no one will ever play, but that's a hobby and not a job.
Good example of game with custom game engine is Factorio.
They also documented their development a lot on their website and I think they have no problem to answer anything regarding developing own engine in their forum.
One of my first bigger programming projects was a side-scroller in Processing. Processing.org was an amazing way to get into programming since you could draw onto the screen with minimal code.
So I essentially had to write my own physics, collisions, trigger functionality, ways of describing levels, enemies etc. The resulting game wasn't really fun, but I loved the process and the lessons learned.
Turns out writing your own game engine is a pretty good way of learning to understand existing ones.
As a "for fun" side project, I've started building clones of retro classics in Pygame as a way to help beginners gain knowledge of procedural game dev fundamentals.
Python seems like a nice entry point and Pygame works well for the 2D classics like Frogger or Defender or Dig Dug or whatever. It's a lot of fun, but, woah! It's a lot more work than I was expecting.
Kudos to you! I'm writing a game (a little MMO) the same way, the technical and creative freedom is priceless.
Since you've been making games for 20 years, I'm guessing you're at least in your thirties. Just curious - do you develop games purely as a hobby, or are you able to make a living from it?
If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
Not OP, but this is Noel Berry, one of the creators of Celeste, a very successful and incredible indie game.
Didn't know that ... silly me. In any case, I think the question still relevant - is the secret just "if you build it, they will come?"
I suspect it isn't since the competition is fierce, there has to be something beyond making a good game
I don’t know Berry’s game dev history, but Celeste designer Maddy Thorson has been making fantastic 2D platformers since, essentially, the very beginning of Western indie games. (Jumper 1 was released in 2004!)
In other words, I think Celeste required decades of preliminary work and industry presence to end up as good as it did. If you build it for a long-ass time, maybe they will eventually come!
The secret extra sauce is called marketing :)
I recently wrote a game in Javascript (2D; Canvas). I was amazed at how simple it was and how performant plain-old-Javascript and Javascript objects were. Despite thousands of animating things moving on screen, and animated stereo audio, I couldn't get the frame rate to spill over an animation frame.
If you're serious about making video games, you should probably be using a commercial engine. Period. No exceptions. Unless you're EA or Microsoft, you're just not going to develop a custom engine that can compete with Unity and Unreal. You may be able to write a good basic rendering pipeline and event loop, but the major engines have enormous ecosystems of tooling and talent, ready to go, and they're available across all major platforms including proprietary consoles. Things will go much, much easier for you if you just use those.
If you're just fucking around, do what you want, but if you actually want to ship, it's Unity or Unreal all the way.
And no, I don't think Godot is "there" yet. If Unreal is Photoshop, then Unity is Photopea and Godot is GIMP.
Just off the top of my head, Celeste, Super Meat Boy, Fez, Spelunky, Dead Cells, Braid, and The Witness all use custom engines and are widely considered some of the best indie games of all time. Moreover, I think much of their charm and uniqueness stem directly from the amount of custom engine work involved. Writing your own engine lets you focus on the details that make your game stand out in a crowded field.
Your assertion seems silly.
In fact, the article is by one of the devs of Celeste.
Agree with your sentiment.
But Spelunky was written in Game Maker Studio.
The original Spelunky, but not HD. The devs talked about how they started out with the Braid engine and then just rolled their own.
For simpler games, libraries such as raylib or lightweight opensource game engines such as Amulet (https://www.amulet.xyz/) / Love 2D are good fit.
+1 for raylib, probably the best C library ever written.
I really liked this post. I've recently been learning OpenGL and C++, and the libraries surrounding it, like ImGui, which I like using a lot !
But for my projects I think I'll keep using Godot. I really want to make a game, and not the tooling required to make a game. That said, I've dabbled in GDExtension, and if I really need to have something performant, I'll use that.
I've got huge amounts of respect for people doing it this way though. They have a level of control over their work that a Unity or even Godot developer cannot hope to have. It has, like any game dev approach, it's pros and cons
The one thing that perplexes me is that there are some annoying warts of Godot that make developing a game in it different than making a game yourself and nobody thinks "hey wouldn't it be easier to make Godot work in this way, than to do everything from scratch?"
The key difference is the code driven development workflow that makes it easy to keep different concerns like visual assets, collision boxes, navigation, etc separate.
If you do this in Godot, the standard editor features become meaningless, because they are optimized for throwaway workflows with extremely tight coupling (e.g. a player character IS a node containing subnodes, rather than the player character being a high level concept, whose nodes merely represent the player character).
I mean, you can do Godot this way - just make your player a scene with Node2D or 3D as the root instead of a PlayerCharacter and have it respond to input
The author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue.
Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slowing down your game unexpectedly? Is it only a problem for a certain class of games?
There’s a recent promising development relevant to the GC pause issue. It seems couple weeks ago some smart developer working for Microsoft has made a version of GC called “Satori” which pretty much solved these GC pauses for many real-world use cases.
An overview article: https://blog.applied-algorithms.tech/a-sub-millisecond-gc-fo...
Long discussion thread with many graphs with measurements: https://github.com/dotnet/runtime/discussions/115627
I don’t yet have hands-on experience with that Satori GC, though.
In a game like the author's where you just init/pool everything on load you can simply disable the garbage collector during gameplay.
So, does everything he said about C# sound about right? I have no real desire to use it, but I'm curious if his opinion was more or less accurate.
Not looking for a flame war, just knowledge
Yes, C# has had low-level primitives since 1.0 and it has only gotten better in this regard. This means that it's worse than Java at things like devirtualizing calls, but you can write allocation-free hot loops in C# these days.
It's also cross-platform and has multiple deployment modes: you can ship the runtime and the program separately (good when you control the end-user machines, like in an enterprise settings), you can tree-shake the runtime and ship it with the program, or you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary.
The JIT compiler is still better for long-running processes like servers, but for one-shot programs where the startup time is critical, like CLI tools and FaaS, the AOT compiler is really great.
> you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary.
The OP talks about doing this for mobile platforms, but could I take e.g. the OP's source code (he co-wrote Celeste) and trivially compile an AOT native binary for x86_64, or would more work be required to make that possible?
(Interestingly, Celeste on Linux doesn't use the dotnet runtime, but instead a portable Mono runtime which I believe is based on MonoKickstart. [1])
[1] https://github.com/flibitijibibo/MonoKickstart
That's kind of an engine though ? An engine is just a bunch of low level types, DS, algos that go onto build mid level abstractions that go onto form systems. In this case you can argue the game itself (aka the runtime) is the game engine?
As others say, getting data (Assets) in/out of the engine is the hard part. Especially as they are the real contribution to the shipped game been so large (unless smart compression, delivery optimisation is used, sadly not common).
Making a video game "without an engine" is basically another way to say "making your own game engine". Which is a fine thing to do, but you're "just" making a bespoke engine for one game (or series of games). Sometimes those engines get large enough to be used by others. That's why it's called "Unreal Engine", because it has heritage in the Unreal games.
A lot of the time the indie game developer is a former professional programmer. This of course affects how they interact with the game development process.
Someone who's coming from a different walk of life (say, an artist or a TTRPG designer trying to make a game) will obviously be much more productive with an off-the-shelf engine like GameMaker or Unity. They accept the engine with its editor as the only way to make a game and get cracking.
A programmer opens the editor and is presented with the 3D scene editor. "Nonono, where's main()?" they immediately ask. "Why is there a 3D scene editor if I want to procgen my levels?" "How do mods work?" "Who told you I needed physics simulation in my game by default?" "Running the game inside the editor is cool and all that, but I'd rather run the editor inside the game."
there is a minor mistake in this.." their minds jump to what it looked like circa 2003 - a closed source, interpreted, verbose...", C# was never interpreted. From the beginning, C# code has always been compiled to Intermediate Language (IL), which is then JIT-compiled by the .NET CLR at runtime.
To be fair, “compiled to bytecode which is JITted af runtime” is pretty common of lnaguage implementations described as “interpreted”, like CRuby.
I've never delivered a game anyone's really paid for, so take with a grain of salt, but imho the big win when you are writing your own stuff is you get to decide what not to include.
That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on - but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine.
Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right.
The list goes on and on... maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way.
Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc.
I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)
I agree with almost everything except:
> Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
When you're making an engine it's perfectly fine to bake in constraints. Probably most famously PICO-8 does that very intentionally and is written by just one person. Similarly RPGMaker and a bunch of other 'genre specific' game engines also do this. It's just that everyone tries to make something super general purpose which is really a Sisyphean task.
In the end of the post Noel mentions Aseprite, but he might be interested in Libresprite as well? https://libresprite.github.io/
Does it add much on top of the old GPL aseprite it forked from?
Isn't that a huge effort? I remember few games which developed their own game engines from scratch (factorio, limbo, bg3). But, wouldn't it be easier and better to use game engines like godot?
I suppose it depends where you draw the line between engine and framework. Factorio used parts of Allegro until 2018.
https://www.factorio.com/blog/post/fff-230
Engine these days implies one of those IDEs with everything included (scene editor etc). I don't know how or why, but language drifted in the last 20 years or so.
Maybe a dumb question, but what is the C# compiler and runtime that you use?
I used to be up to date with .NET and Mono and stuff but I'm 10 years out of date
Modern .NET/C# is cross-platform by default (CoreCLR runtime). You don't need Mono anymore.
I am not at all familiar with C# development, but the author mentions Native-AOT, which, from a cursory look, seems like a C# compiler.
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Hate to be mean, but this guys last game was a complete failure after multiple years of development: https://www.exok.com/posts/2025-01-22-earthblade-final-updat...
That's not a failure, it was just never finished.
And more because of personal matters than anything technical. I'm not sure why this is relevant.
Of course it was relevant. If they had a better game engine it would have been further along.
The article you yourself linked says the game's development troubles were from pressure to surpass their previous game which was a smash hit.
How would a better engine fix that?
They didn't need "a better game engine" to create Celeste.
make me a first person puzzle game
make me a first person puzzle game
make me a first person puzzle game
And now you can also just vibecode little games and start having fun right away, they are great for kids
https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088
https://openjam.ai/lonely_ant_702/v3nyt4if54
https://rosebud.ai
https://openjam.ai/
Why should less thought be put into things made for children?
Why do you think vibecoding and learning together with kids is putting less thought?
However, kids don't care too much about thought. They care a lot more about attention and fun
With these tools you get to the fun part faster and can give them a lot more attention
You also get to co-create with them and they get to express their creativity seeing results in realtime
[dead]
[dead]
[dead]
[flagged]
I agree with making games from scratch. That being said I thought Celeste was wildly overrated. Keep up he hard work though.
Please help me figure out the best way to share code between Github repositories...
I love C#, and I acknowledge Github as the king of source control.
I make a new Repository a couple times a week, and use Visual Studio Code to clone it, and open a terminal and "dotnet new gitignore" and then use dotnet to make new projects all over the place...
On multiple machines, even. On a VM on my NAS. On my Windows machine. On my Windows laptop. On a VPS.
And I'm happy.
But how in the holy hell am I supposed to share code from one repository to another?
I want to make VikingCoderLib as a C# library (classlib), and drop in all of my favorite Extensions for generics and strings, and etc.
And then make another classlib for some of my Protocol Buffer utilities. And another classlib for setting up a terminal.js console for an app. And...
What's the best way to do that?
Submodules?
They really seem to suck. I can't easily make changes here, and use them there, without it being a huge pain in the rear.
Am I doing this wrong? Am I missing something?
I don't mind submodules much. I mean when I first used them I thought it was sucked, but now I use it all the time for personal projects. I like to make small Lua libs or fork existing Lua libs and include those in a lib directory in my LÖVE / LÖVR projects. Works fine for me.
Perhaps the only thing that sucks a bit about submodules, might be if you work with multiple people and some reference of a submodule is updated and you need to go into the submodule directory to update the reference locally. But I think that's the only thing, no big deal. I don't think you deal with this issue much when you work by yourself on a solo project, on a single machine.
How does any other language do this? I bounce between submodules and monorepo for hobby projects and both approaches have some issues. I'm not a git expert so working with monorepos are a little easier to work with for me.
Make your own packages for your extensions and pull that packages into your projects that need to reference those extensions.
And set up my own nuget repo?
I want my code to be private...?
Yes you would set up your own nuget feed and publish as part of your build. You can set up the nuget feed on your own machine, use something like Teamcity or GitHub packages.
Monorepo?
I hate that you're almost certainly right.
It feels like there should be a good way to have a dotnet classlib in one repository, and use it from others, but it just doesn't feel like they fit together the way they should.
You can also see my workflow for patching godot engine so it's mergable on a rebased master or stable release.
> This project uses git-assembler to simplify merging patches on top of the latest stable release by allowing each patch to be in a separate branch, so they can all be merged into a fresh branch without complicating the revision history.
https://github.com/KeyboardDanni/godot-for-sidescrollers
I'm https://github.com/fire
I use git subrepo to make a monorepo.