koobas.hobune.stream
Creating a core project to be used on several projects
Hello there,
I want to create a core project with some functions like save & load progress, level selection, scene transitions etc. so other people can create games with it.
The problem is: while these other people work on their projects, I'll keep updating the core project with new features and bugfixes.
How can they easily update their version of the core project on their projects? Should we use some version control scheme like git, or AssetBundles?
Thanks, Bruno
I have a mercurial repository with everything game-independent in it (so far only code) and i add it as a subrepository to all the projects i start.
yes using version control system like git(bit bucket/tortoise) will make it easier .Other user will clone your projects and other might pull your projects if changes by using commit -m messages if updated. others will see by the log commit -m message you have done latest
https://docs.unity3d.com/Manual/AssetPackages.html
What will help is an asset package, like the standard assets or things on the asset store.
"You can re-name an updated package and Unity will recognize it as an update, so you can use incremental naming, for example: MyAssetPackageVer1, MyAssetPackageVer2."
Make a place to download them from like a cloud drive, git, or something. Then the people working on other projects should be responsible for adding the updated asset package to their collaborate/git.
"How can they easily update their version of the core project on their projects? "
Your best bet would to create a .dll (library) for your projects, for a few reasons
Once you have it created and built out you can just toss it in your project directory and continue to use all the library functions, as if they had the scripts loaded into their project directory.
If your worried they will steal your project code they will have to unpack your dll (Not that many people know how, and if you use Managed code C++ it's even harder)
You give them a single file: "For this example, create a new project in Unity and copy the built file /bin/Debug/DLLTest.dll into the Assets folder. Then, create a C# script called “Test” in Assets, and replace its contents with the following code:"
It's cleaner and it gives you more knowledge for the industry Working with libraries is a industry standard.
You can even end up selling it on the asset store if you wish.
If this core project only provides code, then you can create a library that produces a DLL and bring that DLL as an asset into each of the games that require it.
For example, our company setup a library that provided a myriad of functionality. Some were simple utility scripts, while others were complex mono behaviors that people could attach to get up and running quickly. This library was a Microsoft Visual Studio solution which was version-controlled on a perforce server. Game Developers would then setup their Perforce client workspace to include the library and their game. This library would be pre-configured with a post-build step to deploy the DLL into the unity project's asset directory. When an update was made to the library all the game developers had to do was sync their workspace (which included the library) and rebuild the solution.
Let me know if you need me to elaborate or go into detail for anything I described above. I'm sure there's a multitude of ways of implementing such a library but this is what worked best for us.
