Do you compile your Unity asset store scripts into DLL format?

Just being curious. To those that are selling assets in the Unity asset store - ones that have C# code in them. Do you compile your code into a DLL format? I'm making an asset currently (I'm gonna be selling it) and I'm considering whether to have some of the code compiled into a DLL file or should I just keep it all in the original format.

 

We have a policy of never buying any assets where we can't edit the code, since that means we can't fix it if anything's not working the way we need it to.

So that's a vote against .dll.

 

Some authors go as far as running obfuscators on their DLLs. I have a certain 3rd party taking 1.5ms of our frame time on Switch and can't do anything about it. It's widely used and from a reputable developer to boot.

Also, precompiled DLLs will usually be built referencing specific versions of Unity's built-in DLLs, which can cause problems when you use a different version than the one the dll has been built for.

 

I only distribute source code in my assets for reasons including what @Baste said. I won't punish my legitimate customers because of potential piracy

Some publishers don't however and only distribute dlls (or have a separate license for source)

 

Like mentioned before in the thread, I too will never buy an asset that doesn't come with source access.

 

But you have no problem paying money for a Unity license, while Unity is closed source as well. So tell me why is it not right for asset creators to protect their intellectual property, and for Unity it is? Just a sincere question.

 

I give absolutely zero F***ing S***s about the IP rights of anyone. I'm buying a product from someone, so I only care about my return on investment. And getting source code access increases that by a lot.

If we have source code, we can change the product in order to fix bug, add features, or change how it works. There's also a lot less risk of suddenly having to throw away the package due to critical bugs we can't work around.

So the cost/benefit ratio just plummets once the code is in a .dll. If the package author says "buy what about my IP rights", well, that's not my problem.


People can put their stuff in a .dll if they want to, but then we're not going to buy it unless it's absurdly useful, so something like Unity.

If we had the time and resources, we'd be running our own engine instead of Unity, but we're an indie, nobody's written an engine before in our company, and we need to eat, so that's out the window.

 

Unity has a far lower risk of being abandoned. A not insignificant percentage of the assets I have bought over my eight plus years with Unity have been abandoned and will receive no updates. A handful of them were only available in DLL format and will never be viable in a project again.

 

An asset is also in 99% of cases going to be easier to modify to suit your needs than trying to modify Unity

 

Unity has plenty bugs and you can't fix them either, you have to file a bugreport and hope for them to solve it in a later release. Also, you can't know whether something is useful or not without trying it and possibly lose some money. Sure there are incompetent creators, but to put them all on the same pile is ridiculous.

 

I'm generally not a fan of DLL either, but I'm not entirely against it either. If the creator has a solid reputation with good support, etc I can live with it. But generally only get non-DLL if I can.

 

Unity has a far greater chance of fixing bugs too thanks to having a far greater amount of resources. Worst case if they do abandon an approach they tend to eventually replace it with something greater. Enlighten is deprecated but we're getting a replacement soon. Unity UI is being replaced with UI Toolkit. Built-in rendering is being replaced with the SRP.

There is a massive difference between trying an asset out only to discover it wasn't the one, and investing in an asset only to have it become abandoned mid-development. In the latter case you're forced into a situation of either ripping it out if you're even able to do at that point, or hoping it doesn't break over the lifetime of the app.

And if it does break hoping that your audience won't abandon you while you try to create a workaround and/or rip it out.

We're not placing them in the same pile, nor are we saying anything about competency. Assets become abandoned for many different reasons. We even had a thread recently where authors chimed in with the statement that it's simply not viable for them to support their assets over a long period of time.

https://forum.unity.com/threads/why-are-there-so-many-abandoned-packages.869881/

 

You should provide source code.

Look, if it is C# dll, people will be able to extract code out of it anyway.
DLLs only makes sense if you're relying on machine code developed in C++.

 

Having Unity itself being closed source is already a huge pain in the behind, piling on even more closed source on top of the project is something I would rather avoid as much as possible. Charge a higher price for source if you must, as many "Pro" versions of assets do.

Also, a lone asset developer is completely different than a fully fledged company like Unity. A single developer usually has less resources to test things across different platforms and the chances of life getting in the way and disrupting (or ending) development are much higher.

Personal anecdote:
A while ago I was working on a multiplayer project using a plugin called Photon Thunder. As the name implies, it was made by a reputable developer with a long and nice track record. Midway through the project, they simply discontinued the product all of sudden. We were having several problems getting it working correctly on PS4, documentation got us nowhere. The only way we managed to avoid a complete rewrite of our entire multiplayer code was by de-compiling the Thunder DLLs to fully understand what was going on.

 

DLLs should only be used for technical reasons, not as a means of obscuration

I am an asset publisher who is very much against DLLs, none of the points anyone is making are attacks on publishers themselves, just the nature of the situation

 

Compiling and obfuscating a DLL does not protect your IP at all. People can simply upload your DLL to one of the dozens of asset sharing sites out there. All you're doing is punishing legitimate customers.

If your concern is other people taking your source and uploading it to the Asset Store itself, I'm not sure. Is that actually a thing?

 

Please don't do this. The Asset Store has issues with assets you've paid money for being deprecated and requiring the purchaser to self support. That's fine, as the seller has good reasons I'm sure, but when you compile to DLL instead of providing source you make such self support impossible.

Additionally, the Asset Store rules technically don't require the seller to offer much if any support even when not deprecated. I've often fixed bugs in assets I've purchased, and then forwarded the fix to the seller. I can't do that obviously if I can't see the source. If I notice an asset uses DLL's I generally will not purchase simply for the self support reasons. It would have to be very cheap and basically a must have asset for me to consider otherwise.

 

Another vote for I will not buy an asset that is in DLL form.

 

My favorite way of handling this (as a consumer) is what Sirenix does with Odin: Distribute a DLL for efficiency and offer source as an optional download. Best of both worlds.

 

Putting it up for sale isn't quite the same as selling it

Most assets don't sell much:
* not having source means less people will buy it
* not having source will mean you get many more support requests
* not having source will mean people raise 1 star reviews because they didn't realise it doesn't have source
* not having source will mean people raise 1 star reviews when they find bugs or can't customise and you don't address their requests immediately (hours)
* a few 1 star reviews on a new asset and its dead and almost impossible to recover

Unless your asset is mind-blowingly good it will be completely killed by not having source.

---

Unless you mean what @JoNax97 mentions in which case sure, its not a bad way to do it.

 

I'd put in another vote against no source. Very rarely have I encountered a code asset and not had to at least look at the code for some self-support, as well as sometimes making updates myself.

 

You can compile it to DLL as long as you also provide the source code. (Obviously it's just me, but I do not buy any assets without source code.)

 

What benefit do you think a .DLL would provide, @Quickz ? As far as I'm aware most of the benefit of using .DLLs can be realized using ASMDEFs, without restricting access to the source which leads to the downsides people have mentioned.

It's not a matter of whether or not it is "right". It's a question of what's practical, and where the risk is.

Unity is already one giant dependency which we're relying on a 3rd party to look after. That already comes with some risk, as you rightly point out. However, we multiply that risk every time we add another 3rd party dependency, because we now need multiple things to all play nicely with Unity and with each other.

Plus, it's reasonable to expect all of the 3rd party stuff we use to play nicely with Unity because, as Unity assets, they wouldn't be fit for purpose otherwise. But we often need more than that, such as integration with custom workflows (game dev often involves creating custom tools) and potentially with each other. Source access potentially helps with that, too.

 

Because asset creators are not as big as unity. If you're a multi-million or multi-billion company with a hundreds of employees, then it is possible to put up with having no source access, as it is more likely that developer won't vanish tomorrow without a trace.

For everybody else, the creator will eventually go mia, the dll will break, and without source code access you'd need to either resort to reverse-engineering or write your own replacement. And this is not something I'd personally want to deal with. The purchases are supposed to save time and not waste more of it.

Then there's a matter of dll being less flexible. For a simplified example, if you make a dll that loads something from file and accepts filepath, but I want to feed data from a memory buffer, that can be solved with source code access, but will be a hassle without it.

Also, there's already protection of your intellectual property. Because asset store license forbid redistribution of derivatives. The assets are proprietary. In case the agreement is breached, this is a matter to be settled in a court. And trying to make life harder for people who are not planning to pirate your product does not create favorable impression.

 

In my experience asmdef based code still seems to perform much worse (compilation) than precompiled code

In theory they should be the same, so either I'm seeing something inaccurate or the asmdef implementation is less than stellar