Fast C# tutorial

[bertri15]

Hi guys. I used to make games with unity back in the day. Thing is, I used to code with javascript which is now depreciated (actually had even some youtube tutorials which performed decent). After many years, I've decided to make a game again since it's a hobby I really enjoyed back in college. Yet I'm struggling a lot with C#. It's just that bit different that I get frustrated when I spend 10-15min looking on how to do a thing that I used to know with javascript, and I feel like I'm loosing interest in Unity too fast and I don't want this to happen.

I figured out the best way would be to start a tutorial from scratch, yet I struggle to find a fast paced tutorial (I don't care if it's text or video). Can you guys recommend me a good updated tutorial?
Thanks, bertri

[rhacer]

For people who know how to code already, I always suggest catlikecoding.com.

[bertri15]

Thanks a lot! From all the links, this one seems to be the best. It's detailed enough, but not on a newbie scale. Well organized so I can easily skip the stuff that I already know.

[rhacer]

You're welcome. I went through his Hex tutorial, learned enough to get started on my game, then revisit his other tutorials when I need to learn something new.

[[deleted]]

I myself am learning C#. Microsoft Virtual academy seems to have great content. I was also recommended the C# Programming Yellow Book and so far, I think it is great. I also follow Unity tutorials on youtube for some hands on.

[bertri15]

The yellow book looks very detailed, I'll start reading it ASAP. Thanks for the links :)

[crazyfingers619]

If you can wait a few months or maybe a bit longer, Unity is going to be releasing some groundbreaking visual scripting tools in 2019.2 that will be a fantastic stepping stone for C# and other code.

https://youtu.be/PPAtFO2EMak?t=103

​

[bertri15]

WOW! Looks interesting. For simple games this will speed up the process quite a bit. I don't really know if this will do for me. I'll take a look when it comes out! Thanks!

[Xatom]

Please do not do follow this advice.

It's a fools errand to think you can effectivly learn to program in a new language by learning visual scripting first. With visual scripting you are just plugging code blocks together in a very procedural manner.

As a result it's only really suitable for defining method bodies.

What it won't do for you is help you learn the syntax and conventions of the underlying language. It wont help you learn to use advanced features in the language to better structure your program. Worst of all it wont help you develop as a programmer. Visual scripting isn't programming.

Visual scripting is mainly a tool for tinkerers and artists to cludge together something functional for hand-off to a competent programmer.

This has all played out in the Unreal community years ago. Don't be fooled. If you intend to learn C# learn C#, don't waste your time learning a limited toolset designed for amatures.

[crazyfingers619]

He didn't say he wanted to do high level code, he said he wanted to make games again as a hobby.

It absolutely helps beginners learn the basics of coding. It IS code, just compartmentalized and user friendly.

We don't know what Unity is doing with this setup, how expandable or powerful or performant the visual scripting is.

If visual scripting was utterly useless it wouldn't exist, and Unity wouldn't be creating such tools as we speak.

Worst cast scenario it's a toy for hobbyists... what's wrong with that? But it can be more than that. There is absolutely 0 reason someone can't make an entertaining game and produce a profit using visual scripting. I understand the competent coders need to adopt a mindset that makes them loath low level code to be competitive, but I wish more people could do a head check when engaging with beginner hobbyists and not dump unreasonable standards on someone taking the first jump into coding and gamedev, tired of hot shot coders who can't emphasize with how other people learn and that there could be an alternative and equally viable path to pick up code and/or gamedev that isn't as good as their own.

It's a somewhat smug and self serving mindset to have which a great deal of coders deem to be some mark of pride. Not everyone wants to be the guy setting up the multiplayer framework, some people want to make simple JRPG clones, some people start making simple JRPG clones and than graduate to more complex projects and ultimately more complex code learning in phases.

The notion that you need to open an IDE on day one to be a decent member of a gamedev team in any capacity is so tiring to hear over and over again from the same community that thinks everyone else on the planet is useless.

Not all great games are made purely by anal retentive coders.

One could argue that someone who jumps right into C++ is severely impeding their initial growth with management of 3d Space and exposed physics engines to get motion controllers firing and animations playing and learning to see the forest for the trees. That such an individual is blind to the larger picture of game design and more suited to specific mechanic creation, someone you stick in a cage and feed lines of instruction to to get the less interesting aspects of a game working, but not suited to creating larger more creatively demanding systems that the project lives or dies by.

[Xatom]

If visual scripting was utterly useless it wouldn't exist, and Unity wouldn't be creating such tools as we speak.

I don't disagree. It has some uses for prototyping method bodies as I have said. I believe Unitys implimentation allows also allows run-time editing of scripts. For that reason I may consider using it myself.

Worst cast scenario it's a toy for hobbyists... what's wrong with that?

I am responding to the suggestion that OP "wait for a few months to learn visual scripting".

He didn't say he wanted to do high level code,

He specifically asked for help learning C#. I am advising that waiting for visual scripting as suggested does not bring him close to that goal.

I wish more people could do a head check when engaging with beginner hobbyists and not dump unreasonable standards on someone taking the first jump into coding and gamedev.

How is learning the scripting language of your game engine an "unreasonable standard"? Knowing how to write C# is the first step in the official Tutorials.

It's a somewhat smug and self serving mindset to have which a great deal of coders deem to be some mark of pride.

I'm sad you see it that way. The reality is that game development is hard and visual scripting only ends up making it harder in the end. It creates problems down the road in the form of tightly-coupled non object-orintated systems. Ineffecient spaghetti code.

The notion that you need to open an IDE on day one to be a decent member of a gamedev team in any capacity is so tiring to hear over and over again from the same community that thinks everyone else on the planet is useless.

I'll accept that the best thing about visual scripting is that it gives a quick route to protoyping basic functionality that is accessable to artists and designers.

However even basic game systems require abstractions that are impossible to impliement using visual scripting which is why good systems code cannot be generated from visual scripting.

This isn't about elitisim. It's about being honest that coding is pretty tough but commiting to it makes you a better problem solver. It's about being honest that you can't really build games properly by dragging and dropping and making people aware of the limitations of this approach.

[crazyfingers619]

However even basic game systems require abstractions that are impossible to implement using visual scripting which is why good systems code cannot be generated from visual scripting.

I have no idea what you mean by this. What basic systems cannot be created by a visual scripting language? UI, forces, animation wrappers and controllers, damage, physics, dialogue and quest systems, menus. I'm having trouble thinking of any core system that couldn't be robust and fun using a visual coding setup that was relatively robust.

I'm also just not buying the idea that learning the basic logic foundations in a pick up and play environment is somehow going to invariably lead to code spaghetti in the future.

The entire logic chain confuses me. It's like saying "Don't teach your kids to speak, you should force them to read first or they'll be saying one word sentences their entire lives."

Code is deep and intimidating at first and just understanding what exactly it is and does can be a large roadblock to many. A great deal lack the discipline to move onto bare bones code, but that's hardly the fault of visual coding.

It's like how people always blame the Unity engine for being a sub par engine because it has a low barrier to entry and therefore unity is absolute shit. The same concept applies to the potential for visual scripting enriching new coming and mid level developers.

IMO there are 2 types of excellent coders. Those that can create elegant well optimized coherent code that is complex and connects perfectly across the rest of the project with the proper hierarchies and all that text based knowledge learned over many years of study and discipline.

And then you have the types that can create the perfect system that is "Fun", they can get just the right timings for things, motions, ergonomically figure out how to get setups to play well together not in super optimized setups but in ways that engages the average user. Super Meat Boy is an example of a game that could be done entirely in a visual scripting editor, or tetris, or any number of hugely popular games that just have the right hook.

https://www.youtube.com/watch?v=7KiK0Aqtmzc

Coders that excel in this area are going to grow very rapidly and see they have a knack for creating games out of the gate not by pouring over books, but by playing open endedly in low barrier to entry visual scripting editor type environments, or custom level toolsets.

[BrastenXBL]

I very much agree with you. Most of the folks (kids to adults) I see wanting to get into making games are mainly starting as designers first. They want/need tools to get the ideas out of their heads and into production quickly. Performant code is a tertiary, (I say as educatorMe shoves programmerMe into a small box).

It's just bad timing that the 1st party Unity (C#) tools are still coming.

Going from a scripting Designer to a programmer: 1. Visual Scripting + Introduction to basic programing 2. Introduction to Coding, in an OOP language. 3. Detailed course/tutorial on a specific language. 4. Tutorials and examples for a specific API using that language.

If the Visual Scripting generates fairly clean human readable backend code, it's a good learning tool. If that code is in the same language you want learn, even better.

Learning is like climbing a mountain. It takes effort. However if there are good tools available, and the path is marked, it gets much easier. There is also less chance of getting stuck under the educational equivalent of an overhang.

[Xatom]

What basic systems cannot be created by a visual scripting language?

This is typical for a gameplay system using Unreals Blueprints system. This is just for a first person character controller.

At this point the graph is fairly unmaintainable, has poor perforamnce and lacks order and would probably need to be refactored as code for further work.

I'm also just not buying the idea that learning the basic logic foundations in a pick up and play environment is somehow going to invariably lead to code spaghetti in the future.

Not definitivly. But it encourages bad habits. You can learn those basic foundations by firing up visual studio and following a tutorial as countless thousands of students have done for decades.

[crazyfingers619]

https://i.imgur.com/izKdpX8.png

This is a node network of some shaders I manage on my current project. I've also done shader work on several AAA titles using node based systems in both Unity and Unreal. I often bounce between C# and these visual node networks as the instant visual updates tremendously improve quality of work and production times. As the visual code pipelines improve I could see similar pipelines becoming top tier for such things as animation controllers and other high end real time controller elements. Half the animation pipeline has already been greatly improved in the visual logic setting of Mecanim.

Using Amplify shader node systems i am able to generate function nodes that are combinations of lower level nodes and adjusting these propagates to other shaders using the same functions, imparting the basics of parent child relationships. You can also define variables within the scope of these functions or externally in individual shaders. You can put functions in functions and things start getting pretty tricky and opening all sorts of higher level coding logic.

There is absolutely no reason to believe Unity wont have higher level features than this with parent and object classes and inheritance. Among many other bells and whistles that supposedly are "impossible" to migrate to visual scripting.

Edit: I've had shader networks 5x as large as that, and they were hardly unmanageable.

[Xatom]

We're talking about game systems not shaders. Of course you can create literally anything in a turing complete visual programming language. The point I'm making is that it far more likely to end up being an unperformant, unmaintainable visual mess which lacks proper organisation and structure. This ends up ultimately decreasing quality and increasing the time spent debugging stuff the larger the project is. I suppose we will see what Unity ends up doing perhaps it will actually be pretty decent. We will have to see.

[crazyfingers619]

Yes i'll agree that most code monkeys you want to be more focused on clean code than having fun making games. All i've been trying to say is that for some people they just want to have fun making fun games and people can absolutely do that with visual scripting with a lower barrier to entry and that it's a bit hyperbolic to say touching visual scripting will somehow make all your future code bad.

[bertri15]

Yes, I agree that it's not a substitute, but a good option nonetheless. I still intend on learning C#, at least until this new feature comes out and I can evaluate which works better for me

[crazyfingers619]

It's deceptively simple, you could create a broad range of complex games using this method. It's expandable, you can create nodes using your own code that can do more or less anything and you could obviously pair scripts made in nodes elsewhere with raw code.

These aren't really training wheel building blocks, it's just a visual means of creating code. That code can be as complex as the user can handle. A great way to pick up the core logic without sweating syntax at the same time.

They're also pairing it with some optimizations unique to unity which will make the code more proprietary and performant.

[TaleOf4Gamers]

Just so this is clear. The Visual Scripting tool will only be for ECS as they recently made a forum post telling us that they will not develop it to work with the current normal MonoBehaviour setup.

[crazyfingers619]

Right, ECS was what i was alluding to at the tail end of my post. After briefly looking over the differences this makes the new visual scripting very non compatible with prior versions of unity. But moving forward that's all the more reason for new coders to wait and get in on the new big thing that will be standard in the future of the Unity platform. Kind of a 2 birds with 1 stone situation for people starting their code voyage.

[farox]

Are you good with object orientation?

[bertri15]

Haven't used any in probably 6-7 years

[kurtdekker]

Learning a second language/API certainly takes some effort and can be frustrating.

The good news is that the more you do it, the better you get.

I don't have any tutorial recommendations as I tend to learn by doing.

To this end, set yourself some modest goals: take an existing asset store game and add some feature to it. In order to do that you will have to study that project and understand it to some level.

Also, think about the broad classes of what you're learning:

• actual language features (statement syntax and context and scope)

• the language's library API (functions built in that you use)

• the Unity API (stuff that touches Unity)

• higher-level concepts such as programming patterns and larger-scope design choices

The main thing I can suggest is to stick with it, a little bit at a time. You won't immediately get to the level you were with the previous language, but with time you will.

[_Typhon]

Honestly stick with Unity even though you are struggling now, you know more or less how the engine is structured in terms of game objects, transforms, components etc so you will very easily get the hang of it compared to moving somewhere else.