« DC vs. Marvel | Main | Original Sources »

July 15, 2005


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.



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.


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.


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.



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.


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.


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.


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.

"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.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game