Visual Scripting Language

Along with the Mac and the idea that computers could be made simple by icons came the idea that programming itself could be made simple by turning it into a visual medium where icons are hooked up to each other with arrows and drop down menus set parameters and so on and so forth.  The first I heard of this was on some TV special on a language called "Mandala" - from the brief sketchy research I just did via Google, Mandala later became a VR environment in which very little of what we'd consider true programming was actually done...and when true programming was done, it was with scripts that were written in - you guessed it - text.

Mandala was invented for noble reasons:  so that the noble, joyful activity of computer programming could be shared by the masses.  We often bring up the idea of making our videogame scripting languages visual sometimes for noble reasons (so programming-alienated game designers can express their game design directly) and sometimes for not-so-noble ones (so we can make videogames a deskilled activity and hire cheaper, unskilled workers, thus turning videogames into a sort of fast-food assembly line operation.)  It's the same sort of logic that was behind Fortran - "Non programmers will be able to program." 

Let's discuss the not-so-noble reason first.

These languages, in theory, lower the barrier to entry.  People who are afraid of or intimidated by programming, by pages full of text, will be more comfortable hooking boxes together, and we've now enlarged the pool of people we can hire.

But we're making a bizarre assumption:  that reading and writing text is the hard part of programming.  The hard part of programming is actually understanding the logic and flow of programs.  The hard part is knowing how to maximize either a program's productivity (by being a kick-ass optimizer) or your own (by knowing how to reuse code, make it readable and extensible, make it less likely to have bugs.)  By lowering the barrier to entry, it's like we're reducing the admissions standards to a hard college.  The college accepts more applicants and then they flunk out...or barely muddle through.

Now Maxis did this for *The Sims 2*, with Edith, a language where you can connect command-boxes with arrows to create programs. 

I only know what a couple of people have told me about Edith, so I may be making a lot of unjustified assumptions, but hiring people who would have been afraid of programming in text to do your programming seems like a terribly inefficient way to get a game made.  Of course, having teams of one hundred to two hundred people and cruncing the crap out of them is also terribly inefficient.  Efficiency is usually the last thing on EA's mind - as long as they hit their ship dates (their number one priority) and make the best game they can in that timeframe (their number two priority) they're willing to spend a bundle to make that happen.  So from that point of view, Edith may actually be a pretty good idea.

But all the programmers and scripters I know, no matter what their skill level, look on these sorts of efforts with horror.  With apologies to Jake Simpson, I even met someone who's worked with Edith, and he would have much preferred to program his Sim objects in text.

Visual languages put up a wall between us and the code, making it so we have to do a lot of cumbersome mouse clicking to get our code written.  While it may offer advantages - providing a palette of commands we can use, and validating parameters as we create - we'd tend to prefer to just type.

Now let's discuss the more noble reason:  not all game designers can program;  maybe a visual language would allow them to express their game design directly, instead of having to write a spec which they hand to a programmer.

Chris Hecker once wrote a Soapbox in *Game Developer* magazine where he urged game designers to learn how to program:  a game, he argued, is a system of rules out of which gameplay emerges, just as a program is a system of rules out of which behavior emerges.  If you can design a game, he figured, you can program a computer. 

I'd tend to agree.  Game designers in general are pretty smart people who already understand logic, and should be able to learn how to program.  Some game designers are *really* smart: Reiner Knizia and Richard Garfield are both mathematicians, and I don't have to tell you about Will Wright. 

We have trained a lot of our designers to script with good success.  But occasionally I'll meet a designer who does seem a little intimidated by programming.  Maybe a visual language is just what they need to get their feet wet;  a sort of training wheels.  But I imagine once they got proficient with it they'd want to discard it and script directly.

Comments

[Mark Danks]

whoa...I can't disagree with this more.

The key is to understand the type of game that you are making. For the Sims, a visual language doesn't make much sense, I agree. However, for level/story based games, a visual language is incredibly powerful. Games where you have things like "here is a spawner, and here is a trigger for a cinematic, etc". Basically, games which require coordinating concrete events in 3-d space.

The designers who used my system on LotR:Two Towers did awesome things...and none of them knew how to program.

I'm at EA now advocating those visual languages still. I've found that game designers who do know how to program very often don't make good game designs. This helps the designers who focus on _design_ get their "squishy ideas" out into the game.

Mark

[Greg]

I couldn't agree with this more.

To address Mark's point: Perhaps the more flexible you make a "programming language", the more specific you need to make its purpose in order for it to work?

I actually really like the idea of visual programming systems when used for rapid prototyping. Take for example the new visual shader systems that are all the rage now. These are great for artists to prototype visual effects. But as a programmer, I still need to actually hand-write the resulting shader code in order for it to be shippable.

Just my $0.02.

[Jamie Fristrom]

It seems to me what Mark is talking about is a visual editor? For spawn points, some kinds of triggers, whatnot, you want to be able to open up a level in your level editor and just drop them in there - you don't want to have to script that, I agree.
For anything where the behavior is somewhat complicated, though, I'd prefer to see it in text.

[Factory]

At least from the academic side of things, 'visual' languages are centered around the dataflow paradigm, so it's a bit of an apples and oranges comparison to compare to 'normal' scripting languages. You are prolly comparing paradigms instead of code representation methods.
OTOH I think that plain text isn't the best programming language representation method either, IMHO some more symbol heavy mathematical-like notation.

[Mark]

Yes, I am talking about a level editor, but once you introduce a messaging system and basic logic (counter, one-shot gates, etc), it really does become a visual programming language.

It is always interesting to me when my designers realize that they are actually "programming" when they make their game.

Mark

[Mark]

As a side note, don't forget who the audience of the tool is. In The Sims case, the audience actually is programmers (object designers are considered programmers).

In many level games (LotR, Godfather, Bond, etc), the designers do not have a programming background.

Mark

[Jeff Freeman]

So, I'm on the "learn to program" bandwagon, here. But I'm also crazy about giving designers tools to streamline their workflow.

We used to have manually code every conversation in SWG. It wasn't the least bit easy, even FOR programmers.

Then we got a conversation editor. This tool allows non-programmers to write lengthy, complex conversation scripts without ever touching the script itself.

And...we get no end of bugs from the faulty logic.

Still, the tool is extremely important and I wouldn't want to do without it (again!), but non-programmers use it to make bugs fast, whereas it used to take them hours and hours to make bugs like that. Heh.

[Jeffool]

Loving comic books, I always thought the best comics come from a sole artist/writer, or at least a small/tight team. That's not always true, but I've always thought that a good rule of artistry-thumb that the more focused a team is, the more pure the art. So when I decided I wanted to make games, I decided to learn a skill important to game-making, programming.

And I, like Jamie, think of games as a system of rules from which gameplay is either defined or emerges.

So it's kind of difficult for me to think of a designer who doesn't understand rule systems. It would be similar to a film director who doesn't know how to 'frame a shot'.

But realistically, it only makes sense to try to make programming easier. To worry less about the menial tasks of recreating the wheels, and more about creating the game itself. The problem is making a development tool that offers standard world-laws for the game in creation, (concepts of a player, powerup, etc,) and allows for creation/modification game-laws that define the game (what each unit does, why, etc.)

Like Jeff Freeman said just above this, it seems most systems would allow for systematic bug introductions moreso than actually help the issue. But there has to be some ground where, if compartmentalized enough, design tools could be a viable solution.

[mjh]

There's a certain amount of confusion here about what a 'designer' is; lead designer = director, maybe, but ordinary designers are more akin to set painters or actors or what have you. Having the big-picture view of all the parts of the project helps them do their part in a way that fits the whole better, but I wouldn't say it's necessary.

Visual vs. non-visual is a distraction. The thing that's bitten us with scripting is when you've got a team of guys all writing the same scripts over and over again--so you've got a dozen level start scripts and two dozen pull-a-switch-to-open-the-door scripts and each one has a slightly different bug in it.

A visual system might help this by constraining the designers' freedom.

[Jay Woodward]

It's unfortunate that calling this sort of programming "visual" is so well-established, because the task of standard textual programming certainly has a strong visual component. No one writes code with their eyes closed! So it's important to talk about what we might mean by "visual programming," and how it's distinct from the textual systems which we're familiar.

One possible distinction is that a visual system might be symbolic/pictorial, simply in the way it describes objects or actions -- using icons or even 3D proxy objects.

Another is that such systems might be visual in their depiction of data flow and informational connectivity. For instance, a variable might be depicted as a node, with visible connections to the objects which set it and the objects which read it.

A third possible distinction is that a "visual" system might tend to be better at modeling objects and triggered events than at modeling sequential actions and plot flow.

(The latter two, of course, are not necessarily entagled with the idea of a system being non-textual in its interface, but they seem to be part of what a lot of people are thinking of when they think "visual language.")

In my opinion, the second of these things is quite useful. For instance: I personally do a fair amount of searching for names of local variables or class member names, to see where else in the code they're used. That seems like something that could be worked into an editor, so that the connectivity is more easily followed, without needing to search -- even if it's not represented by a slew of little lines. (In my experience a slew of little lines just makes things hard to understand at a glance, anyway. It's information that you want to see *some* of the time, not all of the time.)

As for the first and third... in my opinion, using symbols or icons to depict a language's elements doesn't do anything real to help simplify the task of programming, and in fact only further obfuscates it.

And as for modeling behavior (vs modeling sequences of events), I think behavior is often better left to code [boring old textual code], and that what designers most often want to do, when creating unique content, is either to create unique sequences events, or to alter an object's behavior simply by manipulating the numeric & logical properties that govern it -- not to create entire unique behavioral rules.

[Soren Johnson]

So far, we've gotten good results (Civ4) with exposing what the designers need - and no more - to python. It's proven remarkably hard for scripters - even those with little programming experience - to write bugs that will muck up the rest of the game (exceptions don't crash, garbage collection, transparent string manipulation, etc.) Obviously, they can screw up their own little world, but they have the ultimate tool of game design at their disposal - code.

I've always felt that most game code is usually pretty simple, at least compared to typical engine programming. Lots of ints, short functions, and easy abstractions. It's the initial "what's a pointer?", "how do I handle memory?", "what does >> mean?" issues that are the usual stumbling blocks for people who have the potential to write good game code.

[JP]

"I've found that game designers who do know how to program very often don't make good game designs."

I'm curious as to what your reasoning is here.

[Sam Scott]

So bringing a thread back from the dead, I have to disagree with the majority of comments here. Essentially in my opinion using any kind of game editor is programming at some level and so in my opinion can be given the tag 'visual' programming.

As with all the techniques used in making a game its keeping the right balance in using them thats important. Just as coding everything in C++ is a bad idea so is trying to do everything in an editor a bad idea. The argument should be what method+tool to use for the job at hand.

In my experience something like the following works best:

ASM/C++ (Coding): to create the low level system code and game objects
LUA/Python (Scripting): to create complex 'branch' game logic such as 'do A under a set X of circumstances or do B under a set Y of circumstances'
Event driven game editor (Visual): to create simple 'linear' game logic 'do A when event B happens.

Traditional coders take care of ASM/C++ and some LUA/Python scripting where as traditional designers take care of the visual editing and some scripting.

This has worked really well in the past and treats the two displinces as a continuous set of skills: design designers<->technical designers<->game progammers<->technical programmers. Indeed if you treat the skill set of all three major displincines as a continuous circle and assign work methods to each you can more easily see where it all fits into the game making process.

Why you want to do this is because you want as many people as possible in the game team contributing to in game content, thus lowering costs, increasing quality and shortening development time. As an industry we should be well past the time of designers simply sitting on the side lines creating documents whilst programmers implement everthing.