Any tricks for communicating between scripts without having to share the same assembly definition?

Unity Engine
, , , ,
1

I’m fairly new to assembly definitions (and relatively new to C# too), but it seems like such a waste to have so many scripts all sharing the same definition and bloating compile times when they often times just need the smallest bit of succinct data from various scripts.

In my project I have various combat related scripts like movement, attacks, stats, etc that all are interwoven in complex ways, but I have MANY other scripts that only need to reference a single float or bool sometimes that I’d love to be able to remove from the mounting compile times.

These compile times are such a drag that I even considered using PlayerPreferences(), as to my knowledge that would allow me to send messages to entities in a way that they don’t have to always be combined in the same assembly definition.

So as a simple example lets say you have a GUI with a health bar. You could set an int in PlayerPrefs, have that set to the players health each frame and load it from the GUI script with PlayerPrefs.GetInt( “PlayerHealth”). Not performant at runtime but I hope this kinda communicates what I’m getting at.

Are there any means of sending information that’s the best of both worlds? Performant and doesn’t bloat compile times by requiring these scripts from all sharing the same assembly definition?

I’m pretty new to this so this might be a really dumb question. Thanks in advance for any insights even if to say it’s not a good idea to chase this concept.

2

Script recompilation is only a small part of the overall domain reload. Assembly definitions can make a difference, but not always, and sometimes won’t be a huge difference. There’s a bunch of other stuff that goes into the overall domain reload, and you can see where the time goes into each step by merely looking into your editor.log file, which logs each domain reload.

Though your question of communicating between scripts honestly has nothing to do with assembly definitions and nothing to do with compile tiles. Assembly definitions are for combining code into, well, an assembly, and for managing the dependencies of said assembly, among other things.

Your question is really an architectural one, one which has many solutions. This is why we talk about singletons, service locators, and dependency injection. There are many different solutions to these kinds of problems, and they are often very context sensitive.

A health bar (or anything similar to that) really only needs some opportunity to get a reference to the player (or whatever entity it cares about), so that it can regularly read from said reference the value it cares about.

How about just, a component on the same game object as the player, that references the component that manages health? It often doesn’t need to be any more complicated than that. This works better with UI Toolkit as your UI doesn’t live in your scenes, and you only need a UI Document component, and a custom monobehaviour in order to communicate between the scene and the UI, and we now have tools like runtime binding to do more of this at the UI level.

You can of course, separate your non-UI code from your UI code with assembly definitions, with the latter assembly referencing the former. This is something I now do, as I find the responsibilities are more clear when the non-UI stuff has can have zero knowledge of any UI code.

And that’s what I find assembly definitions most useful for: maintaining clear dependencies. To make sure certain lumps of your code only have access to what they need, and prevent them from using things they probably shouldn’t. This leads you to (hopefully) code more in terms of systems and API’s, with some being top level and some being low level, based on their position in the dependencies.

I also recommend using assembly definitions from the very beginning of a project, as it is difficult to implement them once you have had free reign in creating a ton of tangled dependencies.

But how you communicate scripts is somewhat separate to this, as - so long as one assembly references another - how you get a reference to something doesn’t exactly care about your assembly definitions.

6 Likes
3

Thanks for this post, LOTS to take in.

Wish I weren’t so far along in my project because I have a lot of poorly planned and implemented elements that i threw together without a care in the world for compile times or assembly references.

I feel like a deer in the headlights trying to figure this stuff out because i have so many scripts at this point and so many variables and references scattered around, but I have no one to blame but myself for that.

I’m in a bit of a unique situation because I chose one project and stuck to it for so long without really knowing what I was doing to begin with (I still have no idea WTF i’m doing, obviously). Never knew it would bite me in the ass so hard, but it is what it is.

Thanks again for the info!

4

The first thing I do when starting a project is to speed compilation up with these options in Project Settings:

Enter Play Mode Options [enabled]
Reload Scene [disabled]
Reload Domain [disabled]
Scene Backup [disabled]
Optimize Mesh Data [disabled]
Asynchronous Shader Compilation [disabled]

And I crunch compress every texture with an AssetPostprocessor so it takes way less time to load and memory.

4 Likes
5

This is super helpful, thank you. I had no idea some of these things were increasing compile times.

6

I’m a bit skeptical, I would be happy to have more details or exlanations if you have.
I can definitely see how those options are helping to have faster enter/exit play mode, but I’m not convinced that it would impact compilation (or assembly reload).

For example, I thought the Optimize Mesh Data option was used only when making a build?
I’m also surprised you would recommand to disable the Asynchronous Shader Compilation instead of enabling it.

As far as I know, the Scene Backup option has been implemented following one of my suggestion, to make entering play mode much faster. Unfortunately, it seems it was a source of issues in some edge cases and it has been removed in latest Unity versions :/.

Some additional tips to optimize compilation/assembly:

  • If you’re not using Assembly Definitions, you can move the scripts that you are no longer modifying into your Plugins folder (they’ll be put in another assembly and will no longer be recompiled, except if you changed a script inside this Plugins folder).
  • In your scripts, be careful with attributes like [InitializeOnLoad] that could trigger heavy operations after recompilation (Profiler can help to see what is potentially taking time after recompilation).
  • If you use Burst package, you could try to use the Optimize For Fast Compilation option in Project Settings (if available depending on your Burst package version).
    image
    image1914×475 57.7 KB
2 Likes
7

I’ve seen this option before, but only recently have have I been compilation time minded Every little bit helps! This won’t affect build performance if I change it will it?

And yeah i’m assuming marcoantap’s changes may only help in rare instances, but any tips are appreciated.

That’s a bummer! I was wondering why i couldn’t find this setting, oh well.

The more i learn about this the more I’m seeing that the compile times are a negligible factor and the real culprit of long loading bars is the domain reload and “running back end” which are largely out of our control as our project grows as far as I can gather outside of just keeping our projects clean and not keeping random assets in our project.

1 Like
8

I read the original post as a request for tips to improve the Editor performance, not all of those settings are directly related to compilation time, but there is a combination of factors that can slow it down.

For example, I have worked on a 300GB+ project with all kinds of assets from the asset store, in a single scene that contains everything, in a Windows system with 16GB RAM and 4GB VRAM. Compilation never took more than 5 seconds, and entering the scene was almost immediate. The Unity Editor is probably the most performant and stable tool I have ever used.

Asynchronous shader compilation only adds more stress to the editor, it’s better to wait 2 extra seconds to run a scene than having lag and cyan materials for 10 seconds. Same for uncrunched textures, that adds lots of stress to the system that impacts the Editor performance.

Also here are my thoughts on why scene load is so slow for Unity applications, how to fix it without addressables, and why addressables should be automatic:

4 Likes
9

You can have types in two different assemblies, and still have types in one of the assemblies reference types from the other one.

So if you were to move your health bar handler class to a separate UI assembly, it could still directly access the health property on the Player class, just like it did before.

The only limitation when you separate types into different assemblies is that you can’t have two-way references between assembly definitions. So your UI assembly could know about the assembly where the Player class is, but then the Player class couldn’t know about the types in the UI assembly. This is where it can get tricky, to design your architecture in such a way, that you’ll be able to organize your types into modular assemblies, with the references between them pointing in directions that make sense.

In cases where you need to pass some data from assembly A to assembly B, but A doesn’t know about B, you can achieve this by adding a mediator between them, which both assemblies know about. For example, you could have an assembly called MyGame.Events, which contains events that types in assembly B can subscribe to, and types in assembly A can raise. You could use simple built-in C# events, an event bus, scriptable object events, etc.

1 Like
10

Well when I started this thread it took about 2 seconds for the compile to finish, and now it’s so fast that I can’t even catch it before I tab from the IDE to Unity. So definitly some progress enabling all these override references.

image
image524×889 26.6 KB

Am I crazy for thinking that an “auto” setting that would just enable the editor option and whatever platform you’re currently building for and ignore the other builds would be handy? I don’t know what sort of performance hits these extra build options are so maybe a waste of time, and this ends up being a random tangent. Can you go off topic in your own thread?

I was able to get by just enabling a couple sirenix settings. And thanks for the info on the different types of refence.

So at this point the domain reload and “running backend” take up by far the lions share of loading. I tried doing some google searches but couldn’t find any resources on how to lower these settings. Do you guys know any tricks for reducing those times? I’ve also searched on this forum and there is surprising little resources on this stuff.

P.S. wish I could set more than one post as solution as you guys have all contributed some great tricks! Like holy crap i don’t even see my compile time bar any more, it’s all reloading backend.

3 Likes
11

Good question, and I don’t know the answer. The option could also potentially only afffect builds, and so having no effect in the editor…

1 Like
13

Am I going totally insane or did some advanced AI bot just ChatGPT try to get me to buy some puppies?

(Apologies if you’re a real person, I don’t even know what’s real any more)

2 Likes
14

I think as we now have signatures we should ask ourselfs what the rules of signatures are. I have to say Discussions is a lot more cluttered than the forums were (the embedded link preview is just weird with little to no benefit, IMHO). Are personal advertisement links in signatures allowed? Where and how do we draw a line here. If this is spam because the signature is included in every post the user makes, then the post is not spam, but the user is.

We need better and more clear rules here. UA had moderation guidelines and user guidlines as well as the FAQ. The Forum had the community guidelines and a few other rules in place. It seems we lost pretty much all of them when we moved here and it seems nobody has an idea about the rules or how this actually should work out…

2 Likes
15

Yeah it’s certainly a problem, but another problem is overburdeneding what should be a fun place to come and engage with too many rules and regulations. That said I think we can all agree roving AI impersonating people slinging puppies is unnerving.

16

image
image602×770 58.4 KB

https://discussions.unity.com/faq

I might be misunderstanding, but the site has this.

1 Like
17

Thanks. This is actually the first time I’ve seen it as I wasn’t really active the last months. Well hidden post -.-'. It needs more visibility. On the scripting forum we had sticky posts and even those were mostly ignored / missed by new users.

Uhm, this is not a social media platform to have fun or to share what you had for lunch. This is a narrow focused support platform. Why are you suggesting to have an anarchy forum? The rules are pretty much standard for a support forum and follows pretty much normal netiquette. If you want to chit-chat, use a social media platform like discord or reddit.

Though I don’t want to get off-topic here. It’s just that Samanth242’s post was flagged as spam because of the signature. Funny enough the signature isn’t even visible in the review…

ps: I just noticed that only about 300 people in total have ever opened the guidelines. Which just shows that they are pretty pointless when they are hidden somewhere.

2 Likes
18

These forums were a lot more fun and a lot more useful as a resource for information just a few short years ago. Who said anything about starting threads about our lunch. My point was that u can be so focused on keeping people on topic that it kills the communal spirit which leads to a community in decline. But to be fair, suppose I’m being a bit of an agitator.

I think I need a little break from these forums. I just miss the fun and vibrant place we had not too long ago that was also very informative too.

I also realize the can of worms that gets opened if you start letting people have fun these days because what’s offensive and fun has gotten so out of sorts. It is what it is.

I try to find a healthy balance of fun and technical talks when posting. But I’m also seeing that some of my posts are inflaming things among what posters are still around and the last thing I want to do is drive people from the forums. Sometimes just trying to see what the lay of the land is and kinda get a feel for where the room has their head.

I’ll save crazed rambling for elsewhere on the Internet and keep things dialed down around here.

19

I’m on UnityAnswers for about 12 years if I remember correctly. I haven’t really noticed any major shift in policies. What I do notice is the huge amount of new users which can not stick to the most basic rules and can’t even format their code correctly. This has started probably around 6-8 years ago and always was a downhill trend.

Most of the biggest and interesting questions had been asked years ago. So there aren’t that many “interesting” questions around anymore. Most are pure support questions with a specific code snippet. I miss some of the fundamental questions on how Unity works, but as I said, those essentially has been answered years ago and a couple of times in different ways. That’s also why the last couple of years on Unity Answers I was just banning spam bots, that’s almost all I did.

2 Likes
20

I’m not sure about policies but from my position I’ve experienced a solid amount of mods cracking down on topics in recent years that woulda been fine before.

Anyway. Talking about this stuff is counter to my goal which was to just have conversations about Unity and have some decent convos.

I think there is still a lot of potential for great topics. But a lot of the optimism and cool things to talk about haven’t been around for a bit.

It’s just a sign of the times, the culture has changed so much in gamedev. Now it’s no fun, be super safe, don’t talk about exciting new things. A lot of the old posters in these communities are on tick tok and reddit and discord.

I’m not sure anyone knows what a community even is in gamedev anymore. It’s like pick your poison and the professionals seem to keep to themselves.

Just how things feel these days from the engagements I’ve seen as of late.

Edit: Im almost blind to the code questions at this point. You raise a good point about how all the key questions are already answered and a lot of the posts are people who just can’t be bothered to research their own answers or the questions are some bizarre edge case. Either way it’s not as satisfying to help people as it once was and the vast majority of interactions is labored a bit.

It’s kind of an impossible situation. You let people post whatever and u get inevitable clashes. And once the fun isn’t allowed u end up with a wasteland of inane, unexciting questions. Again, it is what it is. No point crying about spilt milk at this point, but it was painful to watch this unfold so slowly over all these years.

Maybe I’m crazy and self indulgent, but I like to think I fought the good fight trying to raise awareness against this decline. But I am also fully aware from some perspectives that makes me a bit of an arse. I mean maybe I am. /Shrug

Strange world we live in. Everyone thinks they’re the good guy in their own struggle against the evil forces conspiring against them. It would do us all a lot of good to think about moral relativism. Or maybe not maybe I’m just getting off topic again and just making everyone angry again :stuck_out_tongue:

I was happy with this thread, felt like a decent thread with some good practices talk that reminded me of the old days.

So yeah, good time for a break. Not really much of anything to save at this point. Excited for future updates though.

21

Ok, I gotta make one new post as it’s pertinent to this thread,

Hot Reload is on Sale for 50% price and I finally got around to giving it a chance as I saw the recent sale

HOLY F*(#

Reloading Backend is totally gone now and in total my code saves tend to take a fraction of a second.

Old:

New

This changes absolutely everything. I’d read lots of mixed reviews on this product and even that it could bork your project, but so far jesus this is incredible.

It never even occured to me that I may want to code on my other monitor because it compailes so fast that you actually lose time by tabbing between the IDE and the Editor.

And I haven’t even tried changing values at runtime, which I hear Hot Reload allows.

If EVER you were considering checking out this asset, there is no better time than now.

I don’t even want to think about how many hours I sat here tweaking some random value over and over and how many hours/ days I’ve lost to loading bars. Oh well, better late than never.

Edit: Just tried out the realtime code changes and it didn’t skip a beat: