[Animats]

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.

[opan]

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.

[TheRoque]

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

[ben-schaaf]

Arc Raiders is a great example for why UE5 is the reason games run poorly. It neither uses Nanite nor Lumen. Valorant goes even further and uses a custom forward renderer. The studios that care about performance avoid using the big headline features of UE5.

[vvanders]

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.

[raincole]

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

[smallstepforman]

The thing about custom engines is that by the time it supports all the features you need, you’ve worked your mindset into optimal engine usage, so you end up being more performant on a hacked engine vs suboptimal code on commercial engine. Home grown always has some unique flavour.

[raincole]

It might be true in some very special cases, but if a programmer can't make games like Crab Champions (the example used in the grandparent comment) performant with Unity/UE, they should be nowhere near to a custom engine.

[Waterluvian]

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.

[patch_dev]

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.

[rustystump]

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.

[patch_dev]

I have to disagree again sorry. I can't speak to being able to "spot a unity or unreal game from miles away," but if you want to make a game, make the damn game not an engine.

I get the feeling there is a serious survivor bias happening here. Individuals who are talented and knowledgable enough to roll their own engine, make it well and quick enough, maintain motivation AND cross the finish line to actually make a game likely make a pretty good game. Now consider all the other people who tried this path and got stuck along the way. Now you're gonna recommend all that complexity and difficulty to someone because you think games should "feel" unique. Like, its just not based in reality sorry.

I think there are 2 reasons to roll your own game engine

1. Making a game isn't your top priority and you're interested in game engines

2. No existing game engine does what you need it to do and you have enough experience/knowledge to know where you're going

If you're decision is based on "I want my game to feel unique", "it might not be performance enough" or some other immaterial and ethereal concept I fear you're gonna be set up for failure.

Noita is a perfect example of when to roll your own. They push the boundaries so much that they absolutely need a custom engine. Path of Exile, another example where their vision REQUIRED a custom game engine.

[rustystump]

I started out writing my own engine. Never finished a game. Switch to unity and finished two then hit industry.

Both games were mediocre if I am generous.

The janky demos i made with the custom engine felt and looked so much better. I even had folks on forums asking if they could join the project.

The issue is if everyone uses the same unity standard shader, lighting, posteffcts, etc, it ends up with a certain smell. The effort it takes to work around this requires implementing the version of the given components that better match the vision. Most custom game engines still use a plethora of libraries replacing the ones that matter. It also isnt so binary. Earlier box3d post was literally catalyzed by Unreals physics engine lacking some 3 line of code.

I think what you are really speaking to is that few people have the discipline or motivation to complete anything. The two games above that I completely were in a large part because i actually sat down wrote a design doc, made a schedule, and stuck to it aggressively reducing scope.

I recently wrote an article showing just how easy it is to make a game engine using css box shadows as the renderer, web audio, and a stupid simple tween system. I think it illustrates pretty well that people vastly overestimate what a engine is.

Edit: https://dgerrells.com/blog/how-to-make-a-game-engine

[raincole]

> I can spot a unity or unreal game from miles away. They have a smell if you will that is very hard to escape.

Confirmation bias. Are you saying Hollow Knight, Cities: Skylines and Escape from Tarkov have the same kind of "smell"?

It's as ridiculous as saying that you can spot a SaaS written in Rust from miles away.

[JoeyJoJoJr]

For 2D games I can usually tell if it is made in Unity, and I don’t even develop with Unity. Hollow Knight for instance does not get me immersed like I do for Celeste or Bolatro. When I look at Hallow Knight I see moving animated sprites instead of characters, and it’s like that for the majority of 2D Unity games for me.

[Chinjut]

When you look at Super Mario World, do you see moving animated sprites?

[lowbuzz]

Yeah, there are some unreal "slop" games, even big ones, that just look like UE5 looks with kinda default settings, but there are also games made with these engines that look nothing like that.

[setr]

The smell is 50% the asset packs available in the respective stores. The other 50% is the default character controllers and the default lighting settings

[torginus]

I think you assume most people want to compete with Unreal on visuals. That's of course borderline impossible. But getting a basic renderer and game loop going isn't really that hard, and likely won't be the majority of your game's code. Just doing drawObject() in a for loop is good enough, you don't have to think hard about optimizng if your game is simple enough, or all the concerns about resource streaming, binding optimizations or parallelism can come later if necessary.

> Building a game engine takes about two years to get to the My First Renderer point.

I wonder what starting point and success criteria do you assume for that 2 year timeline. About a year ago I wrote a deferred renderer with dynamic lights, and shadow mapping, and few post effects in about a month of free time (Less than a week of full time work).

> This is why most indy games now are 2D. That's do-able. Often in HTML/JavaScript.

I don't think that should count against them. Most serious works is done on 2D interfaces. And both WebGL and plain old 2d canvas are very capable nowadays. And quite a few hit indies are 2D.

> If you want a job, be aware that the game industry sucks

Sure but basically everything uses the GPU nowadays. Writing and debugging ML workloads, data visualizations, HUDs and just user interfaces in general requires some understanding more often than not.

[RicardoLuis0]

> I wonder what starting point and success criteria do you assume for that 2 year timeline. About a year ago I wrote a deferred renderer with dynamic lights, and shadow mapping, and few post effects in about a month of free time (Less than a week of full time work).

i'd assume it means fully understanding what you're building, if you already know 3d graphics or are just copying example code around, sure you can build something quick, but to fully understand the concepts from a background without previous graphics knowledge takes time and dedication

[kkukshtel]

I work professionally on game engines and also have my own custom engine. Watching the space for 15+ years, I would say that nearly _every_ custom game engine exists as a demonstration of graphics capability, not anything to do with improving the actual experience of game development. This is in part to do with the fact that working on 3D at all is a slippery slope towards continuing to work on graphics stuff.

[globalnode]

i guess the hn peanut gallery sometimes just doesnt like the message and downvotes it

[deliciousturkey]

Games industry might suck on average, but I'd argue that graphics programming niche does not. There are lots more users of graphics than games, like visualization, simulation, etc. Coupled with the fact that good graphics programmers are extremely rare, it's a surprisingly good career. This is in very stark contrast to game developers, artists and so on, which seem to have much harder time getting good quality jobs. Of course, both job market supply and demand is small, so changing jobs might not be easy.

I'd very much argue against somebody making game development their career, at least from job security grounds. But graphics programming is different.

[ex-aws-dude]

Agreed, it’s not really the same as being a gameplay programmer which is what most people think of as “gamedev”

It can pay quite well at large studios or tech companies if you work outside of games and the hours aren’t necessarily bad, it depends on the project

[purple-leafy]

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.

[TeMPOraL]

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

[deliciousturkey]

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.

[raincole]

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

[Twisol]

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.

[echoangle]

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.

[torginus]

Yeah the browser is sadly underused, especially for indie games. Js is plenty fast for most indie games, there are a ton of libraries, dev tooling is good, and all the APIs you could ever need are wired in. There's also an 'escape hatch' with WebAssembly for better performance when you need it.

[qingcharles]

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.

[rustystump]

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

[qingcharles]

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.

[charlie90]

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.

[sfn42]

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.

[thelaxiankey]

If you could beat Godot and Unity in two weeks with AI, why doesn't everyone just do this?

(A: there be dragons)

[Chinjut]

What is the advantage of asking AI to build an engine cloning these existing engines, vs just using these existing engines.

[someonebaggy]

I'd like to see evidence for this claim.

[kleiba2]

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

[Negitivefrags]

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.

[nnevatie]

There's also plenty of us creating our own engines for the games we develop. Whether the mentioned games ever get finished is another topic...

If it's all for a hobby, creating your own engine is a lot of fun by itself.

[the__alchemist]

Related to graphics programming in rust: One reason to get into graphics programming is if there aren't any engines that suit your purpose that are available for your programming language of choice.

If I wanted to program a 3D game, I would choose UE5. I'm not, however: I made my own engine (`graphics` crate) and own vector/quatrnion lib (`lin-alg` crate), used by no one other than myself, to view chemistry and molecular bio visuals, with convenience controls etc. And it's suitable as a general purpose engine for rendering simple, non realistic scenes. I'm surprised I had to do this, but didn't find any suitable existing solutions.

[bmitc]

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.

[flohofwoe]

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

[bmitc]

I have looked at Godot before but each time stayed away from diving into it for various reasons I can't remember at the moment. I thought about creating F# bindings for it at some point.

How are the Rust bindings? How would it compare to using Bevy?

[imtringued]

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

[EnnEmmEss]

Isn't that GP's own 3d engine?

[Zecc]

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

Where does Fyrox sit in this?

[andai]

Two years? Why does it take two years?

[flohofwoe]

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

[TheSamFischer]

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.

[dahart]

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.

[flohofwoe]

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

[TheSamFischer]

I’m certain there’s enough actual game engine code in the datasets that with enough token spend, you could have a platform layer, basic renderer, entities moving around.

There would be absolutely no point in creating one over using one that exists and since there’s no learning that’ll come of it, it’s kinda wasting money.

[flohofwoe]

Sure, but that part is only the "trivial 10%" of what's called a game engine these days. The actually important and much bigger part is the tooling.

[TheSamFischer]

Absolutely. tooling is very rest of the owl when it comes to building something rather than just working with debug data.

[legends2k]

Two if you're lucky, and work full time on it. More like 5+ plus if you are inexperienced/part time.