Here's my biggest issues with Unreal Engine at the moment, and subsequently, games (especially UE games on PC) that use it:
-
For starters, the default settings for Unreal projects are hilariously bad, some of which are exposed deep in the editor settings, the others requiring config tweaks on the developer's side.
For example, every Unreal Engine project ships with Vert- FOV scaling by default (As a massive middle finger to ultrawide users, despite how trivial it is to fix), and also has mouse smoothing and sensitivity that scales based on the FOV enabled (resulting in mouse input feeling wonky, this was actually one big complaint people had with Atomic Heart's release). The former is a problem because it causes the FOV to zoom in the wider the resolution aspect ratio (While keeping the intended horizontal space by adding to the top and bottom for anything less than 16:9), and due to Epic not giving most developers an easy way of fixing this inside of the editor, most games either don't bother switching this, or they result to pillarboxing/letterboxing the game camera (There is a practical reason this is done, because when testing in the editor, it zooms in the wider the viewport size, which can happen if you have the browser on the bottom of the screen, or need to expand the inspector), even if the game and it's UI elements display properly otherwise.
Unity doesn't have this problem, most games use Hor+ by default, and with some tweaks, you can support both rather easily (Overscan scaling with physical cameras with a 16:9 sensor size). Even Fortnite uses Major Axis scaling (Something which switches between Vert- and Hor+ based on the aspect ratio, that way both 4:3/5:4/16:10 and 21:9/32:9 resolutions are accounted for while leaving 16:9 at it's intended viewing space). I will at least admit that Unreal handles calculations for the FOV properly now, where it had issues with older versions of the engine (As it took horizontal FOV values like 45-50 degrees rather than vertical ones like 90 degrees), but this seemingly has become locked down in a way where you cannot overwrite it using config tweaks (Garten of BanBan is a UE5 title that comes to mind straight away when I think of this). Singleplayer games that explicitly lock down or overwrite config tweaks on startup (SpongeBob The Cosmic Shake, Monkey King, and Final Fantasy VII Remake come to mind) are especially egregious about this.
If the amount of Unreal Engine games on PC that ship with these issues became a drinking game, I'd probably die of alcohol poisoning. I've practically boycotted making mods for any of these games, because it's monotonous, and it's going to be an uphill battle unless awareness is actually brought around the subject (Hogwarts Legacy, HiFi Rush, Days Gone, and Returnal are seemingly the only games I've seen that don't do this luckily, but their PC ports don't feel like glorified Xbox debug builds). -
Secondly, Epic's policies regarding distributing editor tools to non-Unreal licensees throws a wrench in the possibility of offering modding tools (Something of which was never an issue with Unreal Engine 3), and even then, there's some massive technical limitations that need to be kept in mind. If you're wondering why the only mods for Unreal games nowadays are just model swaps, rather than extensive gameplay modifications (Something which was possible thanks to how open UnrealScript was, similar to Unity games shipping without IL2CPP) or custom content, this is why.
For starters, I've only seen developers release modding tools on GitHub (in the case of Hatred) using some tools that hook into their API to check if you have your Epic Games account tied to GitHub before downloading the tools, modding tools only on Epic's launcher (In the case of Ark: Survival Evolved, Hello Neighbor, or Chivalry), or stuck to using a generic Unreal Engine project with some custom plugins that requires a binary build from Epic's launcher (I've seen Pavlov do this, but there's no real explanation on how they approached doing this).
The UGC Example project that Epic released on their GitHub requires using a GitHub source code build of the engine (Which balloons up to nearly 200GB at this point), which severely limits how you can distribute engine tools. It hasn't been maintained. If you want to save to the Saved Games folder instead of LocalAppData or My Documents (like what games should've been doing for years), or if you want to have custom shading models like toon shading without arbitrary limitations, then you have no choice in the matter, as a lot of things are hardcoded in the engine's source code. Even after you overcome those obstacles, you are stuck with Blueprints for any gameplay logic that you want to have modular (Which poses performance and legibility concerns, as what this Tumblr blog would show). Epic has yet to release UnrealVerse (their middle-man scripting language between Blueprints and C++), and most of the Lua or C# plugins that I've seen for the engine have their fair share of limitations that make them more of a proof-of-concept rather than something shippable for a game. SookumScript (Which Epic acquired) hasn't been maintained in years. -
The way that Epic is handling shading models in the engine severely limits what kind of visual style you can go for (Which is why most Unreal games including stylized/NPR games are using PBR rendering), unless you do a custom fork of the engine, due to how hardcoded a lot of that stuff is with the material editor and how rendering is handled. It's nowhere near as "just works" as Unity, S&Box, or even Godot (All of which mostly operate using shader files), and you have to manually change a ton of the material editor's source code and manually expose specific properties that you want to modify to GBuffers. The engine doesn't even give you the option of selectively forward shading specific objects (like Unity) if you need flexibility, despite Unlit materials being forward shaded.
For example, Toon Shading is a contentious topic, unless you want to spend the time to properly implement it into the engine, all of the alternatives have noticeable issues or limitations. Emissive/Unlit Materials require using Blueprints to emulate point lights and directional lights (and none of these allows for stuff like dynamic shadows), Post Processing materials have inherent limitations (For example, per material shading colors, unless you want to deal with the complications of stencil buffers) and shading problems from long distances (Due to how most effectively subtract the albedo texture buffer from a desaturated version of the output, including reflections, SSAO, and Global Illumination). Switching the engine to Forward Shading is an alternative (and there are ways where you can expose material properties as shown Here and Here) that has been proven (In games like Guilty Gear Strive, where the MSAA option that is available makes perfect sense in hindsight), but you end up cutting out a ton of Unreal's deferred rendering features as a result (Yes, this includes the ability to use GPU lightmass to do precomputed lighting).
Before anyone says anything about Strata, that material system for Unreal is mostly for layered materials (For example, rain drops on a dry material) rather than anything that needs a custom BSDF. I decided to give it a try during the afternoon, and it's use-cases are rather limited outside of layered materials (as I mentioned). Strata is not a custom shading model system like I've seen most (that aren't versed in Unreal Engine development) claim. -
The controller support in the engine is in a dire state. There is no good way of offering support for anything other than Xbox controllers on PC, and Windows GameInput (the only real alternative to SDL outside of SteamInput) is probably going to take a while to be supported.
For starters, XInput is the only officially supported input API that's actually shippable without much work being required (Which means you need third-party drivers to use literally any other controller outside of Steam, and more often than not results in ports of games only having Xbox prompts on PC).
The Steam Controller plugin has been rendered irrelevant since SteamInput offered XInput emulation (If you look at the engine source code for the plugin, it simply emulates an Xbox controller alongside a mouse for the Steam Controller trackpad, and really should be deprecated at this point as it uses long deprecated Steam Controller API functions).
There is no good way of having a proper SteamInput implementation on Unreal Engine at the moment (for most people). The engine is still using a fairly older version of the Steamworks SDK (That lacks proper Steam Deck or DualSense controller support, the ladder which has been around in Steam for three years already), and some of the third-party Steamworks API plugins that I've seen on the Unreal Engine Marketplace and GitHub require a lot of external work and completely ignoring how the existing input system works (For example, manually polling for inputs each frame). It's nice that those plugins exist for when you need extended functionality, but the Steamworks SDK problem makes it hard to do anything recent without modifying engine code. There was a overhaul to the Steam Controller plugin that was being worked on a few years ago, but progress on it halted, and there are limitations such as Axis Actions (the thing responsible for analog input) not working and the plugin technically binding actions to the first key (Which means it's not separated from keyboard and mouse input). I personally cannot blame them for it, as getting the other systems working would require engine modifications and pull requests to have added to the engine. From my time implementing SteamInput support into a Unity game, it's far less of a headache.
The way that Epic (and to some extents, Sony) handled PlayStation controller support on PC has been insulting at best. The two current solutions that are available have problems, and a majority of the SDL plugins on the Unreal Engine Marketplace have significant problems with how it hooks into systems that are painfully difficult to ignore.
For starters, the WinDualShock plugin:
* Requires libscepad libraries that are only accessible from PlayStation SDKs. For many reasons, this is not an ideal solution, and for those saying "yOu NeEd To HaVe A sOnY SdK lICeNsE tO sUpPoRt ThEsE cOnTrOlLeRs" fail to take into consideration that there's other ways to go about implementing said controllers without using libscepad. Unity's New Input system is a prime example of that.
* Outright refuses to work over Bluetooth (You can see this with the native controller implementations for Returnal, Days Gone, Fortnite, and Like a Dragon: Ishin). You can also see this phenomena happening with other games that use libscepad for native support, unless you are willing to spend a decent chunk of money on an official adapter that isn't sold anymore and used to cost $25-30 USD. The only way that you can fix this is to use DualSenseX to emulate a DualShock 4 being connected over USB. Due to how terrible Bluetooth has been in Windows for years (And how neglegent Microsoft has been towards fixing anything for the better), that's also why headset functionality and DualSense functions like haptic feedback are unavailable over Bluetooth.
The other option, Windows RawInput, is a DirectInput implementation for Unreal, but it requires a lot of manual work to work properly, and is busted over Bluetooth for reasons I'll get into:
* For starters, you have to manually adjust the bindings for controllers based on the Vendor and Product ID listed in the device manager. This is quite a streneous process for different controller types, and the way that analog values are handled are completely different for each controller makes finding the correct values in the project settings more painful than it has to be. This plugin was originally designed for flight sticks and steering wheels, not PlayStation (or even Nintendo Switch) controllers.
* There is also a problem where Bluetooth connected controllers will have completely different layouts from USB connected controllers, and this still hasn't been addressed in an engine update, resulting in button prompts either being completely missing unless you're explicitly using a DualShock 4 over USB (in the case of Tony Hawk's Pro Skater 1+2) or completely scrambled (in the case of Code Vein's usage). The only way that you can fix this is to use DualSenseX to emulate a DualShock 4 being connected over USB.
The way that I see it, games should be checking if SteamInput is enabled, and then grabbing the controller handle type through that, at the bare minimum. Games on Steam use SteamInput by default, and you explictly have to disable it to use any natively implemented controller support. Otherwise, it will be recognized as an Xbox controller (and have Xbox prompts), if it's not using it's action based rebinding system.
Certain individuals in Unreal Slackers or the Unreal Developer Community just telling people to "just use DS4Windows", a third party driver, as a workaround is lazy at best (I'm sorry, while the lazy developer claims are stupid, there is a legitimate point there), and shows that most people that frequent those communities just dabble with Blueprints (and never interact or have to deal with any of the engine's low-level systems) at worst.
Epic's reluctance to fix a majority of the issues with their engine (that have been around for years, mind you), alongside the state of their launcher (throwing money at free game giveaways and exclusivity deals, hoping that will fix the problem that nobody outside of Fortnite fans want to deal with their slow launcher while open source alternatives like Heroic Games Launcher (that work on Windows, Mac, and Linux) to Epic Games Launcher have been doing way better in that regards) while touting themselves as a savior to PC Gaming is extremely tonedeaf at best, considering Valve has actually put in the effort to make PC Gaming more tolerable. How plug and play the Steam Deck is in comparison to a Windows HTPC/Handheld (and having a ton of features, like decent controller support and Gamescope with it's per-game resolution/scaling/framelimiter profiles) should be good evidence of the fact that Valve has actually put in effort into UX.
While PC releases of games have been a bit of a meme as of late, and SHOCKER, all of them are using Unreal Engine. The engine itself has become a red flag for a bad PC release, setting aside the problems it has for developers. Some people are quick to pin the blame on the shader compilation stutter (Plauging Unreal Engine games using DX12) for example on something the developers have to do, but Unreal Engine is marketed as an easy to approach game engine similar to Unity, there's a reason why I think part of the problem of games incorrectly using FixedUpdate in Unity (Stuttering above 50FPS that cannot be fixed by the end user) is also partially Unity's fault. Why issues like asset streaming stuttering (That still happens on DX11 and Epic has yet to add DirectStorage to UE5 on PC to help make asset streaming less of a pain, despite it being finally released) also still exist is pretty indicative of this too.
I got tired of waiting for Unreal Engine to improve. It's been nearly ten years, and I still don't think I can ship a game using the engine with the level of polish that I'd expect as both a developer and an end-user. Most of the features they've been adding as of late is solely for virtual production, rather than fixing any of the legacy code that still has problems. I've moved to Unity, and I've been looking at Godot since v4.0 released. I really like how much more modular Unity is without needing a low level C++ architect with intimate knowledge of the engine's API on board (Speaking of, Unreal's C++ documentation is still embarassing and poorly documented). I can implement most of these things without problems solely created by Epic. The engine is scalable, but some of Epic's decisions and developer decisions constantly go against that philosophy.