Unity has become an unfocused, poorly optimized, half-baked mess. This WAS bad for the independent and small developer market that actually uses their engine for final builds, but they've begun a mass exodus to Godot, which happened to go from "ok" to "great" JUST as Unity ruined their platform with their short lived "20 cents per install" policy.
Someday soon, we will see Godot eclipse Unity in the same fashion that so many other proprietary juggernauts were slowly cannibalized by laser-focused open source projects over the years:
In 2022, the split among GMTK participants was 16% Godot to 61% Unity. In 2023, it was 22% Godot to 49% Unity. This year, it was a whopping 37% Godot to 43% Unity: https://pbs.twimg.com/media/GVfo5-0WQAAIMAQ?format=jpg
This is major, because Godot has just had another round of home run improvements that brought in even more developers. I think 2025 is the year that Godot effectively replaces Unity for new developers.
> Jam and commercial games have different requirements.
Indeed, but it's a clear signal that something is shifting. In jam game environment, the shift is obviously faster, as the timeframes are different. But you extrapolate that things will change for mainstream games as well, it'll just take way longer time.
It would be interesting to see the number of jam games being done at Unity when it first appears, although I think the whole "game jam" thingy wasn't as big then as it is now. But maybe that could give some indication on how long it'll take before we see a difference in mainstream game engine marketshare.
The 'thing', be it a game engine or whatever else, of choice for small projects often end up taking over for commercial products too, devs bring their favourite tools into their work and slowly corporate adoption of it grows.
It happened with Slack, it's very quickly happening with Blender, hell it even happened with Unity itself
I'm not sure I'd be as optimistic as OP in terms of how quickly Godot will take over Unity, but I do believe it will happen, or at least something similar
I think Unity just publicly figured out what has always been the case - there is no market for a game engine targeted to developers that want to make PC games. They all have no money, don't want to pay license fees, and are rarely successful enough to pay their success forward back to Unity.
However for realtime applications other than "standalone games", Unity has absolute (and growing) dominance outside of where Unreal is carving out a niche (Film/TV). Automotive, simulation, robotics, etc. are all leading Unity adoption.
If you're (royal "You") the type of dev that wants to make games for Steam, Godot is definitely leaning more in that direction these days than Unity, but I think Unity isn't seeing anything really "bad" coming out of that besides lack of good PR in places where game developers post screenshots/etc.
Funnily enough nobody who paid attention was going to pay the $0.2 since it was only there to funnel developers to the pro tier which would have given them a significant discount on the per install fee (IIRC there weren't even any current customers who would have paid that much because the personal tier had a $100k limit which was removed and the fee only applied after it).
Unity just had such a horrible PR release and did an inconceivably bad job at explaining the changes that they mad an already horrible pricing model seem 5x worse than it actually war. It was so incoherent that nobody read past the $0.2 per install...
It wasn't the quantity of money that was the issue for most people. It was the "I am changing the deal. Pray I do not change it any further"
They were asserting their ability to unilaterally bring in new terms, and specifically with the per-install issue bring in terms that require data that was poorly defined and could potentially be arbitrarily decided.
The quantity of money legitimately is an issue too though. Especially for mobile games -- which rely heavily on advertising and scaling up thin margins -- 2.5% of revenue (plus $2,000/yr/seat) could be quite a significant percentage of profit.
To be fair that % of revenue Unity was historically getting from most of its customer that were actually making meaningful amounts of money (i.e. enough to have a permanent paid workforce) relative to the value it provides (especially compared to Apple's 30%) was very low. Of course not surprising given how relatively little pricing power it always had.
But I don't really buy the pricing argument. Most of that type of games are all made with Unity meaning that it wouldn't be too hard for all of them to raise prices by a few % with minimal impact. That mostly only applies to IAP not to ads but then again Unity was offering a discount/waiving the fee if you were using their platform (which is of course scummy and predatory but probably wouldn't have had a massive financial impact).
Overall yeah... they completely messed up with aligning their pricing model with their long term goals as a company. It was always highly suboptimal (the per seat license is almost insignificant for some companies while a significant barrier for smaller ones, contractors etc). They would probably still have been fine if they hadn't started almost literally burning money like complete madmen after the IPO for no reason. Instead they now have >$2 billion in debt (albeit low/zero interest) and nothing to show for it whatsoever (well besides IronSource to some extent I guess..) in addition to a still extremely bloated but also unproductive and heavily demoralized workforce.
Yeah certainly, changing the terms retroactively was just something else.
However I still think that the $0.20 headlines did a lot of reputational damage (even if most medium-major customers did the math) and that could easily have been avoided.
The way they introduced the already the hardly fathomable changes was IMHO as amateurish and half backed as it gets. Literally a corporate suicide attempt, can't imagine what were they thinking...
> Unity has become an unfocused, poorly optimized, half-baked mess.
Unity has always been a relatively unfocused, poorly optimized, half-baked mess.
It's just that there used to be no concurrence in this segment and their overall attitude towards makers made the mess somewhat endearing. Now that they act like a typical listed company, well, people feel less inclined to give them a pass.
If you start using Unity, you're not an independent developer any more : has there been a point where Unity did not require a subscription yet ? And when did it became a platform ?
> If you start using Unity, you're not an independent developer any more
How so? The usual definition is that if you're self-publishing, you're independent, but you seem to go by some other heuristic.
> has there been a point where Unity did not require a subscription yet ?
Yes, up until 2016 Unity sold "normal" paid licenses (as well as offering a free version), meaning pay once and keep using, rather than subscription-based like it is now.
Unity is still a pretty good tool overall but just like the author states they are going in too many directions at once and it's hurting usability. And of course there's the problem with Unity Technologies not making enough income to be sustainable long term and trying to capture more value from its users.
I know a lot of people are very excited about Godot replacing Unity but I honestly hope that the 3D engine market becomes more diverse. I'd argue a lot of engine tech and ways of creating games hasn't innovated as much as it could have if there was more competition in the space.
There's a lot of awesome 3D frameworks and engines out there and they should get some attention too.
The uses cases for Unity haven't changed. While development has stagnated, It's still the best tool for many small teams wanting to avoid the pain of Unreal's C++ or the downsides of Godot (less mature, non-standard scripting language, console support)
The problem is that it's become a much riskier business decision. What if Unity just disappears, or is bought out by another company, or hikes up fees again?
What if there's unfixed crash bugs in the big black box of that closed-source engine, bugs that may go unresolved for far longer since the mass redundances and could sink an entire project?
I’m curious about the C++ issues with Unreal. I am a hobbyist game dev. I did a couple years with Unity, learning C# on the fly; and a few years with Unreal more recently learning mostly blueprints but a decent chunk of C++ where needed. My day job is python based and I never really did OOP aside from AP computer science in Java a decade ago.
I definitely have not felt like the language was a top of mind issue for either engine. Much more important is just the built in features that the engine has for things like movement and what not. I tend to assume that dedicated developers are more skilled than I am. So why do people care so much about cpp? Imo it’s just been a tiny bit of extra boilerplate and a sprinkling of macros.
It's not as much the language itself as the build process and iteration time (although C++ enables nasty types of bugs that are mostly avoided in C# - memory leaks, heap corruption, etc)
While I'm very new to UE but experienced with Unity, one of the first things I ran into with Unreal was the complexity of implementing a ComponentVisualiser in UE vs using OnDrawGizmos (or a custom inspector) in Unity.
Drawing a couple of lines in editor mode involved dealing with build scripts to add an editor module to the project. While live coding/hot reload works for minor edits, some code chanfes require closing+reopening the editor. In Unity, it'd have been a few lines of code in an OnDrawGizmos function and no editor reloading or messing with build setup.
Unreal was really designed to be blueprint first then only move the messy parts to C++. So if you are using it like that you won't hate the C++ side of things.
I think a lot of ppl that come from Unity want to go all in on C++ and run into issue after issue after issue. Then end up hating the living hell out of it.
It's C++, which is rarely good. The language is large and complicated and you generally need to be extra careful when using it. There's a lot of features that interact with one another in surprising ways. UE5 does its best not to make things worse, but it's not always successful. (Are you certain you've tagged everything as UPROPERTY/UCLASS/USTRUCT that needs to be? Are you definitely always capturing your UObject pointers correctly? Are you definitely never using UObjects outside the game thread? Is your TSharedPtr structure acyclic? Are you certain they're all getting cleaned up? Have you tagged each one with the correct multithreading mode? Are you keeping an eye on FName creation? Etc., etc. - perhaps some of these are fixed now, this is just some stuff I've had to fix in the past that stuck in my mind.)
C++ build times are often terrible and UE5 does not buck this trend. Editor startup and on-the-fly cooking can also adds to the iteration time. (If you're part of a larger team you'll also spend a lot of time waiting for Perforce and watching it compile shaders and recook. OK, so you can't lay the blame for this bit at C++'s feet, but if you're anything like me then this will give you additional time to spend thinking about how much the iteration time sucks.)
The debugging experience is also subpar, because you pretty much always have to run an optimised build, which makes debugging tedious. Missing variables, wonky single stepping, inlined functions that are impossible to breakpoint, all the usual problems. It's no fun having to work with C++ code using the disassembly.
Having an enormous pile of engine code to carry around also does not help when trying to get the game into a shippable state. Eliminating all the minor hitches and surprising crashes is a huge pain, simply because there's so many places they could be coming from, and even when it's obvious what the problem actually is, actually fixing it is another matter. The build times (which towards the end of the project are as bad as will ever be) really don't help; you'll be working largely with code you've never seen before, and the issue could be anywhere, so header changes aren't uncommon and spending time deep in thought while waiting for builds is not as helpful as it might be if working with your own stuff.
UPROPERTY tagging - indeed, pretty much everything does need this, but nothing actually seems to check whether you're getting it right. You can easily add a UObject * , fail to tag it as a UPROPERTY, and now stuff will go wrong. This is what I mean about having to be extra careful. If you get it wrong, you'll never know, until things get GC'd prematurely and it won't be obvious why.
Capturing UObject pointers - in a lambda capture list, I mean. These don't participate in the GC mechanism. You have to store a copy of the pointer in a TWeakObjectPtr or TStrongObjectPtr and capture that instead. Again, nothing actually enforces this, so you just have to be very careful to do it.
UObjects outside the game thread - had this on a recent project where there was a background thread retrieving stuff using a REST API. The data was related to some thing or other that was configured in the editor, so one reasonable-sounding thing to do is hand the relevant UObject * to the thread and have it handle everything. But this isn't valid, because the GC relies on UObject pointers only being manipulated by the game thread. But - and the reader may sense a theme developing here - nothing actually checks whether you're doing this.
TSharedPtr - TSharedPtr is reference counted, so you can't have cycles in your pointer graph. This isn't UE specific (std::shared_ptr suffers from exactly the same problem), it's just another thing that can go wrong that nothing checks for. And it's hard to spot, because there's no built-in debugging features for it.
And regarding tagging TSharedPtrs with the correct multithreading mode, UE5 is multithreaded out of the box as it has separate rendering and game threads, and TSharedPtr is an obvious way to share data between them. But if you do that, you need to specify you want the multithreading-friendly TSharedPtr! (This is a particular pitfall for programmers familiar with std::shared_ptr, of which TSharedPtr is supposedly the equivalent, because std::shared_ptr is multithreading-safe by default.) Anyway, we've had this problem on 2 separate projects, and it wasn't easy to track down in either case. And I'm sure I don't need to specify whether anything checks for this situation.
Anyway, niche or not, I've no idea. I'm no UE expert, just somebody that's done a lot of this stupid C++ crap and helped out on several UE4 and UE5 projects that needed some bugs fixing. And it was just a bit noticeable to me how much the same old C++ stuff (that I've been dealing with for years) was still much in evidence.
I like godot, but c# is second class citizen in that ecosystem, which they are open about (1) and despite improving (2), it still a bit rough.
“Fully supports”? I’d say more like “works mostly”.
/shrug
Gdscript is a weird stupid custom language. I feel like in most cases you shouldn’t write a new programming language for your application unless there’s no viable alternative.
I know, unreal did it with blueprint, but that’s because there are no good open visual scripting languages; and they had a lot of existing infrastructure from their previous (also stupid, for the same reasons) unreal script.
What they’re doing with verse is arguably also stupid, but I’ll give them the benefit of the doubt on the basis of a) having done it before, b) having unusual requirements for their metaverse ambitions.
Anyway. Godot did have any good excuse; gdscript was not something people asked for or wanted; it was a lazy version of python because actually embedding python was too hard. Other options existed. …but, instead the time and effort went to building a new language.
One thing you can look back at in Unitys history that is interesting is their aborted attempt to have js, c# and boo as scripting targets.
…but over time, it became clear that having feature parity in all of them wasn’t plausible.
I guess we’ll see where godot ends up, but my $0.02 is that as the api surface increases, feature parity is difficult to maintain, and gd supoort for other languages will wane with community interest.
The only language they are committed to is gdscript.
I write Godot games using both C# and GDScript and they’re both excellent. It’s wonderful being able to use the latest C# features, and integration with the engine and API is flawless. GDScript is just python, but with a few extra functional programming features added that make it a much nicer language to code with than Python. And it’s fun and easy to learn - a reasonably experienced developer can learn it in a few hours.
I see the c# of unity as a major downside vs the c++ of Unreal. We have tried both for simulation engines and have had a much better time getting the performance we need out of Unreal than Unity.
Keep in mind that it speaks more about Unity-specific behavior of C# rather than the way it performs outside of it, like in Stride3D or Godot. There is an absolutely massive performance rift between Unity's Mono and .NET 8's CoreCLR. Unity fixes this by using a subset of C# as DSL for its Burst compiler which is LLVM-based for specific hot paths, but it's something you don't need to do with "vanilla" .NET where all code has good codegen or offers really good SIMD API.
Also if your application is bottlenecked by allocation and collection throughput, you might see even greater difference in performance.
My final straw for unity was when they locked my org due to fraud. I appealed the case thinking it was a false positive by some automated system and they would correct the error.
It took them 3 months to finally unlock, but by that point I just moved on to Unreal and never looked back.
> For example, in the old Unity’s built-in render pipeline, you had a choice between say “deferred lighting” and “per-vertex lighting”, and while these two target extremely different hardware capabilities, result in different rendering and support different graphics features, they work on the same data. Which means the choice between them is “just a setting” somewhere, and not an up-front decision that you have to make before even starting your project.
That's untrue. I've worked on a project that used forward lighting. Converting it to deferred was not an easy task, we had to remove and work around so many transparent objects.
By trade I'm a C#/.NET dev. Unity made it easy to dabble with gamedev on the side. But I've since moved to Godot. Their approach makes a lot more sense. Unfortunately, the C# experience isn't quite there.
GDScript is just barely OK. You really start to miss a lot of advanced features on bigger projects. Generics, Typed Dictionaries, Extension Methods, etc.
Godot adoption will skyrocket further once they add proper C# Web Export. Unfortunately, they claim to be blocked by this .NET team issue.
I came from the same direction. I ended up using ChatGPT to teach me how to convert my C# expectations into UE5 compatible C++.
Between that, and the blueprints, it's not the most painful thing to do as a hobby. Not sure this approach is scalable of course, and I wouldn't recommend taking this approach for making Real Games. But for a little gamedev dabbling? Sure.
I recently started looking at Unity again - not for gaming, but as a way to deliver cross platform B2B products. Primarily leveraging the 2D layout primitives rather than the 3D rendering pipeline, but perhaps taking advantage of things like TextMeshPro instead of traditional techniques. The overall architecture would be client-server, very similar to a typical web app. Unity on the client, some backend written in .NET (so we can share contracts).
If I was forced to do a proper "native" experience on every platform, I may spend a more significant amount of time on this path. The licensing arrangement with Unity isn't perfectly ideal, but in the realm of B2B products it's probably a manageable cost of doing business.
This is kinda similar to what Caves of Cud did. Pretty much wrote the entire game from scratch and then used Unity as a dumb renderer/UI handler/multi platform support.
When the licensing fiasco happened the creator spent a live stream "converting" it to godot.
He didn't open godot until the very end - just to start a thread with his code. Nor did he open unity at all either.
I spent a while working on a digital painting app in Unity. UIToolkit is not complete, but it is pretty good for web-like UI, and you can leverage existing knowledge of HTML/CSS layout. With some tweaks you tell Unity to only redraw the screen on demand, which is better for battery life. My experience is that Unity could be pretty good for cross-platform semi-graphical app development. Except that Unity dev is miserable (slow, never-ending compilation, bad docs, constant bugs, glacial update pace, broken Linux editor, etc etc etc).
I'm aware of at least one client terminal SW that uses Unity as a way to ensure consistent UI.
This was way before AvaloniaUI was a thing and .NET became what it is today. Likely today we are spoiled for choice even if each one has tradeoffs (every crossplat GUI framework has and even native development can make engineers suffer just as much).
Yes, the original DOTS idea had a very strong vision and direction. I don’t know what the current DOTS vision is. But to me the original DOTS vision felt a lot like it is trying to be something else than Unity...
DOTS stands for “Data-Oriented Technology Stack”, which is a collection of Unity technology to include their Entity Component System framework, the Burst Compiler, and their Job system.
Each of these technologies have their own descriptions, but a very quick (and perhaps over simplified) explanation:
ECS is a framework where you have entities that themselves have one or more components, acted on by systems. The way these components are laid out in memory and acted upon by systems is typically more cache friendly then traditional game engine design with heap allocated GameObjects that are themselves a mess of pointers (Structs of Arrays vs Arrays of Structs)
Burst allows you to annotate functions, jobs and systems written in a subset of unmanaged C# that compiles to highly optimized instructions for better performance.
The job system allows you to schedule jobs with dependencies in a useful way that can help enable parallelism without manually having to deal with thread primitives. The jobs can also be burst’s themselves and used in a non-parallel manner if you don’t have something easily parallelizable.
It stands for Data Oriented Tech Stack. It's their ECS (Entity Component System) + "high performance c#" (a C# subset with their custom compiler). I used to call it Unity 2, since it was so different and incompatible with Unity itself.
In Unity's ECS they literally had to throw out every single thing from the OO game engine to get ECS working.
So it was like having two entirely different ways of building a game in the same game engine. Everything one knew about Unity was now gone and you had to learn an entirely new way of solving the same problems. Sure you can still do OO things like inherit systems or whatnot but it was nothing like the original unity.
Once they realized how big of a change this was they did come out with some hybrid approach where you can have OO objects converted into Entities. But really it was just a Band-Aid to the gaping wound they made of the engine.
I should have known that last one -- I have been programming using Apple's RealityKit for a year and a half which is an ECS -- I guess I get lost in all the acronyms ...
I have FINALLY made the decision to leave Unity for my hobby games/programs, after about 10 years using it fairly heavily. It is just making my life miserable and I sincerely hate using it, with the latest beta being almost literally unusable on my computer. I do disagree with the author about UIToolkit though - that is one of the only things Unity has done in the last 5 years that is actually useful.
I'm not sure what to move to. I think there is a big vacuum for a code-first, open source framework that basically does what Unity does without the awful editor. I know a lot of people like GDScript in Godot, but to me it looks like the same mistake Unity made with UnityScript, which they eventually got rid of.
GDScript does have pretty good integration with the engine's internal data models, especially when it comes to persistence.
But Godot does also have first-class C# support thanks to the Microsoft grant and the community-made Rust gdext crate is very nice to use once you've gotten used to how it presents the Godot types.
It just feels like C# is always going to be the better choice though. Why have both, with one of them inevitably getting less attention, and why spend resources reinventing the wheel?
It's also important not to forget other integrations such as that promoted by "the mono guy" ("one of those" or xamarin or even ximian guys if you're that old) himself: https://github.com/migueldeicaza/SwiftGodot
GDScript is really nice! It’s a 99% clone on Python with some extra lovely functional programming features added that make it much, much nicer than Python. Try it, it’s really fun to use.
Or, just code in C#, which has complete API support.
It really isn't. It shares a similar syntax and significant whitespace, but Python people are going to read that and expect idioms like list comprehensions to work and be sadly disappointed.
To each their own. I wouldn't call GDScript nice, I don't think anyone would use it as a general purpose programming language. It isn't as painful as Dark Basic or GML, but it's only value to me is its integration with the engine.
Thanks for the recommendation! I'm currently doing a small project in Monogame to see how it is (maybe too low level to be practical for me), but I think you've convinced me to give Stride a look after this.
Unity is a terribly managed company led by people who know next to nothing about gaming or simulation
Unity is in the “transition into hedge fund” phase of corporate development - but they don’t know how to make the kind of long term revenue that is necessary for that, the same way eg MSFT or Uber does with exceptionally predictable product revenue
JR couldn’t care less about customers, product or anything other than making investors richer - he pushed the whole company whatever direction investor sentiment went (metaverse, ads, Weta failed acquisition etc…) and we see how that went.
MW was a weaker less psychotic version of JR, and couldn’t make a game in Unity if you forced him to.
The new CEO is whatever who cases, just another psychopath trying to pretend he cares about developers. Yawn.
Overall there a lot of people who care about gaming and simulation toiling at Unity and only keep going cause the remnants of a great engine still produce value - however waning. Investors, management however don’t and never did.
Unity sealed their fate going public when they had no long term way to sustain it without destroying it (I’m unaware of a company who didn’t destroy the original products after going public, so, who is surprised)
Not really, there is a big difference in how Unity and CoreCLR GCs work. CoreCLR itself has two-ish GC implementations that are very differently tuned (WKS GC and SRV GC aka Workstation and Server). This is further complicated by DATAS mode, if we talk about implementation, as it dynamically scales heap count and sizes based on application allocation behavior, time spent in GC and the proportion of memory used (enabled by default in .NET 9 for SRV).
AFAIK Unity uses Boehm GC based implementation with augmentations for incremental per-frame collection. It can sustain much, much lower allocation throughput than what CoreCLR uses (and CoreLib APIs try to be not allocatey as well). Would be interesting to read more if someone with better Unity knowledge chimes in.
With all the hype going around Godot in light of Unity failings, I'm hopeful Stride3D will eventually see more light of day as it focuses on high-end rendering and VR, and will eventually integrate Bepuphysics2 to trade blows with big boy engines. Written in pure C#.
> A group of brilliant, top-talent engineers seemed to want to build technology that is the opposite of what Unity is or has been. In their ideal world, everyone would be writing all the code in SIMD assembly and lockless algorithms.
Nice one Aras. I can't say I recognize the company anymore, so disfigured from what it once was, but I still love the engine and editor and still use it day to day.
Someday soon, we will see Godot eclipse Unity in the same fashion that so many other proprietary juggernauts were slowly cannibalized by laser-focused open source projects over the years:
In 2022, the split among GMTK participants was 16% Godot to 61% Unity. In 2023, it was 22% Godot to 49% Unity. This year, it was a whopping 37% Godot to 43% Unity: https://pbs.twimg.com/media/GVfo5-0WQAAIMAQ?format=jpg
This is major, because Godot has just had another round of home run improvements that brought in even more developers. I think 2025 is the year that Godot effectively replaces Unity for new developers.