That's a false narrative, game engines don't create games that look the same. Actually one of the funny propositions (not serious) that a fellow game developer had on social media was to instead replace the default game engine logo with a custom one, just to avoid this narrative that gets repeated. Outside of asset flips, most people can't tell which engines create which games without that giant logo alerting them. Then it creates this bias of "oh yep that's a unity game!"
Shader compilation has more to do with dx12 than it does game engines. Game engines try to encourage developers to handle this appropriately, but there is no one button automatic handling yet. You would also run into this issue in your custom game engine unless you avoid vulkan/dx12 entirely.
I have no scientific basis for disagreeing, but from my own experience, I can definitely tell with >50% accuracy whether a game was build with Unreal or Unity, especially for indie games. For Unity it's something about the materials and lighting that seems to give it away, for Unreal stuff like over the top focus effects and such.
Technically, from what little I know about these I don't see why you couldn't make a game look exactly the same in both. But I guess what's easy to do and what the respective community commonly does have a notable impact? Or maybe people self select for one or the other based on what games that align with their sense of aesthetics use one or the other?
One of the great things about both Unity and Unreal is that both engines let you get a basic project up and running quickly. Throw in a cube, give it controls and movement, and build a little level, and things basically work. The game engines have handled physics, lighting, shaders, camera, etc without you needing to touch them.
The tipoffs you are detecting are those game engine default settings. One distinction between them is that Unreal has motion blur, camera aperture effects, and some fancy lighting configured by default. Unity is more "basic" by default. For small projects, a dev is focusing on other things rather than pouring a lot of energy into how light reflects off surfaces or whatever. Each engine is capable of really unique looks, but they also look pretty good even if a dev doesn't touch it.
Yeah most of it stems from the asset marketplace. If you look at Unreal's marketplace or Unity's asset store and sort by top seller (and especially the free categories), you'll probably find exactly the things that you're talking about. From particles to sounds. Great resource, but a lot of developers don't really customize them much and they tend to be the things people are noticing per engine.
You are on the money regarding self-selection as well. A small team is probably going to pick Unity due to all the preconceived notions, and alongside this will probably create similar looking visuals to other Unity games due to a reliance on the asset store if their team isn't heavy on visuals. It might seem like I'm focusing too much on the asset store, but it goes for custom assets too where even if you're working smartly, you have to blend those premade assets with custom ones. If you're on a large team working on an Unreal game, it's probably going to be realistic looking for example so you're limited based on what lighting makes the skin look good, what particles make sense in a grounded world, and so on.
It's technically possible, you're only going to run into problems when you then try sharing assets from different stores (audio and textures excluded), where you now have to recreate it from the ground up to match in that other engine. So you're also right about that aspect!
As real examples of the flexibility of modern game engines, Octopath Traveller Yoshi's World, and Arkham Knight were made on UE4. For Unity; Cuphead and Escape from Tarkov.
As a player, Unity games seem to have some issues with stuttering especially on resource load (e.g. first time a new enemy type appears). It happens to a degree that is surprisingly bad, given the relatively low fidelity of a lot of titles compared to games of that past that ran better on worse hardware.
I recall Ori and the Will of the Wisps being particularly bad for this. It was unplayable when it was installed on a HDD, and when I moved it to SSD it still had major stutters during racing segments where the goal is to traverse the map quickly (and presumably, load a lot of assets on the way).
>game engines don't create games that look the same
sure they do. Like anything else in software, what defaults you set will drive the course for a lot of user behavior. You make a downvote button and users will start to use it to say "I disagree" or "I don't like this comment", even if you remind them everytime that the downvote button is not a disagree button.
Of course you can dig deep and change every default, but few studios in the grand scheme of things will bother if the default is good enough.
This is especially so with 3D games. 2D games has less of this problem, as you tend to rely more on the assets for art direction than fancy lighting or in-engine geometry creation and the default lightings for 2D stuff is simply your basic shaders with sprite textures.
I agree with you in spirit, but reality tends to show otherwise.
Shader compilation has more to do with dx12 than it does game engines. Game engines try to encourage developers to handle this appropriately, but there is no one button automatic handling yet. You would also run into this issue in your custom game engine unless you avoid vulkan/dx12 entirely.