Unity has gotten so painful I've sworn off ever taking another Unity project. Since mid last year I am 100% exclusive on Unreal Engine.
Unity wants you to think this instability is temporary. It is not. Unity has been unstable since at least 2014 when I first worked with it. Every year there is a new-new thing, "please stop using the old-new thing". Meanwhile those upgrades are always painful, not sometimes painful, but almost always.
Back in the Unity 4 to Unity 5 transition the studio I worked at had a contract to port a single game screen from NGUI to UGUI. NGUI being a plugin which used to the de-facto UI framework. UGUI being Unity's inhouse clone. No upgrade path, just a rewrite required.
You want to know the juicy fact? Unity has more engineers than Epic. This despite Epic developing both a cutting edge game engine + Fortnite. Unity makes noise about needing price increases and extra revenue sources, yet that high headcount is not showing us as quality for the gamedevs.
With Unity you are paying for the "build a bear" of game engines; while Unreal is selling a batteries-included solid foundation.
One of my on-boarding tasks at my first tech job was to evaluate the merits of upgrading to a newer version of unity. I installed the new version, imported our code base, fixed a few bugs, and everything worked. We gained a few niceties, we could remove some of the hacks we had to program in to bypass unity weirdness, and we could start keeping our product up to date. I gave a presentation, we went over the pro/con list, and decided to move forward.
It was awful. Every other programmers' attempts to upgrade failed, and each in a unique way. We had to pause releases to untangle everything. I felt terrible for derailing production my first week on the job, but after a dozen or so people took me aside to tell me some variation of "it's not you, its Unity" I learned a valuable lesson. You said it perfectly: the instability is not temporary.
We are a tiny dev team using Unity on a non-gaming project and we basically have to dedicate 2-4 weeks of the year to updating Unity and all the mess that it entails. But if you don't update then you have to spend even more time the next year catching up. Then we end up being too scared to use their new features cause they aren't supported well or cause bugs. Its lose-lose.
I'm in game dev and have been responsible for doing Unreal Engine updates for medium-sized teams (50-150) on AAA games.
Our updates have taken one full-time engineer for 2 weeks plus an additional 2 weeks total of various people's time for each upgrade. It's worse if we skip a version.
We dedicate probably 3-4 person-months per year to staying updated, but it's well worth it. As an investment its ROI is easily 100x.
Do you make changes to Unreal's source? Or have middleware that makes changes (Havok and Fmod)?
Your effort estimates line up with mine, but I'm not sure about the ROI (but it's been a few years and I was pre-fortnite).
We made limited changes to Unreal source, but I think we made more changes than we had to. We had our middleware, we fixed bugs (none upstreamed via github due to company policy), but we also introduced new features varying from necessary for the project (instanced mesh rendering) to unnecessary (fancy logging). Every upgrade, I regretted most of the changes we made.
But also, it seems like every upgrade our data assets and blueprint script would get less stable and cause weird infrequent crashes in the blueprint/uscript interpreter.
Do you use bleeding edge features? I recall being wary of anything that hadn't been around for a few updates.
Yes, we make a significant number of changes to Unreal source, probably on the order of 1-3 per day across the team.
All changes to the engine are required to be wrapped with a special comment tag indicating the author and explanation of the change, so that it's evident in a 3-way merge window how to resolve if there's a conflict at engine-upgrade time.
At a previous company we used Enlighten and Simplygon both of which made changes to engine source, and those were a nightmare to deal with. We had several source branches set up specifically to deal with 3-way merging at all steps of the way.
We also implemented things like instanced skeletal meshes, an improved navigation system, and additional shader passes. Those were all very complex to upgrade especially when Epic had refactored the underlying systems.
We don't use features that are experimental in shipping code.
Last year's Unreal conference had a couple of talks related to engine migration and how teams managed to do them, which some mentioned they rather do it between projects than jeopardizing an ongoing game development cycle.
Middleware migration headaches are everywhere, regardless of the chosen stack.
Honestly I've never seen this problem solved well for any game engine short of in-house engines(which obviously wouldn't break titles they were supporting).
It's been a while since I've been in the industry so maybe things have changed but last time I was there unit tests weren't even a thing. Smoke tests where if a set of levels loaded and didn't crash was considered success from an automation validation standpoint.
I think it is telling that in Unity world, 2 years is "Long Term". I wonder what cutting edge is? Building your entire game on the unstable weekly branch and crossing your fingers?
Not just unity unfortunately. .net core LTS is 3 years, Firefox "extended support" is 12 months, some random library from cargo/npm/nuget probably not at all. "Long Term" is becoming a meaningless buzzword.
Companies cling to 40 year old COBOL because there's nothing stable enough to migrate to.
Java has been one of the few that are more stable but I get the impression that's coming to an end. The support lifetime for the current LTS will finish 4 years earlier than Java 8 (according to wikipedia: https://en.wikipedia.org/wiki/Java_version_history) so it's trending down fast (although still good). It also looks that 2030 is only for people paying oracle, which isn't necessarily bad but it's something to consider.
There's also a lot more to consider than just how long an LTS lasts, like the degree of backwards compatibility and the rest of the ecosystem. It was my understanding that project jigsaw broke a lot of that, but I'm outside the java world so i didn't really keep up. .net for instance was great until recently because they had decent support lifetimes and kept backwards compatibility, so updating to the latest was at least simple and painless. Even trying to do those upgrades was like pulling teeth inside corporate environments though.
There's a difference between end-user software and software that you're going to produce things in.
2 years is a reasonable time to expect that the user will move on to the next LTS browser version. 2 years is not a lot of time to release a game without having to upgrade the engine mid-project.
That is the old model, the new LTS model is three years.
Oracle just extended it due to Java 9 being our Python 3, which is kind of pointless because all the packages that matter have migrated already.
But enterprise being enterprise, there are plenty of projects only now migrating to 8, and then there is that little robot that isn't even fully compliant with 8.
Not that I really know much about Java stuff, but it looks like maybe Amazon/OpenJDK are providing longer support lifetimes? [1]
And here's an official Oracle doc regarding Java support where they show Java 11 (LTS) being supported until either late 2023 or late 2026 depending on your support level. I'm not sure they provide free support anymore, or maybe that's limited and what you're referring to?
Java has several commercial and free implementations, so every Java vendor is free to choose their own timelines, I was only talking about the free layer of OpenJDK/Oracle, as that is what many around here understand as Java.
It's funny. I see it (anecdotally) all the time. More engineers doesn't mean a better product.
In fact at my old shop, things (product, quality) really started declining once we 'rapidly' scaled the team. Communication and consistency really suffered from lack of solid processes among other things.
I think it comes down to power in the company. Unity was extremely simple and small before, once they got John Riccitiello it become a management/business focused company over engineering leaders in terms of power and direction.
Unreal has Tim Sweeney, and old school guy that understands how to make a game engine and has done it over and over. They learned alot from Unity, and are now doing it better than them once they turned towards simplicity over complexity.
When Unreal 4 swapped out UnrealScript for C++ it went into overdrive in terms of performance and clean.
I think UE and Unity has complete different markets. Unity is focused on small mobile game developers, those small shops don’t have expertise to work with UE C++ source code and most of them are new grads themselves.
I’m not sure what is the overall strategy of Unity but I don’t believe they care much about the PC/Console space and frankly at this point I don’t believe they will ever manage to capture it from UE.
I thought I remembered there being some bigger games, but looking at a list[1], they are all pretty indie, or at least small. Not sure I saw a AAA game on the list (which doesn't mean there aren't any, but they seem rare). The equivalent list for Unreal Engine[2] does contain quite a few big titles (along with a plethora of less well known ones).
I'm not sure if that's cause, effect or marketing. It could be that using Unreal Engine results in a smoother process and is more likely to result in a AAA target game being AAA. It could be that AAA studios area already predisposed to use Unreal Engine. It could be both. It could be that Unreal Engine is just better at marketing to larger studios given their pedigree.
Unreal is for people who get games financed. The demos looks great and the execs don’t play games anyhow so what do they know. That’s why it’s all FPSes, it’s stuff non-game-playing adults can understand just by looking at it. They will fund the most photoreal looking pitch for the Star Wars IP.
Unreal as an engine product is competing with Frostbite and Source Engine (the various engines Star Wars appeared recently) not Unity.
However EA and Respawn won those bids for a variety o reasons, mostly related to the mechanics of royalties and their support commitments.
It’s complicated. There are many forces at work, only somewhat related to engineering, that funnels the engines to one kind of game or another.
Escape from Tarkov might be the biggest Unity game on Twitch right now. Thanks to Unity you get game stutter and freezes during tense action. Escape from Tarkov devs keep promising every year that thanks to the close cooperation with Unity team 'this next update' is totally going to solve the problem! year after year it doesnt.
Game stutters and freezes during tense action sound like GC related problems. In theory it is solvable but I doubt that anyone is going to bother and actually put in the work. Lots of popular games have known flaws and unless there is a direct competitor nobody is going to switch games.
Hearthstone is the largest that comes to mind, I'm not sure if it qualifies as a AAA game but it's from a large studio with a lot of experience and earns AAA money.
Hardly a complex product compared to some, yes, but time to market and speed of iteration are still important. I don't like the game but the presentation and feel was good when I tried it.
I don't know how well it worked out for them overall though, and I don't recall seeing them use Unity again on another game.
There are a bunch of AAA-ish? RPGs and strategies on Unity, like Pillars of Eternity, Pathfinder, Endless Legend, Endless Space. They may not have the player numbers of Heartstone but they are basically what top notch equivalents like like Baldurs Gate or Civ are, and more.
In my experience Pathfinder for example suffers from poor perf compared to e.g. Tyranny, but Endless Legend doesn't compared to recent AoW or whatever non-unity game equivalent.
The OP article is written by Garry Newman the developer that did Rust in the Unity list from 2013. Previously he was the developer of Garry's Mod on Valve Source engine.
I'm not sure what you're trying to communicate. That Rust is a AAA title? It's not, as I understand it. AAA is not a designation of quality or popularity, it's a designation of resources that go into it. Large company with lots of resources putting lots of money behind it means AAA. It's less a designation of the end product than of the process going into that product.
Just mentioned that it was on the list of games in terms of popularity, never said it was AAA.
However, Garry has lots of pull in games including towards AAA developers. I did not say that game was AAA but on the notable Unity list that everyone knows about.
Rust is much bigger than most Unity games, so Garry's opinion on this is highly relevant and influential. Facepunch studios and their forums were also a gamedev spot for a long time.
Garry Newman is also someone speaking from shipping experience in another engine that is for AAA studios, Valve Source Engine. Eventhough that was a mod, and yes not a massive budget or team, it has pull at the AAA level in terms of influence as well.
Rust competes with AAA titles on Steam in terms of playtime/playercount all the time, was top 10 for a while and quite often. [1]
The point is Garry's opinion is more valid than most, even at AAA probably about Unity. A developer of a top 10 Steam game has some pull and is someone to listen to, hopefully Unity hears it. Rust is clearly one of the biggest games in terms of playtime/playercount than most Unity games at least on Steam with the popularity only rising since release in 2013.
Rust is AAA level in terms of playtime/playercount with a small team, that is exactly the market Unity wants, in fact it highlights the benefits of Unity clearly. They should listen.
I think you misinterpreted my original comment (which is why yours seemed like a non-sequitur to me).
I wasn't saying Garry doesn't have any big games, I was saying that the list of games made using Unity doesn't include many big/AAA games. I also wondered why this might be.
To clarify, I'm not saying there aren't AAA Unity games, just that I didn't immediately see one. Nor am I stating that Rust is not as good as a AAA game, I made my position clear that AAA is more to do with resources. I would even go so far as to say it's more of a marketing term. What I am saying is that is seems like (from the lists I saw) a lot more large and AAA titles are made using Unreal Engine, and I wondered what specifically leads to that.
> The point is Garry's opinion is more valid than most, even at AAA probably about Unity.
I'm not sure why that's the point. It has absolutely nothing to do with what I was talking about. This thread was about Unity being better targeted as small/indie/mobile developers, and I was responding in that context.
Ok yeah we were talking past each other initially, I see what you are saying now.
I never really mentioned AAA and the reply I made about Rust was also saying that they said "Not sure I saw a AAA game on the list" which is true in terms of budget/team size but not playtime/playercount for a few games on the list.
The biggest games in Unity are probably Rust and Kerbal Space Program merely in terms of playercount/playtime and they do compete with AAA on those metrics, not team or budget size. Both teams have complaints about Unity, as everything, as long as those are addressed things progress.
That is the problem though, Unity is chasing AAA/more licenses when their main target is mobile/smaller scale games and doing that simply. That is the reason both Rust and Kerbal started using Unity, simplicity.
Garry picked Rust in 2013 for the simplicity as he says
> "Unity was about that when we first started with it. They hid all the hard stuff in c++ so we didn't have to think about it. The more time has gone on, the more bullshit has crept to the forefront. The've gone from hiding the hard stuff to moving more and more stuff into C#."
With Unity Rust is competing at the level of playercount/playtime with AAA. That is literally the thing Unity wants the most and their selling point. Unity you can have smaller developers, able to make games that can compete with less team, with a focus on simplicity and being the engine team that makes transitions easy. It is also ok if they are hard transitions if there are major improvements. Unity is many times asking you to update to a new system that is the same or sometimes less than what you need in terms of benefit, and then only to be half complete and then changed again.
As Garry said
> "So while other engines have been trying to catch Unity up in terms of developer friendliness, Unity has been going the other way by making itself more unfriendly."
They are losing the simplicity selling point.
Unity can make games that compete, they should be taking these critiques to heart strongly as teams/games like Rust and Kerbal are exactly the target they should be going for along with smaller games/mobile games etc.
Unity has so many internal developers now, that requires alot more communication needs, testing needs and maintenance. It also pulls the company in many directions if there is no clear engineering/product lead at the top and it is all management/business/finance pushing feature based development which gets them into version 2 syndrome or the "second-system effect".
> The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.
If the second-system effect doesn't describe Unity I don't know what does.
Get back to simplicity Unity, let the engineers/product people have power to set this back on course. Stop catering to big developers, they make their own engine for this reason, consistency and simplicity of their own process. Dogfood Unity with an actual game, the problems will be clear today. If you aren't doing that, listen to people like Garry who are.
But it's more fun to work on 5 different rendering pipelines! They're definitely trying to please everyone without really catering greatly to anyone. Like the official 2D capabilities are still about as hacky as what I implemented 5 years ago myself in about a month of work at a mobile games studio.
A lot of mobile game developers who use Unity aren't small at all. They are huge companies with lots of experienced engineers. The baby devs don't generate the $ for Unity.
> A lot of mobile game developers who use Unity aren't small at all. They are huge companies with lots of experienced engineers. The baby devs don't generate the $ for Unity.
Even if they are large companies, the teams are still small and the point of Unity is simplicity.
Unity wants to be AAA for console/desktop but mobile is their bread and butter as you say. Companies and indies chose it for simplicity and there are lots of Unity developers. They are messing up the simplicity angle and going after new markets but causing pain for their existing customers. I get they want to grow and sell more licenses, but I'd argue most of their paying customers are indies, smaller mobile studios and larger mobile studios the have many small game teams.
Unity also make lots of money from the asset store. All these constant breaking changes also break many assets.
Unity just need a more consistent surface level API/signature/facade, and move the hard stuff down below that for most cases with advanced modes accessible with more setup/work. Their changes now are making people that don't need AAA level output, more cartoony mobile games, do unnecessary work losing out on their selling point of simplicity.
Mobile games in some sense have taken over gaming. They're not as flashy, but the amount of money some of them seem to generate is obscene. Just take a look at NCSoft's income and how mobile Lineage crushed all of their other offerings.
It comes down to a truism about generally anything: it's inefficient to figure out how to do a thing without some amount of doing a thing.
It's not a huge surprise someone building games makes a better game engine than someone building a game engine. Because they solved the problems they ran into!
You see this time and time again with businesses. Dogfood, and you'll have a lot better idea of where the warts are in your product. (And most importantly, waste less time fixing things you're convinced are warts, but nobody ever noticed)
Because there is excellent tooling for C++, while they had to reinvent all the tools from scratch for UnrealScript.
I believe that ReSharper C++ alone makes me 10-20% more productive. Their refactorings and inferred constants are amazing and produce real-world performance benefits. Plus having const wherever it is warranted makes code easier to read and easier to debug.
C++ is very common in gamedev largely for the performance, less learning another language and more direct. UnrealScript in previous Unreal versions was simple but so is the necessary C++ for Unreal 4. Developers can make pure C++ games, or they have a simpler way using Blueprints that you can add into C++/Blueprint mixed games [1][2], or purely Blueprint that helps for non programmers though they are slower. There was lots of work to keep UnrealScript synced with the engine. Without that middle layer of a DSL, going direct is also important since everything needs to perform on mobile but also be native/AOT compiled. Helps for consoles, desktops and web as well.
Fun fact: Unity was going to go to C++ in 2013 during the Apple blocking Flash and other JIT tools, Unity thought they were going to be blocked from mobile publishing. [3] Since you can't run interpreted code Unity was going to go C++, I wish they had with C# as a scripting language maybe. Instead Mono had AOT compiling around that time but since the Mono license was expensive they built IL2CPP which takes byte code and makes C++ from it. About a year later Mono was bought by Microsoft and it would have been free for Unity to integrate. Though I still wish they would have went C++ with C# scripting that creates C++, would have been an easier route. I believe much of their problem is all these complicated legacy/translation systems at the base of the engine, which just going direct C++ would be easier with scripting on top of that that directly converts to C++.
Godot you can also use C++ and other languages including C#, GDScript. [4]
Early days of Unity you could use C#, Javascript, Boo (Python flavor) or anything that Mono supported.
I don't know if this is true but I don't see why it would be absurd. The man is pretty much an absolute gaming and coding legend and from what I've read about him, he's genuinely interested about code and tech so if that's true I find that actually pretty awesome.
Absurd would be if he had to just stick to management and bureaucracy just because he has a few billions on his bank account. You do you Tim!
I doubt that's true now, but it could've been something like that when UE4 released. The story went that he'd started work on it almost a decade before the release of the engine.
... and alot more communication needs, testing needs and maintenance. It also pulls the company in many directions if there is no clear engineering/product lead at the top and it is all management/business/finance pushing feature based development which gets them into version 2 syndrome. [1]
> The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.
If the second-system effect doesn't describe Unity I don't know what does.
Get back to simplicity Unity, let the engineers/product people have power to set this back on course. Stop catering to big developers, they make their own engine for this reason, consistency and simplicity of their own process. Dogfood Unity with an actual game, the problems will be clear today. If you aren't doing that, listen to people like Garry who are.
> ... and alot more communication needs, testing needs and maintenance.
Yeah, I was sort of including that in overhead, of a non monetary sort, in my own head. There are valid reasons why FAANG companies are so big on teams and team size and managers and reorgs, etc. I imagine one of them is it makes it much easier to switch expectations and focus and projects easily when stuff starts going off the rails (which you can always expect it too with so many people and departments with slightly, or very, divergent goals).
> let the engineers/product people have power to set this back on course.
Careful about wishing for engineers to have too much say. Some of the biggest (business) blunders have been because the engineers went and built something magnificent (or attempted to), but the market and sales people didn't know how to sell it (or it wasn't what the customers wanted).
Sometimes that comes out okay for the rest of us in the end as it spurs innovations and other companies to (eventually) do the same, but it's bad for companies when it happens.
Although you probably know that, and that's why you said engineers/product people. :)
I agree with the first statement. I'd go as far as saying that Unity is the JavaScript of game development.
Sure, when you start out you get out results FAST, but then you run into limitations, weird behaviours and quirks that have to be worked around, and soon everything becomes a mess.
Mind you, I'm a hobbyist in this field so maybe you could chalk it out to inexperience, but I shiver to think to what professional developers have to deal with if the small prototypes I cranked out got so convoluted.
I'm trying out UE4 lately and although it can be daunting at times (and with horrible documentation), it feels much more comfortable to use in the long term.
> Mind you, I'm a hobbyist in this field so maybe you could chalk it out to inexperience, but I shiver to think to what professional developers have to deal with if the small prototypes I cranked out were that painful.
Careful adherence to best practices (often discovered the hard way), banning certain code pitfalls with a linter, and many workarounds :(
It took me months to make something semi-usable out of (a subset of) UNET, and I can clearly see why nobody at Unity wanted to maintain it. Still, something half-decent and mostly backwards-compatible could have been made of it with enough work, but again they chose to chase the new shiny :/
The more you can avoid the "nice" stuff the better your project will be. All those shiny things in the UI that look easy will be painful in the long run once they start disappearing (I swear component references just disappear sometimes) and breaking and making the life-cycle of the application confusing.
My main complaints about UNET could be summarized as "the order in which things happen is very chaotic" (in unbelievably many ways!). I've not checked to what degree Mirror has improved on this.
Based on a superficial look, I'm worried it might have been more concerned with adding features than fixing and simplifying the fundamentals, but I don't really know.
Mirror is amazing :) But it's a big shame for Unity that you need to use it in the first place, because they don't ship a working networking stack out of the box.
What limitations does Javascript result in after initial FAST results as you say? All of the web is running on JS. It’s not without its faults but I resent the analogy.
Do you have any pointers towards good tutorials for a hobbyist on UE? I dabbled with Unity and want to see the other side and it wouldn't hurt to get back into C++ after all these years.
Sorry, I don't have a solid reference, I'm mostly watching snippets of random youtube videos and trying stuff out on my own and putting the pieces together as I don't have the patience to sit through a course.
Also, I'm working with blueprints as the C++ side lacks any kind of docs or tutorials. Initially I was repelled by them, but after getting used to them, they're not as bad as they seem at first glance.
Mmm... how’s that unreal engine version upgrade going for you? break your plugins? break your blueprints? can’t actually tell because they don't fail until you run them? :)
Just saying; A lot of people say this kind of stuff, but unreal isn’t all roses either.
I've been continously upgrading a couple months behind new releases on commercial projects since 2015. I've upgraded about 17 times so far. Unreal's update story is light years ahead of Unity's half-hearted "automated" mess.
Worse bug I had was back in 2016 when an upgrade lost reset the scale on weighted bones to 0.
Really depends on your code base and project. Unreal upgrades can be painful if you're using APIs that can or are rewritten, and if you have made engine level changes.
Unity often feels like rolling the dice with upgrades, basic things can break from version to version, but I've done many Unity upgrades with no or minimal issues, and seen extremely painful Unreal upgrades
It’s true that you really, really want to avoid making changes to the engine. Even for AAA studio source licensees in prior UE generations this was widely agreed upon. The good news is, you really shouldn’t have to.
In my mind, the big win from having the Unreal source code is understandability. But also, in contrast to Unity, if you should for some reason need to—say a critical bug that’s stopping your game from shipping at the last hour—you at least have the option.
Every AAA source licensee that I worked at made large changes to the engine source. There are many AAA titles both shipped and in development that change fundamental things about how the engine works. Look at the GDC presentation about Mortal Kombat rollback network, or its predecessor about running UE3 at 60 fps on console for some good examples. Completely avoiding engine changed isn't the reality for AAA, and I imagine it's only true for small indies. Good news is it's pretty easy to merge small engine changes.
God, and whenever something is deprecated, they don’t update the documentation with new info and sometimes they remove pages of older info that’s still usable.
I also had a free edition installed on an old laptop and wanted to make a quick edit to an old game to send to someone. But nope, needed to update my license first to open the engine, but the version was old enough that the reactivation button somehow became invalid and rendered it unusable. Basically had to tell the person “I know exactly how to fix the issue with the game but Unity won’t let me.”
When he came back asking questions that I would have expected to have been answered by the documentation, turns out... there just really isn't any. And the stuff that's there is various stages of incomplete or out of date.
When he got the point where he was like "Okay, I have to take this year old tutorial that doesn't work anymore, review the documentation to see if it's out of date as well, then grep the change logs for all the things it references to see where and when breaking changes were made and then go off on another Google-journey and hopefully find some sort of reference on how I'm supposed to use this new thing..." he just gave up. It wasn't interesting or fun anymore.
I can imagine UE4 is fine if you have an existing codebase and are just staying up to date with each new release. I was pretty flabbergasted that the documentation for a project of that size was so poor. I can't imagine how anyone would jump into a new project now.
I used Unity professionally for 5 years, then I took a 15 month break from game development and went to work on a hobby project and the latest version has completely changed to the very core. Made me give up and I'm currently looking for a game engine that's basically what Unity was 3-4 years ago. Pretty simple with a robust multiplatform support.
Godot looks the most promising (and open source) but the lack of console support is not ideal.
For indie game devs Godot [1] is huge. Great scene graph, scripting and debugging inside the editor, wonderful 2D tools (animation, physics and tilemaps are really great). It does not come with as many features as Unity or Unreal, but actually this is an advantage, because you don't have to learn a new way of doing things over the years. And you even have a dark theme out of the box! [2]
Console support is not there by default due to licensing, but I heard that one of Godot developers runs a company which provides console builds for Godot.
It's not really necessary to say `This despite Epic developing both a cutting edge game engine + Fortnite.`. Fortnite as most people know it is Fortnite Battle Royale. FNBR was essentially a weekend game mod project to an already existing, but floundering, multiplayer game. Most people that play Fortnite today have probably never even played the original game mode.
> Most people that play Fortnite today have probably never even played the original game mode.
That might be strictly true, but I think a lot more people got interested in and played Fortnite: Save the World than you think. My 10 year old son came in about 6 months ago asking to buy it, because some of his friends that were playing FNBR had gotten it and were talking about it (playing together? I assume it's multiplayer).
Due to Fortnite's massive usage, "most people" not playing it still could result in an absolutely huge number of people that have, dwarfing all sort of other games that might be considered popular, so I wonder.
I guess I was just clarifying that the OP makes a comment implying "Epic made a game engine and blockbuster game all with smaller staff".. but the blockbuster game kind of.. takes away from the point because it already existed. the comment stands stronger simply on the fact that Epic made a better game engine with a smaller staff.
I think the point is that software development is generally a continuous process. I highly doubt they've completely stopped all active development on Fortnight.
I tried to write stuff in Unity as someone with a working knowledge of C# and who wrote code in it professionally in the past. No environment was as infuriating as Unity as seemingly everything I wanted to do was overridden by the Unity API, and their given alternatives both didn't work as advertised and were barely documented
In my opinion, studios using Unity were always the ones too cheap to hire external freelancers to help their development, but instead going with copy&paste from (outdated) internet tutorials. I mean with Unity's deprecation speed, a tutorial from 2018 is basically unusable now.
So effectively, my work was mostly UE, because that's where the customers were.
But just out of curiosity, can you give me a hint where you found OK-paid freelance Unity work?
I'm Tokyo based so bunch of local multi-billion dollar companies doing Unity. Mobile games for the most part. A good chunk of their developers or either outsourced to smaller local studios, or contractors themselves.
Unreal contracting is even better. Most of the AAA studios switched from in-house engines to Unreal. Thus constant unmet demand for expertise and production on big console projects.
Granted what counts as okay money here might not match what you are hoping for. With the up side that Tokyo is never going to run out of gamedev work.
I'm not sure why larger headcount would ever be indicative of higher quality.
It's usually a negative signal. If you tell me a team of a dozen worked on a product, it is almost always better than if a gross of developers had their finger in it.
Unity wants you to think this instability is temporary. It is not. Unity has been unstable since at least 2014 when I first worked with it. Every year there is a new-new thing, "please stop using the old-new thing". Meanwhile those upgrades are always painful, not sometimes painful, but almost always.
Back in the Unity 4 to Unity 5 transition the studio I worked at had a contract to port a single game screen from NGUI to UGUI. NGUI being a plugin which used to the de-facto UI framework. UGUI being Unity's inhouse clone. No upgrade path, just a rewrite required.
You want to know the juicy fact? Unity has more engineers than Epic. This despite Epic developing both a cutting edge game engine + Fortnite. Unity makes noise about needing price increases and extra revenue sources, yet that high headcount is not showing us as quality for the gamedevs.
With Unity you are paying for the "build a bear" of game engines; while Unreal is selling a batteries-included solid foundation.