Could Unity Use a Library?

By this I mean could Unity use a meta project library, where common default and asset store purchased components can be stored.

Why do we need to import assets into a project when we could just link to them in a local Library?

Possible benefits of a local Library setup could be users adding their own common used features to it, e.g. Arowx's Intro Scene, Arowx's Default Menu

I know it would get complex when new versions of things are added. So it would need to run under a basic file based version control system but would a Unity Library make developing multiple projects in Unity easier.

For instance Unity (on the cloud) or a Studio could set up a shared library for a development team on a network server.

The aim of a Library would be to reduce duplication between projects. What do you think would a 'meta' project library help you?

 

If you build it I'll try it out.

I'm thinking something like the asset store window. Just a simple listing of all of the packages and systems I have built, that I can choose to import at will.

I'm not overly fussed about versioning, most of the time a system gets heavily customised to meet the current game needs, and there is little point pushing that back to the library.

 

To work well the library would store the assets/sub projects saving you having to import them into your project, only changes to them would need to be localised to that project. In theory it could work using file system features e.g. a directory appears to be in your project but is actually in the library.

However it would be better to build it into Unity as it needs to work within the build process.

 

Integration of and updates to 3rd party assets are things that need to be managed carefully. I see a risk in such a shared library in that someone working on another project could make an update that breaks my own project. Things get hairier when one project needs an update and another project wants to avoid it.

 

You can do this now with symbolic links (create a common folder, and create links in your app to it). I've done this in the past. Would be nice if it were an actual feature of the engine, and they'd work around the issues that come with it.

 

I have ported computers several times with my project and every single time I've had to deal with missing references or various errors. So if that was the goal, it isn't being served by this method.

It would just be nice for the developer to have some choice in that functionality. Those of us who want to create games that aren't entirely static and possibly modifiable would absolutely love to have the ability to store project files in an external folder post-build.

 

Really? I move projects around regularly, and haven't ever had an issue except where I've missed putting something into my source control.

If I want to switch computers I just go to the other computer, pull my latest version down, and open the editor. Occasionally, if I'm on a computer not set up for development, I just install Unity and copy the project over via USB storage, which has also worked fine every time. This even works when changing development platform between Windows and OS X.

What kind of issues are you getting?

 

It's been about a year since my last move from comp a to comp b, but I remember there being several shader errors that randomly decided to pop up and halt my entrance into play mode. Something about struct "o" not being fully initialized. For some reason, this didn't bother Unity before moving the project, only after. Occasionally, several prefabs would lose their references, various objects would show up magenta due to missing shaders.

But the point I'm trying to make isn't about specifics. It's to say that there is always a chance for issues when changing computers. Saying that using this method somehow eliminates that risk simply isn't true.

 

If you had max on one machine and not the other (for example) then you'd get all sorts of problems if there were only max files in the project (for example). Maybe. I've never had a problem.

That honestly sounds like it wasn't all moved, or it was opened in an entirely different version of Unity than what the project was made in.

 

Nothing is going to completely eliminate it. As I said, even I have had issues, albeit arising from user error rather than tool issues. Still... none of my issues from memory, over many many moves between computers with dozens of projects, have had engine-related migration problems that I can remember.

That said, I'm usually reasonably careful about sticking to stuff that works cross-platform nicely, which helps a lot.

Unity's approach isn't the only one to handle this, but it seems reasonable enough.

 

Yeah, just use version control and you can pull the entire project onto any machine. Done.

 

I wouldn't doubt it at all. My standards for being careful with that kind of thing have exponentially grown over the years.

This is what I'm trying to say. The user should be the one making sure there are no errors when moving a project, not the engine. The issue I have with Unity's approach isn't about effectiveness, it's that the trade off leaves the developer with less control. <- That issue is persistent through almost every component Unity brings.

 

On that note, I just watched a team of software developers going through a much more complicated process to move a non-Unity project onto new computers. I think it took them half a day, not including getting dev tools set up on the new machine.

That's not intended as a comparison with Unity. Their work is quite different, so of course their dev environment and workflows are also different. Still useful as food for thought, though - how much time would get chewed up with that stuff if Unity didn't opt for the project-folder-contains-everything approach?

 

I'm not really thinking of a shared library. I'm thinking more of a central place to push unity packages once I've built a system. And an in built system to pull packages into a new project.

The more I think about it the more trivial it seems to build. I might go ahead and make it for my own use.

 

VCS, branching and/or forking with just a dash of scripting and assetpackages. Add flavoring and seasoning over time. After a while you've got a type of framework.

Mine is majestically called "_baseFolders" project. It started because I hated creating all my basic folders every time. I never bothered to change the name. Currently it has pretty robust asset management, database support, content mgt, modular prebuilt game UI framework, a ton of development tools/suites/widgets and prototype assets and most recently a base project control panel/sub-system to support builds/project management and tools framework.

So, from the command line I just navigate to the asset folder of the new project and type "makeUnityFolders [gameID]" the gameID is for namespaces and such. It also has a few of optional flags:
-dotween (adds in the latest dotween package)
-shaderFun (adds in all my current custom shaders),
-uiFun (a ton of structural ui assets, tools and fonts),
-FXparty ( all my fx textures and tools and prefabs).
-mongo (imports mongo plugins.).

It started as just way to automate folder creation, now it is pretty much a game development library and tools framework. The trick is that every project I try to contribute at least one thing to it. Each game/prototype gets a little faster.

 

Yes, it's up to us to use our tools properly. The tools have a huge impact on how much work we have to put into that. What I was getting at is that as long as what I'm doing is compatible with the computer I'm working on, the only external setup I have to do to open any Unity project is installing the Unity editor. After that, a file copy or a version control pull is it.

I'm responsible for making sure it works, but Unity does a great job of making that job super simple.

 

I just love the idea of how easy it could be to work on multiple projects with Unity if Unity had the option of a meta project / library or asset database.

In a way with the asset store it almost does have this, you fire up a new project and buy or import the assets you need and they are in the cloud.

But what if your own frequently used assets e.g. code/shaders/UI/templates could be put into your private cloud based section of your asset library on the asset store.

I'm surprised the community seems to view this idea so negatively and UT do not realize the potential they have to make developing games easier!

 

You make a good point, penguin. You make a very good point indeed.

Admittedly I know very little about how Unity's build structure affects project transportation. I suppose I've just seen this done the other way so many times that I wasn't sure it really made all that much difference, but you seem to have a lot of experience dealing with that, so I'll defer to your judgement on that matter.

I still use external folders via the StreamingAssets directory to handle custom file types, and that works just fine. I'm even able to load textures as well, but the more complex objects such as animations/sprites/models/etc have been a bit more difficult to handle.

The reason external folders are so important to me specifically, is that I've essentially recreated the Aurora engine within Unity to work with my game. I'm just naturally attuned to having those external directories to quickly drop in and override different aspects of the game post-build.

I'm a bit biased on the matter.

 

I don't know if anyone is negative about it really. It's more that a lot of folks either don't need it or have their own solutions. In terms of critical needs / improvement for unity, it really not important at this point.

But it is a great discussion, and I am very interested in hearing other peoples solutions and methods.