Visual Coding (Playmaker, Universe, uScript) and one confused newbie.

News & General Discussion
1

I have spent the last few days reading about all three of these and even downloaded and messed with one. However, I am so confused! I understand what they do…but I am confused for other reasons.

  1. Why does Playmaker have such overwhelming positive 5/5 star reviews? I hear nothing but amazing things about Playmaker, and no review lower than 4/5 stars. Almost all reviews are 5/5 stars and positive praise. The reviews alone make me think that I don’t want want this, but I need this!

  2. I want to learn how to program (I’m already familiar with the basics and a bit more) and learning Unity Scripting is important to me, as I want to make multiple (types) of games in Unity3D. I plan on using Unity exclusively. Would using any of these 3 cripple my learning process, or enhance it? I am certainly not intimidated by one being “more difficult” or “complex” than the other. Utility and Power, as well as Ease of Use Time Saving are important, not any learning curve which IMO is always flat for me.

  3. I am sure I will need to go beyond what any of these three can do alone (create my own scripts) and have heard these plugins can make very good use of that. However, I have also heard that it really isn’t necessary, and can actually slow you down sometimes. That these “visual coding” plugins are for people who do NOT want to become programmers or create their own scripts. They are tailored towards non-programmers, although I have heard a lot of arguments pro-programmer. I want to make things easier on myself (time saving, NOT learning difficulty). After all, I use Unity3D to prevent the recreation of the wheel.

Every professional programming book I’ve ever read repetitively states that there would be much more progress in programming if coders would stop recreating the wheel over and over. Every indie and AAA developer I read articles over or talk to always wants to do it the hard way and “do everything themselves” even the code which has been done and redone so often that newer languages don’t even require the code specifically anymore! I don’t understand these people, and find the time wasting to be incredibly insufficient.

So as a self-learner of programming and game design, I do not care about learning curves or difficulty, but entirely DO care about saving time, and being as efficient and organized as possible. After all, I’m German, and we’re known to be efficient! :stuck_out_tongue:

2

If you are german and efficient, wait 2 months and jump into Cryengine:smile:.

3

Will cry engine be in german only? :-0

4

If you want to learn how to program, then I don’t think it’s a good idea starting with a visual tool; it will not teach you much about programming.
I started by looking at other people’s code and making changes to see what happens.
Next, pick simple tasks, like popping up a menu when your character walks up to a building or something.

With regard to "much more progress in programming if coders would stop recreating the wheel over and over. "
This is true. I tried to make my own game from scratch and it took ages just to get a terrain and a vehicle working - and that’s with no special effects or level editor.
If there are tools out there that will speed up your development, use them. Why spend years writing an engine only to end up with something almost as good as unity?
If it will save you time or money to purchase an engine or plugin, then it makes sense to do that.
Any unique features will have to be done by you - if you find it quicker to use a visual tool for coding then use one, but if you’re planning on becoming a programmer, then they will probably only hinder your progress and limit you.

Basically, start simple and move on when you feel limitied by your environment.
There will be big limits on using a visual scripting tool and the product will not be as efficient as custom code.
Unity as an engine has very few limits, especially for a small team and you whould be able to go far with it.

5

Programming is telling the computer what you want it to do. It’s translation; nothing more. As long as you can grasp the basic concept of cause and effect, and can understand how computers “think”, the programming itself becomes downright trivial. Most of the real work is deciding exactly what you want the computer to do, and how to express it using the medium you have chosen to communicate your requirements to the computer.

Absolutely none of the above absolutely requires the use of a traditional programming language, any more than manipulating files and folders on a computer absolutely requires typing obscure instructions into a command shell like BASH or MS-DOS.

Whether you tell the computer by typing your instructions out letter by letter into a text editor, or by (re-)arranging visual representations of command blocks, the difference between these two methods is merely one of interface design, not function.

If you’re after a learning tool, there’s no reason at all to dismiss graphical tools.

6

Believe me: So many people just fail in this :slight_smile:

That said, I never fully understood in which way the different visual programming tool can help you until I started constructing my shaders with such a tool. Unfortunately, many visual tools just “look” as difficult to me as might programming be for others. In my case, I might be faster coding the stuff than searching for how to achieve the same with a visual tool.

7

You are German?
Why in the blue hell did we talk in english then Lol

8

I agree wholeheartedly; if you don’t have the potential to be a programmer, you won’t be able to use visual tools either, and using visual tools can help you learn the logic of programming without having to worry about spelling everything right and knowing all the commands.

Whenever somebody asks me what language I know, I think to myself “does it really matter?” All languages have basically the same constructs; it’s the APIs and libraries that are important. The only language I’ve tried and failed to learn so far is Erlang, and that’s mostly because I have no use for it. (And I simply cannot fathom the usefulness of a language where variables’ values cannot change, but that’s another topic…)

That said, written code is much faster both to run and to write and even remotely complex algorithms will get unmanageable very quickly in a visual language.

9

Clearly every possible programming tool—regardless of interface—has been invented, and there is clearly no greater programming nirvana than the written programming languages currently in vogue. Heaven help anyone working on a voice-recognition programming interface, or one built around motion detection; they’re clearly doomed before they even begin.

To quote Wikipedia: “[CITATION NEEDED]”

In all my years in IT, I have yet to see so much as a single, compelling, piece of evidence for your assertion. Human communication is mostly visual, not verbal; it makes no sense to dismiss visual media as a valid form of communicating with computers.

That the various graphical coding add-ons for Unity are still a little rough around the edges (although some are already being used successfully in commercial Unity projects) is hardly surprising as none are more than about six months old yet. Not even Unity v1.0 was perfect.

10

Visual Scripting tools help BUT they are not as powerful as good old fashioned Coding.

11

While I have no idea what future innovation will bring, setting up 3 arrows and 4 nodes to add X to Y seems backwards.

12

When I was starting to learn programming in 90’s first thing that we learned was to draw an algorithm. To make the program flow on the paper by nodes and lines. And only after that we were allowed to make a code ( FORTRAN, Pascal, or anything else).

So I really don’t understand why some people are against visual programming?
For me it is one step less. I just make an algorithm and that’s it. I don’t need to type the code at all !
So learning the visual programing is learning the real programing. After you have an algorithm you can translate it to any coding language easily. Or somebody else can do it for you.

@andorov maybe only the first time you have to make 3 arrows and 4 nodes for adding two numbers, after that you could make a new node for that function, so you can reuse it million times after that. All programming languages where made like that. After machine binary language they made some routines for common operation and assembler was created, and after that common operation in assembler where grouped together to make higher program language function and so on…

But the first thing you have to do is to draw an algorithm, and the visual programing makes that the only thing you have to do :slight_smile:

13

I can recommend to use both. My experience is that visual programming languages can create prototypes much much faster then you ever will with a text based language. The downside can be code readability and flexibility, the upside is that you can’t make syntax errors and can see the flow of the code visually. What I mostly do when I code at home (at work I only do C#) is code things first in Vizio to make them work test and tweak gameplay. And when the prototypes are done and working I set up my classes and start filling them with C# code to make the final product.

If you want something done fast and test out ideas visual programming is the way to go.
If a game grows really big 10000 lines or more code you are going to want maintainability then I suggest the traditional way.

Neither is wrong or right both have benefits so I suggest you learn both at the same time and the one thats best suited for you and your purposes will probably be the one your going to use the most.

cheers!

14

I was looking forward to trying visual coding, but now that it is here in Unity with 3 different addons, I am really struggling to get it. Maybe text coding is better for some of us after all!

15

I stand by my statement and do not disagree with “Programming is telling the computer what you want it to do.”

To explain my stance by means of an example:

If you want to learn HTML, a visual program that does the HTML for you is going to limit you to the syle of HTML that that program produces and you will not be able to learn anything beyond that program’s limitations.

You are always limited by your development environment. By using a visual tool, you are limited by what that visual tool can do.
By actually writing the code, you are only limited by the engine.

Untimately, it’s up to you to decide.
How much do you want to learn, what do you want your limits to be and how efficient do you want the results to be?

16

This is an awfully hostile post for mostly agreeing with me. I spent my whole post defending visual scripting as being roughly on par with code scripting. In the part you quoted, all I was doing was stating that coding is still useful.

To clarify, I have used visual scripting languages before, and every time I’ve tried to implement some sort of semi-complex algorithm, my nodes wind up sprawled all over the workspace, connectors overlapping in a spiderweb of nonsense, and I’ve wound up wishing I could just go type in what I mean.

17

I wasn’t criticising you, personally. I was criticising the specific assertion you made. To wit:

You provided absolutely zero evidence for this.

  1. There is nothing inherent in graphical programming that makes it inherently inefficient—certainly no more so than any traditional programming languages. Nothing. Nada. Zip. In fact, most compilers spend a lot of time parsing all that text you’ve typed in and turning it into glorified node graphs!. Most graphical programming is therefore removing a stage in the process of communicating information to the computer, not adding one.

  2. Not all visual languages have been invented, so it is impossible to make any assertions regarding how difficult it will be to represent “even remotely complex algorithms” in them. I’ve said it before and I’ll say it again: 3D will help. As will touch-based input. You can move a lot more stuff around, and more easily, with a multi-touch display on an iPad than you can with a single, mouse-driver, pointer on an ageing WIMP-based GUI. You ain’t seen nothin’ yet.

I agree with everything else you wrote, but you effectively undermined the entire argument with that assertion. It has absolutely no basis in fact.

You’re probably doing it wrong. Subgraphs are the procedures / functions / methods of graphical programming tools; use them to break down your algorithm and reduce the graph’s complexity. If you have a messy graph, it’ll be just as messy in code. Spaghetti code is spaghetti code no matter what medium you use to write it.

There will always be a role for textual tools—especially for low-level coding where you need to control every tiny detail, but I don’t believe such low-level coding is necessary for 99.999% of Unity projects, most of which will only ever require FSM management and a little glue code.

18

I assert that it wouldn’t take long of trying to find random widgets in a list of 500+ api’s, before I was shaking my first at the monitor screaming, “OMG what can’t I just type SCREENTOWORLDPOINT already?”

19

at least in uScript you can do that through its filter, don’t remember if Universe could do so too, haven’t touched it for 3 weeks due to the work I’m on

20

Forgive me for not providing evidence… it’s based mostly on personal experience (and most of that experience is Kismet in my brief investigation of UDK; I sincerely hope that Unity varieties are better than that mess). However, I will explain my conclusions; maybe you can inform me if the situation has changed since I last dismissed it?

Maybe visual languages aren’t much faster than interpreted, but against a compiled language (such as UnityScript, C#, and Boo. Yes, they’re compiled… sort of) they don’t stand a chance.* That said, with computers themselves as fast as they are nowadays, it doesn’t really matter.

Faster writing of code is really the point I wanted to make. Imagine a statement like this:

transform.velocity = Vector3.Lerp(transform.velocity, (destination - transform.position).normalized * Speed , 0.1f);

That’s not even that contrived. That’s a simple matter of targeting a destination with a smidge of velocity smoothing. (OK, I’d usually break that up into a few more lines in real code so it’s more readable)

With a visual language, you’d need at least 10 nodes for a direct translation of that using a system like Kismet. Admittedly, I don’t know much about the Unity varieties and they probably have some shortcuts and pre-built nodes that do a lot of boilerplate work for you, but imagine something more complex. Try an A* pathfinding or Markov predictive algorithm in a visual language and I’m quite confident that things will get out of hand really quickly. If not, I’d love to see your graph.

And what do you mean that FSM and glue code is all that Unity projects need? I’ve spent most of my time in Unity coding player physics, AI, GUI, etc. I’d really hate to do most of that in a system that even remotely resembles Kismet. Especially player physics. Do 99.999% of Unity projects use Character Controller prefabs?**

*Barring the invention of a compiled visual language
**Quick tip for getting people to take you seriously; don’t pull numbers and statistics out of nowhere. I’m not criticizing; I do it, too, and then I stammer like an idiot explaining that what I really meant was a vague “vast majority”.