Just wanted to share my experience, as I finally decided to go for the Flax Engine for a new solo game project.
I have been using Unity for over a decade across many different kinds of projects (games, visualization, VR, and so on), so I thought my transition experience could be useful to others looking into a change of environment.
My main motivation to move away from Unity is their licensing model, which is too costly for small independent startups like mine. The cost also feels unpredictable since they can apparently change the terms at any point.
The second reason is that Unity has become bloated and slow to work with. Thousands of micro-pauses, leaving me staring at the progress bar every day, started to hurt both my productivity and my sanity.
Iāve been working with Flax for just a week, so these are just my initial thoughtsāIām still very much in the learning phase.
PROS
- Responsiveness: Thereās no noticeable delay after changing a scriptāit can be tested immediately. This is such a huge relief compared to Unity, which loves throwing progress bars at you for every tiny change. This alone is reason enough to switch.
- Easy to learn: Flax is set up very similarly to Unity, both in the IDE and the API, making the transition much smoother.
- C++ integration: Itās great to have the option to use C++ for extra processing power in a seamless, integrated way. Many engines support multiple languages (e.g., Godot with C# and GDScript), but Iāve never liked that approach. Who wants to learn a proprietary language just for one engine? It also feels like a waste of resources for the engine devs that could be better spent improving the engineās core functionality. Flax does it right by providing access to a modern, high-level language like C#, while also offering an accessible way to use optimized native code through C++.
- Up-to-date .NET support: Flax supports the latest .NET versions, such as .NET 8, and I assume soon .NET 9. In contrast, Unity is stuck with outdated .NET versions due to legacy support. Modern .NET versions bring critical improvements, which are essential for competitive AAA game development.
-
Thoughtful design: The more I explore Flax, the more impressed I am with how thoughtfully itās designed. For example,
OnDebugDrawallows you to render shapes and text directly in the editor view for debugging, its neat and avoids having to cluttering the code with switches or remembering where to disable debug visualizations manually in the release. - Modern 3D engine: Flax is clean and optimized from the ground up, without being bogged down by legacy support. Itās fully PBR-based, unlike Unity, which gradually adopted a PBR workflow while maintaining compatibility with outdated systems. Unityās patched-together pipelines and quirks can be frustrating, and in some projects, I spent more time figuring out workarounds for bugs than actually developing the product.
- Stability: Despite its relatively small user base and limited real-world testing, Flax has been remarkably stable. I havenāt encountered serious crashes, bugs, or the illogical workarounds that Unity often demands.
-
Meaningful feature set: Everything in Flax feels practical and usable. I anticipate using 70-80% of the engineās features in my game, compared to only 15-20% in Unity. While this might sound like Unity is more capable, its extra features often get in the way. I frequently found myself fighting Unityās āhelpfulā abstractions, which would break or block progress. Itās like Unity insist holding your handāonly for you to realize the hand is attached to a torn-off zombie arm.
- Cutting-edge technology: Flax includes modern features like automatic LOD, tessellation, terrain streaming, and networking. The engine feels like it was built by someone who truly understands the needs of game developers. It gives me a sleek, modern Unreal Engine vibe, whereas Unity feels more like a patchwork of ideas thrown together over time.
CONS
- Limited documentation: While the API is reasonably well-documented, there isnāt much support from forums or third-party sites yet. Many developers rely on LLMs these days, but GPT-4 often struggles with Flax due to limited training data, sometimes fabricating methods or defaulting to Unity code. Would really like to see more samples, getting my head around how the animation system works without samples showcasing it has been time consuming for example.
- No Asset Store: Unityās Asset Store is massive and provides solutions for nearly every need. You can port Unity assets to Flax, but non-art assets will require additional work. Personally, this doesnāt bother me much since I often prefer sourcing assets elsewhere, like GitHub for code and other sites for art and music.
-
Uses cm as units: Using 1/100 m as a unit is one of those annoying legacy quirks often found in computer graphics. I assume this was adopted from Unreal Engine, which likely used it to handle the lack of native floating-point precision in the old days. In a modern engine, this approach doesnāt make much sense. For example, I built my own 2D physics engine for this game, and constantly converting between units is a headache. For large worlds, sacrificing the range of floats to achieve sub-millimeter precision feels unnecessary.
This also leads to another awkward issue: the engineās dual support for double/float precision coordinates, which seems to be a solution for the range limitations caused by using cm as the base unit. This results in a lot of code being written twice, with switches to choose between double or float. Supporting dual precision seems time-consuming and adds complexity that could be a source of potential problems. In my opinion, sticking uniformly to floats and using meters as the base unit would be a better approach. It would provide a 100x larger range, which is more than sufficient for most cases, and it would also improve compatibility with existing code. That said, I do appreciate the reasoning behind supporting doubles, as it makes large, open-world games more accessible.
Now, the good news is that, from what I can see, Flax Engine 2.0 will adopt meters as the standard unit. I just hope this change doesnāt lead to the kind of legacy support bloat that Unity struggles with, given how fundamental it is. Personally, Iām fine with porting my game to 2.0 with the new units if it means having a cleaner engine. - UI system: I havenāt had much time to explore the UI system yet, but it does seem a bit lacking. To be fair, Unityās UI system isnāt great either. The new UI Toolkit is a buggy mess in my experience, IMGUI is outdated, and Unity UI, though still my favorite, lacks many basic widgets. From what Iāve seen, Flax uses a code-heavy, Unity UI-like approach. For example, I couldnāt make a button and bind a method call to it directly in the inspector, as you can in Unity. I had to write some code to handle event binding. It also seems to lack support for rich text tags and advanced text rendering, like text outlines, which you get with TextMesh Pro. Overall, the UI system feels bare-bones, but thatās not necessarily a bad thing.
CONCLUSION
Iāve only scratched the surface after a short time with Flax, but the transition from Unity has been overwhelmingly positive. Flax feels clean and modern compared to the convoluted, bloated experience Unity has become. My productivity has noticeably increased, and the learning curve has been manageable.
Iām excited to test the upcoming Flax Engine 2.0, especially its adoption of metric units. Each update has brought meaningful improvements, and Iām optimistic about the engineās future.
Iāll share more insights as my project progresses. Hopefully, this journey provides useful takeaways for anyone considering the switch from Unity.
Finally, a huge thanks to the talented team behind Flax Engineāyour work is incredible and deserves more recognition! 