Game Development Community

Visual Scripting Feature?

by Robert Fritzen · in Torque 3D Beginner · 07/23/2013 (2:51 pm) · 64 replies

So, I've gotten the hang of this pack development stuff now. And with potentially a month of free time available before my true job hunting begins, I thought I'd tackle one more pack. Only this time, I dove into the list of features people would like to see for the engine.

So, One of the big ones was a system that works sort of like UDK's Kismet System, a visual scripting system. Now, I haven't touched UDK other than for a few minutes of the lagfest it generated on my laptop when trying to make a simple map, so I'm not too knowledgeable about Kismet 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?

Now, I have a ton of experience working with Torque's GUI system and interfacing the engine and TS now, and I was wondering, if I were to take on this task, exactly what would be expected out of this kind of system. I'm kind of hunting for a more detailed feature list of what it is exactly supposed to do before I actually say yes to doing this kind of a job. Exactly what would you want out of a Torque Visual Scripting system?
Page«First 1 2 3 4 Next»
#61
02/21/2014 (2:37 am)
Here's the thing finally. Refer to my previous posts if you missed it.
#62
02/23/2014 (12:05 am)
All@ Interesting thread, just came across it. Personally, I am more code oriented than visual ... but I have used Kismet when forced to use UDK for a couple school projects.

And the ability to "See" the logical flow of the code was helpful.

But in reading this entire thread, I can see how it could quickly become more and more complex ... and a pain to maintain, if its hard-coded for the existing engine or objects and their respective functions.

Still, am curious how it might be used for simple functions on existing objects ... like add a door, then access its on-collision function and tell the door to animate (open) ... which triggers another function which checks for the collision to stop and shuts the door.

That is what I used it for in UDK, open a door and close it. Turn on red light, while turning off the green one ... etc.

Guess the question is would it be more effective use of time for a programmer to code this up ... or for a non-programmer, to just learn to write the code ?

Seems like once built, it could be a time saver for everyone - no ?
#63
02/23/2014 (9:00 am)
@Jeff - hard-coding would make this really tough to maintain. However, Torque has built-in discovery (see the GUI and Mission Editor scripts) so that anything exposed to the console can be found and queried for properties and fields (even custom fields - the Inspector Pane adds dynamic fields). Leveraging this, any object correctly added to the engine would just become available after compilation (with a little script-side adjustment).
#64
02/24/2014 (12:55 pm)
I sort of left this thread here as sort of a discussion at this point (seeing as my coding has been oriented to work beyond this idea), but Richard's right. The only good way to implement a visual scripting engine here is to make use of Torque's discovery system to grab avaliable object methods from individual pieces and use it in the editor, which would pretty much allow the system to auto-update as you add new custom code to the engine.
Page«First 1 2 3 4 Next»