Should I soley focus all my development efforts on Unity C# Scripting Language?

I was considering splitting up time from using visual code tools such as PlayMaker and such. And combine them with my C# scripts.

And then today I just realized how powerful scripting is when I passed a method inside of a player class which was assigned as a component to a player game object class as a.... member class? anyway im no coder but this got me thinking how insanely powerful this is:

Code (csharp):

1.  
2. var somevar = whatever;
3.  
4.  
5. GameObject blah = new GameObject("Blah");
6.  
7.  
8. Blah.AddComponent<some_class_Script>();
9.  
10. Blah.GetComponent<some_class_Script>().<some_variable> = Blah.GetComponent<some_class_Script>().MethodCall(somevar_passed);
11.  
12.  

edit: (addeed code tag)
returning this new <some_variable> inside this game object blah as a variable created within this other class manager class.

I mean this is pretty intense stuff. And I only just realized it. But now I just realized how... garbage my visual scripting tools are?????

If someone could let me know what the right way to manage my time (limited) would be when using Unity i'll just focus on C# scriptingm 10000% instead of wasting any more time hitting my head over the specific ruleset usages of various visual scripting tools.

Thank you...

 

Code (csharp):

1.  
2. var somevar = whatever;
3. GameObject blah = new GameObject("Blah");
4. SomeClassScript script = blah.AddComponent<SomeClassScript>();
5. script.someVariable = script.MethodCall(somevar);
6.  

You are right, it is powerful, but to get it straight, stop thinking of everything together, but start thinking in terms of objects.

I simplified the script by thinking of script as the SomeClassScript, instead of going and getting it 3 times.

 

Code is far more powerful than visual scripting, absolutely. Even the makers of the visual scripting tools will tell you exactly that. (After all, what do you think they wrote their tools in?) This is not in question. Possibly one day, someone will invent a visual scripting "language" that can match the power of code, but we've never seen such a tool to date.

There are different levels of scripting power and ease of accessibility required for different tasks. For all your core functionality, you should definitely use C#. The core functionality needs to be efficient, precise, durable. But when you get to the point of, say, defining the behavior of one level's turrets? That may well be a task more suited to visual scripting, especially if you are partnered with, say, a level designer who's not a programmer, who may want to modify this behavior.

Right tool for the right job.

 

Hmmmmm, so the declaration of SomeClassScript script turned it into an object versus being grouped together? I want to come to understand this point better. Thanks.

So I shouldn't use visual scripting tools except for the management of coded behaviors? Maybe I dont understand their use. Perhaps they are just finite state machines for my coded logic?

 

It's always an object. Each time you call GetComponent<SomeClassScript>() you are telling the computer to get the object (and it's being returned), and then you are running some logic on it. What @bigmisterb did was store this returned object in a variable, so that instead of the computer getting it multiple times it only needs to do it once.

Code (csharp):

1. var somevar = whatever;    // Make a new variable and store 'whatever' in it (could be a number, a word, etc)
2. GameObject blah = new GameObject("Blah");    // Make a new gameobject named Blah.
3. SomeClassScript script = blah.AddComponent<SomeClassScript>();    // Add a component of type SomeClassScript to blah, and store a reference to this script in the variable script
4. script.someVariable = script.MethodCall(somevar);    // Call the method MethodCall on script, passing in somevar and storing the result in script's someVariable

Above is an annotated version of big's script. If you're looking to learn scripting, Unity has a bunch of really good intro tutorials on it.

Use whatever tools get the job done! And above all else, always use [ code ] tags.

 

There are many difference ways to use or not use tools like this, and no one strategy is going to be the "best" for everyone - you'll just have to feel out what works best for you and your project.

 

I have used PlayMaker extensively, and mostly as exactly that. A finite state machine for my own code.

Eg: I can make custom FsmStateActions. I'll make one that takes a parent NPC and make it walk around. Or search nearby targets and attack, Or run away. The walk, attack, and retreat actions are all my own C# code, but it becomes super easy to create new behaviors for enemies just by swapping around states and transitions.

 

In 1979 I was elated to see my computer print my name on the screen 10 times because I told it to.

Once that lightbulb turns on, you can never turn it off!

 

Hell yes...

 

I also want to add... if you're a proficient C# programmer, there are C# jobs out there that don't even have anything to do with Unity.

I would only suggest programming as a career if you can enjoy looking at code for hours upon hours at a time though! Otherwise it'll be a life of frustration.