visual scipting tools: point of view

hi

i am programmer with like 13-14 years of experience

i'm new to unity and i'm now picking tools for ours project on it. i wasnt even thinking about using visual scripting tools but there is too much hype around them so i decided to research through and am doing it last few days. so have some thoughts on this topic
so they are playmaker, uscript and antares universe

although the common point that i observed was like: playmaker is for non-programmers, uscript is for people with little experience in programming and antares for programmers that do not write code, i now thinking of it little different

start with antares. it looks like it is for programmers that don't wanna write code. i find all this low-level graphs pretty 'ambiguous'. it's like a graphical representation of code. too low level. like code inside functions. considering c# code is perfectly readable, why do you even want this?

next to uscript. with all this global variables, graphs seem ubiguous. and few lines of code became monstrous construction.

the above two seem to me, as i said, more like tools for programmers that don't wanna write code. but i like to write code..

as opposite, playmaker looks like system that represents only high level algorithms, that are hard to distinguish just by briefly looking through code. it helps to better see the system as a whole.
i cant say the first two not giving you the same possibility, but considering the fact that their visual representation is more complex, i find them excessive to use for 'architecturing' the system. playmaker shows you logical blocks, while other too show code blocks, making you see logic through them almost as hard, as isolate logic from raw code. yes, i know they have nesting, but i'm afraid hte use of them may end up in mix of logic and implementation anyway.

so the conclusion is: playmaker is the best for programmer, who is not afraid to write custom code to solve low-level tasks and wanna high-level logic to be represented for easy perception and fast subroutines access

that's it. i may be mistaking, because all i know is taken from tutorials and forum discussions of those three

what do you think? please share your thoughts!

 

thats a contradiction.

personally i think as a programmer it is in our nature to dwell into things, not suggesting that you start on the deep end. Given that you are

, I would suggest to not use any tools at all but to grind into the code and understand the dynamics of how things work which is dependent on how much time you have ofcoarse.

But I would start with some simple games like tic tac toe or follow some tutorials on building from scratch. That way at least you have a firm grounding before tackling on some projects then find yourself being lost within not only unity engine but the tools and can't differentiate what is what.

that's my 2cent.

and allow me to re-iterate

 

the full quote is "the above two seem to me, as i said, more like tools for programmers that don't wanna write code. but i like to write code.."
above two are uscript and antares, get it? ^__^

i've already made a small game. and it's much more complex, than tictactoe. actually it's a demo of our project.
i'm pretty much understand the inner working of unity and how things are done. i've went through and implemented physics, animations, gui, sound, input on mobiles and so on.

that is the case. in the process of writing a demo i always was like: "ok, that's working, but how will it scale?".i understand the level of complexity that is facing me in future project. and i'm convinced that i need tools to make workflow more "disciplined" and, say, modular.

i've used some tools too, just to try them, while making a demo. some of them i liked some i didn't. but that was enough to understand the power they may give. why reinvent the bicycle. tools were written by people, that are competent in narrow area that tool covers mush more than me. i'm not saying i don't want to learn unity inner workings, but opposite. when i learn inner workings i see the opportunities to make work process more comfort and search tool that satisfies my needs. in case of visual scripting tools the point is to build another level of abstraction.

and the quote
"considering c# code is perfectly readable, why do you even want this?"
was about: why do you do simple low-level task in visual scripting if coding them and display one graph node for each is much more convenient for readability and will keep entire scheme more clear?

 

Code can pack a lot of information is a very small space, sorted, and commented. I can write and debug faster code than any visual scripting. Visual script is simply, in my opinion, not for coders.

Visual scripting, for me, is a double edged sword. It makes logic building accessible to non-coder, and it makes logic building accessible to non-coder. The issue is usually that when things go wrong, and they do go wrong, it's the coder who will end up debugging graph nodes, not the designer who built them.

I believe visual scripting should not be used to build new basic game mechanics, but to build chain of events, with or without logic branching in it. We have our own visual scripting system for this purpose; http://i.imgur.com/PmVy1JG.png (because I hate nodes and they always ends up being an unreadable spaghetti)

 

Here's some good info. Lots of other links in IDB's reply on the bottom.
http://forum.unity3d.com/threads/220036-Opinions-Playmaker-vs-Universe-vs-uScript

 

wow, this movra guy is talking exactly what i mean, thanks for link, i have read this thread, actually, but missed movra's comment at bottom


what i'm saying in this thread (and what movra said), i'm disagree with IDB and sicga123
that's the perfect laconic statement, that contains all the sense of my point of view:

 

but some things are better organized with diagrams. more of it, any medium or large scale system is started with drawing those relation diagrams and then coding. so why not draw it in editor and write code for nodes? i also like code for brevity, but it not gives you instant vision over relationships, like diagrams

i think people without programming skills must not be allowed to programming of application in any form.
yes, they may handle simple sequences of events, like cutscenes or simple trigger systems or anything, that has simple frontend which were implemented by programmer. their ideas about logic may be completely perverted, as experience tells me
if you give autocad to painter, don't expect him to invent a machine and make a technical drawing of it

 

Don't get me wrong, diagrams have their use. Mecanim is one, and a good one. Building FX, shader or scripted event are good examples too. However, I truly believe AI, gameplay mechanic and game logic tend to ends up in pain if built from graph. Most of my stuff are built using state machines, which is an easy way to controlling what is currently running. However, who, what and how a state change is often too complex for a graph to properly represent it.

If someone has issue understanding the hierarchy between classes, there's always UML. http://en.wikipedia.org/wiki/Unified_Modeling_Language

The issue is, any complex diagram always ends up in spaghetti. It takes tremendous discipline and effort to keep a graph from falling to entropy. And if more than one individual is editing a graph, that entropy just sky rockets. Something like (Entropy = NumberOfNode * NumberOfUser)

 

I've found AI to be pretty advantageous to do visually. FSMs are quite good for AI considering that you're basically just managing the current state and connecting multiple FSMs, asynchronous communication is trivial. Managing data collection in one or two fsm's and feeding that to one or two other behavior fsm's is pretty successful for me, it segregates the AI, keeps it easy to read, debug and quick to modify.

Poor design will most certainly result in spaghetti and my early attempts were indeed total jibberish and inefficient. Similar to the pitfalls of poor regular code... However finding ways to design clean visual AI has been very rewarding, legible, flexible, and given clean results for me... I have a physics based space flight combat AI totally done in playmaker if you are curious. I personally find it really clean, but maybe we just have different ideas of that.

 

Maybe it also has dependance on the complexity of what you're trying to achieve. In the game I'm currently working on, the player has 22 different states, that can be called from lot of different place in the code. Hell, even the mecanic of that character is on the threshold of spaghettification.

 

thanks, your point is strong and helpful. just don't crush my illusions completely!
i must test this approach anyway ^__^