TGB: Visual Scripting
by Jason Booth · in Torque Game Builder · 03/01/2006 (10:53 pm) · 7 replies
So, tonight I was reading over the thread on T2D vs. TGB, which has some very valid points about what the name TGB implies. (I prefer t2d, myself, just for the record). It got me thinking about some of the scripting languages I've worked with in the past, and how the models used would provide a system much more in line with what people may expect from something with the TGB name. Warning: This is going to be long and dense.
Quick Background on me:
I worked at Turbine for about 10 years, doing everything from art to design to music to code. I joined when it was about 10 people in a basement, and I left last year due to disagrements with the management and joined Harmonix Music Systems (Guitar Hero), where I spend most of my time working on thier next generation toolset.
Evolution of visual scripting:
During the development of Dungeon's and Dragon's online, a friend of mine (also at Harmonix now) began work on a scripting system designed around artistic needs. It grew out of a very simple problem. During the development of Asheron's Call 2, we had created a system of tables to support various data. You would define a key name like "OnHit" and place various pieces of data on the key, such as a sound, animation, or particle effect. We then added a system to control object appearance (changing armor, etc), which allowed you to overwrite the data of these keys (sparks instead of blood). These tabled quickly grew out of control, and to solve certain problems I wrote ones that would self modify themselves, which, lets face it, is just fugly to the extreme and makes debuging nearly impossible.
So; Dan began work on a UI driven interface for writting simple logic. Instead of replacing keys, we'd just switch on object properties. The armor would set a property on the player when worn, and the 'onHit' key would switch on that property before firing off the appropriate effect. This script was click and point to create, as each node in the system had a standard set of properties to edit. In the case of a particle effect node, it would be which particle effect to fire. In the case of a switch node, it would be the property to switch on and any sub nodes for each value.
Each node in the system was displayed in a tree view, but it could have been represented just as well on a graph as Unreal3 does with Kesmet. Basically, a key is like a function which holds nodes. Nodes can have sub-nodes on them, which can have sub-nodes on them, etc, to create logic flows.
This seemed straightforward enough. But animations, music files, and sounds work a little different than many other things. Unlike setting a value, these events happen over time. And there are many things you want to do based on that timeline, or ways you may want to effect the execution while they are active. This lead to a concept of 'persistance' within the language, and it was deeply imbeded into everything.
Lets examine what persistance ment on three nodes:
Switch
Switch is like a switch statement in traditional code. It looks for a valid case and executes that case. However, when persistent it takes on slightly different behavior. It effectively becomes the equivelent of saying "while this property is this value, execute this set of sub nodes". Internally, it registers with the property and is notified of changes to that property. When it gets a change, it sends a stop message to the previous values child node and starts running the new values node.
Sequence
Sequence was just a way of creating code which executes in a linear fashion (as most code does). However, if a child node of a sequence is persistant, sequence will wait until that node completes before contunuing. Thus, chaining several animations together becomes extremely simple.
Animation
Animations are things which happen over time. If an animation is set to persistant, it causes the sequence to wait. If it is not persistant, it's basically fire and forget.
--- continued in next msg ---
Quick Background on me:
I worked at Turbine for about 10 years, doing everything from art to design to music to code. I joined when it was about 10 people in a basement, and I left last year due to disagrements with the management and joined Harmonix Music Systems (Guitar Hero), where I spend most of my time working on thier next generation toolset.
Evolution of visual scripting:
During the development of Dungeon's and Dragon's online, a friend of mine (also at Harmonix now) began work on a scripting system designed around artistic needs. It grew out of a very simple problem. During the development of Asheron's Call 2, we had created a system of tables to support various data. You would define a key name like "OnHit" and place various pieces of data on the key, such as a sound, animation, or particle effect. We then added a system to control object appearance (changing armor, etc), which allowed you to overwrite the data of these keys (sparks instead of blood). These tabled quickly grew out of control, and to solve certain problems I wrote ones that would self modify themselves, which, lets face it, is just fugly to the extreme and makes debuging nearly impossible.
So; Dan began work on a UI driven interface for writting simple logic. Instead of replacing keys, we'd just switch on object properties. The armor would set a property on the player when worn, and the 'onHit' key would switch on that property before firing off the appropriate effect. This script was click and point to create, as each node in the system had a standard set of properties to edit. In the case of a particle effect node, it would be which particle effect to fire. In the case of a switch node, it would be the property to switch on and any sub nodes for each value.
Each node in the system was displayed in a tree view, but it could have been represented just as well on a graph as Unreal3 does with Kesmet. Basically, a key is like a function which holds nodes. Nodes can have sub-nodes on them, which can have sub-nodes on them, etc, to create logic flows.
This seemed straightforward enough. But animations, music files, and sounds work a little different than many other things. Unlike setting a value, these events happen over time. And there are many things you want to do based on that timeline, or ways you may want to effect the execution while they are active. This lead to a concept of 'persistance' within the language, and it was deeply imbeded into everything.
Lets examine what persistance ment on three nodes:
Switch
Switch is like a switch statement in traditional code. It looks for a valid case and executes that case. However, when persistent it takes on slightly different behavior. It effectively becomes the equivelent of saying "while this property is this value, execute this set of sub nodes". Internally, it registers with the property and is notified of changes to that property. When it gets a change, it sends a stop message to the previous values child node and starts running the new values node.
Sequence
Sequence was just a way of creating code which executes in a linear fashion (as most code does). However, if a child node of a sequence is persistant, sequence will wait until that node completes before contunuing. Thus, chaining several animations together becomes extremely simple.
Animation
Animations are things which happen over time. If an animation is set to persistant, it causes the sequence to wait. If it is not persistant, it's basically fire and forget.
--- continued in next msg ---
About the author
#2
03/02/2006 (1:18 am)
Very interesting reading. Now you've got me thinking about how to design my next game's toolchain...! :)
#3
It would add more torque to Torque!
:)
03/02/2006 (2:52 am)
Yes Jason Booth, I have seen Visual Programming at work...where I work... and it works!It would add more torque to Torque!
:)
#4
It would be a wonderful tool but it is a big project! :)
- Melv.
03/02/2006 (4:55 am)
Well, I've quite a bit of experience with VPL (visual programming languages) at work with applications such as WIT, MATLAB (Simulink) and Labview.It would be a wonderful tool but it is a big project! :)
- Melv.
#5
Just my oppinion thou.
This was a very interesting reading!
Lee-Orr
03/02/2006 (5:45 am)
I think it will be great to have such a system in the whole group of torque products. In addition, I think that if TS will be VPLed, or have a VPL option, it should include more features, and allow more things to be done with it.Just my oppinion thou.
This was a very interesting reading!
Lee-Orr
#6
Again, this is probrably not something for your plate; but something to consider if GG is aiming to attract non-coders, who get hung up on syntax issues and such, and are generally afraid of text, regardless of the language.
03/02/2006 (7:52 am)
Oh, I agree Melv, it's a lot of work. However, once the basic UI framework is in place (node tree + property editor) the rest goes fairly quickly due to the fact that you can add nodes as you go. Dan spent about 3 months on the system before it was basically useable for actual code, which is actually not that bad when you consider what you get for it. Something like this, of course, would be a core TGE thing, not 2d specific. We added nodes as we went on a need basis, but always kept the nodes consistent with the rest of the framework (persistance support, network syncronization, etc).Again, this is probrably not something for your plate; but something to consider if GG is aiming to attract non-coders, who get hung up on syntax issues and such, and are generally afraid of text, regardless of the language.
#7
She isn't really a programer so one could consider here as beginner.
And after her tendence to go "explode" the last few weeks when we reach the topic "programming" for some reason, I'm not that sure that it really is that easy to learn for beginners.
On the other hand, I already used applications that use a similar approach (Carrara and a terrain generator whichs name I can't remember anymore) and must say that for specific tasks, visual programming can be a really great thing. Its just harder for me as technical inspired guy to get a feeling for them, as I am that trained to think in code that thinking in "pictures" isn't as intuitive for quite some time ;-)
It would definitely be a good thing for some parts of the torque series. At the moment, I would especially count TSE as a good point to start something like that with its materials ...
03/07/2006 (12:00 pm)
On the easy point: My girlfriend is forced to use labView to programm their scientific stuff.She isn't really a programer so one could consider here as beginner.
And after her tendence to go "explode" the last few weeks when we reach the topic "programming" for some reason, I'm not that sure that it really is that easy to learn for beginners.
On the other hand, I already used applications that use a similar approach (Carrara and a terrain generator whichs name I can't remember anymore) and must say that for specific tasks, visual programming can be a really great thing. Its just harder for me as technical inspired guy to get a feeling for them, as I am that trained to think in code that thinking in "pictures" isn't as intuitive for quite some time ;-)
It would definitely be a good thing for some parts of the torque series. At the moment, I would especially count TSE as a good point to start something like that with its materials ...
Torque Owner Jason Booth
Switch (persistant, someProperty)
true: PlayAnim (Persistant, SomeAnimation, Loop)
false: PlayAnim (Persistant, SomeOtherAnimation, Loop)
Now, as the property of the object is toggled, the animations will stop and start accourdingly.
Ok, so you have a little node based language which has a pretty deep concept of state and event management, and a visual UI to construct logic. That may sound cool, but in reality, it doesn't really explain why this is so cool. The real charm of this type of system is how dense your code can become, and how you can easily abstract complex things into simple options.
As an example, lets explore an option on a switch style node:
Switch will execute code based on some property value and supports persistance; but how do you want that handled in a network environement? A small set of options can control how this is syncronized over the network; does the client have autonomy or not? Do we care about correcting it if it's wrong? Am I switching on my own properties, or some other objects?
So now, switch is really much, much more. It's got super powerful event management system (persistance) as well as network synconization encapsulated in just a few properties. We've thus compacted quite a lot of narly code into a single node. And since script code is slow, we've sped up scripting considerably because we need much less interpreted code to create the same effect.
Now lets say we have a performance sensative node, like a routine that checks the distance between two objects and executes nodes below it on valid ranges. This would act a lot like a switch and support peristance. But do we really want to calculate the distance every frame? That could get expensive. We might want to only recalculate distance at some rate, like every half second or so. That's more than good enough for say, a monster detecting a player. Well, this can be exposed as an 'CheckRate' property on the node and coded into the node. Once again, a simple property hides a bunch of complex scheduling code.
Visual Programing
So, often when I talk about visual programing, people expect you can't do all that much with it; or that it'll be slow; or in some other way limiting. But from what I've seen, this style of programing is the future, expecially for games and state machine type programing. Almost all of Dungeon's and Dragon's online's gameplay is written in visual script. Dan and I wrote the AI, detection systems, traps, spreading fire, object interaction, real-time combat, music system, puzzles, quest flows, and much more using visual scripting. It allowed us to do many things much faster than we ever could in C++ or a traditional scripting language. The language toped out at about 40 nodes in total, most of which were things like 'animation' or 'particle', and about 15 or so being core components like 'switch'. And as for performance, well, it's a fully 3d massively multi-player game that has to handle thousands of players at once with real time combat. It was also easy for artists to set up objects, and content designers to use them in interesting ways.
t2d vs. tgb
So it seems to me that if Torque (3d, shader, 2d, whatever) really wants to get to the point of being more friendly to beginer developers, it needs to move beyond traditional scripting. Done right, it can be just as powerful, more compact, more performance friendly, less buggy, and faster to learn and develop with. Very complex interactions between many systems becomes much easier to write, debug and manage. That means more time for iterations, and better games.
references:
http://www.unrealtechnology.com/screens/kismet_1.jpg
While I've come to prefer the tree view (more compact, less messy lines, no 'how do I lay this out' BS), this screenshot of Kesmet shows off several key features in next gen visual scripting languages. Notice that a series of nodes is being grouped into re-usable routines (thus, becoming a new node themselves), and those routines can be chained together to create even higher level logic. Notice the standard property editor that allows the user to edit the node selected.
http://www.unrealtechnology.com/screens/MaterialEditor.jpg
Notice that the material editing (shader construction) is really just the same thing, but the various nodes are displayed better (they show texture and the tabs are visually labeled)
http://www.unrealtechnology.com/screens/animtree.jpg
And complex animation graphs
disclaimer:
I haven't worked with Kesmet at all, so I'm not sure how they deal with things like persistance, routine re-use, etc. Also, DDO is, I believe, the first game written primarily with a visual language that I know of. It won't be the last ;)