Hacker News Reader

Comment by Townley | Hacker News Reader

It's interesting that this phenomenon is much more prevalent in game development, as opposed to (for example) web development: some people build their own web development frameworks, but it seems like every game dev tries to make an engine at some point.

My theory why: good web frameworks consider developer experience to be of paramount importance, and invest heavily into examples, documentation, and API improvements. Unreal and Unity by comparison are unpleasant to work in. The UI is clunky, the examples cap out after a certain point of complexity, and community input is almost nothing when compared to the Django, Express, Rails, or language-specific ecosystems.

Anyway, I can't say I've ever made it far enough down the rabbit hole to want to make my own language... but I know for me, the desire to make my own engine* has punctuated every attempt over the years to get better at both Unity and Unreal

*Acknowledgment that I might be partially disproving my own point, as I've tried to build both my own web framework, AND my own game engine... but I spent a lot more time on the game engine (https://github.com/RobertTownley/gamehook)

View on HN

I would hazard that game engines are an order of magnitude more complex than web frameworks. A better analogy may be game engine vs db engine or web framework+runtime(ex: Erlang/Elixir+Phoenix). If you have performance issues with a web framework you can scale it horizontally to a degree(depending on downstream dependencies like your DB). Games are built to run against resource constrained hardware and so they optimize for specific usage patterns.

There's also the issue that most engines are built to be good at a specific game type and may make trade-offs in terms of how assets are managed and scene complexity. An open-world has much more different requirements than an on-rails shooter. For instance I had to do some pretty heavy retrofitting of one of those engines to handle LoD/geometry streaming and a bunch of other optimizations to make them work well with a large sight-distance game.

Depends on the game engine, most 2D ones are quite comparable.

No no, browser contain components similar to a game engine, browser are way more complex, and frustrating, because you do not control the specs.

Depends on what the game engine X and Web Framework Y are trying to achieve.

That's true, but you can see new open source engines rising becoming a serious choice to make games. Not so much for web browsers.

Depends on the motivation and how much of ChromeOS one wants to implement.

https://twitter.com/awesomekling/status/1508953394836353024

I’d go an order of complexity above again. The real comparison is to the browser, particularly for general purpose engines like Unreal and Unity. I’d hazard most game engine teams are bigger than most browser teams.

I disagree. Modern web browsers are the most complicated pieces of technology we have today. The amount of work that goes into sandboxing and security alone probably eclipses the complexity of game engines.

That seems very optimistic when compared to some of the bigger engineering projects we have going as humanity. Aircraft carriers and nuclear submarines as a whole system (including the multiple computer networks and their software) are much more complex than browsers, to say nothing of one-offs like the ISS (lots of cutting edge hardware but also full of software) and the systems controlling modern factories. Browsers don't even come close.

I think it's kind of hard to quantify complexity in a way that compares nicely across domains. For example, a lot of the complexity in a browser comes from needing to service ~billions of users across thousands of devices using loosely implemented standards. This is quite a different problem to building an aircraft carrier, where you're going to run in to hard engineering and physics problems but you only have to target ~10k well trained users.

Web frameworks are nowhere near as complicated as browsers

I’d go an order of complexity above again.

Not when you start. While UE5 is no doubt orders of magnitude more complex than any web framework, no one sets out to write UE5. In fact most people start writing their own game engine because they want something a lot less complex and more tailored than what is available.

If you have the right background knocking out a very simple game engine isn't hard. Many people do it as part of a university course. The problem is that your 'simple' game engine ends up being not that simple very quickly once you start adding features.

Right which is why in the following sentence I limit it to general purpose game engines like Unreal and Unity.

Making a toy browser is something you can do as well.

Yea, my point was related to why people so often write their own game engine (and so rarely write their own browser). Writing your own game engine for your own game looks fun and easy from the outset. And in fact, depending on your game, writing a game engine that lets you ship that one game doesn't even have to be complex.

Right but there are smaller scale browser-like things as well which have a more vibrant DIY scene like Gopher, Gemini and so on. We shouldn't take a narrow view on what a browser is if we're not going to do that for a game engine.

For me, at least, I like to write my own engines to get the end-user experience I want. Every game engine comes with a million little decisions about how games should work by default, and writing my own engine lets me make those decisions for myself.

In the same way, every React app eventually starts to look and act like the Reddit redesign, but many web developers consider that more of a benefit than a drawback.

That might be because there is a lot more creative freedom in game development because playing a game is essentially an exercise in coming to an understanding of the underlying dynamic. And a game is played for fun.

Conversely users of a web app generally don’t want to invest any time in understanding its underlying dynamic and instead want something that works in a familiar way. So we optimise for that.

That many react apps look like that is not a react thing but a design thing. You can make a react app that looks like HN. Or like a game!

You can make a React app that's wildly different to all the others, but if you follow "best practises", and you learned from the same tutorials, and you're using the same component libraries as other React devs your app will probably drift towards looking and working like other React apps unless you make a conscious choice to stop that happening.

Yeah, one difference between React and, say, Unreal Engine is that Unreal Engine is the brand for the whole package while React is the brand for one of the core components. ("I'd just like to interject for a moment. What you're referring to as React is, in fact, React/Redux/Tailwind...")

Once you've bought into the whole ecosystem, you get an "engine" that wants your app to look and work a certain way just like how Unreal wants your game to look and work a certain way. You can customize it however you want, but every decision you don't make is made for you by the engine.

And even when you are making the decisions, the engine is always there, nudging you in a certain direction by making some things easier than others.

That is just not true, no matter how hard you try to make it seem that way.

There is some truth.m to that. Tutorials need to decide where to focus on React but want to make you feel like you are building something cool so they will bring in style frameworks to assist so you can focus on the react.

I assume this is also true for jquery/angular/vue and other library tutorials.

Maybe just for fun they should use alternative frameworks!

Then on the job, well unless you are a designery company it will be devs who do design and will happily delegate that thinking to a framework. Again not a react thing but a general dev thing.

I have seen this too in desktop apps of 90s. Just use MFC or some popular toolkit.

"In the same way, every React app eventually starts to look and act like the Reddit redesign, but many web developers consider that more of a benefit than a drawback." - Erm, nope. You might be talking about people relying on UI component libraries, which has nothing to do with React.

I've been using React full time almost since its first release and I somewhat agree with the previous comment. While the choice of framework usually doesn't really restrict what can be done; it's often easier/harder to do specific things with a given framework.

For example; animations responding to user interactions are easier to do in frameworks with an OOP approach. It is generally more "different" in a declarative way. So most React apps simply don't have those. There are lots of small things like this that over time make React apps feel Reacty.

> every React app eventually starts to look and act like the Reddit redesign,

Not every unreal engine game starts to look and behave like gears of war. If you drop a bunch of asset packs from the store it's going to look like every other asset flip out there, but so will your game engine if you use the same assets.

> , I like to write my own engines to get the end-user experience I want.

My day job is working in unreal engine, and in the last 7 years of using it I can only think of one scenario where the engine was the limiting factor in the user experience I wanted, and not something I could easily work around. If you think you're going to be limited in your end user experience in unity or unreal you probably need to reconsider how much you know about those engines.

In essence I agree that the big engines very seldom get in the way and should be good enough for almost any project.

However, I will say that I've constantly (during 10+ years of working full time with various game engines) come across cases where I need to extend or modify the engines I work with to either fix bugs or add missing features.

To take a fairly recent Unity example I worked on a game using the Universal Render Pipeline (URP) and found myself having to implement some things I just couldn't understand were missing. For instance, URP supports a depth prepass for opaque objects but still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass.

Just binding the already generated one instead allows you to get a lot of free depth culling and in my mind is one of the main reason to use a depth pass. But in URP it was apparently used exclusively to feed depth information to shaders.

> I will say that I've constantly (during 10+ years of working full time with various game engines) come across cases where I need to extend or modify the engines I work with to either fix bugs or add missing features.

Agreed wholeheartedly, and this is part of game development. Sometimes that comes in the shape of adding features that are straight up unfinished, other times it comes in bugfixes/workarounds. I hope my original message didn't come across as "there is no work involved in using a preexisting engine!"

> To take a fairly recent Unity example I worked on a game using the Universal Render Pipeline (URP) <...> still uses an empty depth buffer on opaque rendering instead of utilising the one generated during the prepass.

Presumably implementing that was _far_ less work than writing a URP yourself, and that's before you take into account the benefit of the art/design pipelines being able to use the render pipeline for the X months it would take you to write one yourself.

That example doesn't effect the "user experience" of the game either (which is what the GP comment claimed they wrote their own engines for), but that's not to say it's not worth doing!

It was absolutely a tiny amount of effort in comparison to developing your own fully featured render pipeline. As is anything I've had to do. That is, after all, the point of using a commercial engine. It does the heavy lifting, I just need to tweak it.

> I hope my original message didn't come across as "there is no work involved in using a preexisting engine!"

Absolutely not. I've come across the argument about making a game for the end user experience before and it always strikes me as a case of not understanding the capabilities of your tools. I just wished, more for others who come across this than people with our experience, to add that some modification of the tools is to be expected.

> That example doesn't effect the "user experience" of the game either

Let me finish by saying that it's true, unless you count your game having stable frame rate on weaker platforms as part of the user experience. ;)

> Let me finish by saying that it's true, unless you count your game having stable frame rate on weaker platforms as part of the user experience. ;)

While this is true, it's also not a "given" from a custom engine and needs to be planned for. It's a big ask for a team to reimplement their renderer as a forward renderer, but it's a checkbox in UE4 (plus reimplementing all the materials etc).

I certainly agree. I'm really not arguing for writing your own engine as anything other than an excellent learning exercise. I've written my own engines and renderers (both forward and deferred) and I'm more than happy to rely on whatever engine we happen to be using at work to solve most hairy issues for me.

Many Unreal games released around the time of the original GoW did look very similar though. I think it was the lighting. Two examples: Bioshock and Batman Arkham Asylum.

I don't think anything is impossible in big commercial engines. I mean, IIRC Unreal Engine gives you a Visual Studio project containing all of the engine's C++ code, so theoretically if you use Unreal your game could be any legal C++ program.

But as a practical matter, using Unreal turns every decision you make from "what behavior do I want" into "what behavior do I want and is it worth fighting Unreal on this", so Unreal games are a lot more Unreal-y than they otherwise would be. (This is especially true on PC, where things like "how are the game assets organized on disk" are visible to end-users.)

Particularly on the 2D hobbyist stuff that I do, writing my own engine is less work than becoming an expert in an engine I don't really like so I can change most of it.

> But as a practical matter, using Unreal turns every decision you make from "what behavior do I want" into "what behavior do I want and is it worth fighting Unreal on this",

I don't agree with this at all - Unreal gives you defaults that can be easily replaced. The decision is "do I use what unreal gives me or do I write my own" for most systems, compared to "do I write my own or do without" if you're starting from scratch.

> so theoretically if you use Unreal your game could be any legal C++ program.

That's a bit reductionist, and not really fair. All of the "behavioural" parts of the engine are exposed in very customisable ways. As an example if you're not happy with the collision detection behaviour/triggers, they are designed to be modified and changed around. If you're not happy with character movement, you provide your own character movement definitions.

> (This is especially true on PC, where things like "how are the game assets organized on disk" are visible to end-users

If your definition of end user experience of a game is file layout on disk, then so be it. Knowing that something is made with unreal engine doesn't immediately turn it into another copycat unreal engine project. Besides looking at the disk layout, you could also just see the splash screen that you're legally required to use when licensing the engine. Also, you have source code to the engine, to the automation process, and the pak tools. If you want a different layout on disk, go ahead and change it.

> Particularly on the 2D hobbyist stuff that I do

If you want to do hobbyist engine development work, _that's_ a great reason to write game engines. Not "liking" an engine and wanting things done differently isn't the same as wanting something that's incompatible with a game engine's design and architecture. If you want a lock step multiplayer game with rollback then sure, you're probably not going to find it. But if you want "less floaty" character physics, or a different camera perspective, a different startup flow/implemention, you can _definitely make that within the bounds of Unity and Unreal

> writing my own engine is less work than becoming an expert in an engine I don't really like so I can change most of it.

You definitely don't _need_ to be an expert in an engine to use it, any more than you need to be an expert in python to start writing some scripts. Also, how can you know how much of the engine you need to throw out before you actually know how to use it?

I think part of it might be learning how to ask good questions. I wrote a terrible terrible C compiler for a class. But I learned so much about the choices between doing things the slow but probably correct way, vs the cool but hard way, or even the jaunt into esoteric decisions. This more than anything else in my career taught me how to evaluate random software. As a professional, or even serious hobbyist, I think it's a good idea to dive deep, build one yourself. Really get a feel for the tradeoffs and hassles of different choices.

Even if nothing goes anywhere, it'll improve your craft.

This comment speaks to me. I hate modern web development but I always want to build user interfaces so one day, I thought to myself "Why don't I start from scratch and make my own protocol and write a browser but only for the terminal?"

So that's what I've been doing and it's been a lot of fun. A lot of the time I'm pulling concepts from HTTP but what's great is that I can be very picky. Maybe I'll end up just rewriting HTTP but at least I'll understand deeply why all of those decisions were made.

If you want to build user interfaces, I'd recommend learning Cocoa or Qt, which are both well-designed UI libraries. (Java/Swing is okay, but Win32 has a limiting design, and MFC is crap. Was pretty unimpressed with Android's UI, but haven't really used it enough to have a quality opinion.) HTML was designed for documents and its model is unsuited for UI. If you're going to learn for research first, then in my opinion you'd be better off learning how to do it right, and then if you still want to use the DOM, you'll have a better idea on what would be an effective framework to make/use.

Part of the reason I chose the terminal because it's basically the same on all platforms.

I've worked with a lot of game engines, and indeed made my own engines and editors.

My reason for making my own was partly that it felt like less work to write what I needed than to learn the intricacies of an existing engine. Also, back then the big engines didn't have as generous licenses as now.

As for Unity and Unreal: I found them both very easy to get into and get productive with.

Probably, many programmers played videogames when they were little, so there's always an underlying dream of creating one.

I dabbled in games development, but I've met the same problem; videogames development is actually much more than programming (the engine), and the creative part, which is the primary one, may not appeal people who are technically-minded.

This phenomenon is very visible in Rust; there are several game engines, but very few production quality games. The most famous game engine, Bevy, is very popular, but after approximately two years of development is still an alpha (and a very changing one); contrast this with Fyrox, which is much more stable, but is considerably less popular (essentially, unused).

Both industry leaders and indie programmers have used Unity and Unreal to make finished games. Large studios may opt to create their own engines at one point or another, but even with all their resources, these custom engines don't always work out.

An example of this would be the frostbite engine, of which multiple devs at EA reported that it was an absolute nightmare to work with. Turns out, if you need developers to work on the engine at the same time the game is developed, you just lose manpower to actually engineer your game. [1]

[1]: https://www.usgamer.net/articles/ea-frostbite-engine-history...

I worked with Frostbite for five years. The engine is very capable. It's also developed in a vacuum with very little exposure to actual game development.

It's used to create fancy new features and show them off in tiny toy projects. Then it's handed off to developers to make actual games and the issues begin.

The biggest issue with Frostbite was always that its developers treated it like an ever revolving set of cool new projects. There was always some fancy new system meant to replace the old one in just a few years and never any fixes for the shipped and still broken systems.

Making a game is at least an order of magnitude harder than making a website. Web apps are constrained by the protocols upon which their built (mostly the lifecycle of HTTP requests). Games are gigantic state machines that also require complicated rendering cycles. Unity and godot et el ARE good developer experiences in that they remove much of the complicated stuff even if the abstractions they use require them to be a bit clunky.

This is only true if you talk about the average website, and the average game. Because there is a lot of wordpress spam.

I can practically guarantee that any given AAA game is less complicated than the horrible morass of complicated system requirements a multinational company can invent for their internal systems.

Mostly because it’s designed to approximate reality, which is complex.

Making a game is at least an order of magnitude harder than making a website.

Ridiculous statement. Making a polished AAA game is orders of magnitudes harder than making a React ToDo Clone. Making a Tetris or Snake clone is orders of magnitude easier than making Gmail. With engines like Unity you go from never having written a game to a shitty 3D fps game in a weekend.

I pondered this for a while, still not sure why.

It could be the connection to the physical world. There is something satisfying about working with geometry and differential equations.

The realtime constraints force you to care about performance, which many people find a fun challenge.

Your output is the frame buffer instead of the DOM. It's more of a blank canvas.

Most web development is utilitarian, whereas games are more artistic.

I am not sure, but I would love to be a game engine developer in another life. I have zero interest in web framework development.

Take a look at Godot. At least then it will be "our own game engine" rather than "my own game engine".

Speaking of making a language for an engine for a game...

There's the Mono version that supports C#, which is also faster than GDScript already, if it's at all a (real) sticking point. And you can use C/C++ or Rust if you really want.

Web developers may not create their own frameworks as much as game developers, but many spend a lot of time switching frameworks, libraries or simply just rewriting existing applications. I see this tendency at work, where the relatively simple React app has been rewritten 4 times in a couple of years. The recent hires would rather rewrite it from scratch than to refactor / improve the existing one. Apparently, the 5th rewrite will solve all problems with the first 4...

When I was a kid, I had this messed up idea in my head that if I used a game engine then the resulting game wouldn't be one that "I built". It's like I built this "Unity game" rather than I built this game. I don't really buy into that mindset anymore nowadays, but I guess there's something to be said about how the tools we use influence the products we produce.

> [...] prevalent in game development, as opposed to (for example) web development [...]

Everybody made their own framework before some of those became popular. And people are constantly producing new frameworks. Because it always will be more entertaining and meaningful for someone to build a framework/engine that feels good than yet another app/game.

Not to mention many compiled to js languages made by and for webdevelopers.

Because making websites isn’t near as fun as making games.

Reply on news.ycombinator.com