I’m looking at alternatives, mainly Stride, Flax, and Godot. Does anyone have experience porting a large Unity project to any of these?
So Godot does support C# - and overall it’s a very competent engine. Though from my experience you won’t be able to port much of your extant code over to it. The differences in structure between Object/Components and the Godot Node tree change things up a lot. You may be able to reuse a lot of your base data structures, if you are using things like scriptableobjects for a lot of things, that may not be too hard to convert. Another thing compared to unity is that I’ve found the C# language server doesn’t do you quite as many favors in your code editor with godot, unfortunately. Practically the only way I was able to use Unity was with auto-suggestions for class members/methods/etc.
I don’t have enough experience with either stride or flax to give a recommendation either way. I do hear that for better or worse, Flax has a pretty fast update cycle, but I’m not sure what that means in terms of how often they get breaking changes.
From this list it seems like your focus is mostly on C#, one thing I’d recommend while checking things out is that .NET 7 is actually a pretty big deal compared to other releases. NativeAOT support is a pretty huge development for C# game development - it’s going to make multiplatform and console porting much much easier for developers, particularly smaller projects that aren’t going to get direct support from those platform’s teams. this is a pretty simple read about what nativeaot is and can do, and why it’s good for games
The Unity debacle has made me think about putting together a sort of larger thread for sharing+explaining useful tools, resources, engines, and libraries, so i’ll probably start that later today
Oh - my local game development group is about to host a workshop on migrating from Unity to Godot in a bit over an hour. Hopefully they save a recording or something, but it looks like they are planning on a repeat session at a later date
I did try out Flax a bit today. I mostly focused on researching some tasks that are particular to my use case. My overall impression was mixed; I could probably do the things that I need to do, but they would be generally more difficult than doing them in Unity. I found creating GUI elements in particular kind of frustrating, and the documentation overall is very sparse. One thing that baffled me is that member references to some classes are serialized into the inspector as references (as I expected) and references to other classes are serialized as encapsulated objects. I’m not sure what determines this.
I will try Godot next, but it sounds like porting to that would be even more work. I also hear mixed things about its C# support.
Okay so I thought about this a bit more over dinner and wanted to frame my opinions/recommendations a bit differently.
I think if you are doing some research into things, there may be other ways of looking at them than just what it would be like to port things. I think no matter what someone switches to, there will some things unity has that other things just don’t, where you’d either have to wait for support, or find a workaround. So looking at them in terms of features alone probably doesn’t do every option justice.
I can’t really comment on what tools would feel best and most intuitive to work with, because it really depends on what elements of Unity you liked or used the most, but I’d definitely put a lot of emphasis on what feels really comfortable to work in. Based on initial impressions though it does seem like Flax would have the most familiar UX. Past that I’d think about:
Community, support, docs - These three things kind of go hand in hand, the bigger one is, the better the other two are. This also applies to things like 3rd-party libraries and tools that would hook into the engine. Out of three above Godot probably has hands-down the biggest, and obviously with unity shaking things up it’s getting a ton of attention now. When you inevitably get stuck or hung up on an engine-specific bug this kind of thing really matters.
Stability, Longevity, Battle-testedness - In terms of C# engines, I don’t think anything compares to the number of actually shipped games from MonoGame. MonoGame and FNA have pretty much been the backbone of self-started indie games for over a decade, though it’s hard to tell because it’s not really an engine in the same sense. You’d basically be starting from scratch is the downside. There are a lot of frameworks built overtop it but I can’t speak to them. It also isn’t as focused on 3D overall, though there are plenty of 3D games. Godot is pretty stable too it seems but C# doesn’t get the same attention as it’s built-in scripting language. Plus things do change a lot with Godot, they add new things pretty often which makes managing jumping versions a part of the workflow consideration. Sometimes it’s nice to use something that is proven in the field, that just works and will continue to in the future…
Another thing I took a look at to consider is the licensing model between flax and stride3d. While flax is source-available, there is no open-source license, only their revenue share (above profits of 250k US) of 4% - which is more or less similar to Unreal Engine’s. Stride3d has an MIT open-source license which is very very permissive. Rev-share licenses aren’t that uncommon, this one looks fairly standard to me (not a lawyer). The main difference being that if for some reason Flax does a similar licensing rug-pull, because it’s only source-available, there would be no way to continue using it under the old license, where with an MIT project, users could simply fork their own version of the last available MIT version and continue to use that. I don’t want to think about other engines as un-optomistically as that, but it is something to keep in mind.
Another thing I took a look at to consider is the licensing model between flax and stride3d. While flax is source-available, there is no open-source license, only their revenue share (above profits of 250k US) of 4% - which is more or less similar to Unreal Engine’s. Stride3d has an MIT open-source license which is very very permissive. Rev-share licenses aren’t that uncommon, this one looks fairly standard to me (not a lawyer). The main difference being that if for some reason Flax does a similar licensing rug-pull, because it’s only source-available, there would be no way to continue using it under the old license, where with an MIT project, users could simply fork their own version of the last available MIT version and continue to use that. I don’t want to think about other engines as un-optomistically as that, but it is something to keep in mind.
Yeah, this was also the first thing I looked at, and people are raising that concern on the Discord. The response from Flax is that they are looking at adding a perpetuity clause, but Unity had one of those as well and they just tore it up anyway, proving that a clause like that doesn’t mean anything. As you point out, Flax not being open-source means there’s ultimately no protection from that.
I see a lot of people jumping ship to Unreal, but I think we should be careful about that. Epic is definitely not to be trusted. They’ll tear up their agreements just like Unity did as soon as they think it will benefit them.
I am not sold on Godot. It makes some things easier than they are in Unity, but I keep encountering bugs and fairly simple use cases that either it can’t do or I can’t figure out how to do. My needs aren’t that elaborate, so I feel like it’s a bad sign that I have hit so much friction after barely doing anything yet.