by selvan on 5/20/25, 5:54 AM with 246 comments
by samiv on 5/20/25, 7:58 AM
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.
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.
by JKCalhoun on 5/20/25, 11:49 AM
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/
by oliverdzedou on 5/20/25, 7:41 AM
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.
by danielbarla on 5/20/25, 6:50 AM
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.
by thorn on 5/20/25, 8:36 AM
Thank you for writing this post, Noel!
by msephton on 5/20/25, 2:07 PM
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
by throwawayffffas on 5/20/25, 9:27 AM
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.
by trollied on 5/20/25, 8:59 AM
by Lichtso on 5/20/25, 3:31 PM
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.
by kkukshtel on 5/20/25, 10:35 AM
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...
by z3t4 on 5/20/25, 8:47 AM
by leonard-somero on 5/20/25, 8:50 AM
by enbugger on 5/20/25, 12:47 PM
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.
by gr4vityWall on 5/20/25, 11:57 AM
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.
by doawoo on 5/20/25, 3:49 PM
- 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)
by hannofcart on 5/20/25, 5:53 PM
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!
by savory_pancake on 5/20/25, 7:22 AM
by zerr on 5/20/25, 8:20 AM
by interludead on 5/20/25, 8:18 AM
by ccvannorman on 5/20/25, 7:32 PM
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).
by tiniuclx on 5/20/25, 10:25 AM
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/
by noduerme on 5/20/25, 8:47 AM
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.
by Fokamul on 5/20/25, 12:29 PM
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.
by atoav on 5/20/25, 7:25 AM
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.
by RyanOD on 5/20/25, 5:09 PM
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.
by andreamonaco on 5/20/25, 7:41 AM
by Protostome on 5/20/25, 8:01 AM
If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
by sambeau on 5/20/25, 8:36 AM
by bitwize on 5/20/25, 9:45 PM
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.
by selvan on 5/20/25, 8:37 AM
by tosmatos on 5/20/25, 7:19 AM
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
by OnACoffeeBreak on 5/20/25, 11:22 AM
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?
by russellbeattie on 5/20/25, 9:28 AM
Not looking for a flame war, just knowledge
by EdgeCaseExist on 5/20/25, 12:06 PM
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).
by LocalH on 5/21/25, 12:57 PM
by orthoxerox on 5/20/25, 3:21 PM
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."
by codeproject on 5/20/25, 1:02 PM
by dakom on 5/20/25, 8:42 AM
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)
by HelloUsername on 5/20/25, 8:11 AM
by varbhat on 5/20/25, 9:57 AM
by lucraft on 5/20/25, 10:01 AM
I used to be up to date with .NET and Mono and stuff but I'm 10 years out of date
by BryanLegend on 5/20/25, 9:00 PM
by wdhwy on 5/21/25, 2:41 PM
by 1a2b3c4d5f6e on 5/21/25, 2:39 PM
by gogogaga on 5/21/25, 2:39 PM
by nico on 5/20/25, 1:47 PM
https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088
by slowhadoken on 5/20/25, 8:06 AM
by VikingCoder on 5/20/25, 2:48 PM
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?