#DOTS Best Practice - Classes/struct per file

1 messages · Page 1 of 1 (latest)

covert dragon
#

Hello there fellow developers,
Quick question for the DOTS experts (or experter than me that is ^^), is it good practice to put in the same file the Authoring, Component and Baker classes ?

mighty fern
# covert dragon Hello there fellow developers, Quick question for the DOTS experts (or experter...

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.

covert dragon
#

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 ?

mighty fern
#

Yes, I think so. Them are closely related. In Rukhanka I even have BakingSystems which are in different files from Baker

covert dragon
#

(I'm trying to make things a bit tidier because it's like a zillion files for aspects/properties etc ^^)

#

okay, thanks again !

mighty fern
#

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.

covert dragon
#

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

ripe torrent
#

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

covert dragon
#

yeah okay makes sense, Aspects would go in the Components assembly too ?

ripe torrent
#

and should, since they are just wrappers for components that can contain logic

covert dragon
#

okay!