Can you tell us what engine limitations you ran into with Unity? I'm genuinely curious.
I'm actually surprised this surprises anyone. I mean, I've been working with Unity for about 8 years and there was always some sort of friction. I've also never met a dev who wouldn't experience such friction in Unity. It's a general-purpose engine, its submodules are designed certain way and despite the best effort, it's impossible to cover any and all use-cases devs face. I was told by other devs in NB that along the years, they even tried to get source code license from Unity on several occasions but, well, Unity's financial demands were quite...
unholy, to put it lighly.
Anyway, in this project, they were usually smaller things. A good example is the implementation of pixel-perfect sprite interactions. There is no way to make that natively, with some built-in component, since all interactions (done with raycasts) are physics-based in Unity (AABBs and octrees, I would assume), even in 2D. So I had to implement a workaround for that. Other things are mostly API-related. Either it doesn't expose some functionality you need, data you want to use, or generally it's just implemented in a way that doesn't really suit your use-case. Usually, you can, again, get around it, but it also usually adds a lot of boilerplate code and/or rather strange scene/gameobject setup, or something else that is
extra. Good example is the Tilemap submodule. The tools that come with it don't support sprites we use, they are made for sprites that are shaped like the grid cells. We use hexagons for placement but the sprites are obviously shaped differently. So we had to make our own tools. There were also limitations in how sorting works in Tilemaps, there is very little control over how the draw commands are issued. We had to figure out the scene structure and quite complicated layering structure to get it right. And you know, I'm quite
pedantic with these things. Getting a functionality done is not enough. It should also be simple to understand, simple to extend and simple to maintain. Because there are other people working with it, and some of them are not tech-skilled. And the more workarounds and hacks you make, the more obscure and complicated your projects become.
This is just from top of my head, it's not a list of all problems we ever had, just a few examples. Now, I'm not saying Unity is bad and nobody should use it, actually I usually advocate for the opposite. We could definitely make this game in Unity. But we opted for a custom engine in the end. It's not just technical reasons behind that decision, there's more to it, like financial independence and others. Anyway, I hope that answered your question. I'm sorry if some of the answers sound somewhat vague, but I just don't want to go into too much detail about the development process, it's not
my project so I try to be respectful to others in the studio.