Unity compared to other engines

I really like Unity, but theres a few things that really annoy me as any path i take seems like a sidegrade at best. The issues are rendering, inputs and ui, or basically, packages and technologies.

Theres legacy tech and new alternatives. The legacy tech is "yeah, its got issues but we don't improve them anymore, because we do the new stuff now". And the new stuff is like "yeah, it's still buggy, lacks old features but it will be fine in a few years maybe."

So if i switch to Godot or Unreal, will it be different? Do those have stable, finished, reliable components or is this normal on game engines?

 

I suggest you search topics and articles like, Unity vs Unreal, Unity vs Godot, Unreal vs Godot, Lumberyard vs ... etc.
There are tons of topics, discussing differences.

Consider the time, you will need to invest into learning another engine.
All allow to get things done. All got pros and cons. But in the end, it is really up to you, if you can cope with such.

 

I'd try to find some indie devs who recently published games similar to what you want to make and ask them what the biggest crux of their projects were.

Going to take time to do that but probably a lot more worthwhile than just starting the millionth forum flame war.

 

Thanks for your answers!
The discussions and videos i saw about engines difference are often about the pogramming language and result in "it's a matter of taste" and "you can do most projects with any engine", which is absolutely true, but didn't really answer the questions i had, which would require someone to have experience in both engines to get to that point.

I had the topic typed out for almost an hour not sure if i should really do it because i didn't want to start a thing where everyone feels the desire to defend their own choice as if it was a question about their worth as a human being, which imo is the weird result of a lot of questions between technology on the internet, but then i decided that my trust in humanity is bigger than my cynicism, and here we are, with a horribly convoluted sentence.

 

The game domain language is secondary to how well the engine works with rendering, etc.

 

This is exactly right, and bugs me too. I don't have as much experience with other engines, but I think I would find some other major PITA at some point down the road. For example, how easy is it to publish an AR project to iOS and Android with the same code base? Maybe that's not important for everyone, but for me I have to do that often enough, I can deal with the current state of the engine I know.

I agree with @BIGTIMEMASTER , find someone or a team making something close to what you are doing. I'm pretty sure I would switch to another engine if I was doing a FPS game of any kind.

 

Before you're jumping into a multi-months endeavor forcing yourself learning a new engine because you're upset with Unity, think about it in a more practical manner. Is there anything you cannot do in the "legacy' framework you got and you want to? Do not care about Unity Technologies and their software engineering habits for a moment.
If there is something you want to do but you can't get for whatever reason, then look for an engine which can give it to you or think about how much time and resources it would take for you to develop it. This also applies to picking up a "new" engine as well. If it takes longer than making your stuff in Unity, then it is lost investment. Unless you're planning to use the new engine moving forward and you don't care about time. But then this question isn't a question, because you already know what you want to do.

Do not jump _any_ ship just because you don't like the captain. Jump if you can't make it to your destination intact.

 

My biggest gripe with Unity is lack of moddability. The editor would be a great tool but it requires my playerbase to learn how to use Unity and learn to deal with all the quirks, slowdowns, frustrations, and excess stuff (Unity hub, large download, git, package manager, setting up render pipeline... ugh)

One of the most important things for modding is that it is simple and easy, both in getting set up and in creating things.

Upside to an engine like Godot is I can ship the entire Godot editor with my game, modding toolkit included, or simply tell people to download Godot because it's like 50mb. Downside is I don't get ProBuilder, RealtimeCSG, etc., to package in with my modding toolkit and would have to create them myself.

Unity has a lot of cool stuff coming. But in the time spent waiting for all this cool stuff to be production ready and usable I've already published my game. It's been years. And as far as I know there are no efforts being made to make Unity more compact and usable for modding.

Learning another engine (as a developer, not a modder) isn't a big deal. Switching to another engine that lacks in resources is the problem.

 

You deffinatelly don't want to include whole engine into game, just because you want to make mods.

Most players won't be modding. And they want resenably fast download of the game. Not some few GBs where game itself is just 100MB for example.

There are many solutions for mdding available. From simple as mesh importing at runtime, to some extensive dll loaders. And if players want to mode code, they don't need Unity at all. They need IDE for writing C# and compiler. Now, do you expect game to be shipped as well with VS? Well, of course not. And is completely uneccesery.

Anyone who wants to mod, can download relevant tools, as required. I.e. Blender, gimp, Unity, VS, illspy, etc.

 

I would never ship the Unity editor/engine with a game. But Godot yes most definitely, it's only about 50mb. Opening the game folder and clicking an exe makes modding your game much more accessible as opposed to downloading various gigabytes worth of software and learning how to use them.

 

Only if you don't want to build your own modding framework on top of your game.

 

Consider what you want to do, then try and find out if what you want is doable with the stuff that Unity has available right now and are finished, which pretty much excludes most stuff they have produced in the last couple of years.

If the answer is that yes, you can do what you want, then if you are aiming to release for PC, you're good to go. For all other platforms, since you might be forced to upgrade Unity (especially if you have a long development cycle), you need to consider "will the features I'll be using now also be available in X amount of years?". Because you can very easily need to update your PS5 (or... mobile) game which now has a new requirement, and the requirement can only be fulfilled with Unity 2077.1f1, which also happens to get rid of a feature you're using in your game. This one is harder to answer clearly, but it is most definitely a thing to consider.

If the answer to any of the above is no, look into alternatives.

 

OK, let me ignore niche topics like modding. Yeah, I love modding, I started my career as a modder, but this is only important for a handful of games. And OP didn't even ask about it.
Let's talk about the general issue of stability which is simply the one biggest issue of Unity in recent years. And why we can't expect it to change soon.

The reply might a relatively long one, but... there's only one way to make an informed decision on which engine to invest in in upcoming years. Need to understand the development philosophy behind every available off-the-shelf engine.

Well, it's normal for in-house engines to rely on many half-baked systems and tools. Although, where you maintain your own engine, you are free to decide "we ship this game with half-baked, hacked AI system, we gonna rework it entirely in the pre-production phase of the next game".

That's the major pain of Unity since it's so popular engine but Unity authors don't work on their own games, so... there's no culture of maintaining "obsolete and ugly, but working tech".
Most off-the-shelf engines are usually developed during creating a specific game, well-designed for this kind of game, improved for general usability, and made publically available. There are might pros and cons of engines like CryEngine or Defold, but these are battle-hardened engines.

Unity lacks stability for the following reasons
- Unity as a company stop creating games 15 years ago, focused on the engine. It paid off greatly until the Unity 5 era, I guess? The engine didn't impose any gameplay framework or even basic tools on its users. It's to these days a great shortcut/framework to assemble your own engine and workflows.
- Although Unity as the company was never profitable. For the last 15 years, owners need to find investors to keep the company alive. They don't have sugar-daddy like Youtube has Google. Which forces them to constantly try to expand Unity in every possible direction at once. "Guys, add things that will generate more income in next year already". Working years on the new and awesome architecture before even announcing it requires healthy financial support in the long-term perspective. Development on something entirely new will take 5 years instead of the planned 2 years. Meanwhile, you gonna earn zero dollars on it.
- The engine systems legacy doesn't seem to be profitable in the short-term. As Unity makes most of the money on ads, online services and Asset Store. Maintaining the old systems while creating new ones from the scratch would cost much and it wouldn't bring much money - at least this what spreadsheet people will tell the company boss
- Unity engine suffers because its team didn't embrace dogfooding. They don't use the engine for their own games every day. This alone would cause teams to prioritize stability of everything, promoting efficient pipelines (setting up Unity for automated build systems it's still a pain in the ass, while I can do it one evening with Unreal).
- Unity can't be stable for the average developer since Unity Teams don't act as game developers. Only recently Unity handled ever-broken prefab systems (it's not a production-ready template system if everyone could break the template in the scene) or optimized common things like calling Camera.Main. These are things that would be first fixed in the Unity team would make their own games. Mhm, maybe they actually really started work on their own game? And we see the first effects of it? Who knows?
- Unity Engine business model relies on subscriptions. Technically, they got more money if project X requires more developers in a longer timeframe. It's not directly tied to the financial success of the game. Also, if the engine workflows would be more efficient (fewer programmers needed) then the income from subscription would be lower.

Let's look at how the Unreal Engine business model forces its developers to provide stable and production-ready tools out of the box. Why doesn't come barebones like Unity and actually force plenty of tools on you?
- This can be still a surprise for some, but probably UE4 also wasn't ever profitable on its own. Work on UE4 started shortly after releasing UE3. Although I heard that initially, one guy worked on it.
- Creating UE4 - and Fortnite along with it! - required a huge investment. Epic sold 40% of its shares to Tencent. The new UE generation had to be attractive to small teams. As the AAA sector was heavily investing in their engines (Frostbite, Ubisoft engines sharing internal technologies, etc), Epic could only make a profit on anything smaller than AAA.
- UE4 is technically an enormous success. The first alternative to Unity, designed for efficient development of any kind of 3D game. Initially, UE4 had a $19/mo subscription plan. They dropped after few months. Probably it wasn't generating much money, but only it was slowing down the adoption of the new engine.
- Unlikely UT, online services didn't bring any money to Epic. Because there were almost no online services attached to the UE4
- There was never an official report on it, but we all "know" that billions of dollars made by Fortnite fuels current UE development, EGS, Epic Onlive Services, mega grants...
- Epic truly makes money on Unreal only if the game succeeds financially. Now the small developers need to make more than a million dollars on the game before Epic will earn anything. The more efficient developers are with the engine and editor, the more money they can make. There's no financial incentive for developer teams in dropping support for old systems too soon. It makes no sense for Epic to push the engine in all directions at once, as they won't make much money this way. Epic usually focuses on one huge area of development (i.e. movie industry), creates an out-of-box toolset for this area. Is it production-ready, did the engine took the movie industry by the storm by providing game-changing workflows? Can we expect many newcomers to embrace our tech and they will bring money in few years? Great, let's now push another area: open-world games.
- Meanwhile, another area of development might be untouched for years. Like I did wait for better open-world support for years. Although there wasn't a single system that deteriorated. Matinee is a relict from UE3, an incredibly simplified and difficult to use cinematic-like animation editor. Nobody sane uses it for years as it was replaced by Sequencer. Although it's still there, in UE 4.26. Epic even adds Matinee-to-Sequencer converter now, before removing this piece of trash. Seriously, some devs will dance on the grave of the Matinee, but Epic didn't destroy/remove any of it in the last 7 years of UE4.
- There are few victims of this approach. 2D games and Web GL games weren't ever the focus of UE4, although somewhat possible. It would be simply slow down and make it more complex to create new systems and high-end rendering advancements if the engine would still support an ancient version of Open GL. So Web GL support got removed recently.
- IMHO there's no schizophrenia in UE development. It's clear they gonna push the development of amazingly looking 3D games, more and more based on PBR. It's hard to imagine that Epic would create 2 incompatible renderers...
- Almost every new system comes with dedicated editors, battle-tested by Fortnite developers. It takes more time to learn basics than Unity systems, but it's usually much easier to create anything than "basic things".
- It's clear that 2D support in UE was just an experiment. If some new system works with 2D in Unreal, it's only because it's impossible to make an audio system incompatible with 2D. There's no discussion or doubts "are they going to improve 2D support?". Nope, no chance. The market for 2D engines is crowded, Unity services small devs and corporations use their own tech (as developing competitive mobile 2D tech doesn't require a decade of work).
- It's clear that non-gaming industries get all toolset integrated well in the engine, frequently even without paying anything.
- There's no need for ECS in Unreal Engine, as game-specific multi-threaded code can be easily handled in C++. Dozens of systems (including blueprints) are fully OOP. And detailed 3D games (Unreal Engine main focus) are usually GPU-bound, re-working half of the engine for a few CPU-bound games won't make sense here.
- There's a single caveat of UE architecture prepared for rapid changes in complex toolset - there's no way to provide a safe path to revert all assets from the newer version to the older one. Simply, asset formats of UE constantly change and it's impossible to roll back from UE 4.26 to 4.22 without crashes on asset loading - older code won't know anything about serious changes in asset format "from future"

As of Godot... I never touched it, so I have zero knowledge of its development philosophy and stability

@CortiWins
I hope it helps in some way...

 

Erm... you should see what people did with beatsaber.

Spoiler

^^^ Pretty much all of this is a mod.

Out of the box, beat saber has no avatars, has no 3rd person camera, does not support full body tracking, and also has no support for 3rd party playlists. All of this was modded in (without permission, probably).

Because of the way unity engine works, end user can hack the game to an insane degree by default. That makes it very moddable.

 

What you've mentioned looks like a project created by some very dedicated users, something a majority of people casually interested in modding will never do.

Think Source Engine's Hammer, you navigate to the game folder and double click Hammer.exe. The Hammer ux and workflow is old with a learning curve which could be streamlined in modern software, but still a very accessible tool for devs and non-devs which made way for all kinds of experimentations, gamemodes, maps, memories, and a very successful modding ecosystem.

My complaint is that Unity Editor could be the perfect tool, it already has 3d level editing tools, lightmapping, extendibility, everything you need. If only it were compact and lightweight like Godot and didn't require my modders to set up the render pipline, have git installed, unity hub, etc. People definitely still go for it and create maps/mods, but it's far from casual friendly and not very inviting.

 

My only complaint with your post is this line here. Because the advantages brought by an ECS framework are not mutually exclusive with the benefits of multi-threaded C++ code. ECS is focused around optimizing memory and cache systems and when combined with multi-threaded code allows you to scale to an extreme that cannot be achieved with just multi-threaded code.

 

Nobody aside from very dedicated users needs that. And majority of the games on the market do not have this kind of feature.

Regarding unity, you can provide your modding framework. As a unity package. VRChat does it this way, and couple of other games as well. I recall that unreal games often work the same way - you want to mod, you download a devkit which is a modified engine. Ark and Conan Exiles work this way.

I believe that instead of being "accessible", it is an "acquired taste".

 

True, true!
What I meant was more like "Epic can keep OOP gameplay framework and implement ECS in limited scope under the hood or let developers apply it in some critical parts of their code. The engine itself doesn't need to be refactored, so it's more stable this way".

 

It helps a lot to understand why things are the way they are. This is more than i could have hoped for with this topic, so i am really grateful, that you took the time to write that humongous post! Thanks!

 

Where's the pain? The first time I set up a CI system was for Unity, it took probably half a work day, and I've since helped others do it in less. Of course it's going to vary drastically depending on the tools you're working with, target platforms, etc. as some of those can complicate things dramatically.

I'm also highly skeptical of the way Unity's business model is painted, there, because it makes no mid- to long-term sense.

I don't have the experience with either of those to say. Before Unity I worked with a variety of other engines / frameworks, though, and based on that can say that everything I've used so far has its issues. Anecdotally, I hear of issues with UE as well. And I can tell you first hand that Unity isn't perfect. People do great stuff with all of the above, though.

Assuming you have time, my advice is to spend some time trying out all of the major tools. An engine isn't a part of your identity. It's just a tool you use. Being familiar with more tools gives you more job opportunities and will make you a better developer in general. I also suggest that people make a small game without a pre-built engine, not because you should do that for actual projects but to have a thorough understanding of all the "hidden" stuff off-the-shelf tools do for us.

So if you're working on or starting a project with time pressure, identify and use the best tool for the job, taking current experience into account. If you don't have time pressure then experiment with all of the most relevant tools. It'll make you a better developer and improve job prospects in the future.

 

Unreal uses more aggressive approach to updating. Basically it is not unheard of things failing to compile after an update (even minor one), and what's more they do not appear to keep archive of old documentation. Documentation site keeps the latest version only. Which can be quite inconvenient.

If we're speaking of significant disadvantages, Unreal has no equivalent of mecanim, and the shader system is much harder to hack.

 

Not sure what you mean by it "does not have mecanim", you can create BP animation graphs which literally do the same thing and facilitate animation blending, retargeting, IK, blend trees etc. Pretty much all of the useful stuff of mecanim is in UE4 currently, and lets be honest mecanim is not the greatest when it comes to animation systems anyway

At least, I have yet to find something I cannot do in a BP anim graph, that I can do in mecanim.

 

It sounds about right that a Triple A engine like Unreal have good animation support

 

"Mecanim" here means animation retargeting. And not "animation state machine".

In unity you can pretty much create any sort of humanoid, slap animation on it from any other humanoid, and it will work properly. Even with root motion. Animations are interchangeable, regardless of body proportions or limb lengths.

You can't do that in Unreal. Animation is part of the character. Retargeting is done during design time in editor, requires manual adjustment and switching them at runtime is not a thing.

 

Runtime animation retargeting is a thing in unreal? Like there is official videos on it and everything, not sure what you are talking about.... are you talking about from an older version of the engine perhaps? I am talking about what is available right now in 2021 in Unreal engine perhaps that is where the misunderstanding is?

EDIT: I will say that it is harder to setup that in Unreal though, thats a given. But most things are harder to setup in Unreal engine to be fair, its more targeted at high end and expects each person using a system to be using that as their main job and so each system is very in depth - but very difficult to use. But it does exist.

 

Mobile + Web GL. At least guys trying to set it up in one studio where I freelance, spend dozens of hours on it already.
Wonder if you used cloud services like GitLab or self-hosted Jenkins/Teamcity?

Do you mean code fails to compile just after the upgrade?
Well, it's usually it's simple to fix. Especially that with many API changes, they simply add a warning to function - explaining what to change. Not everything is documented, but still upgrading a small project takes me less than an hour (where fixing API changes is just part of it).
A bigger project with a lot of project code and tiny engine changes took like a day at 4.25 (because of UProperty-FProperty conversion which was well documented and easy, but a lot of places to change in our code).

I wonder, is it that much more aggressive or unusual than average software? No sarcasm here, not sure if I used a lot of software

Mhm, actually you can switch to older version of Docs page, right at the top. Or did it change?

I got a bigger problem with the fact they often don't update pages after a given feature got upgrades, i.e. they added World Subsystem in 4.24, but this page didn't get the update...
https://docs.unrealengine.com/en-US/ProgrammingAndScripting/Subsystems/index.html

 

Links, please.
https://docs.unrealengine.com/en-US...MeshAnimation/AnimationRetargeting/index.html
While "retargeting" existed in unreal, it was subpar compared to unity, and you had to preapre retargeted animations in advance.

Not seeing it.

Spoiler

Let's say I want an API index for Unreal 4.19. Where is it?

 

Both. Azure, and Jenkins + who-knows-what repo. PC and mobile and other targets, no WebGL. Mobile build chains can be pretty fiddly, though, so it wouldn't surprise me if there's some complication arising from that.

 

By the way, the reason why I brought up retargeting is basically because this is something I tried, and results were awful.
Unity mecanim is also core tech for things like VRChat where user-created character use stock avatar animation.

So, if there are advances I'm unaware of, I'm all ears.

 

Sharing skeleton assets across characters has been supported for over 5 years. You probably got sidetracked by the fact that, by default, UE4 makes you think each character needs its own skeleton asset and there is a whole separate feature for retargetting animations to a different skeleton, which duplicates the animations (also happened to me.)

This page details the requirements for skeleton sharing: https://docs.unrealengine.com/en-US/AnimatingObjects/SkeletalMeshAnimation/Skeleton/index.html

The documentation on retargetting you posted yourself also explains this.

It is not as robust as Mecanim: there is no "avatar" asset to abstract away the skeleton hierarchy, so you must use the same bone names across all characters, and you have to handle effector IK yourself via animation blueprints. I suppose this is for performance reasons: Mecanim humanoids are more expensive than non-humanoid animations because the retargetting is basically running all he time.

 

Sharing skeleton assets is not equivalent to Unity's Mecanim. It doesn't matter how long it was supported, because it doesn't do the same thing as mecanim.

Which was the reason why I brought it up.

There isn't a way to abstract the hierarchy, you have to follow specific conventions, and results are inferior.

My experience with it was that "unsheath sword" can turn into "slit your own throat" animation.
It is absolutely inflexible, and you can't do things like VRChat with it.

Meanwhile in unity any humanoid can use any controller, most of the time. They can even have different bone hirarchies, have extra bones, have some bones missing and so on. It will just work.

Therefore if there was an improvement in this tech and I was unaware about it I want to know where the improved retargeting is documented. Because this is an important feature, and if the situation in Unreal got better, I want to see it.

 

@neginfinity I was going to post links to this but @KokkuHub beat me to it As they pointed out and as I mentioned above, unitys approach is certainly easier - but unreal is built to be closer to AAA engines and takes more work for each system as I mentioned. In no way was I saying that it was better or easier than unitys, just that it exists

But the above points havent stopped me working with it, its actually not that much more of a time sink compared to mecanim in general once you get a hang of their workflow (which is the main part I struggled with due to the engine being very different UI wise)

 

"but" When you are not an AAA but try to do things the way AAAs do, that's a good thing to hurt or destroy your project.

If we had hundred million budgets and tens of thousands of people in staff, it wouldn't matter, but until that happens, unity's mecanim, despite every other flaw the engine has is the closest unity got to the "killer feature".

Because you can animate things once in unity, plug in ANY character later and it would just work (most of the time), while in unreal you'd have to transfer animations yourself and check that they work, OR use identical skeleton (which is bad).

This actually appear to result in reduced character customization in unreal games. While in unity if you plug in UMA and add skins to it, you can have people have different build without creating bazillion animation controllers for them.

 

Hey I am not saying I disagree! Although I disagree about the "hundreds of million" budget wise - a company I work with on a contract has a team of 15 and we have swapped to unreal and are getting fantastic results (deeprock galactic as example was made for the most part with a core team of about 10 - with outsourcing ofcourse and extra members added during development). Things initially are slower than unity, but the idea that it takes such high resources is not based on reality.

For my own projects even commercial ones I will be using unity, but if you have a team of 4+ you can easily make a great game with high quality using unreal.

On the team I spoke about, we have a dedicated animator and other than getting to grips with the new workflow, they have not had any trouble implementing the same quality and variety in unreal than in unity.

I agree about character customisation - that will always be easier to do in unity as in unreal it has to be done manually (make everything yourself and come up with your own system).

Just originally pointing out that these things do exist, and they definately are not as difficult or human/cost resource intensive than it is being made out to be. I am certainly not out to convince anyone to swap engine, they are both tools and both do some things good and some things bad - its up to users to determine which is best for them and it shouldnt be based on anything other than your current project. The current project is a great fit, my previous clients projects would not be a good fit.

I also have WebGL projects going and I could never do that with unreal, as I said some things are great there some things not so much just like it is on the other side of the fence here with unity

 

You know, a few years ago when I wrote about Unreal/unity differences, one thing that I noticed is that switching to Unreal appeared to kill some projects. Basically, at the time there were quite a few games which switched to Unreal from unity, posted few happy status updates "everything is amazing we can believe how great everything looks"! And... then vanished.

My assumption was that at the time they used free stock assets, which set quality bar quite high and they couldn't match it with their inhouse production. But then again. That was an assumption, and since that time Unreal made Quixel available for free to its users.

 

I am not sure but I noticed the same thing. I just want to point out that I am in no way saying that unreal is a replacement for unity. It totally is better at some stuff and worse at a bunch of other stuff.

I think for experienced developers like us its great to have the option to compare for different projects and use it when it is useful. But to a lot of people they assume it means swapping to unreal will fix their problems or give them better graphics, and most of the time it wont.

I stand by the idea that if you cannot get good graphics / gameplay / performance in unity, you will not do any better in unreal!

I think however if you are doing something that you can easily compare the diferences (such as a photorealistic ArchVis application for example) then you should always try to do so as the tech+ workflow in both engines is always changing.

Personally using unreal has mostly made me a better unity developer as I have had a chance to tackle the same problems using a different set of tools / codebase and that is great. As said for client projects who want Unreal I am glad I have the knowledge now, but for my own I will be sticking to Unity simply because I have nothing to gain for my own projects by swapping.

Also Naturally if you have a 2D project you would be crazy to swap to unreal! Want to point that out for anybody coming later to this thread

 

I suspect they'd have vanished anyway.

 

Oh, if you mean this type of "documentation"... ekhem
It's just content autogenerated from the source code. Well, in this form (quite useless), it doesn't even make sense to version it, I guess? This what you can see by browsing codebase

I'm not sure about runtime retargeting, didn't try Control Rig yet... but this new Control Rig thing allows
- procedural animations and Full Body IK, so fewer pre-made animations needed
- docs mention "custom retargeting", and if it's procedural can be used for runtime retargeting of pre-made assets?
- editing skeletal animations in the engine
- exposed to Python scripting for automating work
https://docs.unrealengine.com/en-US/AnimatingObjects/SkeletalMeshAnimation/ControlRig/index.html

Need to finally find time to dig into all of this...

 

My problems with Unity and CI are more related to Unity being more fiddly when it comes to generating builds for anything that isn't Windows, plus the whole license-management thing and the Editor essentially needing internet access to properly function. It takes quite some work until you learn all the steps to correctly setup a Unity project so it can be built from command line straight from a clean checkout without ever opening it in the editor GUI first.

 

Check out Qt docs. Or unity docs. In unity docs, by the way, in both manual and script reference you can actually switch between different engine versions. It is very useful when porting/updating old/legacy code.

Auto generated doxygen class graph does not qualify as a documentation, by the way. In many cases, especailly in case of user-facing documentation, there's a need to explain what the heck was the original author thinking.

The new "control rig" judging by documentation alone does not allow retargeting, but can be used to write a retargeting system. Meaning you'll have to roll your own (also, it is blueprints-based again). It appears to be a generic IK framework.

 

I know
This part is a pseudo-docs has no reason to exist, serves no purpose. Only a few classes got any description manually added

 

Quality APIs built for third parties and customers should have complete documentation that shows in the editor as a tooltipp. From my experience with lots of libraries in different technologies, some companies seem to think that some three year old pdf with a few examples is just as good.