Comment by Animats
12 hours ago
Do you want to make games, or do 3D engine programming?
If you want to make games, use an existing engine. Unreal Engine, Unity, Godot, and Bevy are good choices. You'll learn the higher level issues of graphics, not how to push pixels around. The real problem is making it fun.
If you want to do 3D engine programming, be aware that there are too many bad game engines. In Rust land, where I am, there are three failed renderers, one unfinished one, and the one inside the Bevy engine. Those are the major projects. There are many other "I'm going to build a game engine" projects. Building a game engine takes about two years to get to the My First Renderer point. Getting to big, highly detailed, dynamic scenes is a much bigger job. Be aware of the scale difference between the first demo and a useful engine.
If you want a job, be aware that the game industry sucks. Pay is lousy, hours are lousy, jobs end when the project is completed, and, like Hollywood, there's an army of wannabees wanting in. Also, right now, because of the collapse of the Metaverse thing, there's a glut of experienced people.
Then there's mobile. Everything is a cram job. Not enough screen, not enough compute, not enough GPU, not enough battery.
This is why most indy games now are 2D. That's do-able. Often in HTML/JavaScript.
The amount of otherwise decent games that run poorly due to Unity or UE is very unfortunate. I wish people would stop recommending this stuff. I do hope Godot and Bevy are better, but I'm not sure if they are.
To name some games with very bad perf issues that I've played in the last couple years: Core Keeper (Unity), WORMHOLE (Unity, mostly see the lag in endless mode), Crab Champions (UE4, have to use nonsense upscaling stuff that makes the game hideous just to maintain 60fps at 1920x1200).
Meanwhile Terraria, Necesse, and Barony use their own engines and run great, they have aged like wine.
Out of fairness, I'll say Tiny Rogues (Unity) usually ran pretty well from what I recall, though the dev is actually working to move off Unity in the future, so he has clearly found issues with it himself.
I know there is the argument of making a game vs making an engine, and actually getting a game done and shipping it, but when you put out garbage you aren't gonna have a very positive legacy. I think it would be better to take the long way and ensure some level of quality. Games are often played for decades after release and if they are buggy or laggy, people will continue to run into that forever.
> The amount of otherwise decent games that run poorly due to Unity or UE is very unfortunate. I wish people would stop recommending this stuff. I do hope Godot and Bevy are better, but I'm not sure if they are.
Games don't run poorly "because of unity or UE", those engines are highly optimized for the graphical fidelity they provide, It's super easy to find examples of games that run flawlessly with these engines (UE5: Arc Raiders, Unity: Arknights Endfield). Seriously, this narrative is ridiculous and needs to stop.
Some games with those engines run poorly because no matter the engine, if the developers don't take the time to optimize their games, the result will be an unoptimized mess. Is Unity engine responsible for the fact that Cities Skyline 2 devs decided to render the full polygons of every individual's teeth no matter the distance ? There are a ton of tools built in to handle level of details and they didn't use them...
I doubt those unoptimized games would do any better and in a shorter time if the studio had to build their own engines, or with any other available engine. Bevy is too barebones to be compared, and Godot is not as capable as Unity/UE.
As someone who's worked professionally with these engines I'd largely agree.
The other thing to keep in mind is that engines are build towards certain strengths/game-types. Trying to do open-world in UE3 required making some fairly invasive and substantial changes as the engine was built more for somewhat on-rails shooter. It didn't support geometry streaming and a number of other things that are needed to seamlessly transition between large open areas. I remember a number of MMO-style games used UE3 purely as a rendering front-end and mostly built the game tick, physics and netcode back up from scratch.
There are "tells" for engines if they aren't tuned properly(i.e. it was really easy to tell UE3 by the 30s frame hitch as the periodic GC ran) but a fair bit of that can be addressed if the team wants to put in the time to enhance or rework the systems involved.
> The amount of otherwise decent games that run poorly due to Unity or UE is very unfortunate
The amount is approximately zero. If someone write badly optimized code with Unity they have 200% chance to write badly optimized code with their own engine.
Today I discovered, fell in love with, and returned Tainted Grail because it is horribly, terribly optimized. Apparently the PS5 version is so bad that it’s an offense to nature. Which is sad because it’s apparently a phenomenal game.
Though maybe it wouldn’t have even existed if it wasn’t for Unity.
This is a really bad take, sorry.
1. Engine choice is only a factor in performance. If you build an unoptimised game it will run poorly. Doesn't matter if you do it in Unity or your own engine. 2. Terraria, etc did not succeed because they use their own engines. 3. Those bad performance games have bad performance and happen to use an engine, not the other way round. 4. The quality of your game has a lot more to do with effort, care, etc than the engine you choose to use. You can create a buggy piece of crap no matter how you make it 5. Performance alone is a bad reason to roll your own engine. "Existing engines are not performant so you should roll your own" is a very bad piece of advice. 6. Making a good engine is HARD and a lot of effort. There is no guarantee that you produce anything better because you chose that path.
I always argued for custom game engines not for performance but so your game “feels” unique. I can spot a unity or unreal game from miles away. They have a smell if you will that is very hard to escape.
Every game that has a custom engine just feels unique and interesting in a different way. I think this is why people likely push the custom engine. Any game that passes the finish line on a custom engine often has a level of craftsmanship you dont see in standard engines.
Oblivion remake while looking good only works because the underlying logic is the same. I personally do not like the visual feel of the remake as it screams asset pack to me.
4 replies →
> Do you want to make games, or do 3D engine programming?
Yup. If you start making an engine, you probably won't make a game - especially if you're learning along the way. It's technically possible to succeed at both, but having gone through this process many years ago, and having watched dozens of others in our Polish hobbyist gamedev community do the same, chances are under 5%.
"I'll do an engine for my game first, so it's easier to make the next game" - it's a surprisingly strong trap, because you are actually learning important things and winning small victories every day. There's always another win around the corner. Just one more unroll so the scene looks smoothly. Just one more logic layer to the config format, so it's easier to make the scene. Just one more SIGGRAPH paper.
There's always something important to improve. None of that adds up to a complete game. In retrospect, I'd say, writing your own engine is a perfect way for technical people to procrastinate on the hard but necessary parts of making their dream game - "making it fun", as you mentioned. You end up mastering all the skills that add up to coding an impressive video game. You never learn how to make a game.
(Subtrap of that: you learn a hundred ways to make beautiful visual effects that run smooth in real-time. You never learn how to use that to make art.)
--
(It just occurred to me this is very similar to the trap of "Enterprise Java" - except more insidious, because you're working with concrete terms. Your Scene Graph has no Factory Factory Interface, so you think you've dodged that bullet, missing that it's just unnecessary for the task of putting a bitmap on the screen and making it react to keys.)
At least personally, the point of graphics programming or making "engines" is not to make games. It is to make real-time graphics, implement interesting approaches etc. If you are making a game instead of an engine, you will probably never focus on the graphics / rendering part, and instead need to focus on gameplay, 3D modeling etc. For many people this is explicitly not what they want: They want to make engines, not games.
I don’t agree necessarily that if you want to make games to use an existing engine in every case. For most cases it’s good advice.
But existing engines are so “general purpose” and full of assumptions about your game. Maybe your game requires different constraints?
Especially for 2D. For instance I’m building a game, powered by my custom game engine, that specifically focuses on performance and compression and no server or database in the loop.
My engine has very specific structure and assumptions about how my games must be structured, to reach pretty extreme performance and compression scenarios based on the constraints I set for myself and my game. (Hackernews post about it soon, I’m hoping next week)
I tried building my browser game so many times previously - first with unity, then godot, then react (lol!) - but having to learn the apis sucked, and the engines were not able to meet my extreme constraints (also attributed to me not being good with the engines). But looking back, I still don’t think what I’ve achieved internally would be possible without a custom ground up engine.
But I’ve learnt so much building my own engine and game.
Especially now with LLMs, I think it’s reasonable for experienced devs to try build their own custom game engines, it’s suddenly in reach for most developers.
> This is why most indy games now are 2D. That's do-able. Often in HTML/JavaScript.
Most indie games are definitely not in HTML/JavaScript unless you count vibe coded ones.
I can't speak to "most", but the incredible CrossCode displays the HTML5 shield on startup, so indie games on the web stack do exist and can be amazing.
I would be surprised if you can find any platform with graphics output that someone hasn’t published a game for. Having one game says nothing.
Agree with almost all of that. Unless you are targeting some obscure or old platform, I don't even know how you'd justify trying to write a 3D engine from scratch in 2026, except as a fun learning experience.
Also, think about tooling. Last time I wrote an engine from scratch, the tooling to support it probably took way more time than the engine did.
AI changes this a lot.
You can realistically get a featured 3d engine+editor up and running in a couple week with AI, working solo. Probably better than what Godot or even Unity gives you. Also AI is very good at editor/tooling stuff, I've even found it getting better at graphics programming stuff, just telling it to 1-shot implementing gpu occlusion culling, ddgi probes, taa, etc. type of features. Also for stuff like animation, I just told my AI "clone Unreal's animation blueprints" and I have a pretty featured animation system now. "clone Unity's particle system" and it 1-shots it in an hour with the runtime and nice editor tools. With the advantage being you can just implement exactly what you need.
Oh man I can't wait until you release a fully featured game engine less than 2 weeks from now that's better than both unreal and unity.
I'd like to see evidence for this claim.
While the sister comment is down voted, they are not necessarily wrong. AI absolutely makes custom 3d engines easier to make because the math is very well understood.
Most games do not need 90% of the features 3d engines have. A simple geometry batcher with a bog standard rendering equation and simple single directional shadow map will go a very long way. I can confirm AI has been able to one shot this for well over a year.
However, dont expect to churn out nanite overnight
You can definitely get it to make a custom 3D engine easily. I asked Gemini 3.1 Deepthink (or whatever the Ultra version is called) to make me a 3D engine that ran in CGA on 8086 XT in x86 assembler, and it one shot it perfectly with filled polys, backface culling etc.
> Pay is lousy, hours are lousy, jobs end when the project is completed, and, like Hollywood, there's an army of wannabees wanting in.
Well, in that case, I'm going to go into academia!
I am not a fan of this take.
It's possible to not make an engine, or use a 3rd party engine. You just make a game. Use SDL or something. It's honestly easier and more fun. Definately don't use Rust.
It doesn't take two years.
The more you focus on making gameplay, and not making an engine the better. Which sounds like similar advice to "use an existing engine", but it's not, because using existing engines is also a pretty sad time. You can waste just as much time farting around in Unreal as you do making your own engine.
At the end of the day, most people are just not serious about making a game. Using someone elses engine, building from scratch, both will work if you are actually making a game and not just wasting time.
Two years? Why does it take two years?
Because 90% of the work on an engine goes into the tooling (DCC tool exporters, asset pipelines, editor tools, ...), e.g. the "actual" engine runtime is just a small (and frangkly: quite trivial) thing dangling off the end of the asset pipeline. And game engine tools development is a never ending rabbit hole that's never quite finished (UI tools development got much easier though thanks to Dear ImGui).
IME two years sounds about right starting from scratch until getting everything into a state that can be called a basic game engine (if a bit optimistic). You can start earlier building a game on the in-progress-engine of course and tbh that's the only way to not develop an entirely useless engine. But that way you'll also end up with an engine that's mostly only useful for that one game, and progress on the game will be atricious in the first year or so. And of course developing both side by side means spreading the butter even thinner.
In the end though I have seen at least as many game projects fail using an off-the-shelf engine (in that case: Unity) compared to using an inhouse engine. The decision to use inhouse tech versus off-the-shelf engine doesn't make or break a game, in the end the failure always lurk within the team (but the engine is usually blamed first when things went south heh).
Unless you’ve written one before, it’s the natural learning curve.
You can always generate one using LLM if you don’t care about how it actually works.
And if you have written one before, it might take five years. ;)
At least, that was my actual experience at a game studio. The engine team wanted to rewrite the engine but underestimated how much was there, how much was worth keeping, and how much work needed to be done. But that was a long time ago, and the studio’s now on Unreal.
> You can always generate one using LLM if you don’t care about how it actually works.
Lol, right. That might work for some of the runtime parts of a very simple engine, but not the other 90%, especially when you "don't care about how it actually works".
A game engine (like UE or Unity) easily exceeds the complexity of an entire desktop operating system (not necessarily in line count, but in number of features, their diversity and complexity).
Two if you're lucky, and work full time on it. More like 5+ plus if you are inexperienced/part time.
Yeah if someone wants to do 3D engine programming they should consider reviving rend3 [0] instead of starting their own project.
[0] https://github.com/John-Nagle/rend3-hp
Isn't that GP's own 3d engine?
I want to do something different. I want to make desktop applications that utilize 2d and 3d graphics. These aren't games, and so while game engines can work, they are a heavyweight fit. And this is certainly not game engine programming, although there may need to be a way to program a 2d system rather than relying on the litany of 2d graphics libraries that all have major limitations.
Godot is actually a good choice for that use case and compared to Unity or Unreal Engine fairly lightweight:
https://docs.godotengine.org/en/stable/tutorials/ui/creating...