Visual Scripting Feature?

#21 If you really do make it, for the love of God make it free.

#22 Only thing I can think of that would list all callable functions, Robert Fritzen, is the .dump() function you'd have on pretty much any object. But this was back in Tribes 2.

#23 SimObject.dumpMethods() -- lists all methods on a SimObject

dumpConsoleFunctions(); -- should try putting in variable and dump to file

dumpConsoleClasses(); -- should try putting in variable and dump to file, this takes a long time

Edit:
Hmmm, these do not dump to a variable...

#24 Hey Robert,
Was wondering if you are still planning this or not, if so I would love to bounce some idea around with you.
I know some of the hold up was the systems there were being put in place. Nonetheless I would like to discuss some stuff with you.

#25 Visual Scripting is great expecially for none experience programmer and yes you can do full player up game with UDK Kismet ex:

http://www.youtube.com/watch?v=Iob-WR8BzqM

http://www.youtube.com/watch?v=4mCV__ywfUY

http://www.youtube.com/watch?v=Bk22Z-maMWM

#26 Missed a good deal of these replies.

I'm currently working on a few different things, one of which is actually a form of my own 2D game engine (just trying to learn some more advanced C++), and the beginnings of potentially another one of my feature add-on packs for T3D (details to come), so this one kind of slid under the rug.

Doesn't mean I won't completely bypass this or ignore it, but it's kind of something I'm just not ready to devote 100% of my time to yet. As for the recent replies, I do have some feedback of my own to respond back to.

@Rob: Yeah using .dump() is still a viable tool for obtaining vars/methods, pretty much summed up by the three functions provided by Demo.

@Kory: See above, there's a few "big" and I do mean "big" potential challenges with implementing this kind of system in a smart way. Mainly with the continual addon of new features and objects to the engine, how I'd also keep up with all of those without introducing a huge amount of additional work for myself (mainly, I'd want to create a system that "updates itself" :) ). Other than that, the general idea behind this kind of a feature in the engine isn't too complex, in fact one could probably accomplish this with a fairly sized TS/GUI only package without even needing to touch a single line of C++ code, none the less, There's quite a bit of pre-work that needs to go into a VSS not to mention you need to get the general idea of the code figured out and how you want the entire system to work for you, it would just be a huge amount of work and I just am lacking the open time currently to devote it, keep me posted with idea though!

@Ramon: I do like the idea of bringing a VSS to T3D. It's not that it would be impossible, or even that difficult for the manner, it's just something that would be very time consuming to do. But yeah, the goal of a VSS is ultimately to bridge the gap for non-scripters to enter the scripting side of game development (which is what your videos demonstrate).

#27 If you look at the GUI Editor you'll see that there is a way to access the fields and other information on an engine-side object such that you could use a flow-chart style "connection" system. I'm not entirely clear on how it works, but I do know that properly added fields show up in the editor just fine. And I'm not entirely sure on how to grab methods (and their signatures). Nevertheless, there is a feature in place that can be used at least as a starting point.

#28 That was the exact thing I was thinking of when I first started devising the idea of this pack. :)

#29 I'm not a Torque developer or user (yet, possibly), but I was quite surprised and delighted to find this thread. I thought I'd give a word of encouragement and a few somewhat differing opinions and experiences.

In short: I claim that arbitrarily complex programs can be efficiently built with nodes, if the system is designed in the right way. I'm working on such system now in Blender, and I might some day go for Torque integration of some kind.
-------

I became incredibly interested in node systems after Softimage ICE was released. I thought it was the most incredible thing of all time. I then grew out of it in just few months and started devising my own system for much broader applications. After 2 years of weird experiments, I kind of concluded what most people have hinted in this thread, that it will be just too much hassle and mess for more complex things. I then mostly shelved the project for about a year.

When I started learning Haskell, it immediately became clear that any node system must work like a purely functional programming language (or at least close to it) if it must handle more complicated logic cleanly. After embracing functional style, many of the things that make nodes cumbersome and awkward seemed to just disappear. I won't go into any details here, but it seems to me that it's perfectly viable to build arbitrarily complex programs with nodes. I've now redesigned my system and implemented a small subset of it inside Blender. I'm almost at the point where I can show off basic functionality.

I'm not sure how relevant this is to you though. Of course if you aren't aiming for higher complexity, you can do it however you wish and it won't matter that much.

I do say though, nodes are by far the best way to do particle dynamics, and I urge you to consider this in your (possible) design. I'm surprised no one has mentioned this here. I have a very particle heavy game concept in mind (which is why I'm even scouring game engine forums) and I wouldn't dare to even attempt it without nodes.

What I have in mind is to just write a compiler for torque C++ api and torquescript for my Blender node system, so I would never have to worry about properly integrating it to the engine. With some additional bridge code, that should be enough for most thing. It will probably be years before I'll have time to try that though, so I'm kind of hoping someone will do something similar before that.

#30 Back to this thread love everyday. What i see later in the Game Engine Development is more and more Engine adopting the VSS and let face it the idea of those high level programmer today is to incorporated Smart RAD on there engines you can see with the adaptation from old screen ms-dos /basic FORTRAN etc to today new programing object oriented language in the way those are similar to VSS (you type pop a recommendation dlg box select function keep typing) VSS is a step on from of that drop box function link to other box function etc etc. it help to cut some percent of coding on the game development that is my personal opinion maybe im wrong but i look at it like that.

#31 Antton - I hope you're referring to pipes ;).

#32 Robert Unreal Kismet tool is a very flexible and powerful tool that allows non-programmers to script complex game play flow in level. It works by allowing you to connect simple functional Sequence Objects to form complex sequences. Sometimes a Kismet event doesn't affect game play at all - it controls an ambient effect, spawns particles, or performs other actions.
Kismet visual scripting system gives artists and level designers virtually limitless control over how a level will play without touching a single line of code.
Allows for connecting together simple events and actions, created by programmers, to quickly assemble everything from simple behaviors to complete game play prototypes.
Has support for Math, Conditional Logic, Event handling and performing Actions.
Kismet visual scripting supports hierarchies of scripts for organizing very complex sequences into manageable units.
Lets programmers easily extend and create their own game-specific actions and events.
An intuitive user interface allows you to drop events and variables onto a canvas and control program flow by dragging connectors between objects. Comment boxes allow you to clearly group and organize bodies of code.
Web browser-style Back and Forward buttons and a streamlined Search feature allow you to easily navigate complex scripts with many sub-routines.
Hope these give you some idea Robert. I take Free or paying for the plugin if someone implement these feature on T3D

#33 @Daniel
I wasn't actually, but I can see why you'd think that :). I was merely talking about the fundamental idea of functional programming, where our functions only have inputs and outputs and we never mess with the global state. With some very simple rules like that, one can build really beautifully flowing programs. Non-monadic parts of Haskell translate to node graphs almost without modification, and that's where I drew most of my early inspiration.

I mean, from that and Haskell's type system.

@Ramon
I think most of us already agree that it would be handy, but designing and implementing such system is a gigantic undertaking. I'm not convinced that anyone who is qualified to do it, should devote that much time to it at the moment, unless it's their own passion project (like it is for me). There seems to be a lot of other things to fix and improve.

I'm also not convinced I would like anyone else's design, so I will probably do it myself eventually anyway :) (no disrespect meant for anyone). I already have my design, which is fit for my purposes and is generic enough to be applied anywhere. But since it actually is real functional-style programming, it might not work quite the way that basic users would appreciate. I do consider it a lot better approach than kismet, though.

#34 Antton: if you're still active in Haskell you may want to look into its FRP libraries for inspiration on network flows. But I agree, functional programming does have a lot of helpful ideas for this sort of work.

#35 Antton I know implementing such system is a gigantic work, but is a giant work for a none experience app developer I see node rad plugin done for Unity and last few months to be more preside a year or so. and fix and improve will be always there on any app. the VSS is a improve I guest, I believe what we doing here and correct me if I'm wrong is to input ideas from users and developer to make T3D a good competitive game engine and to make it attract it so other user came and join these application/game development community, I'm here because these engine got my attention and I think with time and others input we can make it strong, now my question is T3D is been let open so user do all the upgrades and improvement???? or it have a small base full time developer? Kismet (udk) UScrit (unity) playmaker (unity) etc. and tools better approach sure it made pop-up someday here or with those engine too that is the idea..

#36 No, there is no base of full-time developers. There is a steering committee, but this blog is pretty clear on what their responsibilities are. It is up to the community to drive improvements.

This would be a terrific feature but it's a ton of work even for an experienced developer. It will take time (it would take time even if you hired 5 full-time 20 year veterans). There is a huge difference between building an engine with this sort of system in mind and adding this sort of system to an engine that was built without consideration for it. It would be nice to see and kudos to the guys who tackle it - in the meantime, anyone who isn't contributing to the discussion of "how" might want to step aside and let them work.

#37 What do you mean Mr Richard or Steering committee? We can not made statement here??? Or place opinion??? because some of us don't know how to code with these engine??

#38 Daniel
For pragmatic reasons I'm not actively using Haskell any more, but I do still follow news and library development, specially FRP, parallelism and Cloud Haskell. I know the basics of FRP and it is one of the things that I will definitely look into more when I start dealing with input and events.

Ramon
It's fine for you to express your opinions, but it seems you are trying a bit too hard to sell the idea, when we already agree. That doesn't really add much to the discussion. Like Richard said, it's more constructive to talk about the specifics on how it could or should be done. When such system is up and running, user feedback will be a lot more valuable.
--------

Speaking of development though, I just started reading the sources and it actually looks surprisingly easy to follow. For particle systems I think I already figured out (in principle) where and how to plug in the compiled node graphs. So at least for particle dynamics, this might be easier to implement than I expected. Game logic will be a lot harder though.

Since this would unavoidably be an extension on top of the engine, I think the easiest approach would be to keep the system as far detached from the core engine as possible. We would just have bunch of nodes to access engine data, then we process the data internally, and finally return the new game state and sync it up with the engine. That's the basic idea anyway; it probably won't work quite that easily.

A lot of the core functionality would probably have to be replicated with nodes, but I think that would be worth it. That way everything in the system will operate in a coherent fashion.

#39 What I mean is "there is no full time developer assigned to add features, fix bugs or anything else."

This is in response to your question:

Quote:
now my question is T3D is been let open so user do all the upgrades and improvement???? or it have a small base full time developer? Kismet (udk) UScrit (unity) playmaker (unity) etc.

As far as the rest of that post, I meant "we all know about Kismet and have known for some time now. This is not new information though we're all very impressed by it. Lets engage in fruitful discussion of design and implementation details."

#40 And I stated in my last post why this would be a very tedious task for me to handle. Sure, I have 9-10 years of TorqueScript experience, with GUIs as well, but there are two gigantic, and I do mean gigantic hurdles that need to be crossed for this system to work.

1) Determining which functions are available to which objects are being selected by the VSS. This is going to be a pain to accomplish, only because you've got to deal with name changes, different game codes, and custom code created by users, IE: myObject::Blah(%this), how do I go about adding this to the "list" of selectable functions? It's a hefty practice that needs to be done.

2) This one's probably the hardest part of the system. Determining the logical "flow" of the script. Sure, you can build a very nice and pretty looking nodechart, but now how exactly do we properly assemble to TS code? Even with my years of programming experience, I honestly am still stumped completely by this one. There is no simple and honest "start here", "end here", "do this loop here", ect. to a VSS, it's simply just object, condition, execution. Being able to translate that into proper logical, and human readable TS code, is going to be the main hurdle to accomplish, get this done, and I could honestly have a VSS done in two weeks.

While it's true, I've got time now (and it's being put towards my next pack), This is honestly a nightmare situation from a programmatic standpoint, and I just don't have that kind of time to be able to put together a very user-friendly system without ripping all of my hair out at least ten times in the process of making this.... and I don't want to do that either. ;)