koobas.hobune.stream
Best Methods for Asset and Code Reuse and Organization
Hello,
I was wondering if anyone had any opinions on organization of assets and code that would be reused over several projects, that may or may not relate to each other. Hypothetically speaking if I wrote a script that would perform a generic reusable function, that could be used by two different games, how is that code best managed.
Is it better to build two different Unity projects and copy and paste that code into the two different projects from a "source" location?
Is it better to build one Unity project where both of the games are developed and have access to shared resources.
The first method I see as easier to conceive, but would require diligent updating of code. May not be a problem for 2 games, but scale that to 6 games and that's a problem.
The second sounds like a much better code management model, being that code can be update once, and it will populate to all the other applications. This coding method seems like it may be much harder for developers to keep their head wrapped around, and also may mean that code specific to one game, ends up in another when it is not necessary. I also wonder about potential limitations multiple games in the same project, the ability to be built independently.
I'm sure there are other methods for production. I would love to hear anyone's ideas and opinions about the subject.
Best Regards,
Stephen.
One method that was discussed at Unite is to have a separate project for your code and to compile re-usable code into DLLs (using Visual Studio or MonoDevelop) that can be linked to from other projects.
If you have a lot of questions like this I would recommend attending Unite... it's basically 3 days of presentations about how different teams have approached issues like this.
The guys from Schell Games did an awesome presentation about their approach. They shared their slides here (I hope they don't mind me sharing the link):
http://unite.schellgames.com/
Here's the presentation those slides come from http://video.unity3d.com/video/3708530/unite-11-scaleable-game
I'll answer my own question since after more thought, I determined my own answer. This isn't for me as much as other people that might wonder about this. It isn't possible to have multiple mechanics occupy the same project, ie. #2 above. If you are creating an app that you want to be "skinnable", and leverages the same mechanic it is possible to have variables, that can inform the code which "skin" to use. Other than that, it isn't possible for two games that have diverging mechanics to share a code repository. The Assets folder seems only able to be used by one project. So as a result, the scripts that could benefit both mechanics will have to be copied and pasted from the Assets folder of one project to the other. The other big gotcha prohibiting this workflow is that it appears that the build will only allow for one set of files to be specified. So if the build list changes in any significant way, it would require significant alterations that would mitigate and benefit to having shared resources. I am interested in hearing anyone else take on this issue.
Best,
Stephen
It is certainly feasible to re-use code libraries by compiling them into DLLs. Large $$anonymous$$ms developing sophisticated games aren't copying and pasting code from project to project.
I like your organization of folders.
In general we, open a new project and import any Unity Technologies package and the only folder organization enforced is an 'Assets' folder with a subfolder of 'Standard Assets'. What about our custom assets?
Here is the SOLUTION. What Unity Folder Structure Do You Use? - http://bit.ly/1b7cLyq
-Sam!
