4 ms·

> 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

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

Agentlien 5y ago
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.
- maccard 5y ago
  > 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!
  - Agentlien 5y ago
    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. ;)
    - maccard 5y ago
      > 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).
      - Agentlien 5y ago
        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.
simulate-me 5y ago
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.
csande17 5y ago
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.
- maccard 5y ago
  > 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?

Agentlien 5y ago

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.

maccard 5y ago
> 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!
- Agentlien 5y ago
  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. ;)
  - maccard 5y ago
    > 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).
    - Agentlien 5y ago
      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.

simulate-me 5y ago

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.

csande17 5y ago

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.

maccard 5y ago
> 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?