search

specklesystems / speckle-unity

AEC Interoperability for Unity through Speckle
https://speckle.systems/tag/unity/
Apache License 2.0
55 stars 20 forks source link

Optimized package structure #86

Closed haitheredavid closed 9 months ago

haitheredavid commented 1 year ago

Shifted the package structure around so the connector looks similar to hierarchy of speckle-sharp, so it looks like: 

-Speckle Connector 
\-Editor
\-Runtime
  \-Objects
      \-Lib
  \-Core 
    \-Lib

Moving all the runtime scripts into a separate folder will give a lil boost to the unity compiler time. Next step would be to organize the scripts to live in their respective folders

JR-Morgan commented 1 year ago

Hi @haitheredavid, This is a really nice thought, and I like your approach.

On another branch #88, I have made some other structural changes. So I decided it would be easier for me to recreate your changes on that branch, instead of merging these.

I have replicated your suggestion of Editor and Runtime folders, this has indeed tidied up the code a fair bit.

I have one question, Objects and Core, you place under a libs folder, with an assembly def. Is there any reason for this? I didn't think assembly defs interact with pre-comiled DLLs in any way? I may be wrong here.

I would love to hear your thoughts, and if you were interested in the other assembly structure changes I've made in #88

haitheredavid commented 1 year ago

👋🏻 @JR-Morgan branch #88 looks good to me 👍🏻 I like seeing the main scripts being organized into their respective folders, makes the unity dev life easier. There are some pieces to consider though, and it sorta addresses the question you have with the Lib folders.

The Core and Objects folders would hold more than just the plugin data, it would be an individual unity package that hold also the scripts and components necessary for that package. The Lib folder is just a designated location for all the plugin data to live. They actually don't need to live there, I just prefer to have them organized in their individual folders since each file generates their own .meta file in unity. Makes things easier to update when doing CI 💩.

But to keep digging into why I was building these as individual packages, take a look at the connector I've been building there are three main unity packages that can be installed, com.speckle.core , com.speckle.objects, and com.speckle.connector. This replicates the same structure speckle-sharp has and it aims to allow any curious dev the ability to extend objects or core pieces without breaking the connector. My only goal with this was to make the converter interfaces (IComponentConverter) extendable, so if someone wanted to modify how a converter worked in the main connector they could achieve that via script or editor. Or if they wanted to publish their converter for others to use they could by only referencing the com.speckle.objects in their unity project.