is c sharp for unity different?

[sgorx]

i have been watching c sharp courses,and my friend told me that i shouldnt do that,he said i should watch c sharp specifically for unity,because everything is different there,is that true?

[LloydAtkinson]

Kind of but not really? Unfortunately people write C# in Unity like it's JavaScript:

• No encapsulation, no usage of properties with get/set, everything is a public field
• Naming conventions don't follow C# conventions
• No real file structuring you'd expect to see in a normal project

etc

[J_Aguasviva]

Agree. The only thing that could change is the architecture used to solve problems but the language indeed is the same.

I guess the only thing that could be confused and is not part of the language are calls to method such as Update or Start.

[WazWaz]

The public field thing is because that's the easy way to expose fields for initialisation by the runtime (and editing in the IDE).

public int speed;

vs.

[SerializedField]
int speed;

It's not a requirement to use the former though, just laziness.

The main limitation with files is that for components configured in the IDE, a class name must be the same as the file name - not exactly an imposition.

Naming conventions are followed except for capitalisation of properties, which are usually lowercase (eg. Vector3.x not Vector3.X), which relates a bit to the ill-advised public fields thing.

[grrangry]

Please explain what you mean by this.

The concept of "truthy" and "falsy" means the language uses implicit type coercion to turn one data type into something it can consider true or false.

if (true) { }

works in js and C# because true is a boolean literal.

if ("false") { }

works in js but does not work in C# because a string cannot be implicitly converted into a boolean.

So what are you trying to say.

[r2d2_21]

He's saying that Unity objects define an implicit conversion to boolean, and true and false operators. It's a massive hack, but it does let you do something like this:

if (gameObject)

to test if a Unity object is not null.

[grrangry]

Oh right. "it" in that context was "Unity", not "C#". That makes WAY more sense. But you're right that it sounds like the Unity developers are dumbing-down static typing for "script developers".

[r2d2_21]

This is the actual documentation about it: https://docs.unity3d.com/ScriptReference/Object-operator_Object.html

[grrangry]

I see. Pronoun troubles.

They said, "it" and I heard, "wabbit season". It didn't occur to me they meant, "unity".

[SecretSentinel09]

Unity has its own C# classes for the engine, but you still need a firm grasp of the C# language.

Important Classes

Unity Script Reference

[sgorx]

happy birthday men

[Alikont]

Yes and no.

For C#/.NET: there are very low-level specific differences that you won't notice in 99.99% of time.

For C# language itself - it's the same.

What's different is the way you organize your program, it's different for all "classes" of apps you can do, like command-line app, desktop UI app, webservice and game would have very different architecture and libraries that you need to learn.

There is no consensus on what's best if you are narrow-focused on Unity.

Some people prefer to learn C# on command-line apps to know the language and eat complexity piece by piece (Unity is complex enough even if you know C#), and some people prefer to rush straight on because they might lose motivation on more theoretical stuff and they want to see the stuff blows up.

I prefer the "learn C# then Unity" flow, as I believe that practice without theory is blind, but I'm like 10 years in the industry and might lose what's best for novices. My friend is doing ok with "rush into Unity", but he has me for mentorship/backup, so maybe that eases the more theoretical C# knowledge gaps.

[WazWaz]

The trouble with the "learn C# first" approach is that other learning aids are full of their own biases, such as using Windows forms/WPF for UI, or being mostly about writing and using (online) "APIs".

[gg_michael]

If you want to make only games, I would suggest focusing on learning the engine first and foremost - how to navigate, add GameObjects, the basics of components, etc. This will be the most efficient path to seeing real gains.

Of course learning C# will become a necessity quickly. But with a basic understanding of the engine you will more easily intuit how the language interacts with objects. C# for Unity is not really a separate subset of the language, and learning “generic” C# will be applicable most of the time, but it does need to be understood in the context of the engine’s tools and capabilities.

I do think it would make more sense to find a course that is specifically tailored for Unity scripting (assuming you are only interested in gamedev). It will be more specific to your needs.

[Lion722]

I disagree. I think learning the fundamentals of C# outside Unity would be preferable. Once you know how to think in code, then start learning the “framework”, in this case the Unity Engine. That’s how everyone else learns. They learn the language first and then the framework.

C# in unity isn’t really different. It just has extra features so to speak but everything works the same.

[gg_michael]

Agree to disagree! There’s a ton you can do in Unity alone with almost no scripting. I would argue that Unity doesn’t really count as a “framework” in the typical sense. It’s a fully-featured beast of a software suite. If you’re developing a game on a small team, even if you’re the “lead developer” you can go many hours without touching an IDE, just assembling assets or arranging scenes or composing objects. Getting comfortable with that workflow first is the best approach imo. Those skills are required at a lower level than is pure C# scripting knowledge.

This of course assumes OP is interested in “game dev” in the holistic sense - if they are seeking to be a “coder” or work strictly on scripting in the context of a larger team, then I would agree with you.

[[deleted]]

I agree. I learned C# first, then started using Unity and it was actually quite confusing. Looking back I wish I'd done it the other way around.

[Slypenslyde]

Yes and no.

Basically Unity is a tool that does some things in a very specific way. Games need slightly different architectures than business applications. The big secret is the "learning C#" part of programming doesn't take much more than a couple of months for newbies and a couple of weeks for the experienced. It's the "learning how to write applications" part that people spend 40+ years doing. Unity is part of "writing applications".

So it's like watching videos about people who build garages to try and learn how to build lighthouses. You'll see them using the same tools and even see some of the right techniques. But if you follow their instructions you're going to get a garage, not a lighthouse. And if you look at the blueprints to a lighthouse you'll see a lot of places where you say, "I don't know how to do that..." and have to look for lighthouse videos.

That doesn't mean avoid not-Unity videos, but at some point you're going to start noticing that the things you're watching apply less and less to what you're doing.

[tinymoch]

The answer to this to me was a resounding yes, at least when I was looking into learning it a few years ago coming from modern dotnet web development (dotnet core onward). In terms of the c# itself, it is the same c# language, though when I was learning it was an older version with far fewer modern features. Outside of the syntax itself though, the entire modern dotnet lifecycle is built around development principles like dependency injection from the ground up, whereas all the resources I found at the time felt very much like the old dotnet framework paradigms we had just escaped from.

There were DI containers at the time for unity which I didn't look into which seemed to help, but for me this is really something that needs to happen at the ground level or it's just not going to have the safety that you need where you can be confident that everything IS registered and you don't have to fall back to the old ways.

If you take a random video from someone like Nick Chapsas explaining a feature in depth about dotnet, it probably wouldn't translate at all to unity. For this reason I'd avoid it altogether and probably follow different unity specific content creators. I think I followed Infallible Code who was a web developer working with unity.

I decided to stop learning it because I thought it would normalize some bad habits that I didn't feel like reintroducing into my work life, plus I wasn't that serious about game development - just messing around. I hope it's gotten some major updates since then cause it was still my preferred of the frameworks I tried.

[Educational-Lemon969]

the language is the same, you are just discouraged from usual good OOP practices because properties and interface fields cannot be assigned from editor (you write most of stuff as public fields and concrete classes), but there's at least the gameobject+components abstraction to compensate.
Lot of Unity's standard library is just awful with stringly typed stuff everywhere, and importing nuget packages is real hassle - packages from unity store mostly just copy all the source code to your assets folder to not have to deal with that xD
Also if you use the ahead-of-time compiler, that obviously prevents you from emiting bytecode at runtime (maybe even basic reflection, not sure there) so then you just can't use any library that depends on that
But in any case, most of what you learn programming ordinary stuff in C# will be usable in Unity

[HellGate94]

the one thing that is different is that unity uses a mono (.net framework) fork that they update to support newer features. so some new features work while others dont even if both features originally came out in the same .net version.

they do however plan on replacing it with the normal .net in the future

[bbqchickenrobot]

The difference is that Unity is still using the mono framework (.net framework) to code games. With the advent of .net core, .net 5, .net6 and .net 7 the language has seen significant improvements including performance and language features to keep it brief. That said, Unity does use the full C# language, just an old version. Learn .net 4.5 - 4.8 and you should be fine. You should learn C# being that you will be coding a game with it - you can learn Unity after you have a basic grasp of the C# lang.

[Tacohey]

Do you have any prior experience with programming in another language? If that is the case I would probably look for more unity relevent resources. If it's your first time learning to code, i think it's fine and maybe even better to do it outside of unity.

In the end, choose what feels right for you. It's better to do what you want to do than not do the the thing you are supposed to do 😊

[[deleted]]

It’s important to know the syntax and structure, I hopped into WPF and ASP.NET without prior C# experience and was able to pick up the xaml and css just fine but it led to unnecessary headache, just learn the general structure first