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