Nested Prefabs are a good idea but what about...

Nested Asset Store products.

You could add someone else's asset store product such as an animal model into your product. When you submit your asset to the store, the price would add on the other asset's price and the customer would essentially be buying two products. This could possibly be done by having nested UnityPackages.

Ok a different text example

*Makes an entire shooter level*
*Uses UFPS: Ultimate FPS to control the player*
*Realizes they can't submit the package to the Asset Store because it includes someone else's product*
But wait, nested products!
*Uploads the product and the price will be adjusted accordingly*

If the customer already has the extra assets, then they don't pay extra. In a way this could make it possible to do a sort of Asset Store DLC. For example I might like to sell guns that use my product Energy Based Objects which is a weapon system. I don't want to have to update each individual gun with the updated weapon system scripts every time I want to update the system.


TL ; DR
Nested Asset Store Products via Nested UnityPackages

Is this possible?

Vote for it on Unity Feedback! http://feedback.unity3d.com/suggestions/nested-asset-store-packges-slash-products

 

THIS. I like this.

 

For free assets like iTween (often thrown into other packages) this works nicely. When money's involved, complexity is a beast of a problem.

Assets and packages currently have no encoded "pedigree" and I'm not sure it would be possible or practical to support them.

All Unity developers would have to digitally sign their package to submit it to the store. They'd probably have to keep their digital keychain files around, and require the same key be used to sign and upload updates to the package. This is the model that the Android marketplace uses.

Then the person who wants to upload a package that includes another person's package would include the older package's pedigree, along with the new assets. Unity would have to confirm that the new package had ALL of the older package intact with no changes, or prorate the price, etc. This depends on the new package's author being meticulous; it's much easier to just "forget" to include that other pedigree and get all the money.

With a simpler dependency system, it would be easier for Unity to inform prospective buyers of linked packages. If you need "Joe's Marshmallow Mesh v3.2" to make all the features of "Amy's Marshmallow Infinite Runner Pack v2.0" to work properly, then Unity could help the buyer organize their purchases and understand the total cost better. This requires almost no work on Unity's part, and no incentive or risk for sellers to try to cut corners.

 

Darth Vader gives a thumbs up.

 

This would be especially good for 2D game "frameworks/projects" - that way, you won't be banned from using an existing 2D plugin like the awesome 2D Toolkit, and they would also get a share

 

It's called: UT learn2maven. This is a pet peeve for me as well, there should be a dependency structure WITH versioning supported through the AS - i'd use maven to drive it and integrate with the unity editor. But i'm sure they have plenty of work on their plates atm already. So if you release an asset with UFPS as a dependency, the AS will ensure you own everything or warn you to the contrary, it will allow you to install that asset and automatically install dependencies and it will let authors specify a max/min version of each dependency so that if UFPS updates it doesn't potentially break the authors current AS offering.

Deprecation should be supported to allow for flagging an asset version as moving into EoL stage.

 

I think it benefits the 4 sides of it, so thumps up.

 

I was was thinking exactly this. I wanted to make a game kit, but I don't have the time to write a complete 2D framework AND the project kit.

 

I just posted this on Unity Feedback. Vote for it!
http://feedback.unity3d.com/suggestions/nested-asset-store-packges-slash-products

 

I think this is a very good idea. Conflicts seem to happen a lot with tween packages in particular.

On a related note, I think Unity needs to require Asset store packages to follow more rigorous conventions, regarding:

1. Namespaces. I think each package should live in its own namespace. I've had quite a few conflicts between packages. It's not a huge deal, but annoying nevertheless.

2. Directory structure. Currently, plugins can dump into any directory they feel like. This means my root asset directory gets cluttered to hell.

 

The problem with this is that Unitys support for namespaces is quite shoddy. And I think not at all officially supported on iOS.
When I first noticed that Unity 4 had support for namespaces I started using them extensively, but after quite a few broken projects (sudden influxes of script name doesn't match file name) I now avoid namespaces for MonoBehaviours and ScriptableObjects.