Does writing an asset in C# carry extra weight?

Okay so I write my stuff in Unity Script because I like it and it’s familiar. I haven’t taken time to learn C# and maybe never will. I often see among various Asset Store assets people touting the technical merits of their tools and saying e.g. “Written entirely in C#”, as though it’s somehow a greater credit than being written in UnityScript. I know there are some differences between the languages and a few things you can do in one but not the other, but is this really such a big deal?

Like if I released a $100 asset and it was written in Unity Script, would it to any degree put people off that it’s not written in C#? After all it’s not the tool you use but how you use it, right? Is this just programmer snobbiness, preferring proper programming languages, and does it really matter to CUSTOMERS at all?

What are your thoughts?

If you want to charge people for an asset you need to support the language they use . I started in US, but C# is my focus now .
The best thing to do is to support both , and for the love of god STATE WHAT LANGUAGES you support . If you sell me an asset and I assume it supports C# and it doesn’t I will be emailing the asset store the next day asking for a refund .

Support C# first, then support US, no body really cares about Boo .

It does sort of put me off personally if I have to interact with it via scripting or is a large package with hundreds of lines of code. But if it is a small art package with 2-3 scripts in JS or Boo I usually either convert them to C# or delete them.

It depends entirely on what you’ve made. The only thing I can think of that would probably put me off buying an asset written in UnityScript is integration with assets I’ve written in C# - getting stuff written in the different languages to talk to each other nicely when there are compile time dependencies can be a mess. But if the assets are isolated components then I’m really not going to care.

Personally, though, I’d rather an asset written in UnityScript by someone who knows what they’re doing design-wise than something written in C# by someone who doesn’t.

In short, the language you choose does not significantly impact the quality of the code.

I am heavy asset consumer and I must say, when I want to buy an asset that I know I will interact through code on many situations, if that asset is JS only I don’t buy it.

So is your preference toward C# purely because it’s the kind of asset that you interact with by scripting? What if it’s not the kind of tool that has any kind of API, like a visual programming system or something where you aren’t meant to use it from scripts? Does it matter then?

It’s possibly a stigma thing too. For the sake of argument, let’s consider US to be JavaScript ( which we all know its not ). JavaScript started as a web scripting language developed at Netscape and was/is a skill often acquired once someone has tackled HTML. It’s possible that a majority of developers coming this route haven’t made the leap into a “proper” language like C#, Java or C++ and might lack an understanding of formal programming concepts such as polymorphism. It is feasible therefore that formal programmers have an expectation rightly or wrongly that there is a greater chance of poorer quality code if something is written in US. It’s code snobbery, and possibly unwarranted given that US adds strong typing. Of course there are OOP features in C# that you don’t get in US, which might rule out an optimal implementation.

Personally I prefer all my code to be in one language in case I have to modify it. There’s just something mentally messy about having code in multiple languages. That said, echoing angrypenguin, I’d rather have well written optimized US than poorly written C#.

If it has any code in it at all, it seriously needs to be C#, a visual programming system needs to allow me to expand it( like play maker) .
Stupidness happens when your forced to mix C# and US.

Who are your customers and how are they using the tool?

I will rarely buy a US asset because I am a programmer and I want to read, modify, integrate, expand etc. the code.

Well put !,

Right now I have an entire project that’s C# inside and out , theirs no reason I’d want to ram US in their .

At least how unity handles them, C# and US are pretty close I took the leap from US to C# a while back and since then its been awesome , Mono dev works FAR better with C# then it does with US. Improve your craft, switch to C# , and then create something that we want to buy

You can read, modify, integrate, expand the Unity Script code too though? Or is it that you just want everything to be C#?

It is a matter of dealing with compilation order of scripts, some times it may became a pain if you mix too much C# with JS/Boo.
If my code won’t interact much with the JS package then I don’t care much about it.

Edit: However, .JS extension makes me triple check who made the package because js code tend to be made by new comers…

Can I?

Sure I’ve experience in both, however:

Reading wise I’ve not got Visual Studio support - so I lose features familiarity there.

Modifying expanding US can be hard because the syntax and features I normally use aren’t available, and the ones that are available can be hard to find documentation for.

Integrating can be quite difficult - as is well documented.

Remember, you’re selling me an asset for $100, but by lacking C# there’s a ‘hidden’ cost of 0.5~5 hours - say $50 to $500. That gives your competition, or even the DIY route quite a substantial leg-up.

Fixed.

Personally, I convert any scripts I buy/find into Boo.

Yeah, but if I’m paying you for something its to make my life easier , mixing US into a C# project will often make things much much harder

The vast majority of assets on the asset store don’t support Boo , its just a fact of life .
I’d actually prefer if Unity made an effort to at least give me all of the built in scripts in C#, having to force US and C# to work together is no fun at all

I won’t disagree. But I’ll find a way to make it work :wink:

Also, if I release an assets (which I plan to soon), it will be in Boo. :stuck_out_tongue:

*Note: I am not advocating OP to write his assets in Boo. Just advocating Boo in general.

I haven’t really tried Boo at all but my impression is it is vastly less commonly used than C# and US, which I admit does make me wary of it. But it seems that a tonne of stuff is done in US, so I feel more comfortable with it. So far what I’m hearing is that if it’s the kind of asset that needs to play nice with other code you’ve done or other assets you’re using, then you may prefer it to match the language you’re using (whether it be C# or US) … but this doesn’t really tell me if C# should be thought of as better… and I don’t want to get into a C# is better than US argument… I’m exploring whether there is perceived weight given in the eyes of a customer based on which language something is written in, and why. I don’t really feel adverse to writing a $100 asset in US, and in some cases I’ve bought an asset which is in C# only and find it annoying that I can’t use US with it… so I guess the best deal would be to write two versions, one is C# and one in JS, or provide some kind of bridge or connective interface between them that lets the two languages work together? How would someone go about that?

That’s why it is seen as not used. But it honestly is the easiest language, and as powerful, if not more so, than the rest. Takes longer to compile according to tests conducted (while not a big deal IMHO).

Learn both :wink: At least for two different scripts. I’m not sure about a “bridge”, as I don’t really care about compatibility with other languages too much. I assume anything written with US is compatible with Boo (as US is made with Boo), but not necessarily vice versa? (as C# nor US supports duck typing, for example.)

There are less transitional issues for a US user to use a C# library/asset than vice versa. Partly because of the build order, partly because they are already accustom to using MD [or other]. That’s possibly why C# is traditionally seen as better for assets.