I pick Unity every time. Yes it has many many issues, but as a hobbyist you'll pick a version of it and stick with it. Improvements isn't where the end goal is at, it's at allowing you to deliver a game/product on a given version.
C# is definitely a lot better than old-school C. Unreal C++, everything is just extremely clunky and verbose. Sure there are blueprints, but then now there are free alternatives for the same on Unity as well (although not working as well). If you need to know something there are 10x more free resources for Unity. If you need to buy something, there are 1000x more items on the Asset Store.
You don't need Unreal for Quixel, you can also use it in Unity. You can also use Substance. Sure there are many useless assets, but there are also many many many awesome assets in Unity. Use them.
Both editors have issues. I won't comment on Unreal. Unity's can be a real piece of work sometimes. They all give you issues and make you go arrrgh.
Networking. Unity has nothing by default, it's all in the Unreal corner. If you want to do it in Unity, install Raknet, cloud options, etc., you'll have to figure it out. It's a big ball they have no clue about.
Financial terms, let's see. Both are ok. As an indie first you need to produce, then it's about the fine print. Both are ok, really.
Last point, 100% agree. It's about producing a game. Both engines will fight you hard if you try to produce anything outside their default mindsets. Unreal by default focuses more on fps action. Unity is more open. but GameObjects are extremely heavy and restrictive. You'll need to figure out instancing (until whenever DOTS becomes production ready and useful). Other issues, newer options like HDR isn't supported in Unity by default yet, so if you're heading that way it's definitely not for you.
Unity's licensing model has always been that developers or users must pay for their own license (for an asset or non-free subscription) unless they are part of an entity's license. Unity clarified that only employees of an entity, or subsidiaries of an entity and the subsidiary's employees, are covered by the license.
This is generally always how it works with software licensing: independent contractors, by virtue of being separate businesses, must pay for their own tools and licenses (and indeed, that is one of the factors in the independent contractor test under federal US law).
However:
Programming in Unity is quicker and easier.
* In Unreal you have to choose between Blueprints (which have some issues) and C++. C++ compile times are slow. Unreal supports hot-reloading of C++, but it frequently breaks stuff, so it's safer to save your work, close the editor, and then recompile and restart the editor. It takes a few minutes, which really slows down iteration times when you're tweaking a feature. If you have a bug in your C++ code, it can crash the whole editor, and you'll lose any unsaved changes.
* Unity's architecture is simpler, lighter, and more pure. Unity has GameObjects. They hold a collection of components. An empty GameObject has very few functions or variables. GameObjects are purely containers; you don't inherit from them, you just make components. Unreal has Actors. An empty actor has 448 functions. sizeof() and empty actor is over 1 KB. You inherit from actors, and functionality is mixed between inheritance and components. This flexibility may sound like an advantage, but I find inheritance tends to cause more problems, especially in conjunction with Blueprints. Unreal's built-in classes (AGameMode, APawn, APlayerPawn, ACharacter, APlayerController, AGameState, UCharacterMovementComponent) set up a somewhat complex architecture for you that's strongly biased towards the FPS genre.
* Unity's API documentation is miles ahead of Unreal's. The community is also larger which makes problems more googleable.
Blueprints kind of suck.
* Blueprints look friendlier to non-programmers, but code is easier to read and write for anything complex. Even short things are often simpler in code. For comparison, here's the same function in Blueprints (https://i.imgur.com/86rt8qp.png) and C++ (https://i.imgur.com/7HSnlR9.png).
* Blueprints are saved in an opaque binary format. This doesn't work well with version control. Unreal has a diff tool for Blueprints, but you can't merge them. On rare occasions, a Blueprints will get corrupted or bugged and your only option is to revert it in your version control (we've had Blueprints crash the Unreal editor whenever you open them).
* Blueprints are an order of magnitude or two slower than C++.
* Blueprints lack a lot of functionality compared to C++. Only API functions that are intentionally exposed to Blueprints can be called. You don't have anything like functors or lambdas. There's nothing like templating or generics. While there appears to be a dropdown to make Blueprint functions public/private/protected, it doesn't work (it literally has no effect).
* Making C++ code useable from Blueprints is extra work. It can be tricky to write classes and interfaces in C++ that can be used from either C++ or Blueprints. It's not much of a problem for a single concrete class, but it gets tricky when you want to make things flexible with interfaces.
Unity has more resources for developers
Epic is slowly closing the gap here, but Unity has a bigger community, a bigger asset store, and better docs. For models and sounds, we often would use the Unity Asset Store for our Unreal projects. Unfortunately, that's not possible for code plugins. Stuff like Amplify Imposters and FinalIK just doesn't exist on the Unreal Marketplace (although looking again, the Unreal Marketplace recently got a Fabrik IK plugin, so maybe they're catching up).
I don't agree with this. I do think C# is an easier language to follow, but Unity's game engine API has less stuff built into it, which is a far more time consuming element to work around. If you want to say, launch a projectile, Unreal has the projectile movement component that you can slap on something. Unity you'll need to implement it yourself. I went from Unity to Unreal and find the number of things that are automatic vs. manually implemented is a way better time saver.
> Blueprints kind of suck.
I've never had them run too slowly versus code. I do miss lambdas. But I think blueprints have some advantages that code does not. It's incredibly useful to visually see at a glance what functions are pure with no side effects. It's lovely to be able to collapse large sections of code into nodes with long descriptive names that you don't need to look at. I code in blueprints as much as possible. I low key wish I could move my python jupyter notebooks from work to such an environment because it makes the pipelines so easy to follow. That is, I find it way easier to produce excellent documentation for them than with code. Mind you many people seem to have the opposite interaction and create lovecraftian spaghetti horrors.
I don't quite follow what Imposters does, but I think this is likely to be outclassed in UE5 with its nanite and lumen. IK solvers are just a part of the engine via Control Rig. Haven't used em though.
To each their own though. Unity is good. I just have doubts about its future management.
> It's incredibly useful to visually see at a glance what functions are pure with no side effects.
You can use the const keyword for this in C++.
> I code in blueprints as much as possible.
I also code mostly in Blueprints. The fast compile/iteration time is the main reason. But it has it's downsides (code review is largely impractical, no merging, physically much bigger and longer to read than equivalent C++).
Imposters and IK are actually both things that Unreal has built-in, but the built-in versions are limited or poor quality. Unreal has two-bone IK, and more recently, a FABRIK solver, but it didn't support multiple end-effectors or joint constraints. So basically, if you wanted something like a multiplayer VR game where the character poses somewhat realistically to match the positions of the headset and hands of the player, you couldn't do that. The main use for Unreal's two-bone IK (which was the only built-in IK for a long time) is for smaller tweaks like adjusting the position of a characters foot to be in contact with the ground.
UE5 looks very cool. I'm looking forward to its release.
Oooh thank you
Both are fine, but if you're going to pick one, I'd suggest Unreal by a long shot. Switching between the two is tricky and is likely to make one feel whichever they started with is more intuitive as the UI design is pretty different for each editor, but both feel fine after a short effort. The main reason I'd vote for Unreal is that Unreal feels like it's getting better at a noteworthy pace, and Unity is stuck in a one step forward, one step back pace.
* C++ (unreal) is not as fun as C# (unity). But Unreal's blueprint system (a visual, node based coding system) is much easier than both, and super helpful in the game dev world because it makes the engine API easily discoverable. Not good if you want to write a list sorting algo. Very good if you want to make a character jump. Dispense any preconceptions they may have implied about "not needing to know how to code" to use blueprints. If you can't code you will likely burn out trying to use blueprints without grasping the fundamentals of coding, because blueprints are just code with visual syntax, and syntax is not the hard part of coding.
* Marketplace assets on unreal seem way better. The high end stuff is better. The free stuff is better. The number of high quality textures and prefabs you get for free via quixel in Unreal is astounding.
* Unreal requires more computing power, and I found the editor crashes more. That's not so good.
* Networked multiplayer is just broken in Unity, versus integrated into everything for Unreal. This is huge! for shame, unity.
* Unreal's financial terms are more indie friendly (free for first million of revenue)
* Neither is going to make or break your game dev experience versus the other.