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.

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.

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.

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

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.

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.

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

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.

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.

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?

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

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.