Hi,
I’m currently in the planning phase of my game, which will be very coding-intensive (procedural generation, game mechanics …)
I’m pretty new to unity so I’m asking myself:
Does it make sense to put the core (‘backend’) stuff in a separate dll, so to leverage the standard VS tools (e.g. unit tests and so forth) and only write the logic for the ui / game objects in unity scripts ? Are there any best practices ?
Thanks for sharing your thoughts.
There are a lot of reasons to use DLLs. Unity recompiles all of the loose scripts, on each saved change, into its own set of DLLs (four of them, to be exact), so the less work you can make it go through, the better. Everything in a “/plugins/editor/” folder is compiled into one DLL, everything else in “/editor/” into another, everything else in “/plugins/” in another, and finally the rest of the project that wasn’t in any of those.
If you edit a script in “plugins/editor”, then all of the scripts that belong to that same DLL get recompiled. Even a small game can end up with recompile times over a minute if all of your scripts are left laying around, and that’s really painful if you’re just making small adjustments to test, but if you put all of your “completed” UI scripts into a DLL, and all of your “completed” combat scripts into another, etc… you can cut that down considerably.
With more recent Unity versions, you can still use Monobehavior classes within a DLL and attach them to GameObjects just fine, but obviously they’ll be harder to edit. You also have to keep in mind that you can’t have dependencies on classes outside of the scope of your DLLs, but that’s nothing new.
Thanks Lysander, your post was very helpful!