Playmaker, Vizio Universe, Strumpy shader editor, WTF?

Someone already had this debate http://xkcd.com/378/

Of course, this is where it all began http://www.ee.ryerson.ca/~elf/hack/realmen.html

 

So true.

 

It's perfectly understandable that you may think of uScript as a Kismet clone right now because we haven't announced much information and did focus on the workflow and interface similarities for our initial announcement, but actually uScript is a lot more than a copy of Kismet.

While we made a conscious decision to follow a similar use model and look (based on our goals for uScript and our past experiences developing commercial products using various visual scripting tools over the years on what works for a production team of designers and artists), behind the scenes however, uScript is much more advanced than Kismet and contains quite a bit more functionality.

 

I find that visual editors are quite useful where I only need one hand on the mouse to get things done and freeing the other hand to hold food or drinks. While coding usually get cigarette ashes into my keyboard which is really hard to clean.

 

lmao, brilliant, and so true.

 

My opinion as ex-user of Quest3D and user of Unity from a year ago.
I have no problem by programming in text. Simply find it very inefficient, especially after my very positive experience with Quest3D (may years, doing quite big projects).
For those who prefer text-based programming, the discussion of these tools does not concern them so much. Simply, do not use them, but let us make our mistake.
Instead, those who, like me, we prefer them, we may debate on possible approaches, and hope that the authors of these new tools take account of these opinions.

From this point of view, here are my preferences (in order of importance):

Real time
I do not want to write the code and then press play.
I want to have the result running continuously in the Game view, and the code changes are reflected instantly.
This is a critical point, often neglected (as well as impossible with text-based programming, by the way).

Comprehensive
Absolutely no need text code anymore. This is not just a whim.
Failure to do so, and they have not addressed the visual programing issue at its root.

Clear
Visually designed thinking about the structure of the whole, not the individual nodes and their links.
I disliked the look, a bit austere, of Quest3D, but in the light of these new tools for Unity, I prefer Quest's. The new tools, and in particular Universe, are becoming confusing.
Perhaps the strong structure of Unity (a kind GameObjects oriented programming) may mislead the designers of visual programing tools for Unity.
A key advantage of visual programming is to take a look at the code and recognize it. Your new tools (with the exception perhaps of Playmaker) put too much emphasis on the decoration, which, when the graph is large, subtract presence to the structure as a whole.

Support
Universe: You are the doing it right. Best support I ever seen for any tool. Keep this way.


Summarized
The model to follow is not Kismet. It is Quest3D.

I do not want a tool to write scripts visually. I want a comprehensive programming environment, not for artists, nor for clumsy or high level programmers (no offense), but assuming it is a professional tool for productivity.

 

Holy crap. I learned Fortran AND Pascal in college, all in one semester in one course. I guess this makes me a quiche eating real man...a paradox!

 

I second the motion. Kismet is good. But why not go better. Bigger. BEST.

 

Great, it is looking fantastic, but how you plan to follow Unity's development, say for example that Unity adds more functions in v 3.4, how much time does it takes to add them to your tool so that people who only rely on your tool can use them?

Btw I am glad I haven't put my money on any of them yet, I am not stuck with one and the more I wait the more exciting tools are coming out! Using Kismet as a model is a great thing.

Another question, can you fold a 'script' and save it as a new node, and after you can 'enter' into and check, modify this folder script?

 

you think coding is fun!?!?!?

 

Well so why are you here and you are not using Quest 3D if it is soooo good?

 

Hey, don't worry, I'm just a fool guy who does such strange things.

 

Ok, first things first. I'm not a programmer, I'm a designer.

Maybe all of you are really good at memorizing and working with all the syntax, but I'm not that great at it. Yes, I can learn and I've taught myself a bit about C# and Javascript, but at the end of the day I just want to get things like trigges and player interaction to work. I'm really good at creating and designing the levels but all that's slowed WAY down because I spend around two hours trying to get a few what-should-be simple scripts to work. I don't really have a programmer at hand to go to for every little thing, so something like these tools are really useful and welcome.

I didn't get a lot of time to play with Quest's system, but it was pretty good.

As for uScript being like Kismet, they said it would appear to be like Kismet, but it would be able to do a lot more. By that statement, I'm thinking that it won't act exactly like Kismet, it'll just appear to be that way at first glance.

I seriously have no idea which of these to go into. Universe, PlayMaker or uScript (even though it's not out yet.

 

Download the free beta of Universe and play with it for a bit and see how it works for you. If uScript releases a free trial, try that one out as well.

 

Maybe this question will sound too "futuristic",
but how far are visual editors from being able to read already written code and display that visually?
Meaning, the program creates the building blocks and connections from already written code automatically?

 

i haven't seen any effort to really look into the problems of building interactive visual conditions and control flow. kismet is very poor along with all node based systems presently available. they consider the level designer is just for presenting static layout, not interactive flow within the scene, thats passed off to a node system to take over all future effects- your better off with a text editor, easier to read and manage.

 

Yeah,, if I were a programmer, but thought it would be helpful to see what code does what for non-coders to learn from.
A bunch of text explaining code doesn't really help me, I lose my thought midway through.
I tried Quest 3D for a few years and found it almost no help.

 

Various .NET tools can already do something similar to that (but in a more "blind" way). For example, DevExpress Coderush/Refactor Pro (one of the) can show you every single block of code in a visual form. It's not exactly useful, because you can just read the code, but surely it's just a matter of time and effort to write a similar system for displaying visual code logic.

 

Thanks, guys.
Just thought it would be instructive to see the code I already have (paid for custom code, pretty much an entire game)
in a visual manner since I know what the main purpose of the code is already, to see what I could glean.
If I don't see one soon, maybe I'll ask to have one written for me.

 

Code convertion is not necessary when you work in Universe. You can use a MonoBehaviour or Universal Wizards for quick easy access to the any code outside your visual graphs.

http://forum.antares-universe.com/how-to-work-with-wizards-tutorial-t272.html

 

@Neodrop,
If you post was for me, what I am asking about is having the program build visual graphs from my existing code.

 

Yes, I understood, but I don't see why you need to build visual code from existing standart code. In most cases it will be a real hard-readable. I think, the best way is to use it together but not convert one in other.

 

For learning for a non-coder.

 

What would be interesting is something like this taking a look at your project and creating a diagram from it for the purposes of tracking and editing your OWN code, especially with bug hunting.

 

It is possible in the theory. But demands the big work and time. In our case, sure. May be someday...

 

Sorry, this reminded me too much of the TOS 3.3.1 fiasco. You aren't, by chance, John Gruber are you?

 

Don't focus on learning how to "code", languages come and go. Learn how to flowchart instead

BTW, here's my take on the matter:
http://themaddoxcorner.blogspot.com/2011/04/visual-scripting-and-coding-for-games.html

 

MaDDox, why so many advertising for one incomplete esse ?
Universe has all ability of Playmaker uScript, and also many more but I see only your opinion about PM.

 

You of all people shouldn't be getting on another users case about 'advertising' something that's incomplete with lots of posts... #imjustsaying

 

Cmon people. No need for this.

 

The part where you press the button and compile rocks! It is like being a Master Wizard. You cast a spell and invoke daemons to do your bidding based on sigils and signs. Get your sigils wrong and they don't even appear.

BTH

 

Hi. I'm artist.

There is no more frustrating thing than having such an important part of the art in a nowadays game such saders blocked.

The creation of the strumpy shader editor is just glorious news for people like me.

Equal aplyes to A.Universe.

This tools are magnificent.

And when you do need to draw a cube if you prefer to enter the coords via code or similar halfmachine-halfhuman stuff good for you, but there are people (like)that do preffer to do this visually.

Thanks guys for those tools!

 

I do. I've written code in umpteen languages over the years, but I found myself getting increasingly bored with the bits that programmers still (erroneously) refer to as "coding", but which are really just writing out instructions for the damned compiler and linker to explain how all your bits of actual code are supposed to be nailed together.

An example is that poor, misunderstood portable assembly language known as "C" (father—and grandfather—of a great many 'child' languages, most of which have "C" somewhere in their names):

Code (csharp):

1.  
2. #include "stdio.h"
3.  

That line isn't "program code" in any way, shape, or form. It's a directive to the compiler. It literally translates as "Copy and paste all the text from the file named "stdio.h" into this file." (Later additions to the original language include supporting the use of angle brackets instead of quotes, so the compiler would go looking for the file in multiple folders—handy for complex projects where lumping all the source code files in one folder gets messy, really quickly. But I digress...)

Naturally, program complexity has moved on a bit since the early 1970s, so a major problem with C++ (until shockingly recently) was the fact that the compiler was too bloody thick to realise that it only had to include these files once when compiling a bunch of source files. Each and every time the compiler saw that line, it would blindly include that file without any hesitation, so the compiler would spit out lots of errors about variables and functions being defined multiple times. So you, the programmer, had to write code like this:

Code (csharp):

1.  
2. #ifndef ___DONTINCLUDEMEMORETHANONCE
3.  
4. // what follows will ONLY be included if the above macro hasn't been defined.
5. #define ___DONTINCLUDEMEMORETHANONCE
6. ...
7.  
8. #endif
9.  

NOT ONE LINE of the above has a damned thing to do with "telling the computer what you want it to do". It's all housekeeping. It's form, not function; structure, not content, etc.

C++ suffers from the same problem, although later versions of the language have tried to mitigate this.

C# finally added the "#import" command, which is basically "#include" with the memory it should have had from the outset.

And that's just the compiler directives. Look at a typical C++ class definition and you'll often find the actual "telling the computer what you want it to do" statements are often greatly outnumbered by all the paraphernalia and structural fluff of defining variable types, interfaces, subclasses, virtual functions, and so on. Often liberally sprinkled with parentheses.

(And, of course, there's the tiresome requirement to add semicolons after each line. As if just hitting return wasn't enough.)

There are perfectly understandable reasons for why such languages were created: CPU cycles were expensive back in the 1970s, and they were slow too, with very little RAM to speak of. A compiler that had to keep track of all the source files it had imported would need to maintain a database as it worked, which meant either using more precious memory, or reading and writing to the drive (or tape!) So, yes, it made sense then. But, for the life of me, I cannot understand the sheer, shuddering masochism that considers such designs acceptable today, nigh-on 40 years later.

"#import <blah>" isn't "programming". It should be a simple drag-and-drop from the project window: there's the file, or library, my code needs to refer to or access, so I'll drag it onto my code. The so-called "Integrated Development Environment" should be—you know—more integrated.

One statement block in Boo looks much like a statement block in, say, UnityScript or C#. Strip away all that idiotic organisational scaffolding and—guess what?—all* languages look pretty much the same. So a visual system will finally bring about that holy grail of programming: genuine, generic, reusable code.

The ONLY stuff I should be typing out letter by letter should be the very lowest level of code: the formulae, the function and loop bodies. Nothing else. The structure of my program should be represented graphically. If I want to see what a block represents, a double-click or zoom operation will bring it closer, revealing properties and exposing them as widgets if needed. Zoom in closer and I fly into the block to reveal either another sub-graph, or the low-level code the block represents. Finite State Machines are trivially represented graphically right now; programming is just FSM on a larger scale.

THAT is what I consider "visual programming".

Given enough time to gain traction and a critical mass of low-level operation blocks (e.g. "Rotate this entity to face [/i]that[/i] entity" block) would be made available through online libraries for download—most of them very probably free, or in large collections for cheap.

Many users will therefore never, ever, need to write code by hand as most games require little more than some glue to stick all the interactive bits together. Visual FSM tools like PlayMaker can already do 90% of that work right now. It's that remaining 10% I'm specifically talking about.

I've said it before: for any visual programming tool to really pull this trick off, you have to make it take advantage of the third dimension too. Drawing glorified diagrams on a 2D plane is not enough. The packages mentioned in this thread are so close, but not one of them really nails it.

Yet.

And now I regret I must go. I can hear the unicorns. NURSE! The pills! The pink ones, with the red dots... ah! Much better.

Isn't that right, my pet? There, there! Did the nasty unicorns scare you with their close harmony singing? Here, have a gorilla; that always calms you down.


* ("Headf*ck" and "Whitespace" aren't serious programming tools, any more than an inflatable hammer is something a carpenter is likely to have lying around his workshop.)

 

And visual programing IS in fact coding. Just another (better and more from present-day, I think) way of do it.

 

I prefer the part where you are making the program while the result is presented in real time, and you fell you are making your game without wasting time in unnecessary complex things…

 

This. All of it. Plus some purple ohms, and dancing girls, with mushrooms coming out their ears.

 

Its better for specific tasks, it is especially then strong when the target is flow and relationship visualization (thats why databases are nearly always "node designed" - relational DBs are worlds easier to design and represent in such a way than code / sql statements).
For dirty low level programming, I personally wouldn't consider it an adequate replacement and I assume that most who use visual programming in their day work would agree - they have engineers craming around in the low level to provide higher level nodes so the rest can work productively with these tested, self containing nodes that offer a functionality thats required, not 20 lines of dirty pointer hick hack or at worst ASM (in other environments than unity naturally)

 

I agree visual programming is in fact coding, but I don't think visual programming is 'more from present-day' as if it should replace written code method, although it is more recent!

I think a 'visual coding' method, if done right, can help people like me (who think visually) to do coding, and to think logically.

But if it's not designed to be practical, it might make coding tasks even harder.

 

I've searched for the "esse" english word and couldn't find anything even remotely relevant. Good'old communication problem it seems?

BTW, as for your second sentence, I did mention Universe and its "comprehensive" red and blue balls GUI in the blog post. Well, I might have forgot the balls, but I'm sure about mentioning Universe

PS.: For whoever it might concern I'm in no way affiliated with Hutong Games, I just reserve the right to express my own opinion which, hopefully, might help other people make their own judgement.