You're 100% correct that this looks like a lazy hack job, though.
It seems like some kind of fork of the Unreal Engine, because you're right that some of the assets in this game really do look like they came right out of the asset store.
I actually said the same thing in another comment elsewhere discussing it with some people about how much of a lazy UE5 asset-store rip the game was, and I was corrected as well and they informed me about the team using their own in-house engine. But I'm still skeptical because it has the same floatiness as the UE5, same animation sets, same jankiness, and it even has the exact same pop-in issues that games have that use Nanite in open-world settings.
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.
You're 100% correct that this looks like a lazy hack job, though.
It seems like some kind of fork of the Unreal Engine, because you're right that some of the assets in this game really do look like they came right out of the asset store.
I actually said the same thing in another comment elsewhere discussing it with some people about how much of a lazy UE5 asset-store rip the game was, and I was corrected as well and they informed me about the team using their own in-house engine. But I'm still skeptical because it has the same floatiness as the UE5, same animation sets, same jankiness, and it even has the exact same pop-in issues that games have that use Nanite in open-world settings.
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.