The engine they claim they're using, the Neox/Neoaxis engine, looks exceedingly similar to Unreal 4/5, based on looking at screenshots of their editor.
Can't be sure if they just emulated Unreal's UI design or if they actually tried to reverse engineer or swiped some code to create it. Looking at the documentation, class names, etc I'm not seeing a lot of distinct similarities.
Actually more distinct differences really, like Neox having a built-in native C# scripting support. While also supporting C/C++ (I'd assume the core engine code's built on that. Unity does the same sort of thing). Also seems like the default mesh format might be obj, where-as Unreal's is usually Maya/Autodesk's FBX.
As for the "floatiness" you describe in UE4/5, that's not necessarily an engine quirk I think so much as a quirk with how game developers will sometimes approach programming their hit detection. Some of these studios tend to be more concerned with basic functionality and stability, and so they'll take safer, faster, over precision and responsiveness.
Admittedly, there may be some aspects with the engine's default configuration for certain things that might play into how "snappy" things feel, but I've not gotten too deeply into investigating it.
There are a couple of areas in the engine I've wondered about though. Namely, the tickrate, and/or something about how animations are handled and processed in relation to character movement and inputs. If there actually was something going on with one of these two areas though, it should be doable to adjust things to be less floaty.
I notice that a lot of Unity-made games have -- as you put it -- much snappier response timing and animation and inputs are far more precise. It makes sense why devs making platformers and side-scrollers prefer Unity over Unreal as one of the reasons for that. I think it's also because of so much of the bloat in the Unreal packaging due to having to support a lot of third-party plugins and libraries, most devs just settle for the default physics instead of fine-tuning it as you mentioned.
The engine they claim they're using, the Neox/Neoaxis engine, looks exceedingly similar to Unreal 4/5, based on looking at screenshots of their editor.
Can't be sure if they just emulated Unreal's UI design or if they actually tried to reverse engineer or swiped some code to create it. Looking at the documentation, class names, etc I'm not seeing a lot of distinct similarities.
Actually more distinct differences really, like Neox having a built-in native C# scripting support. While also supporting C/C++ (I'd assume the core engine code's built on that. Unity does the same sort of thing). Also seems like the default mesh format might be obj, where-as Unreal's is usually Maya/Autodesk's FBX.
As for the "floatiness" you describe in UE4/5, that's not necessarily an engine quirk I think so much as a quirk with how game developers will sometimes approach programming their hit detection. Some of these studios tend to be more concerned with basic functionality and stability, and so they'll take safer, faster, over precision and responsiveness.
Admittedly, there may be some aspects with the engine's default configuration for certain things that might play into how "snappy" things feel, but I've not gotten too deeply into investigating it.
There are a couple of areas in the engine I've wondered about though. Namely, the tickrate, and/or something about how animations are handled and processed in relation to character movement and inputs. If there actually was something going on with one of these two areas though, it should be doable to adjust things to be less floaty.
I notice that a lot of Unity-made games have -- as you put it -- much snappier response timing and animation and inputs are far more precise. It makes sense why devs making platformers and side-scrollers prefer Unity over Unreal as one of the reasons for that. I think it's also because of so much of the bloat in the Unreal packaging due to having to support a lot of third-party plugins and libraries, most devs just settle for the default physics instead of fine-tuning it as you mentioned.