How would you improve Classic Unity?

I came from before OOP, so learning OOP seemed hard work especially as there was no internet and i was younger, i had 1 book and if that didnt make sense, well i was on my own.. oh and of course it was c++ ... and i knew no one who would assist. So, yeah that was fun. However.. the whole ECS thing I semi understood I didnt mind till at some point i thought hey I'll poke at this, and tried like some simple stuff and discovered there was no equivalent to "OnCollision" well there was, you could get a list of collissions... but the simple of event of "OW miss miss billy hit me" was not available.. you had to scan to ask if they had been hit, and scan to ask who hit it.. They have done a lot of work since then and Im hoping that has improved. I backed off at that point and I guess now its out I should look and learn enough so I know when is a time for me to use it and when is not. tic-tac-toe doesnt need the whole ecs system..so far Ive for sure not needed it - but maybe tomorrow I build something like they are billions, and i will appreciate it..

 

Someone please re-do the tests in Unity with C# and compilation to il2cpp!!

I think there is middle ground as overly OOP/interfaced code can become as complicated as the unclean code to follow and debug! (more so actually)

But while this optimisation is important for inner loops and some genres like RTS with many units, you can not manage a large project very well if you code the entire thing C-style, that is why we got OOP. So use it where you need it.
Also many games are GPU-bound, saving a little CPU will not help you, but may make your project much less manageable.

 

It's true that MonoBehaviour Stuff is ancient, but it still works really well.
I would just wish for more usability options.

• Some alternative to Drag and Drop, like in Blender with Copy&Paste while just hovering.
• Relative Execution Orders -> A runs before B and B before C - but all of them just run whenever. Would be quite simple to declare with an Attribute or a property override "executeAfter".
• Moving Animation configuration out of the FBX Importer Inspector - it's really weird that these are not their own assets where I can configure everything, but inside some FBX Prefab which I have to "apply" (basically reimport) entirely every time I change just one animation event.
• Getting away from String-References. The whole Animator can only be called using magic strings, if you change one parameter name or animation-clip-name (in the Animator), every script using it just breaks. Which means you have to write your own wrapper for that stuff which is ... strange.
• Other cool things from blender
  • -> API lines on hover, everything can be called from code, every button. And when you hover it, you see basically the line of code you have to use.
  • Alternative to Transform Gizmos. Moving things with the keyboard, instead of Mouse-Dragging (G X 10 -> Move 10 units along X axis)
  • Hold Mouse down while moving over many checkboxes to set them all without clicking on every single checkbox.
  • Circle Selection Tool, aside from clicking and the rectangle-selection, there is also a circle selection which I use 99% of the time when using blender.
  • Built-In Array and Align Tools. I know assets exist but it would be cool if this was built-in as almost every game has some kind of repeatet elements somewhere (pillars, floor/ceiling/walls made out of tiles, ..)
  • Spacebar -> Search and execute any Action (global (like import FXB) or for the window the mouse is hovering (like recalculate normals))

 

Lots of people here conflate performant code with premature optimization. Those are two different things. Also, performant code doesn't automatically mean it's unreadable, unmaintainable and unextendable. The video in question showcases that the more performant code is actually more readable and overall requires less mental load to comprehend and extend. Furthermore, the do what ever and optimize later mantra rarely actually manifests in production unless the framerate is complete dumpsterfire, yet this is basically the default advice, especially in this forum.

The video also reveals that following Uncle Bob's clean code video series and books basically eliminates last 15 years of hardware progress in some cases, which was surprising to me because those videos are recommended everywhere, including these forums. I was under the impression that by writing "clean" code I'm writing good code. I'm not so sure about that anymore as someone who tries to target the widest possible hardware spec, all the people who can't run AAA games, basically. Also, WebGL and mobile.

 

Uncle Bob's stuff is basically only really good in the context of enterprise development and other codebases that will require potentially decade plus long support, things where highly performant code is much less of a priority than highly maintainable code. Like most people who work in enterprise, a lot of specific advice that's given really goes out the window the moment you're targeting 15ms maximum update loops and hardware that isn't basically operating off the same general design paradigms of the 80s and 90s.

 

The thing is, a bunch of people doesn't even know what this means. You have a manager class and you have the reference to all of your enemies so you can loop over them and calculate their "move" action? How dare you!

Is it readable? For me, absolutely. I started as a tinker on a C64 we wrote demos and intros, we calculated every bit and every CRT step. Having an array to go through your object is a nonsense-complexity in this context. Game dev is more like demo and intro development in the end than making the next excel. Well, unless you make a UI-game like Football manager or something. But in general. What changed over the years is we don't really code in ASM anymore (except rare cases), and we have a ton of help from engines, we don't need to write _everything_ ourselves.

It always worth to learn the techniques of "the other side" (it's not really sides, but we tend to draw a wedge between the two paradigm), anyway, I digress. If nothing else, you are more easily recognize the patterns used and your readability of such code improves. Because it's always language learning. The more you do, the more you recognize the patterns. And when someone comes and say, hey, the readability is crap, it usually just means that they are lazy and they don't want to put in the work. Humans often put TOO much emphasis on productivity in the crappiest capitalist sense. You learning is productivity too.

 

I always thought that the animation system is good, but it feels slightly unfinished.

• There is no generic retargetting, even though I'm pretty sure this was a planned feature
• There is no way to retarget an animation clip as far as I know.
• For a character with an animator controller, there is no easy way to just cross-fade to and from an arbitrary animation that's not in the statemachine. The only way I've seen is using a playable graph but the code for this is confusing and not concise.
  
• The API for constructing or modifying an avatar with code is not well documented and has some strangeness to it. For example, if you retrieve a avatar's humanDescription and then immediately assign it back (unchanged) you'd expect nothing to happen, but for some reason it changes the bone orientations.
• As far as I know there is no easy way in code to simply query what state the animator is in at any given frame

 

Since we are at the topic of the animator:
- A slerp for transitions between clips (as an alternative to the linear default) would be such a small addition with great impact in return, making animations overall smoother.
Please.. That was a disappointment to see that it's not a thing.

 

Now that unity supports source generators I'm sure they could go back and massively improve many of these old features as well. No need for reflection or strings and you could basically do anything you wanted.

Recently built one to Serialize Interfaces in the Unity Editor, an "impossible" task.
https://forum.unity.com/threads/ser...the-editor-version-0-04.1465469/#post-9199781

 

Another thing: There's a lot of products on the asset store that allow you to optimize your scenes by combining mesh component objects in to a single object while atlasing the textures- things like Mesh Baker and Mesh Combine Studio, etc. I think this always should have been a provided built-in feature since the beginning, since it's kind-of a rudimentary thing.

LOD auto-generation would be nice too.

Unity already has a sprite atlas generator and it can automatically generate mesh colliders, so it feels like they were already 75% of the way there for a long time now.

 

Not sure this is the best place for this feedback, but Prefabs are SO CLOSE to being an incredible system, but there are many ways that you can accidently change a value, or get disoriented by where your changes lie.

"Did that change affect only the scene object? Or was it only on the prefab child?"
"How far down the inheritance chain does that change go?"
"Why am I always selecting the topmost prefab parent all the time?"

Prefabs try to be too many things at once, you can do so many things at any given time that the entire pipeline becomes muddy. Propagating scene edits to prefabs and the entire pipeline is a tad different from prefab edit mode in various ways. Here's a few suggestions that would really push prefabs a long way to just an all around kick arse system without much confusion or headache and really amplify one of Unity's core and uniques strengths over other engines.

Prefab Suggestion #1: Lock/Hide property
This would be a massive boon to the entire pipeline of working in Unity and give the already robust prefab system an entirely new utility for organization of game logic. Currently, when we select a prefab we get something like this:

a hodge podge of various values prone to user error, noise of non important information.

We often only want only a very few of these values exposed in the child prefabs. You can use [Hideininspector] to hide these values in code, but we need these values to tune in the core parent prefabs.

Imagine if there were new options located when you right clicked a property "Hide property" and "Lock property". This would be an absolute game changer. Hiding a property would cause it to not show up at the current level, and lower level of prefab inheritance, and a locked property would make it uneditable and greyed out for values that you still want to reference, but not make changeable.

This would make working in unity SO MUCH better for those of us working with prefabs, and wanting to maximize our design efficiency, and at a glance, it would be far easier to tell at what inheritance level you're at based on what's exposed and what isn't exposed in the inspector while drastically cutting down on information noise across the board.

Changing the inspector to debug mode could allow the user to see all hidden properties and unhide/ unlock them at any given prefab level

Prefab Suggestion #2:Move the above hide/select toggle from the scene hierarchy to the game object's inspector window below, allowing prefab inheritance to allow for orderly scenes

Above is where freezing/ hiding currently resides, below is a mock up of how it could be added in the inspector

Our ability to "lock" and "make invisible" objects in the scene hierarchy would be far more handy if they were located within the game object and able to be toggled in prefabs so the setting is global in all instances, these settings as they stand are very easy to accidently click on and make the scene heirarchy very messy. They can be handy here and there, but because of the clunkiness of the UI, they're often more trouble than their worth. By putting scene selection per object, it would allow us to create prefabs with nested prefabs, without us constantly having to hunt within that prefab for the prefabs we want to select and edit. (Ok, this isn't prefab specific, but it becomes very powerful in conjunction with prefab inheritance)

In the project view, instead of every object being able to be set for hiding/ selection lock, we could choose a global setting of if we want to override these per object settings so we can see and select all objects, allowing us to select assets that have these toggled off and setting them to be visible or selectable again.

Prefab Suggestion #3: Add a setting within prefabs that makes their values auto update when adjusted in the scene, and display proper color indicators of changed values as if they were in prefab view.
There are very few prefabs in my scene that I want to have scene specific edits, if I edit a prefab in my scene 99 times out of 100, i want those changes to at least affect the lowest level prefab. Currently I am constantly having to right click and tell changes to affect the prefab and not just the scene object.

We put prefabs in the scene despite the extra overhead because it is THE BEST means we have of organizing assets for rapid tuning of values, but there is currently no way for us to tell these prefabs to automatically assign their changed values to their referenced project prefab.

Even better, make an additional value that's scene wide so we can have "tuning scenes" where all assets within that scene will automatically propogate changes to scene objects to their prefabs.

Prefab Suggestion #3: Better color coding

We get some color indicators if something is changed in the current level of a prefab, but we don't get any sort of indicators that show what's been changed at what level of inheritance, or if a change is scene specific, or inherent to the prefab variant. Everything currently just gets a blue notch, and it doesn't convey much information. It would be great if there was a very feint notch indicating that the parent prefab which is also a variant, also had a modifier to a given value. This would also go a long way in showing us at a glance that this is a prefab child of a prefab child. Currently it's easy to get lost in the prefab chain of inheritance, because there are no visual ques of how far down the inheritance tree you are. A Red notch could indicate a scene only change that is not propagating to any prefab instance.

Prefab Suggestion #4: Insert/ Remove inheritance chain from prefab variant hierarchy
Sometimes we create a prefab variant just to be safe and end up wishing we hadn't, and now we're stuck with an extra long inheritance chain with extra prefab variants inheriting from other prefab variants that we wish we could just zap from existence, but there is no way of adding or removing from this chain and unless you want to rebuild your scene and assets by hand you're stuck with a mess of prefab variants.

Prefab Suggestion #5: For the love of all that is holy, can we get a reliable means of creating property windows for prefabs and prefab variants that allows us to reliably make changes to several things at a given time? I'm not even sure how to properly describe this problem because the pipeline is so convoluted, but i know that if I want several inspector or property windows open to tune various things, there is no easy means of having several of these windows at a given time that allows me to tune these various things. There is always some nagging restriction that requires me to open some prefab in prefab mode to make a change that makes it impossible to iterate on several things at a given time. I've suggested this elsewhere, but a "recently modified prefabs" list displayed from the undo history that allows us to navigate back to a recently modified prefab would be a godsend as well. There's a nice handy undo list that shows recently changed prefabs, but clicking it undoes all recent work, would be more handy if we could right click it and go into prefab mode for that specific prefab.

 

You might find this thread/ forum interesting:
https://forum.unity.com/threads/animation-status-update-q2-2023.1445425/
https://forum.unity.com/threads/animation-status-update-q4-2022.1377234/

 

Change leadership so another brain drain doesn't happen due to forced RTO: https://twitter.com/james_r_arndt/status/1690438575060373506
https://twitter.com/gekido/status/1683506354307358722

Aren't they closing like half their offices in the next few years? Seems weird to force people back to said offices.

 

When staff queried the enforced RTO and how its not possible logistically for some of them, the CMO said they should just get 2nd apartments in cities with offices (like San Francisco) as thats what she does to make it work. Spoken as if buying/renting a 2nd apartment in SF is something most workers can afford and casually do. Same CMO was awarded $32 million last year (during mass layoffs of staff due to 'reduction in workforce').

Yikes.

(I apologise for off-topic; but it does tie into how far we are from the world of 'Classic Unity')

 

It's a layoff strategy. The ones who can't or don't want to make RTO work are easy to lay off.

 

That was my thinking when they first announced upcoming office closures. It's not realistic for all employees to relocate. And now it seems they're even forcing remote workers out so them going remote doesn't seem to be realistic. We could see another 20-40% workforce reduction in the next few years.

 

That is interesting! Although I'm starting to think this thread "How would you improve Classic Unity?" might have a bad premise. We're talking about improvements for core Unity without packages, where as it seems like Unity is leaning in to the package manager for any major improvements. I imagine in the future that the Unity editor will just be a skeleton and then you sort-of "build your own Unity" using the package manager. There'll be no built-in renderer, no built-in animation system, no built-in UI, no built-in input handling, only packages. At that point, the only improvements the editor will get are inspector UI stuff.

 

That may have been the plan at some point... I don't think anyone knows what the plan is any more. Lot of crazy schemes in this industry nowadays, lots of crazy monetary plans, AI, venture capital, tertiary revenue streams. Like literally anything but making a game engine better at making games fun any more. Not sure why any of us are even bothering to post here.

 

I meant the pressured RTO from almost all tech. But that too.

 

I believe there was a plan. Unity believed the local maxima in terms of performance with Monobehaviour was too low (and maybe they were right, but I still believe it would be worth it to try and achieve it), so they gambled big on a new DOTS base, and then building everything on top of it and make a "new Unity".

"Old Unity" was left to decay and rot, a conscious decision. BUT. DOTS took much longer than planned, so all tooling on top of it took even longer, plus Unity becoming subscription based made everything worse: Users weren't getting enough fixes or features for the subscriptions they were paying AND overall stability / reliability of the system went down, since with subscriptions they don't need to "sell you" the newest version, you're just paying regardless.

Imagine you had a game running on Unity 7 (or something) and Unity 8 comes out. Imagine you try a trial of it and your game doesn't work on it. Do you buy Unity 8? No. Therefore Unity would be incentivised to make sure Unity 8 is stable and compatible and provides new stuff.

It's as if they knew the new releases would keep getting worse and worse (at least until "new Unity" came out?), so they changed their business model so they aren't really affected by the editor getting worse. Which I think gave Unity managers a new idea, "what if we start to position ourselves in a way to benefit from things getting worse?".

Then, for example, if you know build times will get worse (or you can't be bothered to make them faster), you make a service to offload build times, AND you charge more the longer the build times are. I mean, it's genius in a way, at least in short term. The S***tier job you do with the build process, the more profitable you are.

(and sure, I'm sure the actual developers working on these things want them to get faster and better, but I don't think it matters).

So there was a plan, the plan failed, and since then Unity is positioning themselves to benefit from their failure.

 

You have to recalibrate how you view the organization of what a company is in our modern era. It's not a competition to produce a quality product any more, it's about monopolizing, hoarding the market place, and starving off all competition. The notion of producing superior tools and innovating doesn't even register in their minds any more, they're too high on all the new age bull. Working hard, striving to produce a superior product is dated and cannot sustain against an overarching system that seeks to eliminate competition and quality products. We're living in bizarro world.

Steve job famously revitalized Apple by focusing on product again. But what if damn near every company, all at once, just all decided to say "nah, we're actually good with just printing money, and providing nothing of value, and we're going to use our overarching capital and power to put all our effort into entrenching ourselves, and starving out anyone who isn't on board with our plan of guaranteed, perpetual dominance.

There has been a paradigm shift. Too many boot lickers, too many comfortable posers just happy with that fat paycheck, willing to scratch back and coast along with this giant technocratic machine perpetuating this quiet decline.

The people who cared are gone or don't care any more. It's a new era, the era of coasting along, and not rocking the boat. The people left could give a damn if the engine does anything that pushes the envelope. That's the world we live in. Why Try? Why fail? Just do the mundane bull, show up, shoot the S***, and suckle at the same teet everyone else is as everything stagnates and goes to hell.

 

seems plausible to me.

in a public interview the ceo can't even restrain himself from saying that people who don't use predatory game designs are idiots. So it is clear where the mindset is.

why not use the same methods unity mobile devs use to trick people out of their money on them? there is a fool born every minute, doesn't matter if a few smart people realize what is going on.

 

Seems like anything "as a service" is going down the S***ter. GaaS was a mistake, nothing but barebones skinnerboxes built on top of predatory monetization practices. Worst thing that has happened to the industry.

The plan failed for sure, and I think that's when the old guard got pushed out completely. The failure was used as an excuse to shift both leadership and priorities. I don't think there's an intentional plan to profit from this failure, it's just a side effect of the current out of touch, perhaps even non-technical Unity leadership. Typical C-suite bullshittery. As old boy Rich said, they're here to do good business. They're not here to make a good game engine.

@kdgalla has a good point about packages, not much of classic Unity will remain after legacy stuff is deprecated. But that is unlikely to happen soon, they have to support their 10-year live service games.

 

You somehow mistyped that "Steve job famously revitalized Apple by focusing on marketing BS again."

 

Probably the best thing long term would be for classic Unity to be deprecated ASAP so Unity can stop using legacy systems as a crutch. They have no pressure to reach package feature parity with classic Unity so it's an endless drag with no finish line in sight. We shouldn't be relying on systems that haven't really been updates in 6-8 years.

 

Well this - I would think the entire code base needs a refactor with SRP becoming the base and not some tacked-on code mess like it is currently (basically an additional monobehaviour on each light camera etc!).
But this is probably a non-starter given the time and investment required!

 

th problem with any tool that tries to be everything for everyone is it hardly ever really succeeds.. what with the old render pipline, urp and hrdp.. isnt it about time to walk away from the old? same with the input, you had the old, you made a new, theres been a reasonable cross over, walk away from the old. stop having big bunches of code base to work with

one of the other things i wish is that the asset store had more quality checks.

 

Thanks for summing up the thread wrong, useless bot.

 

This would totally screw us, but I would dig it. Although do you think management cares enough, or has enough editor awareness, that they would be bothered that they are shipping an editor with glaring gaping holes in its feature set?

"No animation system at all? Just buy one on the asset store, or script your own, many developers do it this way, and many released games are making their own. Do you really need animations anyway?"

 

I wouldn't expect it to happen immediately but just the top level decision would likely get package teams in gear simply because they wouldn't have anything to fall back on anymore. Unity heavily needs some defragmentation. Also, the new animation system has been in development for years, I'm sure they can scrounge up some MVP. I don't think anyone's benefiting from this new closed off development. They spend many years and launch something incredibly barebones anyway, supposedly led by their "partner" feedback, which we can't see.

It's a pipedream though, they need to support the mobile live service games long term. So it'll probably take another 10 years for all these stale legacy systems to be finally deprecated, which is kinda depressing when you think about it. The fragmentation of Unity will only increase in the short to midterm.

 

You mean the system where they have been repeatedly telling us they have nothing ready to show for at least another year (which means like at least 2 more years, right?).

New audio stuff have also been worked on for years, (they showed some preliminary stuff in Unite 2019), but they are still multiple years away ( https://forum.unity.com/threads/is-there-a-native-midi-implementation-in-unity.1466276/#post-9177134 ).

There is nothing ready, and considering what a S***show v1 (and in many cases, v2 and v3 all the way up until they stop developing them) releases of any Unity features are, I would say we still have 5 more years until we have usable "new" animation and "new" audio, that are approximating the current feature set but are better maybe but also maybe not?

 

I really don't get why these timelines exceed the biggest AAA titles in the industry when Unity has more resources. Sure, developing a base system everyone will use takes more time, more consideration but, still, it's just a single system with limited scope, they're not attempting to land on Mars here.

I feel like OSS will outcompete Unity for indies and small studios in the next 5 years. Bevy does ECS better than Unity, but still lacks the editor. And Godot covers the GO world. They're more focused engines that don't try to do everything for everyone. And most importantly, they focus 100% on game development with more reasonable timelines (most of the time).

 

They are though. Look at new input system for example. The have rebinding API which is just ridiculous since it tries to assume use case and predict all of them, while only giving you "options" on how it would work.

In old unity we would just get "SetInputActive" method and something like "OnInput" event that is called anyway, so you can do rebinding stuff yourself in any way you want. In new unity we get... this

Code (CSharp):

1.  // Just by the way, PerformInveractiveRebinding gives you object that hooks into lowest
2. // level API Input System has, it reads from raw pointers
3. m_RebindOperation = action.PerformInteractiveRebinding(bindingIndex)
4.                 .OnCancel(
5.                     operation =>
6.                     {
7.                         m_RebindStopEvent?.Invoke(this, operation);
8.                         m_RebindOverlay?.SetActive(false);
9.                         UpdateBindingDisplay();
10.                         CleanUp();
11.                     })
12.                 .OnComplete(
13.                     operation =>
14.                     {
15.                         m_RebindOverlay?.SetActive(false);
16.                         m_RebindStopEvent?.Invoke(this, operation);
17.                         UpdateBindingDisplay();
18.                         CleanUp();
19.  
20.                         // If there's more composite parts we should bind, initiate a rebind
21.                         // for the next part.
22.                         if (allCompositeParts)
23.                         {
24.                             var nextBindingIndex = bindingIndex + 1;
25.                             if (nextBindingIndex < action.bindings.Count && action.bindings[nextBindingIndex].isPartOfComposite)
26.                                 PerformInteractiveRebind(action, nextBindingIndex, true);
27.                         }
28.                     });

Btw the only way to save your rebinds is using built in json converters.
And this is how every new unity's API feels like, too high level, too "Asset Store" like "ready project" mentality

 

A 19 year old game engine company with thousands of some of the (allegedly) brightest engineers on the planet shouldn't take 8-10 years to ship a feature complete system when they have experience with similar systems and have numerous examples across the industry. They're not reinventing the wheel. Or perhaps they're trying to and all we get is the failed version of that. Also, input is different from game to game between different genres. Audio and animation is kinda set to certain formats and played in certain ways. I imagine the issues likely lie within the DOTS part of the equation as it has since 2018.

As for weird package API, I can't comment much. I mostly avoid packages whenever possible. But now I do dread the implementation of key rebinding down the road for the current project. Just another way Unity is becoming hostile to small developers, everything is getting harder to do.

 

Age is a major part of the problem here. Unity has a tremendous amount of technical and organizational debt that is holding them back.

Are you able to name another publicly available game engine that has an equivalent to DOTS or SRPs? Like the tech behind DOTS has been around for years but aside from Entitas which is just the ECS I'm not aware of an equivalent for C# and certainly not with a custom compiler.

Concerning input most engines in my experience just have a very basic implementation. Unreal Engine only semi-recently gained a more capable input system. What they had before was quite literally the equivalent of Unity's old input system.

 

Bevy for Data Oriented and Ogre for Scriptable Pipelines (or I don't know what aspect of the SRPs you consider unique)?

 

A concept doesn't have to be unique to require partial or complete reinventing of the wheel. It just requires that the info on how you approach the problem not be readily available or cover the problems someone is trying to solve.

 

I wouldn't want an engine with Unity's SRPs.

 

That is not what you asked. But also DOD and SRP as concepts are old as F***?

But also, if you reinvent the wheel for no real benefit (who is really happy with SRPs?) and bad tradeoffs (is DOTS really worth the rest of the engine going to S***?), maybe don't reinvent the wheel when you also have other things to do and you obviously can't do all of them?

 

As AcidArrow mentioned - Bevy as DOTS alternative with far less boilerplate. A true ECS engine. Best known game currently made with is probably Tiny Glade. But it doesn't have an official visual editor just yet. All code solution. As far as I'm aware, main lead is focusing on the editor for the following year, so it's coming soon'ish. Definitely faster than Unity's animation or sound.

As for SRPs, do you mean the ability to completely custom tailor the whole thing from ground up? I'm sure it's a boon for teams with dedicated graphics engineers, but that is entirely out of scope for my purposes. Or if the advancement here is dedicated performance/compatibility oriented and high end pipelines then Godot is doing that too now - Vulkan for high end, OpenGL for compatibility but they're not designed to be custom implementable like Unity's. The vast majority of users will stick to one of the default pipelines anyway. Per recent steamdb data, built-in was still majorly used in 2022:

• BiRP accounts for approximately 69.21%of the Unity games released on Steam in 2022.
• URP accounts for approximately 26.89% of the Unity games.
• HDRP accounts for approximately 3.90% of the Unity games.

One could argue that a lot of asset flips are published with built-in, but it generally aligns with data published somewhere here on the forums about new projects using the render pipelines, which I haven't found yet but know it exists somewhere around here.

 

To zero in on this specifically: even if it's less performant to do so in a fair few cases, I've found that using command buffers to extend BiRP to be dramatically easier than trying to accomplish the same effects with HDRP and URP.

 

(I promise no sarcasm) thats really interesting, the way they bang on about urp and hdrp i kinda felt it was only me still using the birp. To the point every few versions id try put it in to urp to see if it would help, and in fairness in 2023.1.8 it finally went in and didnt look awful (although i had to change the lighting a lot as while my game first level is supposed to be dark theres dark and then theres black cat in a lightless cellar which this kinda was) something about the shaders which i never wrote one of (never written one so far) which didnt work but now did...

Now, *we* all know that most games do not appear in a month and get launched on steam, they take a while and maybe like me, when they first started tinkering with the concept birp was the only option released and they too hadnt made the leap.. (Im in no rush to make mine and work on it when the mood arises as im under no illusion anyone will play it or would want to pay for it)

 

They have to trigger the move somehow...

The industry is slow. When there already is knowledge about birp like in the majority of studios, then of course they won't switch unless the other RPs have huge benefits for them.

However as a newcomer it's still a good idea to make the jump. A clear sign that there's steady move towards the new RPs is the asset store. Rather few new VFX assets come out for birp-only. Way more common to see URP only.

 

Im not so much a newcomer, just not a full time unity code grinder, and this game is a serious backburner. I do a lot of dabbling, testing ideas, having more ideas... and ooh a squirrel... but i have also started with good old cubes and capsules and then a few textures, and then actual models... and then hated my layout and all but started again .. had some interesting quirks where raycasts were going through parts of a solid brick wall - yes indeed, despite being a cube say 2m high, 5m long and 25cm wide (yeah big brick)... depending on where the ray cast exactly was it would succeed through the brick wall... why? baffled the heck out of me, as it had a collider on the wall, so shoud have been solid but it was like the mortar was transparent and would go through.. I wasted so much time on that... so so so much time..

 

Projects releasing last year likely started development 2 or more years before that, and the SRPs were in a much earlier state then than they are now. Chances are that most of those projects had to commit to something before the SRPs were well established or, indeed, production ready.

And for many games the RP makes little or no difference, so it makes a lot of sense to stick with what you know and / or what your existing work is built on.

 

Both SRPs were announced to be production ready 2+ years ago.

 

Ignoring the time discrepancy there, for certain cases they may well have been.

I can't imagine you, of all people, believing such an announcement in any case.

 

I shall sit on the fence and say just cos they said it was ready didnt mean anyone believed them

 

My point is that I believe most of the people that weren't convinced the SRPs were production ready 2+ years ago, still don't believe they are any good now.

(in fact, one might argue, the enthusiastic ones who happily jumped on board the moment Unity said "production ready", are probably a bit burnt and disillusioned by now)

Which is why I don't see it as a good excuse for the SRP usage stats being low.

 

That's for shipped games. Here are numbers for games actively in development. It's basically double for SRPs.

https://forum.unity.com/threads/adoption-rate-for-urp-hdrp-of-projects.1440385/#post-9036697