Should Asset Store Devs Be Responsible For Integration With Other Packages?

Just seeking thoughts on this. I have had to integrate many disparate packages that stepped all over each other. Some hogged all kinds of physx layers. Others had subsystems set up in one way that made integrating the second package a subsequent PITA. Does a purchaser have a right to demand integration of your package with another? If the integration cannot be done whose fault is it? In have my opinions on this but looking for other views if they are different or congruent.

 

Demand, probably not, but ask, sure.

 

I think a package developer should do everything necessary to ensure their package is as self-contained as possible, and provide a clean interface with Unity that doesn't interfere with other packages. Good use of namespaces is also a must.

That's how it *should* be done, but I think the only way you can demand it is with your money. Purchase assets that follow good practices.

 

I think it's unrealistic. There are thousands of packages on the asset store, how do we expect an author to manage integration with which ever random one someone demands? What happens if one author has moved on from their complete and working package, but a newer package from a separate author has users demanding integration even though the new author can not get in touch with the other author?

What do we do if they refuse to integrate it, remove the product? So we remove the option from people who don't need the integration because a few, or even just one, does?

Who decides which packages are relevant for integration, whens the cut off, what if it would require a complete rewrite of both packages?

I think the best way, with the least amount of headaches, is to leave it how it is. Allow users to request integration with other packages, but do not set it as a requirement. Users can then vote with their dollars and not support a package that does not have integration with another if they so choose.

 

An asset has to work in itself, being well written and self-contained. Any integration with other packages is purely down to the developer and should be considered a bonus. I don't see developers wanting to spend months ensuring their asset works perfectly with a thousand others, that's unrealistic.

 

Definitely not a requirement - there are too many packages of various levels of mudballedness and it would take all year just to maintain the integration. I worked on one fairly-well-rated package that had, just to begin with, the input bindings spread over a dozen scripts without any indication of where to find them.

But I agree with Dave-Carlile, the package should be designed to be self-contained, and expose its core functions or controls cleanly for easy use in other scripts or packages. Basically if two well-designed packages meet, it should be a case of a simple intermediate script or something like that.

 

There's no absolute right to integration unless you've advertised your product as such. However, although it's a rabbit hole, it's usually worthwhile to offer integration as long as you choose other packages that are either very widely used or nicely designed for integration. It has the added advantage of forcing you to design your code to play nicely with others, too, which is something that other posters are mentioning above. The better your design in this regard, the easier it is to write and maintain integrations.

Wise selection of packages is critical, though, because you'll be maintaining those integrations for the lifetime of your asset. I'd like to think I made mostly good choices with integrations for the Dialogue System and Love/Hate. Even so, over 50% of my development time on these products is now dedicated to maintaining integrations as the other authors change and update their products. I know some other publishers who are in the same situation.

But those integrations are really valuable to customers. For example, very popular frameworks like UFPS and Realistic FPS Prefab don't have built-in conversation, quest, and saved game functionality. It actually takes a lot of programming work to make a polished integration that gives conversations the option to take control of the camera and pause gameplay, tie quest activity into FPS combat, and save and load FPS data. A lot of customers really appreciate being able to drop in the integration package to get all of this functionality without having to do any programming of their own, so it makes the Dialogue System more attractive for customers.

 

"Demand" is probably not the word I would use.

If there is a choice between two assets and one supports more 3rd-party systems, I will favor the more integrated package, especially Playmaker since I use it in every project.

Where there is an issue I let the developer know about it. I don't expect them to test against every possible conflict with 3rd-party packages….

 

How could I forget to mention PlayMaker? Every dev should consider PlayMaker integration. Again, not a requirement, but it's certainly a huge selling point. It's always the first package that I integrate since it's so widely used.

 

Randy wasn't demanded into doing any of this.

I said to him "I want to offer this to you first and see if you're interested before I make any agreements with anyone else"

And he actually wrote this back " I could certainly use the money ", "Can you describe how you would like me to integrate Katagon with the Opsive controller? I do much better with text than videos for following a paradigm or methodology. Call me old school but I learned from those 2 to 3 inch thick manuals "

This is the first time I read anything like "If the integration cannot be done whose fault is it?" he never mentioned anything like that to me.


Edit: Also I think it's worth mentioning that this was a paid job and I paid him $100 ($135.52 AUD)

 

Do you have the right to demand that your clothes match? do you have the right to demand your car take an entirely new form of petrol? No. You have the right to buy or get a refund.

You can't demand because you know what you are getting. What you are getting is clearly spelled out on the tin. But it does not hurt to ask. If the asset is popular, then integrations are worthwhile for everyone.

 

Not freezing your X and Z axis was YOUR issue. I did exactly what you asked for in making the arms work with the IK spline and then was entreated to a series of lectures and admonishments that i should dig into the extensive RPG plugin and stop your orc from toppling over. I spent six hours decoupling that subsystem and writing you a new script. Your post is disengenuous. I had kept this anonymous and since you played this gambit then it is my move. Now it is up to mods to decide to lock this because it is no longer in abstract theoretical territory.