Assembly definitions question

Unity Engine
,
1

Forgive me if this is a dumb question but I’m about to begin restructuring the project for a game I’m working on as its grown to the point of being a bit unwieldy.

I want to take advantage of assembly definitions and I have a question about them.

According to the docs, assembly definitions are assets you can create to organize your scripts into assemblies.

Does this mean I should only create assembly definitions in script folders? I was watching an Infallible Code video where they were talking about how to structure their project and Jason Storey said that he prefers to arrange things but purpose, not by type. For example instead of:
Assets

  • Animations
  • Art
  • Music
  • Prefabs
  • Scripts
  • Sounds

He’d do something like:

  • Common
  • Animations
  • Art
  • Music
  • Prefabs
  • Scripts
  • Sounds
  • Main level
  • Animations
  • Art
  • Music
  • Prefabs
  • Scripts
  • Sounds
  • Bonus level
  • Animations
  • Art
  • Music
  • Prefabs
  • Scripts
  • Sounds

etc.

In light of that, would it make sense to put assembly definitions in the Common, Main Level, Bonus Level folders? Would other assets besides scripts be packaged into the assemblies?

I’m guessing not based on what I see upon examining the assemblies in my project.

Thanks,

Greg.

2

When he argues arranging “by purpose”, I’m assuming he means each thing is in its own subfolder.

And these two arguments have to do with the project size. This is not just a matter of taste, you literally have to be able to navigate through your project to manage it properly. On top of that it doesn’t make much sense to change the internal structure of some assets, and so you simply turn every meaningfully separate asset (yours or 3rd party) in your project into a folder of its own.

Assemblies consist only of code and this is what assembly definitions are for. Practically they let you compile runtimes per-assembly, not per project, which can become really painful for a sufficiently large code base (time-wise). However, you need to practice a little with asmdefs. Dependencies are a pain, and rarely can you truly separate things that are the meat & potatoes of your game. So unless you’re really aiming towards a big big project with many moving parts, that will compile for minutes or more when you change something, I’m not sure how useful they really are.

3

Assembly definitions only care about script files, and don’t touch anything else. You can put them in folders with other types assets in the same folder/sub folders and they won’t affect them in any way.

I personally don’t use/like the above folder structures either, particularly when your project gets above a particular size, and it doesn’t gel together with addressables whatsoever as well. My project is broken down into systems/mechanics. For example my project is broken down into folders/asmdef’s like so:

-[CompanyName].asmdef
– Bunch of general use code
-[CompanyName]-Editor.asmdef
– Bunch of general editor code
-[GameName].asmdef
– SystemA, B, C, etc (all broken apart with asmdef)
-[GameName]-Editor.asmdef
–SystemA-Editor, B, C, etc (again, all broken down with asmdef)

Some of the smaller systems might not have an asmdef, though they might get one as they grow. I also have a ‘Core’ folder that doesn’t have its own asmdef, so all the other ones can reference the [GameName].asmdef to have access to it.

And then within each system/mechanic, many are broken down into further subsystems, some eventually ending in the typical structure of a meshes, materials, scripts folder (but not often, honestly).

This structure is good for keeping all your systems separate from one another, and you can navigate quickly through the files of the system as well. Namely, I try to keep all related assets as closely together as possible. There’s no point having the materials for a system in a completely separate directory.

That said, for small projects it might be a bit much.

In any case you should be flexible with your structure, always looking to improve, and make it work for you.

1 Like