How often you use assembly to separate your code in Unity? Just added unit tests to core functionality and ended up with a few assemblies (Gameplay,Services,Data,Models,UI)
My code was always separated that way, but in single assembly, so no much was changed there. Now, I do understand many benefits of that separation, and from architecture perspective its seems perfect, and I like it, but
Will there be any down sides while developing, releasing, package updates, or anything else that I’m not aware of?
For years I was promised that using assemblies could vastly speed up compilation times.
I’m sure they might, but on the small sampling of mobile games we tried it on, it caused far more problems and required files to be moved around, code to be restructured (arguably those are all GOOD things for us to do), and in the end, compilation times were the same.
I guess once the assemblies are in place they now help enforce better organization of a project, but poor organization, while we certainly had it, wasn’t really hurting us.
And now we had yet another thing we had to beware of, be mindful of.
I’ve found that trying to split code into assemblies based on categories like “data”, “interfaces” and “enums” can lead to challenges. But when you split by feature, the separation tends to be much more natural.
You would use assemblies and external libs for large projects or plugins where you want to expose the functionality without the actual codebase.
We take our packages and do auto deployment, so we’re not constantly rebuilding so having some sort of system like this is suggested. We specifically use them for re usability in our projects, we have a custom inventory for example, we can just pull that into any project easily and have full access.
Just like anything there’s pros and cons, so no one can answer “What are the downsides” because we don’t know your production env, team size, project size, etc.
In my case its not a big project, its Idle casual game.
But 4 years ago had similar game, and it was hard to get back to project after some time and know what to check on release , or what edge case to test on adding new functionality.
So now I want to add tests for that and it leaded me to do that assembly separation, which is great,
not even caring about compile time as much as I like that it forces other devs to follow some rules,
but just never did it in project that I released and not sure will there be any unexpected stuff.
Plan is to have CI/CD in place, and be able to delegate that project to other devs, for now its just me.
Probably most of the devs would say its overkill for that kind of projects, but I dont feel like I spent much more time then usually.
You may have to edit the assemblies more often just to add dependent assemblies (including packages). Although with the proper IDE (Rider) this is practically automated anyway.
If you split it up into too many assemblies, ie dozens in your case instead of four, you can actually hurt your productivity especially if the splits aren’t necessarily architectural in nature.
And that’s the main point: Asmdefs enforce architecture boundaries and this is 99% of their benefit, and typically outweighs any costs unless, see above, you are creating too many or try to make a super-modular architecture if not “microservices”.
