|
We have two projects underway and want to share some classes between them. The shared source must be in a single location so when a programmer on Project1 updates the code those changes are immediately seen in Project2. The important part is that we do not want to maintain multiple copies of the same code. i think we would agree that its simply bad practise to do so. The only option appears to be putting the code in a class library and load it as a plugin into each project. But I don't believe this works when referencing Unity types like GameObject or transform. In C/C++ land we could put the source in a directory and include it into any solution we wanted - doesn't seem to be so easy in Unity-land. Is their a better way to share code between unity projects? EDIT: All projects, including the shared code, are already under source control. This is not a Source Control question, its a framework issue. (And obviously I need to write better questions!) Lets say the directory structure looks like this... Can Unity reference code from other projects? Can Unity reference code outside of its own Assets folder? If so, how?
(comments are locked)
|
|
You can share code (and assets like prefabs) effectively like this: Use external versioning support. (I'll use subversion in this example, but most versioncontrol systems support this scenario). Version your game at: svn://yourcoolcompany.com/games/monkeydonkey/trunk Version your shared code at: svn://yourcoolcompany.com/sharedcode/trunk Now, in the checkout of the game, create a folder called "SharedCode", and set its svn:external property to the svn url of your shared code svn location. This way you can easily share your "common" code amongst different games. If your needs get a bit more complex, you can also branch your sharedcode project to something like: svn://yourcoolcompany.com/sharedcode/branches/monkeydonkey if you want to "freeze" the version of the sharedcode that the monkeydonkey game uses. (for instance, when a game gets close to shipping, but you have another game in full production, it's likely that you don't want to the sharedcode updates to be picked up by your almost shipping game, due to risks of accidentally introducing a bug). I find this to work pretty well myself, as you can easily commit changes to both your game, and the engine code. Had not thought about sharing assets & prefabs too. Thats very cool, thanks Lucas.
May 14 '10 at 06:37 PM
Chris Masterton
This may be a dumb question, I'd already thought about doing this as specified, but I was concerned about the metadata files. Is it possible for one project to change them and then cause problems in another project that's using the same library?
Apr 19 '11 at 10:49 PM
squidbot
so, that's basically saying "no, unity can't do it. instead, use your source control of choice, such as git's submodules, subtree or even cherry-picking"
Nov 16 '11 at 05:03 PM
Cawas
Hi I'm a newbie. I had the exact same question, but also the exact same concern as squidbot in the above comment. Has anyone answered how meta data works when shared between projects? We believe it breaks our project links. Thanks.
Aug 21 '12 at 03:58 PM
wrxmarcus
Dear @wrxmarcus and squidbot: I'm not following your concerns. You have to keep the ".meta" file always together with its "parent". That's all, and nothing breaks down. If you lose the meta, you lose its information, but it will be recreated and only what has been lost from the meta would be "broken", and the meta recreated with a warning. That's still far from breaking the whole project.
Aug 21 '12 at 06:59 PM
Cawas
(comments are locked)
|
|
The link provided by @Cyclops may provide part of the answer. Sharing the code could be accomplished through a clever use of source control. Your scripts (and potentially the whole project if you have pro) should be under source control already. Consider moving all shared code into a single root folder. Keep this folder out of your source control by ignoring it. Create a new repository just for this shared code. With this model, you can develop in both projects making changes to project-specific and shared code. The only extra work comes when its time to check-in and sync your changes to the server. Instead of only doing it once, you'll do it for the project specific repository and the shared one. When working on either project, always remember to check out the latest version of the shared code and you should have a single point for managing all that code. You definitely should have everything under version control - this "keeping in a single location so that it's immediately updated" is a bad idea, as it can break someone's changes. To expand on Michael's answer, I use git to keep track of the project as a whole, but have a submodule specifically for code - that way I keep the binary data from the scenes separate from the text-based code which is re-usable across projects.
May 08 '10 at 12:11 AM
Ricardo
Hey @Ricardo, although I agree that it could lead to breaking code in another project, that risk will come with any method of sharing code between projects.
May 08 '10 at 12:15 AM
Michael La Voie
Hi Michael. Sure, but it's a lot more likely on his originally suggested approach, where he doesn't use a vcs and instead expects the directory to auto-update.
May 08 '10 at 12:53 AM
Ricardo
@ricardo, I am using VCS. I thought this was implied in the question but obviously not. Thanks for bringing it up! I've made appropriate edits.
May 09 '10 at 01:29 AM
Chris Masterton
(comments are locked)
|
I had originally flagged this as a duplicate question: http://answers.unity3d.com/questions/9658/what-needs-to-go-into-source-control-to-share-a-project-unitypro, but on re-reading - it's not exactly the same, although it seems like you're trying to solve the same problem from two different directions.
This is definetely an extension of 9658. I felt it warranted splitting into two seperate parts to make it easier for the community to find specific answers.
If the problem is not source control, and you have a solution for that side of things, then symbolic links could help. Put your shared code in a sub-folder of Assets, then move the subfolder to a shared location and link it into all the projects that use it. Windows 7 symlinks are (finally!) pretty good. See "mklink /?" for details.