I’ve switched over to the Heaps engine by the creator of the Haxe language.
In addition to the compile time issues, I found myself constantly fighting the Unity way of doing things in that I prefer doing things in code as opposed to using the editor.
Also, I think it's worth mentioning that if you care about the longevity of your game (like 10+ years into the future), depending on the Unity runtime being compatible with future OS versions is also a risk.
Then again, the alternative requires some pretty hefty engineering chops and prior knowledge of a whole host of lower level concepts and APIs.
EDIT: Also Heaps is the choice of Dead Cells dev and he's written about it some here: https://deepnight.net/tutorial/using-my-gamebase-to-create-a...
It's not that they make it impossible upgrade to a new major version, but yes it's not prudent to switch between major revisions of a game engine deep into development, that's not unique to Unity.
Game engines don't have the JavaScript style churn where your library is dead if it doesn't do something major every month
Unreal Engine 3 => 4 was 8 years?
Unreal Engine 5 is going to launch next year, almost 7 years later
Unity 4 => 5 was 5 years, and then Unity switched LTS releases which are getting updates for 3 or 4 years?
-
The improvements that come with major versions just don't make sense to try and pull in on a game deep in development either
I mean look at this year's releases, a big focus has been the new render pipelines, but are you going to rip out your game's entire graphics stack mid development and redo every single shader and material?
Unless you really have a good reason, probably not...
You can pull new versions while under development. I've been on a team that did it and it was not fun. Usually involved some poor soul pulling the short straw, spending ~6 weeks 3-way merging followed by a large uplevel commit that breaks everything. This follows ~4 weeks of bugfixing at which point you start the process again since a new major version was just released.
But can you imagine the nightmare if you weren't standing on the shoulders of Unity and trying to do it in your own custom engine? Especially on console? Unity is probably getting hardware before 99% of devs on some platforms, and they have resources that dwarf most dev teams when it comes to shaking out issues. It'd 10000x the nightmare to go it alone...
Like I said, it's not just Unity, and it's not like the game engines are even doing anything particularly brutal, they just treat major version releases with the weight they really ought to carry. You can upgrade, you just better have a damn good reason, and if you don't have good testing procedure you're going to suffer twice as much.
-
And honestly some of the pain is just out of their hands
I remember Wii U development was tied to a specific major release of Unity when N+1 came out due to their custom integrations. But Nintendo didn't track that update, and gave no time frame for doing so for a hot minute. Unity 5 just ended up shipping out of beta with no Wii U support
I don't know what a game planning on requiring Unity N+1 to ship would have done there, but I'm sure similar dependencies exist internally on other platforms that Unity has to manage.
They've essentially got multiple engines that all need to be landing changes together in sync, I don't know why people are surprised that such an insane technical challenge requires you to treat major versions with some real weight...
Last in-house game I did we had to bring a while networking layer online for a platform that didn't previously have it and that part was a pretty painless process.
I mean to put it very simply, do you think that adding support for a platform with hardware that was probably pretty new since Unity does tend to be ready near launch for major consoles... was more work or less work than your 10 weeks of merging stuff then bug fixing?
You could spend 10 weeks on a new hardware platform just getting to a working engine just because of toolchain teething problems... and I bet someone at Unity definitely did to get you to the point where all your biggest worry was testing and merge conflicts
Also this comment in your original post:
> at which point you start the process again since a new major version was just released.
Surely you're not trying to imply Unity... which went half a decade between releases for a while, then switched to LTS releases with 3 years of support minimum... is forcing you to upgrade every 10 weeks...
The larger point I was trying to make is that an internal team is aligned with your goals and can support you. And external engine is tied to their own goals that might not align with your schedule/platform/feature set/etc.
No one wants to be going through a contract dispute in the middle of development as it's a sure fire way to sink your title.
Anyway, it's just a long way to say that when you do your due diligence on an external engine, is to only look at what you see now and not what's on the roadmap.
Due diligence on an external engine is planning ahead instead of acting like a deer in headlights when a new release comes breaking changes, because that's what you should expect.
That's what my comments have said thus far, nothing more nothing less.
People are acting like it's a problem specific to one engine that yes... an external engine is not marching to your personal timeline and will have breaking changes on major releases so you need to adjust your own schedule to theirs...
If you did your due diligence the cost of having to conform to their schedule should lower than the value that they provide is. Otherwise you shouldn't have used the engine.
Honestly it's surprising I've had to spend this many comments explaining that... that's kind if the basic math before you should even use a game engine
I've seen whole platforms which were on the milestones in the contract delivered in an incomplete and unusable state.
I've seen engine developers prioritize high profile internal titles over licensees including explicitly telling developers that their features will be de-prioritized until they ship.
I've had to implement non-insignificant features(ex: LoD geometry streaming) because it wasn't a 'priority' to support open-ish world games.
While internal engines shared across studios may not have the same level of polish they can align with what the teams need and roll out large breaking changes in an organized manner. Once you have 2-3 studios using an internal engine there's a critical mass that builds around it(assuming game types overlap to a degree).
Like everything there's pros and cons, however if I were evaluating a external engine in 2020 anything beyond what's present today would be a nice bonus and not something I would plan around.
Of course you can not update, but then you might be relying on half-finished/half-broken features that could be fixed just by upgrading.
Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time.
First part of this sure, Unity likes to have different ways to do stuff and I do wish they'd focus more. The roadmap approach they're taking shows that they are committed to working on it, and I'd say they've done well tackling that.
But the second part? About getting cornered into updating by new features, not buying that for a second.
If the feature is done enough to use it in a game with a large scope trying to follow a real development schedule, it's not disappearing. If it's not, don't use it.
LTS releases are getting 3+ years of updates, before that we were going 5+ years with the same unity version, so when you say "actively maintained" when you mean is they're not getting changed anymore. Which is a good thing.
Unity 5, from 5 years ago, is still getting security updates.
Where you get cornered is trying to pull in beta features into a game that has a hard schedule then getting screwed when the beta feature takes advantage of has breaking changes during a major release... which is kind of the point of a beta.
Unity has a huge community with a wide range of expertise and scope in their projects, if you're just blindly following what people in the forum are talking about, you'll follow some people working on small projects with small lifecycles.
Unity has never been for rug pulling, if something works well enough for your game today, it's going to work well enough tomorrow, they're not going to yank it just because it's not the new hotness. Even Unityscript ended up getting a smooth path into the sunset with a converter tool despite being used heavily in under 4% of projects (and being used exclusively by <1% at the time)
-
> Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time.
Again, where are these breaking features "all the time"? Unity 4 => 5 was half a decade?
Now they have their date-based versioning, but LTS releases still get at least 3 years of support, and the next LTS is the next year, not the old 5+ year cadence, so you get an incremental upgrade path with 3 whole years of smoothing.
Outside of major releases I've only ever seen a tiny handful of breaking changes per release, the majority of which where back when we were going 5 years between major revisions so they'd hold everyone's hand with a detailed guide and "pay once, cry once": https://docs.unity3d.com/Manual/UpgradeGuides.html
Note how now only LTS versions need these...
I mean, someone brought up Monogame here, apparently not aware that XDA 4 which it targets was a major breaking event from XDA 3. Game engines have breaking changes on major revisions.
Software, often has breaking changes on major revisions.
Don't build your software, on other software, hoping to blindly chase every major release painlessly, it's just not going to happen once you get to a certain level of complexity. These companies are not abandoning previous releases instantly, they still get maintained
I could Ctrl+R Unity for Unreal in this comment and nothing would change, it just comes with being a swiss army knife of this sort
Nope. Unity still has a lot of very important features that are or were in Beta or unfinished state for a very long time, at least until very recently. DOTS, SRP and HDRP, to give a few examples [1]. If I strictly follow your advice I would have to virtually stick with features from 2015. Thanks, but no thanks.
These problems with Unity have been going on for about 5 years and the official line by their team is that "we're rewriting stuff and it's going to be great, but in the meantime just wait".
--
> Again, where are these breaking features "all the time"?
> Don't build your software, on other software, hoping to blindly chase every major release painlessly
So, you're saying that there aren't many breaking changes and updating is easy, but at the same time saying that people shouldn't even think about updating an engine mid-project because it's reckless?
Sorry, but you can't have it both ways.
Notice how you're blaming users for everything here: they can't update because it's hard, but at the same time we can't complain that it's hard because Unity is great and doesn't have many breaking changes. Also there's some whataboutism going on when you mention that Unreal and Monogame. This doesn't matter since them both don't have the crazy update schedule that Unity has where a major-upgrade is released every now and then.
--
[1] And btw I fully expect an answer like like "Oh but you're not up to date on those, feature X has been finished in version XXXX.X, you just haven't upgraded yet". Well, guess what, there are breaking changes and I can't easily upgrade.
You expect wrong, I'm point out how hilarious your complaint is.
That hard to implement features are in beta (And pre-beta!) for a long time so that we can actually contribute to their development cycle with feedback and bugs, instead of Unity getting them almost done then throwing them over the fence...
It's insane to me someone would try and spin this as a bad thing with a straight face, and in fact it makes me question if I'm talking with someone who just has never dealt with the stuff behind the scenes here (like actually having to implement features of this scope)
Every single feature you just mentioned was Unity reaching deep into the bowels of their engine and reimagining something. DOTS is literally a reimagining the core concept of how entities exist in Unity! Literally a core tenant of the engine.
You're complaining features like that are developed in the open? You realize the gnashing of teeth that probably forces them to go through to allow it? Are you joking?
-
> If I strictly follow your advice I would have to virtually stick with features from 2015. Thanks, but no thanks.
No, you'll get to use plenty of features, it's just you won't get to use the unfinished ones unless you're ready to deal with the fact... they're unfinished...
Unity doesn't make that confusing to know either, they literally won't even show you a preview package by default!
Hard stuff takes time, when development happens in the open you get to see that. Unity has plenty of features people are using to ship games that aren't in preview lol, imagine acting like Unity's preview system is a bad thing
-
> So, you're saying that there aren't many breaking changes and updating is easy, but at the same time saying that people shouldn't even think about updating an engine mid-project because it's reckless?
Lol that's a uh... creative straw man, I'll give you that much
Literally the words you quoted spell it out, breaking changes happen during major revisions and that major revisions are not a frequent event or easy to track.
They used to happen twice a decade. But that also meant it was very awkward for them to ship big things.
Now they happen once a year but to avoid forcing you to track breaking changes once a year they switched to the LTS model
So now you have 3 whole years to deal with breaking changes.
Can't deal with that, it's kind of on you.
The problem is that the alternative is to work with features that were so behind the curve that Unity themselves decided to rewrite them years ago, instead of fixing them. That's my issue.
All I'm asking from Unity and its evangelists is honesty: you either have ready to use features or you don't. Putting all the good stuff that you're advertising behind a "preview" label and claiming it's the customer's responsibility when it doesn't work well is not ok.
The features that these new ones supplant on not "behind the curve" just because their replacements take a lot of effort to make!
I don't know what it is that has rotted the ability of some devs to understand the concept of things that actually work without constant refresh, this isn't NPM that's why they can afford to take a couple of years on features and still have a state of the art engine without it .
Literally DOTS is coming down right as we're seeing a reworking of how games approach data and latency.
If Unity had never said a word about DOTS and released it next year, they'd be fully "on the curve". In fact in that specific example, they're ahead of the curve, DOTS is really a rethinking of architecture that no middleware type game engine has tackled yet.
And look at HDRP, it's landing right as Unreal also releases their first major graphical shake up in half a decade next year with Unreal 5.
Do you even know what "the curve" is for middleware game engines? It honestly sounds like you don't
> All I'm asking from Unity and its evangelists is honesty: you either have ready to use features or you don't. Putting all the good stuff that you're advertising behind a "preview" label and claiming it's the customer's responsibility when it doesn't work well is not ok.
That's how things work when you don't care about your relationship with developers. I feel like some devs just don't know what good software practices look like when I read stuff like this.
I mean abject insanity to find someone complaining a company is putting things out, make it very clear that they're in progress, not even letting you use them without changing settings! and then gasp replying to developer feedback?!
Incorporating that feedback into their roadmap even though landing multi-year projects is already hard enough with just internal input?!
After all it's not like Unity is dangling carrots here, even these preview packages are getting treated with the same rigor that normal ones do in relationship to bugfixing, and they are always cognizant of the fact that even preview packages have users if you actually look at their conversations in the forums
-
What you seem to be missing is Unity would still be a top engine if they never mentioned another preview package again. But it'd be a worse product.
Taking external input? Constantly cleaning up your work to put it over the fence? Having it end-user ready years before completion? That's a lot of work.
Unity features would be less work for them if they didn't do that.
But the features would have come out after spending a bunch of time in that state are better for everyone involved.
This all started with people whining about breaking changes, you think breaking changes would be better or worse if they weren't happening incrementally with real users in preview?
Read again. They're not behind the curve because there's new replacements. They were already behind many years ago, and that's why Unity decided to rewrite them instead of upgrading. Non-preview replacements still haven't arrived for a lot of those features. Maybe that's ok for you, but it's not for me. The end.
The rest of your post seems to be making the point that Unity is great for people who want to give input on how to create an engine. Sure, but I'd personally rather have software where the major advertised features are ready for use without having to "deal with the fact... they're unfinished".
I didn't even try porting my 10 year old XNA game until a year and a half ago, and I was able to get it compiled and running with 90% functionality (again shaders and storage was broken) in just 24 hours.
And they just had a major new release that, among other things, supports .Net Core, just two months ago, yet I'm still able to do this.
Monogame is _literally_ an implementation of XNA 4: https://www.monogame.net/about/
> MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework.
It's raison d'etre is to let you run stuff that ran on XNA 4 specifically, you could almost say it's psuedo-ABI is XNA 4. So while they've built on that... it shouldn't be surprising that yes, literally the one thing it was built to do, works.
I mean it's to the point once upon a time XNA's API reference was MonoGame's documentation and to this day they match, even if it takes harming the soundness of the API:
https://gamedev.stackexchange.com/questions/67040/where-is-m... https://github.com/MonoGame/MonoGame/issues/5487
-
Also you realize XNA broke stuff on it's major releases too right?
It's actually kind of ironic and funny you'd bring up XNA 4, because it REALLY broke stuff:
https://www.shawnhargreaves.com/blog/breaking-changes-in-xna...
Literally the words of a Microsoft dev lead at the time:
> I was relieved when the comments on my earlier post about backward compatibility agreed with the approach we chose for XNA Game Studio 4.0. Banjobeni summed up the general sentiment:
> "If you break it, break it good."
-
But also, and I mean you allude to this right there in the first sentence, it doesn't have half the surface area Unity has, it'd be like pointing out SDL's API staying stable?
Even if you look at something that isn't Monogame I'm sure you'll find some frameworks that have had static APIs for decades, after all, if your layer of abstraction is high enough while your scope is small enough, DrawPixel 0,0 is still probably going to end up drawing a pixel somewhere just like "forward 50" is going to "move the turtle forward 50"...
But then to that point, the basic APIs like that in Unity haven't been completely ripped out or something, they're still there in the same way they were.
I googled "how to jump unity" with older than 2007 and this code still works 7 years later: https://answers.unity.com/questions/30127/how-can-i-make-my-...
Sure Unity added a new Input system, but they don't force it on you, it's not even enabled in new projects by default (probably so you can cut and paste 13 year old code and have it work)
Even Unityscript, the most glaring removal since Unity 1, has an official conversion tool, and deprecation wasn't even started until heavy usage had dropped to under 4%. I actually find it a great example of how to deprecate software gracefully. They waited for usage to fall off, they had excellent reasons to drop it, and they bent over backwards to make it painless.
If you're just doing basic stuff like moving CharacterControllers around and stuff decade old code still works in Unity. Most basic tutorials from back in the day still work.
What broke was fancy shaders that were written back when graphics models we use today weren't even an academic concern... and like you pointed out, that's stuff that breaks as time moves on because it's just not high-level enough to be easy to have work in a backwards compatible manner
(You do need to turn off Auto Refresh though, no idea why they think having that setting enabled by default is a good idea.)
Changing a single line of code can take close to a minute on a medium to large sized game under a 2020.1.
Using something like Heaps where you can compile a large game like Northgard completely in 4 seconds is a completely different experience.
For me, I realized that wanting to "keep it all in code" is a learned habit, and part of why I learned it is because the tooling when everything in code is just so much better. I can navigate references, etc., count on compiler errors runtime errors, etc. But none of this fundamentally required me to keep it all in code _if_ the tooling allows it. With ~2020 it feels like the tooling is getting to that point.
I don't think Unity is nearly at that point for my use case. Part of the problem is that I tend to build games that require a lot of procedural generation and user created content.
I basically end up needing to build some kind of level/content editor for my end users, which removes a lot of the value Unity brings to the table.
If you're using procedural generation or using an external tool to design your levels, then the Editor definitely becomes a hurdle.
Baking work into serialized objects at build time (or dev time) is your friend. You should learn to love it.
There are some terrible things Unity does but loading a large block of prebaked assets is one of the things Unity is fairly good at.