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.
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.
Making a toy browser is something you can do as well.
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.
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.
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.
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!
> 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. ;)
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).
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.
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?
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.
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.
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.
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.
Even if nothing goes anywhere, it'll improve your craft.
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.
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.
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).
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...
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.
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.
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.
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.
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.
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)