How would you improve Classic Unity?

Unity is constantly developing and releasing new packages like ECS. Which is great, but most people probably still use classic Gameobject-Component Unity. Most of the fundamental code hasn't changed that much in the last 10 years.

I might be completely wrong about these things, but it would be nice unity upgraded some of their features, here are a few ideas:

- Have a Scene Root object that allows us to traverse the hierarchy without using reflection or string comparisons.

- Have an improved way for game-objects to communicate between each other other than SendMessage()

- Replace Coroutines with async/await.

- Introduce interfaces for common unity objects like ITransform, IMonoBehaviour (move towards composition)

- Ability to reference plain C# class in the editor (drag and drop) using something like a class id wrapper.

- Ability to reference Interfaces in the editor (drag and drop)

- Deterministic execution order of MonoBehavior's. This could be shown in a window like ECS systems, another advantage is it could check for downstream circular dependencies. I know this technically exists with (DefaultExecutionOrder) but it shouldn't default to the order the objects where serialized.

- Events for gameobject OnDisable, OnEnable, OnDestroy, OnCollision etc.

- OnCollision events should be called when a gameobject is disabled or destroyed (supported in 2D physics but not 3D).

I'm just trying to think what steps Unity could take that would direct, or at least open up the ability for cleaner code.

 

https://docs.unity3d.com/ScriptReference/SceneManagement.Scene.GetRootGameObjects.html ??

These are two different things. One does not replace the other.

And you have been able to use async in Unity for ages too.

SerializeReference has also been around for ages.

This would end up overall less performant than Unity's current marshalling method.

 

It's a common misconception but serialize reference doesn't allow the drag and drop aspect, essentially just displaying the values.

 

Yeah there's no proper drawer support for SerializeReference yet. Though, I would hate it to be drag-and-drop (which is the most glacial way to assign things). I would just want a drop-down selector of all available types.

Basically what Odin Inspector does.

 

That would also be pretty nice.

 

Considering Clean Code as described by Bob Martin has very poor performance I think the best thing they could do is steer as far away from that direction as possible. Unity's performance is already bad enough. We don't need them to adopt practices that will only serve to further slow it down.

 

Shortly: almost all of these are there, except Unity should buy Odin Inspector and make it available for free.

 

Hmmm, almost makes me want to make a free version of Odin Inspector. At least covering the most used attributes.

 

But why, really? Everyone and their neighbor already bought it. It was in many humble bundles as well. The only down side is that you can't include its code in your own released assets, but that most would be the case with a free asset you make. I wouldn't rely on someone else's asset if I would publish on the Asset Store.
Unity's hypothetical buyout of Odin would help the studios more and the few hobbyist who can't cough up $30-40 for Odin or for a bundle that includes it. Again, the openness of the tool would be the real benefit here which can't really be remedied by a small subset of features. IMHO, of course.

 

Coroutines have been replaced with async/await in 2023.2

 

$30-40 per license, in larger studios its often more cost effective to just write your own.

 

That's called Naughty Attributes.

And no, most large studios pay for Odin enterprise. Because you honestly can't emulate Odin without implementing their replacement PropertyTree/InspectorProperty system, which, on its own, is a monumental task (speaking from having poured through a lot of the source code). So why go through all that effort when it's substantially more cost effective to just buy the needed amount of licenses?

So good luck making a free version. Once you're done you will want to charge for it.

I just wish Unity would implement some of Odin's features, such as generic type matching for editors, and something akin to Odin's drawer chain.

 

https://docs.unity3d.com/2023.1/Documentation/ScriptReference/Awaitable.html

 

• Drop all reliance on string look ups for things that just dont need to be so, so: tags, layers, animations...
• stop the version update messages, so you update unity from say 2023.1.3 to 2023.1.4 (and remove .3) it then says the version isnt there do you want to install .3 or use .4, you pick .4 (not the default after all) .. there.. i made my decision.. so it asks you to confirm you want to change the editor version.. ok.. yes I do .. mere seconds later.. your project was saved with a different version.. claiming the saved project (before 5.0) actually it was 2023.1.3 to 2023.1.4 but lets not bring a thing like accuracy into the conversation
• Give us back the option for selecting specific versions of packages in the package manager without having to type full package name and version numbers into boxes
• Make it easier to make our own templates, and while we can edit the c# templates per editor sadly each version needs to be done again, you cant make your own templates for scenes, etc.. that would be nice

 

Here's my thoughts:
1. Easier way to find hidden objects in case code doesn't properly delete them on exiting play mode
2. I agree with deterministic order. Components should be batched by type and it would also be nice to have RunAfter/Before attributes like ECS does
3. More accessible version of SceneProcessor that works for prefabs.
In general pre processing scenes to remove as much overhead from initialization as possible would be good.
4. Tag system is literally useless without being able to add multiple tags to an object. And I'm pretty sure this could be added without breaking CompareTag API, just expanding its meaning, so why not? Adding "Remove From Navmesh" tag is far easier than adding NavMeshModifier component and settings "Ignore" checkmark. Not to mention it would clutter UI less.
5. Scriptable Object inheritance or somehow allow to repurpose prefabs into "Data Prefabs" so you could properly search them in project window/object picker. Because I swear to god there's nothing more annoying than changing same parameter for 10 SOs each time, unless you want to add huge amounts of indirection and book keeping and make literally every variable its own SO.

Also not really game objects thing but hierarchy should do literally everything this package does

Last time I checked that package added 20-120ms to IMGUI drawing time and looking at the code. Avoiding GC is not something author cared about at all. Though I don't know if it was eventually fixed (quick look at github commits suggests no)

https://docs.unity3d.com/Manual/scene-templates.html

Uhm?

 

Well blow me over, missed that - but it would be nice if you could do all these things from the editor ( i see the scene is, but not the c# or project templates etc)

 

- Acquire and integrate UniTask for 0 allocation async/await logic. Default C# async/await does not respect Unity's GO lifecycle and allocates more than Coroutines.
- Implement Odin Inspector's capabilities including the serializer. Acquisition seems far fetched since it doesn't work in prefabs with no straightforward solution but Unity could do their own thing.
- Property drawer for [SerializeReference]. Don't leave the job half done.
- Editor only Hierarchy folders with no transform. Give me tools to organize the Hierarchy that doesn't mess with transforms.
- More fully featured built-in components like AudioSource that can smoothly transition between songs.
- URP 2D lighting system that doesn't have to fake day/night cycle with costly Monobehaviours running in Update every frame per their latest Harvest demo.
- Remove current Visual Scripting, it's reskinned Bolt 1 from 2018 they don't even maintain properly. It also massively increases domain reload time when present in a project even if not used.
- Implement BTagged capabilities: multi tagging that eliminates string matching. And makes grouping and reorganizing SOs a breeze with subassets easily controlled via right click context menu. Subasset related operations should be natively supported in general.
- Reorganize the complete mess that is right click context menu.
- A near 0 alloc dynamic layout UI system that is not a pain to use and is fully supported in both overlay and worldspace with built in ListView and GridView caching and has designer friendly workflows. Basically, acquire Nova UI.

 

A solution is on the horizon, hopefully. At the very least they have a strong lead for a solution.

It's a free package that does a lot of common-use things, so I wouldn't expect it to be a premium project.

If you want a proper custom inspector tool... buy Odin.

 

Is there any actual hints on this on a roadmap or something or is this just wishful thinking?

 

I've had direct conversations with the devs on this. They have a promising solution, but won't give any hints as to an ETA. I assume because they want to be 100% sure before issuing a preview version.

From what I remember the solution is more or less to directly bypass Unity's prefab serialisation system with their own replacement (similar to how they replace SerializedObjects and SerializedProperty's with their own replacement). That constitutes a lot of work. They've been working directly with Unity on this too.

So yeah, there's active work going on. It may just take a bit.

 

Then I would treat it as a non-starter until otherwise. Unity have a history of killing things before, after or during release as well as axing entire very-useful-very-requested-by-the-community-teams, so yeah I would absolutely not hold out for it if all you have is "I spoke to some developer". I am sure the developers mean well, but unless they are top level decision makers none of their work is safe until its fully released, fully working, and fully documented.

 

- Layers being used for both Physics and Rendering is utter insanity. Separate them!
- There is alot of data output in Profiler and Frame Debugger that doesn't mean anything or is mysterious. Expand that info into something useful.
- Editor-only Heirarchy Folders.
- Reduce number of core features to ONE. One UI, One Input, One Particle system, One Render Pipeline, etc.
- Combine Scenes and Prefabs. Godot has got it right and its a dream to work with.

In general; make it fun & a joy to use the editor. Having to deal with random editor slow downs and general workarounds just to author basic content is not fun. We live in this tool for 8 to 10 hours a day atleast 5 days a week so we want it to be a decent experience and not a stressful one. Id take that over any new fandangled ultra-rendering of water or hair or whatever else is the current craze.

 

I remember seeing people ask for this a decade ago.

 

They actually seem to introduce something similar with 2023.1!
It's called "Awaitable"
https://blog.oliverbooth.dev/2022/12/12/unitys-awaitable-api/
https://hackernoon.com/unity-20231-introduces-awaitable-class

 

I'm using this as an opportunity to share a "clean code" related video that I find really really good:

 

Interesting video but...
1. Only 5-10% of your game code will be performance critical unless you write the engine itself.
2. Be very careful about applying improvements from C++ to C#.
3. When you want performance in those 5-10%, use burst-compiled Jobs in Unity

 

If you only care about hitting a performance target that is within spitting distance. It's like that quote by Mike Acton: "people who don’t care about long it takes is also the reason why I have to wait 30 seconds for Word to boot". Code written like that video in its entirety means you could target a far weaker system.

DOTS is the way to achieve all of that with Unity but you can achieve most of it by just not writing "clean code".

 

Well, MS earns well with Office and that software still lives after decades. The later may not be possible for maintenance reasons with absolute focus on performance...
It remains a good advice to focus on readablity and clean code for most of your project. You'll learn that quickly when you gotta work with industry code that didn't think so.

 

Part of the problem with performance in games today is that people pick up these concepts when they're working outside of games and automatically assume that it's appropriate to apply them to games. Very few games have the longevity that makes it worthwhile and for the ones that do the important part is usually in a server not the client.

Here's a video by the same author debunking these ideas even for the industry with Facebook as an example as they have gone back and completely reworked massive aspects of their services to improve performance.

 

Magic! (2023.2.0b3)

 

I would phrase it a bit differently, the point is not "not writing clean code" but writing code on specific ways so it can take advantage of certain CPU and architectural environmental factors even if those practices aren't aligned with some evangelizing self-appointed "clean code gurus" opinion. (I always hate when people try to make you feel they are family so they would get more credit with their BS... "Uncle Bob"...)

 

Hi, guys, can you pass those videos to Unity, because, sure, we can get our own code to run fast with like DOTS, but them you use the animator to animate a camera and you loose all the performance you gained.

 

Theres clean code, and then theres OCD code sure OCD code maybe a thing of beauty, but it can be taken far too far.

 

Oh, Charles Simonyi he definitely left his s_mark on the "clean code" software world...

 

really?.... off to go see now.. for the miracle is only true once seen with your own eyes..

 

And 2023.2.0b4 just landed while we were talking here.

 

DAMMIT .. i havent even finished downloading b3.. grrr .. cancel.

 

You guys just destroyed my whole worldview.

Wait for the DOTS Animator replacement. ETA 10 years.

 

What.

I was talking about the Sirenix devs, not the Unity devs. And they've been knocking out feature after feature.

Not sure what you thought I was on about.

 

Idk why people like this video too much. Telling "every abstraction comes with a cost " should not surprise any programmer.
Sure if you use non virtual functions over virtual functions,
or using struct over classes or using manual SIMD over none or
using unsafe code instead of safe of course will result faster code but all of them have some tradeoffs.
Code just not about execution speed. Which looks like cannot be understand by some performance gurus.
Of course these techniques will result 20x performance benefits now my "buff system" code takes 10 microsecond instead of 200 . yaaay. But with what cost, is it worth it?
Taking 30 second to open a excel proves a point, "a program that dominate industry and probably one of the most selling software takes 30 second to boot" so sometimes performance doesn't much matter in SOME situations.
Minecraft written in Java and it was periodically lagging due to garbage collection, on capable pcs.
Terraria still laggy when there is a lot of projectiles, mostly middle of boss figths, on capable pcs
Both of the sells millions of copies.
I guess just I want to say is "performance no matter what, if your program is not optimized you are a bad programmer" is a bullshit as "Clean code no matter what, if your code not Clean™ you are a bad programmer". Priorities change by industry, project and subdomains in that project (UI, Gameplay, Core).
My motto is "Do you exceed frame budget? optimize it, no? then continue. "

 

"When a measure becomes a target, it ceases to be a good measure"

 

My general experience is that code maintenance and manageability is a far bigger concern than performance. That's not to say performance isn't important though, but sacrificing 5% performance in some solution to make it 10% easier to understand and maintain is a worthwhile trade most of the time.

On the other end of the spectrum, there's over-engineering, which also isn't desirable. Sometimes, the more performant code is also the easier one to understand, because it is simpler. Programmers shouldn't make code abstract and "beautiful" for the sake of it, nor should they pre-optimize solutions that don't need to be. The only thing that matters is if you can ship a viable product at a reasonable time, and for that you definitely will need to cut corners. With experience, you'll know where or how. Your motto is sensible.

 

Thats a good point. I recently sacrificed my own Framework by turning classes into MonoBehaviours because I enjoy using the Unity Editor. I like being able to enable / disable components and change values via the editor UI, even though none of those things benefit the final product.

 

With a MonoBehaviour-centric approach you will have to accept that you won't have the performance as high as you want, but that's not necessarily true of a DOTS-centric approach as a major part of the performance comes from how the framework is designed to take advantage of memory and cache bandwidth.

 

The reason I don't agree with the crusade against clean code is that if every abstraction brings a cost then the end point of the argument is...

Build all your games in Assembly.

Every Abstraction comes at a cost. That includes the Unity Engine, C# and even using C. The much revered Jonathan Blow would seem to agree as he enjoys telling people they don't need abstractions, also no coincide he builds his own engines then.

It seems like drawing the line at using Unity Engine as is, is an arbitrary decision to say "this is enough abstraction, but no more".

Abstraction (can sometimes) bring clarity at the cost of performance. How much abstraction is appropriate just seems to be based on how much performance is required. If you need your game to be performant you sacrifice the clarity of OOP for DOTS ECS and Jobs. If you need to be even more performant you go C++, C or Assembly.

Then on the web side of things, it's the opposite, they don't care about performance (as much) and are happy to have 7+ layers of abstractions.

Now I'm not willing to sacrifice the ease of use of Unity to go build the most performant game. If I'm building an RTS I'd probably opt for DOTS. If I'm building a traditional rpg game then Unity OOP will be fine, and if I'm making a turn based 2D game it doesn't really matter if I slap a couple of frameworks and plugins onto it.

 

Ability to selectively save data changes in play mode back to the editor without having to manually do it or use hacky solutions.

 

Yes, and at least one company acknowledged that it was a bad choice for app development. Here's the reference article from the video I linked to earlier. It's a shame that Unity didn't learn from them when making the hub.

https://www.infoq.com/news/2012/09/Facebook-HTML5-Native/

Every abstraction has a cost but that cost is not the same between each of them. In the video linked by @Peter77 the author goes over a few different abstractions and the cost that comes with them. Some have a minor impact and some have a major impact.

 

does OOP have more "clarity" than ecs?

what does that mean? Clarity as in how easy it is to onboard new programmers? Or understand your own code in the future? As in, some bug pops up and it is in some corner I haven't looked at in a long time. "Clear" code would take 10 minutes to remember how it works, and less clear code a few hours?

If that is the measure I'd say OOP is much less clear, at least as far as I understand it.

 

I wouldn't say it has more clarity intrinsically, but it has more clarity if you have 'OOP brain'.

I was self taught on classic unity and very much have OOP brain. My brain thinks of everything as an object, I still use IMGUI because in my mind a button is something I can grab, drag, delete and in general, treat like an object. It's not say, the emergent behavior of some system.

I think ECS systems have the potential to be more clear, so long as you can train your brain to think that way. I'm starting to grow towards ECS more, just waiting for a little more maturity.

Also maybe it's just me, but I find the Component Gameobject structure to also provide clarity. Being able to see there's a Player Object in the scene, and being able to tell what it does at a glance from its components. Although it can quickly get out of whack when you have a lot of cross referencing.

 

The problem lies somwhere different in my opinion.

First, already mentioned is that many game devs (as they calls them self's) comes from different industry. Including software engineers. Where prmerformance is least of their expertise.

Second is general programmers trend on the Internet, to kill anyone's subject, trying discuss the performant code, with arguments like, "profile, before optimise", or "don't do it, unless you need it".

Then people apply their current knowledge, withouth learning optimal solutions, and soon whole code is written like that and often is too late to refractor.

And as result, you got applications and games, which barely can run smoothly on modern hardware, because some, somwhere did say, we got so much RAM, GPU and CPU the days, that we should spend it all. Yeah and now go to shop, buy better hardware, general consensus. See Unity for example.