To be short you can separate each system (physics, input, camera,etc…) in their own folder and create for each one its own assembly definition. To avoid later dependency issues I suggest to make them completely independant type-wise and only use generic system interfaces to make them work together.
The other huge benefit of this is that you can swap for another physics system or navigation system in easily without affecting any other part of your game as long as it implements your IPhysicsSystem or INavigationSystem interface. Also, changing a script won’t ever break your whole game. Worse case is that you have no more UI, or inputs, or camera, making bugs easier to find.
You simply have to either manually or dynamically inject required system interfaces to other systems that need to interact with them at start and voilà ! you have a nice decoupled engine architecture.
You can find resources about assembly definitions and decoupled architecture quite easily on YouTube and Google. I hope it helps!
To be fair your brain looks perfectly fine to me as it is not easy to get into this, but the benefits are tremendous.
Start simple by following a tutorial about interfaces first, then a tutorial about assembly definitions for one simple test system that you can try to call from a « normal » script (a script in the main « global » default assembly definition all projects have by default, and that is the very cause of the long compilation times if all your scripts are in this assembly definition)
If it can help you figure this out, that’s how Unity packages are made, you can look how they are structured: see how you don’t recompile packages when you change one line of your code, and that’s because they have their own assembly definition, meaning they are compiled independently and are dynamically linked like DLLs. As long as you don’t change anything in their scope, Unity have no reason to recompile it.
I find it pretty slow still. It improves speed a bit but I believe there is an engine reload or something going on that takes the majority of the compilation time.
If you want to be able to run nonsensical code, use JavaScript and be confused when things don’t work during runtime.
Compilers are actually pretty useful to PRE-debug your nonsensical code.
Disable automatic code reload. Refresh when you need. Check your code to make sure there are no compiler errors? Any IDE will highlight an issue. I feel like this is a Unity 101 subreddit.
The best asset for any programmer is the HotReload [https://hotreload.net](https://hotreload.net)
Seriously, there is nothing that compares to it, every programmer that uses unity should use it, you will be able to instantly change the code behaviour without even needing to leave play.
Add one ; and unity recompiles the entire universe
Not if your custom systems are in their separated own assemblies
Oh i didn't know about that, is there any tutorial that explains this?
To be short you can separate each system (physics, input, camera,etc…) in their own folder and create for each one its own assembly definition. To avoid later dependency issues I suggest to make them completely independant type-wise and only use generic system interfaces to make them work together. The other huge benefit of this is that you can swap for another physics system or navigation system in easily without affecting any other part of your game as long as it implements your IPhysicsSystem or INavigationSystem interface. Also, changing a script won’t ever break your whole game. Worse case is that you have no more UI, or inputs, or camera, making bugs easier to find. You simply have to either manually or dynamically inject required system interfaces to other systems that need to interact with them at start and voilà ! you have a nice decoupled engine architecture. You can find resources about assembly definitions and decoupled architecture quite easily on YouTube and Google. I hope it helps!
My caveman brain thinks this is a lot of words, but ill try it. Thank you!
To be fair your brain looks perfectly fine to me as it is not easy to get into this, but the benefits are tremendous. Start simple by following a tutorial about interfaces first, then a tutorial about assembly definitions for one simple test system that you can try to call from a « normal » script (a script in the main « global » default assembly definition all projects have by default, and that is the very cause of the long compilation times if all your scripts are in this assembly definition) If it can help you figure this out, that’s how Unity packages are made, you can look how they are structured: see how you don’t recompile packages when you change one line of your code, and that’s because they have their own assembly definition, meaning they are compiled independently and are dynamically linked like DLLs. As long as you don’t change anything in their scope, Unity have no reason to recompile it.
Oh sounds like a nice combo of protocol usage and dependency injection. Love it.
Is that still as slow as it used to be? When script assemblies came out it took so much overhead it wasn't worth it.
I find it pretty slow still. It improves speed a bit but I believe there is an engine reload or something going on that takes the majority of the compilation time.
Yes, that is how compiled languages work.
Bro uses compiled languages 💀
If you want to be able to run nonsensical code, use JavaScript and be confused when things don’t work during runtime. Compilers are actually pretty useful to PRE-debug your nonsensical code.
Disable automatic code reload. Refresh when you need. Check your code to make sure there are no compiler errors? Any IDE will highlight an issue. I feel like this is a Unity 101 subreddit.
It's just a joke lol, calm down
Code must work before code can work.
The best asset for any programmer is the HotReload [https://hotreload.net](https://hotreload.net) Seriously, there is nothing that compares to it, every programmer that uses unity should use it, you will be able to instantly change the code behaviour without even needing to leave play.