Quest to Visual Scripting Language

[Pancakes]

Hi, so I'm working out how I'm going to push the Flowgraph system the last 5% it needs in order to become a fully fledged visual scripting language . Leadwerks is already so close that I think a novice such as myself can hack the functionality in with just Lua primarily.

 

But I need a little cooperation from the devs. Mainly the first thing I need to know about is entity IDs and how I can most effeciently push them around and store them inside of Flowgraphs. Is there a command for this already?

 

What I want to be able to do is to have a special generic entity ID node which has direct access to the properties of whichever ID it is referencing without actually being connected by any of its own inputs. The main purpose of the node would be to instruct other generic nodes upon which entity they should operate WITHOUT requiring those nodes to be connected directly to one another. The result would be flowgraph islands that can interact with one another without having to be connected directly. This is important for creating logic loops inside of flowgraphs where a single entity ID node can iterate through a list and have a single generic node perform several actions upon several different entities.

[Rick]

I haven't looked into LE3 flowgraph all that much yet, but I have no doubt we'll have to hack around some of this stuff as Josh isn't 100% there with flowgraphs. I don't think we need an entity ID, I think we can get the entity's themselves, but we may need a node that accepts a table of entities (not sure if a table can be a public property or not). That way we can just add every entity to this node, and that node can connect to functionality nodes to process the table of entities.

 

I would, however, question if this is needed. If you want functionality to run on certain entities every frame, I think making a Lua script of the functionality and attaching it to each entity would be the way to go. The Lua script could also just be to tag the entity, and we could have a ForEachEntity node that in it's Update method scans all entities looking for the tagged entities and starting the looping process. I'm not sure if we can get all loaded entities from within a Lua script though. I'm guessing we should be able too, given it's all 1 Lua state. Again, for me this will have to wait a month or 2 until I finish my game.

[YouGroove]

I don't agree with islands.

It's like UML ,you need connexions to know who interacts with who.

Or it will become even lot more hard to understand.

 

Anyway i will see and try your solution if you need a review

[Guest Red Ocktober]

who interacts with whom...

 

 

--Mike

[Rick]

I agree islands can make it more confusing, but sometimes you need things to run on entities every frame, and making those connections also comes at a price of readability with having tons of lines everywhere making the connections.

 

Add to that we only get the 1 flowgraph and no grouping functionality and complicated flowgraphs will get messy in LE3

[Guest Red Ocktober]

complicated flowgraphs will get messy in LE3

 

i think Rick has a valid point here... the way i see it, the current implementation is not designed for

implementing really complex logic... though i'm sure it'll get enhancements as the product matures...

 

this does raise a question though... at what point does taking the time to learn these flow graph type systems be better

spent learning how to script, code...

 

just asking...

 

--Mike

[Rick]

I think flowgraphs can/should be looked at as just another language. It's just another way of getting logic to run. Kismet supports variables, modules, loops, conditions etc. It is a language just like any other just not typed. That puts it on par with any other scripting language. It's just a different way of thinking about a problem. We see time and time again that images (colors & shapes) are better teachers than text. "A picture is worth a thousand words" is so true.

 

So for where LE3 is with flowgraphs right now, sure I think learning to code Lua will be helpful. Where UDK is right now with Kismet, designers/mappers/etc are doing some pretty cool, advanced, & complex things with it's flowgraph.

 

I think the more those who like Flowgraphs use and really push them for Leadwerks 3, the more likely Josh will see their benefit as a programming language and expand them. Flowgraphs aren't "MakeMyGameForMe". They can, and should in my view, be just like another language.

[Guest Red Ocktober]

its not a language... it's a tool that enables implementation of logic without the need to use a programming language...

 

if it were indeed a language, then my question above would be even more relevant...

 

--Mike

[Rick]

it's a tool that enables implementation of logic

 

That's all a programming language is. So it would seem they both serve the same purpose. We can give it a different name because it's pictures with some text instead of just text I guess, but not sure what the point of that would be since it does the exact same thing.

 

 

if it were indeed a language, then my question above would be even more relevant...

 

You are right it would be more relevant, but then it would be faced with the same question all programming languages are faced with. Why learn one over the other?

[Guest Red Ocktober]

you're wrong Rick... look up the definition of a programming language...

 

look up the definition of kismet (and similar flow graphing tools)

 

Kismet Tutorial-1

Introduction to Kismet

1. What is Kismet?

Kismet is a visual interface used to help non-programmers control the

interactions within a simulation which would otherwise be done by

programmers using a programming language such as C++ or Java.

from http://www.udk3developer.com/PDF/KismetTutorial-1.pdf

 

they know what they're talking about...

 

 

the second part of your response is non sequitur... for why would you use a programming language (your definition of flowgraphs) in order to circumvent having to use a programming language...

 

as to why learn one programming language over another... the answers to it are quite obvious, i'm sure you can come up with many answers to that yourself...

 

--Mike

[Rick]

I don't even know why I let myself get sucked into these but...

 

 

Wiki says:

 

A programming language is an artificial language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine and/or to express algorithms precisely.

 

http://en.wikipedia.org/wiki/Programming_language

 

 

Typed: "programming language def" into google

 

"a language designed for programming computers"

 

 

"Language is the human capacity for acquiring and using complex systems of communication, and a language is any specific example of such a system."

 

http://en.wikipedia.org/wiki/Language

 

 

Languages don't have to be text based. I don't see the word text in any of these 2 defs or the def of language itself.

 

So if the word language doesn't require text, and programming is to give instructions to a computer, then why aren't flowgraphs a programming language?

[Guest Red Ocktober]

i think you missed your calling Rick you would've made a good magician...

 

 

for the rest of the world, those who don't believe in magic... including those people whose link i gave you above... flowgraphs are not considered programming languages...

 

we're talking about programming languages here Rick... not human languages, not signing, esp, etc... using your impression of what you imagine a programming language to be, a "CreateMyGameForMe" button would be considered a programming language...

 

try signing in some code to your computer...

 

sorry buddy... that just doesn't fly...

 

--Mike

[ChrisV]

I think they both serve the same purpose or goal...which is to make game interactions (or any other action that happens in the game/program).

The big difference between them, is the fact that non-coders can use the flowgraph or visual programming tools to create game interactions, just the same as a programmer would do by writing code.

Non-coders do understand logic too, just as a programmer. They only lack the knowledge to convert this logic interaction into something useful through code. That's the whole purpose of a visual programming tool, or flowgraphs.

Complex interactions are quite possible with a visual programming 'language'.

Personnaly, I think both a programming language and a visual programming tool should be an option in a good game engine. It can help a lot to develop games faster and also test games while creating them. Programmers can use the programming language, and for the non-programmers (or those who have less programming knowledge) they can use the visual programming tools.

But, I'm sure everyone has their own opinion about this.

[Rick]

So Kismet (and other flowgraphs) has variables, modules, conditions, branching, & lets you define logic for the computer to run, but because their documentation doesn't come out and say it's a programming language we can't call it that?

 

http://en.wikipedia.org/wiki/Duck_test

 

So you see all those features that make up Kismet and see how similar they are to other programming languages and you just simply say no? I guess I see the similarities and say yes. I don't think it's that far of a reach.

[Guest Red Ocktober]

@Rick

you can call it anything you want... fact is that it is not a programming language...

 

 

@ Chris

it's not an opinion Chris... it's a fact...

 

i didn't make this stuff up you guys... this is not an opinion i'm trying to get you to agree with...

 

what part of the following (requoted from above) statements are you having trouble comprehending...

 

Kismet is a visual interface used to help non-programmers control the

interactions within a simulation which would otherwise be done by

programmers using a programming language such as C++ or Java.

 

Kismet is not a programming language... no matter how you'd like to see it... no matter how i'd like to see it...

 

--Mike

[Rick]

I'll call it a programming tool from now.

[Guest Red Ocktober]

 

just use it for the good of all mankind, and i don't think anyone will complain

 

--Mike

[beo6]

I have only tried a visual programming language once years ago (Windows 3.11 times). And i think today, that it was a real pain to use and to keep track at what is going on where and how. Back then i liked it as i didn´t had to learn a language. But i needed to read the documentation at least a bit to understand the basics how to use it.

 

I think the Flowgraph is a nice feature that will come in handy even when i havent really used it yet.

 

Please don´t convince Josh to convert the Flowgraph to a full visual programming language.

If really many need this feature make it optional without getting in the way for others.

 

As i understand the Flowgraph is really only meant for interaction between entities. So level creators can define visually how things interact with each other.

 

 

Thinking about hacking a visual programming language into the current flowgraph implementation:

Might it be possible to make some dummy entities (Pivots maybe?) and some scripts with special behaviors and inputs/outputs so you just drag your conditions, timers etc and some methods into the flowgraph like any other entity and connect them just normally with the game-entities?

[Rick]

Thinking about hacking a visual programming language into the current flowgraph implementation:

Might it be possible to make some dummy entities (Pivots maybe?) and some scripts with special behaviors and inputs/outputs so you just drag your conditions, timers etc and some methods into the flowgraph like any other entity and connect them just normally with the game-entities?

 

That's exactly what I plan on doing. I'm going to play around a little tonight with this as a "fun friday" thing

I'm going to push this to the limits and create variable type scripts as well. Of course they will require entities (pivots) in the scene for each variable which sucks, but it's the work around for now until Josh can see the value in such a system and give us variables in the flowgraph.

 

 

Please don´t convince Josh to convert the Flowgraph to a full visual programming language.

 

It wouldn't change anything as the flowgraph is based on Lua anyway. It would just expand the flowgraph functionality closer to Lua. I can't promise you that I wouldn't push for more Flowgraph functionality though. I find lots of value in flowgraphs and I think it should be expanded. If I can hook up a lots of functionality quickly via components, I'm all for that. It saves me time later so I don't have to pick pieces of code out of a Lua script to put into another. I can just take the generic entire Lua file and add it to my project and hook up the functionality via the flowgraph.

[Pancakes]

well this topic went to pot. just chiming in that I ONLY call it a visual scripting 'language' because that is what Josh refers to it as. Nobody else I know ever does that anywhere else. It's part of the Leadwerks bias that you just have to deal with. He's entitled to that bias if he wants. I will call it a 'language' here because this is his forum and there is no reason to argue over that point. It's actually simpler for me to call it a language here because it takes less time to explain the difference between where Leadwerks Flowgraphs are and where I want them to be.

 

Leadwerks flowgraphs are 5-10% away from handling the logic I have in mind. And the changes can all be done superficially in Lua. The only question is whether performance will be hit and by how much.