Visual Scripting Feature?

#1

Quote:only other than it works as sort of an in-game script "maker", so map makers don't need to touch script to get their objects to work the way they want them to. Is this essentially how the system works? So you can apply scripted behaviors to events without needing to actually write the script?

if you look close at the MIT licensed GMK
you will realize that its actually doin half of that stuff already
you bind stuff together thru %this.. simple scripts

#2 Sounds like a good idea. I was actually thinking of designing
A visual behavior editor for ai. So that's Sounds like it would be right up the alley.
I could give a wish list of features I would like.

#3 GMk is doing that by opening a GUI
where you can select what object todo what
and to conect with
so that would really be a start

#4 Well, I know that GMK works with objects with that kind of a feature, but what about standard scripting?

I'm talking about creating a visual scripting system that works for just about anything. Essentially my idea here is to create a new "script" where you can then add functions to it. Within the functions you could create variables and nodes that could be connected to operators and other variables. The tool would then proceed to generate the script for you.

As for object behaviors, it would take a little more time to develop that feature as the system would need to identify a list of functions and their variables and set those variables as the nodes to be connected. For other purposes a manual script (text editor) could be used here. This would all be inside your game (basically a new in-game editor) for use there.

That's essentially my idea for this kind of a system, I'm just trying to get a better idea of how it is supposed to work.

#5 @Robert,
I don't really want a visual scripting system for Torque Script, but I am looking into visual scripting in-game for AI using ECMA script. It will be part of some game mechanics I am working on. I am not sure there is enough parity between my needs and what you are looking at though. In addition to behaviors for AI I will be looking at doing process flow control like PID loops, fuzzy, neural, and data filtering. It will be interesting to see what you come up with if you pursue this. I am sure there will be some good ideas to bounce around.

#6 Kismet tutorial for reference. It looks like a pretty good overview of what the system is capable of and how basic events are set up.

#7 Kismet is an 'ok' idea for beginners. Something to keep in mind, T3d is NOT a game maker. It is a game engine. As I see it, the main problem with something like Kismet, it will NEVER be a total answer to scripting. (trust me, from a guy that only 'dabbles' in code and script) Eventually, a developer will outgrow it and have to open a text editor and truly understand torque scripting and how it all works.

It's sort of like new folks that are frightened of opening C++ express in relation to T3D. My thoughts, if you don't break it and figure out why you broke it, then you are NOT a game dev, you are forever a hobbyist. This is not a bad thing but, this is why engines like Unity exist, and why something like the Torque series are different. Keep in mind, this is just my opinion and I know I have been wrong in the past.

Ron

#8 Is anyone familiar with Mindstorms programming? The original version was based upon Labviews and indeed functioned similarly. I actually figured out how to write generic Labviews apps using that version. The second version for the newer Mindstorms hardware I am not all that up to speed on, but it was visual as well. Those might be good places to see how you might use a language that is completely visual except for some special widgets.

Also, I have not used it, but doesn't Crysis have a visual editor?

#9 Demo,

Yeah. CryEngine 3 uses a very 'basic' visual script tool. Again though, if you want to do anything 'serious' you need to delve into a good ol' fashion TE. Still, does not mean Robert, that any work you do toward this visual script stuff will not help people, and in the end... that is what matters.

Ron

#10 Thanks for the info so far guys, I'll look into the general concepts behind it before I decide whether or not to devote my time to it.

@Ron: Totally aware of that, which is why such a pack I'd make would have a built in manual script editor with syntax highlighting.

#11 I think crysis calls it the flow graph editor. Like Ron said its not a answer to scripting. Id say its more of a tool to save time doing the small stuff for world/level building. For example to control AI or to drop large boulder on a players head if they walk into a trap. Also things like player interaction. If player pulls lever, play animation of big doors opening and then tell the emitters to emit some particles as the wind blows dust in and around. The list gos on and on, but a visual editor can really make world/level building less time consuming and a piece of cake.

Watch the first part of that, I recreated the forcefield doors you see later in the game, just using the flow graph editor. This only took me 1min to setup and make it work. I prob couldn't do that in that time frame just using torque script.
http://www.youtube.com/watch?v=kuMh6w9uRLA

#12 From my POV, a kismet-ish interface would work well when dealing with state-machines, such as weapons timing + callbacks, basic AI decision trees, or a triggered event system, but having poked at it a few times, it really does become more hassle than it's worth once you get to more complex structures.

#13 @Robert,
I take it back. I would be interested in a visual editor for simple level editing features like Casey and Azaezel described. It would make level editing a much faster. Even if only for prototyping.

You could make it much more powerful by having hooks to call TS that can be edited in game like you talked about. This would make a it a bit more powerful. Are you thinking of using "wiring" to make it more intuitive?

#14 IMO the key issue here should be making such an editing environment robust enough to, for example, deal with object name changes. If I make two triggers with scripts that open a door when you enter them, then I change the door's name, those scripts become nonsensical. A good level scripting editor should handle cases like that transparently.

How does GMK handle cases like this?

#15 Hell, if a visual editor can generate a "rough draft" script that you could then modify manually that's a great productivity tool....

#16 Script scaffolds? That's kind of a neat idea. Especially if these modular templates turn out to support that sort of paradigm.

#17 Agree with everyone. As a 'starting point' a visual editor would be great. Daniel points out the primary issue with most of these solutions though, You need to constantly update and maintain something like this for it to be realistic. Considering how tuff it can be to even get the stock docs updated with the assorted releases.... though this product would be 3rd party and therefore maintained by you so it might not be that bad.

Ron

#18 I'm a huge fan of node-based scripting interfaces. It allows for fast prototyping and allows one to easily configure items in a level such as doors, camera cut scenes, enemy spawns, etc. and can later be used by modders to prolong the life of your game. Kismet is a very nice tool used in the UDK and can further be expanded upon to generate material shaders and is very helpful for those that have little experience in either GLSL or HLSL. I support your work on this project.

#19 What about using the UUID that the editor already uses to define permanent mounting relationships? Couldn't something like that coupled with the id of the object create relationships between objects?

Edit:
What about going to a database driven level design?

#20 Wow, loving the feedback so far. I'm going to do a thorough look through the available tools T3D has by default to see if I can accomplish this without needing too much engine changes.

Now to address the questions:

@Demo: In terms of hooks, this system would essentially generate the TS for you by using what you would create in the flowchart. I think the main problem here would be the object ID's in which case I could just enforce a required name on the object to use it's functionality and then use a simple call to nameToID() (which is what the world editor is for anyways).

@Daniel: Object name changes would definitely be an issue with this system. I think the UUID idea might have the answer to that. I'll have a look at how GMK does this to see the approach.

@Richard: That's essentially the idea, create the rough script and then provide a built in manual script editor with TS syntax highlighting to handle the more complex cases.

@Ron: If I properly recall, there exists a function somewhere in TS that pretty much gives you the entire list of available TS functions that can be called by the console. I could make use of this function to generate a database of usable functions for the editor. My second idea was to allow the editor itself to be easily modified by the user to add new functions and scripting modules to it.

@Dayuppy: I don't have much experience in the Shader department, so I'm not sure if I could manage that portion, but all of the above references could easily be accomplished by making use of the usable function list. Since most objects are childs of ShapeBase, a simple database of usable ShapeBase functions could accomplish all of those ideas.

I'm loving this feedback so far, I'm definitely thinking that this kind of response in a short time compared to my other packs basically tells me to go for it.