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