#DOTS Best Practice - Classes/struct per file
1 messages · Page 1 of 1 (latest)
No, because in builds you will need only Component. You can strip (and will because of UnityEditor is not available in standalone builds) all editor related stuff. And easiest/robust/flexible way to do this is by using different assemblies for Editor and Runtime. All entities packages files organization structures follow this principle. Even if assembly split method is not suitable for you file splitting is preferred to one monolitic thing.
Okay, thanks a lot, I'mma split things again then :)
I can put the baker and the mono/authoring things in the same file tho ?
Yes, I think so. Them are closely related. In Rukhanka I even have BakingSystems which are in different files from Baker
(I'm trying to make things a bit tidier because it's like a zillion files for aspects/properties etc ^^)
okay, thanks again !
Oh, I understand. As always it is your decision. If number of files is a main problem then you can go with "one file" method separating authoring and editor stuff with "#if UNITY_EDITOR" guards for example. But I prefer smaller files/functions. Easier maintain/refactor/extend/etc.
I'm going to go the split way for now, because I'm just starting to wrap my head around the whole thing and I may have errors and mistakes already without trying to circumvent the hierarchy and such ahah
for large projects it's probably best to put authoring/baking into separate Authoring assembly
which will have UNITY_EDITOR define contraint on asm def file
so you won't need #if defines in code
components also should be separated from systems
by assembly
if let's say you modified system code which also contains component - your subscene will be reimported
once again - in big projects with large subscenes that usually means 5 or even more minutes wasted for no reason
Meanwhile if systems are in their own assembly, components (at least those, that are used in baking) in their own, and baking in it's own
you won't get any useless baking code in Build, when you modify system code you won't get your subscenes reimported
yeah okay makes sense, Aspects would go in the Components assembly too ?
no, aspects can go into systems
and should, since they are just wrappers for components that can contain logic
okay!