How would you improve Classic Unity?

What I would add to Unity:

3D modelling editor
2D drawing editor

 

Those are not really different numbers though, he says 35% SRP adoption for 2021+ (because not many people use 2022, therefore the 45-50% number he gives is some manipulative marketing bullshit) and if we included 2020 and before it would probably drop a lot more?

 

Shipped games aren't necessarily in active development. His number is forward looking and what it will be once the games currently in development have shipped. It's not the whole picture but then steamdb wasn't the whole picture either.

 

I don't know what your point is, you replied to a data source that said 30% of released games are SRP, seemingly disagreeing, and as a counter you posted a (biased) data source that says 35% of actively developed (whatever that means) projects use SRP.

 

Yeah I changed the post once your edit added much more clarification.

 

God no. Absolutely not. Dreadful ideas. These are external tools for a reason.

I wouldn't be surprised if the reason that these numbers are as high as they are is because current search results are completely flooded with how to do these things in URP and HDRP because of the bias search engines put towards more recent pages. Whenever I'm trying to find out how to do something in Unity, for instance, I have to append "-hdrp -urp" to my searches these days, and that's been the case for at least 6 months now.

 

Allow for GameObject-Inheritance Unity.

 

Let's try this again without the flamewar from the other thread...

How would you imagine that to be implemented?
I mean a game object on its own is quite useless in Unity - you need to give it components. And you give it components in the editor. The codebase at compile time (!) does not know what components the game object has. So how would one meaningfully inherit inherit from a game object?
In my opinion Unity has delivered inheritance of game objects. It's called prefab variants because it could only be an in-editor solution and not a code solution.

 

By making the GameObject not "quite useless".

I mean not to be pedantic, but aren't you asking, "How would you use something that is only designed to be used with composition with inheritance?"

As it is for inheriting any other non-sealed object. You design it that way, no?

I am not that familiar with Godot, but doesn't it implement nodes that allow for inheritance?

 

Foreword: I'm trying to be geniunely constructive here.

The thing is, inheritance doesn't really exist to make things 'less useless'. Its a means to enable polymorphism. The point of inheriting from something is so that you can use the derived type in place of an inherited type. That's one of the defining features of OOP.

Sure you can use inheritance to make things 'less useless', and Unity certainly does this, but it's really an abuse rather than the intention. Even within the massive C# libraries we use, there is seldom any inheritance. Most everything is composed through interfaces as it's ultimately more flexible in nearly all ways because of this.

Game Object wasn't designed to be inherited from, hence why it was sealed. It's a wrapper with one sole responsibility.

Looking at the points you copy pasted in the previous thread, I can't see why you couldn't do anything of this through other, probably more flexible means. If you want a game object with a pre-set collection of components, that doesn't need to be anything more than a static factory method, for example.

I understand Unreal is all inheritance based, but Unreal isn't Unity and Unity isn't Unreal. If you want Unity to be more Unreal based... just use Unreal honestly. I would say the same of people who wanted Unreal to be more Unity. They should just use Unity (like I do, as I don't like Unreal's structure).

Hopefully you can come back to me with a constructive response.

 

That's not entirely true, not all. A substantial portion of it, and a great example why a game engine shouldn't rely on inheritance too much. It's a glorious mess.

 

All of my responses are constructive.

The topic of this thread is "How would you improve Classic Unity?"

Anything that changes Unity is going to make it less "Unity based". I state this just to try to make understood that "Unity designed things this way.", is probably not a useful rebuttal for why a change should not be done in a discussion of "How would you improve Classic Unity." Literally any of the suggestions here would make the new product "less Unity like".

Of course GameObject was not designed to be inherited from. Had it been, I would not be making the suggestion that it could be improved by allowing it.

Unreal allows inheritance in this context as you mentioned. I believe Godot does as well.

As for you not being able to see WHY one would use a method to complete a task different from your preferred method, I again refer you back to part of MothDoctor's reply:

"Please, accept the possibility that different programmers are able to work efficiently with different patterns/paradigms than you.
Asians eat it fast with chopsticks, but they don't go preaching on forums and say
"If you're incapable of understanding chopsticks system or refuse to use it due to incomprehensible reasons, you can go eat to another country."

 

Welp, you're asking for a multi-year refactoring project with very deep implications (rewriting everything and the kitchen sink) on the basis that you don't like Components... That's far from constructive.

 

Yeah, not used Unreal much and don't plan to for this reason. Maybe if the need to make a walking sim every strikes me.

And I think the point we're trying to get across is this wouldn't be to Unity's benefit. Very likely to its detriment, in fact.

Yeah it can be nice to have multiple ways to do things, but then Unity has to also support these multiple ways. Unity could do with less technical debt, honestly. This would incur massive debt on Unity's behalf for very little gain. Especially when it would only benefit very few people.

We only have one way in dealing with game objects - as component containers - and that is ultimately the best path forward, even if your preference is to the other way.

Many people bemoan Unreal's inheritance approach, though I don't see many people if any bemoan Unity's component structure (they definitely bemoan many other parts of Unity though, and rightly so). There's good reason for this.

And as they say... when in Rome...

 

Not in a thread titled, "How would you improve Classic Unity".

(and I do like Components when they are the right tool for the job.)

 

And again, "When in Rome" at least seems like a non sequitur in a thread about how would you improve Rome.

This still holds even if Rome happens to use your preferred method of completing a task.

I assume Unity would like growth of its platform. Providing paradigms other platforms use as options (again, I'm not the one here who is stating every task needs a hammer) would likely engender more platform migration.

 

Right, but we're saying this would make Rome worse. Like Rome without the bath houses.. We want Rome without the vomitoriums instead.

 

You Used That Word, I Do Not Think It Means What You Think It Means.

In any event, I find more choice is usually better.

 

Hmm, you are asking for a significant paradigm shift then.
Fear your wish may be one of the most far fetched suggestions in this thread.

 

Unity could use some bringing up to industry standards

Nonetheless, the thread did not read "How would you trivially improve Unity Classic"

 

As people have mentioned before: Unreal's inheritance system has disadvantages too. Implying it's a must-have industry standard is silly.
Anyways, you have shared your opinion and suggestion - let's leave it at that

 

I think Unity's history has proven otherwise. I think most users today prefer how we only have one supported scripting language, rather than multiple.

And I think a lot of Unity users wish it had one render pipeline that did everything they wanted, rather than one deprecated one, and 2 other ones that only do 50-75% of what they want.

The statement 'do it once and do it right' comes to mind. We have the one right way to do things in this case, I don't think any more would improve Unity.

Again you haven't actually put forward how this would improve Unity, aside from just being more convenient to your workflow and copy-pasting someone else's post.

Ah well it's been real. Looking forward to having this discussion again in a year's time.

 

I read in number of occasion on the forum, how people move from inheritance to component based design. And that reasoning is not withouth solid reasoning. Few games developers, i.e. From The Depths, did stated that they regret chosing inheritance design, as it lead project to the trap.

I haven't read yet any game design blog, or dev response, where developers regret components based design.
I am happy to see such, if anyone provides one.

DOD/DOP has solid proved architecture and use cases. Including DOTS.
While Inheritance usually lead developers, to dealing with Interfaces and fighting with own architectural design in long term.

However inheritance can have various use cases, GO inheritance would be definatelly an abuse of the architecture in Unity world. Trying to inherit GO, shows lack of understanding, what GO actually is. And gladly that it is prohibited by default for own sake of developers.

 

I believe Godot has it as well.

Perhaps we should give up on OOP with Unity. After all, everything CAN be accomplished with procedural code only.

 

This seems counter productive. When Java was allowed, you could still work completely within C#. Again, to me, it just seems the idea of "all jobs need a hammer" is a bit zealous.

 

Why is anybody responding to this troll?

They've said nothing beyond, "unity should have this" and then made reactionary nonsense rebuttals. You guys are all programmers, aren't you? Shouldn't you quickly recognize patterns?

 

• Add physically-based lighting and volumetrics to Built-in and shut down SRP's.
• Procedural terrain like Map Magic.
• Fix Layout system.

 

This is less a "Classic Unity" thing and more an overall thing, but I want there to be a dedicated team that will go through the entire API, including the packages, and all related engine documentation, and bring completely rewrite them all with something like Microsoft's C# docs in mind, with detailed descriptions and examples. I don't mean "bring the existing ones up to speed," but a total reworking of them from the ground up because they are a mess as it is now.

It's not just how there's loads of stuff in the scripting API where you get a list of the parameters and overloads but have no idea what that may do behind the scenes, maybe no idea how it works, and very likely no idea what the best use-case for it may be. The fact that Package documentation is also separated from regular documentation and not exactly terribly easy to access is only a compounding problem. It genuinely feels like there's multiple documentation teams, none of which have any clear intercommunication, with the documentation itself all feeling very separate.

There's also stuff in there that's still clearly using examples from things like Unity 4, notably things like the projector component, though the less said about the projector component the better.

 

Uff, hope you realize such a doc would probably be about 4 times larger than the C# one if not even more.
An engine just has a magnitude lot more going on in the background. And in the end whatever descriptions would be in there, your personal game idea may still use the features in unexpected ways...

 

I am aware of this, but I will counter this with the fact that this isn't the only documentation of this calibre that Microsoft has put out. The vast majority of the documentation they've put out, which in some cases would dwarf what Unity would require, has been the gold standard for ages. Also, the idea that you may use the feature in an unexpected way does not mean that examples shouldn't be included, but is a better reason to include them because it gives you a practical example of that functionality.

Some of the documentation does that already, but that's the problem. It's only ever some. Some of it doesn't even have descriptions. Unity is not some ramshackle operation with 20 employees, don't try and play that "but it'd be haaaaaaaaaaaard" garbage.

 

I mean, people have been touting about Unity (mostly rightfully) having a docs advantage compared to the competition, this is an area where they can double down and have a super clear advantage.

I will accept that it can be a personal problem, but I'm mostly unable to get anything useful from most of the package docs. I'm not sure if it's the way they are written (do they use different guidelines for those?) or if it is the way they are organised / presented that somehow blocks me from absorbing useful information that may or may not be there.

 

Unity is already heavy reliant on inheritance, while I personally prefer composition, I don't see Unity being worse if it allowed the inheritance by default.

Recently I watched this video:

and highlights the problem with Unity for people who aren't thinking in terms of procedural or systems.



This is only a portion of his player classes. Many Unity developers don't know how to structure this any other way and unity doesn't provide many good options out of the box.

I don't believe that ECS is really going to take off and will probably only be adopted by a minority (<5%) of Unity users. It's absolutely possible to write performant, scalable and maintainable object oriented code, it's just that Unity isn't well configured to achieve that.

Another interesting video for Code Aesthetic.

The idea being you have to compromise between the 3 corners.

I think classic Unity offers close to maximal velocity on new projects. You can receive a brief and in only a matter of weeks pull enough assets and plugins together to make a compelling experience. However it also creates enormous technical debt, causing velocity to slow and eventually reverse as time goes on.

Performance I can't comment on, but I'm hoping the efforts to migrate the engine to .NET might offer some reprieve, as well as remove all runtime reflection methods and string comparisons from the engine, maybe offer native object pooling functionality.

As for adaptability, a shift towards composition would be great, better interface support, dependency resolution for non UnityEngine.Objects and something along the lines of a Unity linter that could warn potential code smells. To many developers make EVERYTHING a monobehaviour in unity, which is just not necessary. It's possible to have a mix of functional and object oriented programming.

 

Not sure you can do serious game dev in general without being very familiar with those two concepts...

 

This is the way.

 

I think Unity provides plenty of options, it's just most people forget inheritance is just the stairway to polymorphism.

[SerializeReference]

on it's own provides absurd amounts of flexibility, though Unity really needs to give it inspector support out of the box and highlight it's existance more.

The real, better solution is probably better learning resources to show users how they can make the most of Unity, rather than give them the option to shoot themselves in the foot.

 

less bloat...

 

Its impossible to have such a multi functional tool without bloat

 

The problem is that a lot of subpar half finished features don't make a multi functional tool either and a lot of us would prefer a more spartan feature set but where every feature is best in class or at least attempts to be best in class.

 

Im sure not going to disagree with that - audiofiles rarely buy all their components from one maker for that reason - but it does feel almost like work experience people are used for many features, so theres an idea, great, student a works on it say 6 months, then the experience time is over, so its given to student b who has no real handover from A but looks at it, fumbles around a bit, improves one bit, breaks a bit.. and then their 6 months is over.. repeat.. repeat..

 

i would improve the ssr which is really bad, i would kill built-in once and for all to stop wasting time on archaic systems -.- and i would fix the stupid editor ui problem where you can not see the full texts of what you are using -.-"

Edit: i would improve the documentation which sucks actually

 

Yeah, let's scrap built-in and make everyone use URP and HDRP, which are somehow more difficult to expand and with URP still lacking a proper post-processing stack. Great idea. Genius move.

 

he asked, i answered

 

Honestly, I would scrap everything that came after unity 5 and restart development this time with a clear plan that is stuck to and based on user needs rather than marketing needs.

But because that is literally not even remotely possible and would cost multiple billions of dollars, I will settle for a reduction in all the time spent on random loading bars that have popped up since Unity 5.

 

At first I was like surely something big changed since 5! But didn't 5 have UI system, prefabs, PBR materials?
If so they certainly slowed down after that. Obviously lots of little improvements but mainly very slow progress on SRPs, DOTs etc.

 

Ignoring the time they were in development without being available to us both SRPs and DOTS started becoming available with Unity 2018. Unity 2017 had a ton of new features and improvements which makes sense as if you think about when it was in development and when the subscription model started 2017 was basically Unity 6.

Spoiler: Unity 2017 Feature List

 

100% agree, while i think wasting time on birp today is useless, your opinion is pretty accurate...

 

Yeah unity 2017 is that weird release cycle where they were starting to move from "this is what people want, based on XYZ data" towards what I describe as the model of "lets ask Bob the marketing guy what he thinks is cool and add it to the roadmap"

You can really see the difference between unity 5 cycle features, 2017 and then beyond. Its really paints a picture of unitys (rather fast) decline engine wise.


I am 100% positive that if unity spent a year taking unity 5 and simply updated it to work with all the modern platform SDKs so you could still use it to release for modern steam, modern consoles etc - majority of users would move to it and not look back. That sums up my views on how useful the additions since then are (taking into account the massive investment its taken unity to add them including all the killed but unfinished initatives and fired team members).

I still have yet to find anyone who actually has a use case for a custom SRP that could not be achieved with command buffers etc - I beg someone to prove me wrong though on that front! (As in real use cases, not just for the sake of it but actual real need for a real project that isnt just to say "look you can only do this with SRPs" but is actaully "we need X for our game and its physically impossible without a custom SRP").

Everytime ive had a conversation with a developer its ended up with "oh wow, I didnt realise you could do this with command buffers!" and then their whole reasoning for battling SRP goes down the drain and with it, their sanity.

 

2017 is probably about the time the company started to aim for IPO as the big target; so that makes sense.

 

SRPs always struck me as something that made sense to Unity as engine developers, but not to users. I never understood why they thought having multiple pipelines would be perceived as better than having a single, scalable pipeline where you can add or remove features to fit your targeted fidelity/performance level.

 

The Unity-specific version:

It's not an either-or proposition. Reasonable performance can be a focus too. It's just laziness from programmers that got us to the sad state we're in.

Also, "clean" code is actually less readable because of all the layers of indirection you have to get through when trying to figure out what some method does.

Yeah, but that software could sell millions more if it could run decently on lower-specced hardware. The lives of the users would be also improved by not having to suffer lag everytime they do anything. Just because people are used to crap performance doesn't mean that state is a good thing.

Cue the apology letters from the devs...

https://tech4gamers.com/developer-apologies-too-common/

Somebody else made the example of "trade a loss of 5% of performance for a 10% improvement in readability". That's reasonable. What we see nowadays is code that runs 100 times slower than it should just due to laziness. That's not reasonable.

Hear, hear.

Are enterprise codebases actually highly maintainable? Not really. It's a myth. An excuse to justify crap performance.