I want to make something, instead of thinking about how to make it.

[Michaël Samyn]

To prove his point about a lot of logic, here's two examples of some level design / scripting work I've done using visual logic nodes in the Marmoset engine. The first image shows logic for a battle with advancing lines of infantry, firing cannons, etc.

Could you explain a little bit what this image represents? I'm not familiar with this engine.

[Michaël Samyn]

Do the colors have significance in your diagrams? (representing data types, maybe?)

I think I only use black (and grey) consistently in the diagrams.
The idea of coloring nodes by data type is nice but often gets too limited. Maybe data types should be represented as different shapes. Colors are very handy to make connections between elements. That's how I've used them. One of the big problems I have when programming is keeping track of how everything is connected with each other. This is the main reason why I feel that the entire game should be represented in a single graph (as by cutting things up, one quickly loses a sense of how they fit together and which piece of logic is calling which other piece of logic, or setting its parameters, etc).

[Michaël Samyn]

What about the debugging process? Looks like it would be hard.
May this visual programing run in a layer over everything else so you can introduce break-points or similar?

One thing I have learned is that with visual programming, the number of bugs is drastically reduced. If only because it's impossible to make spelling or syntax errors.

Mostly, in visual logic, when the game is running, the active parts of the graph are highlighted. That helps a lot when debugging. Also, since this needs to run in real-time, you can disconnect parts of the graph while the game is running and see if an error still occurs, etc. And since every parameter can be represented as a visible node, you can see its value update in real-time, without needing to add Debug.log logic.

[God at play]

Could you explain a little bit what this image represents? I'm not familiar with this engine.

The black boxes are invisible walls, the yellow ones are triggers that activate, with a customizable filter for any character, just the player, etc. Some of the brighter small squares are visual effects and triggering animations if I remember right. The darker magenta circles are logic nodes, so you can link that to a trigger that passes messages to other objects. I think an example would be to trigger a line of men to advance when a certain number of enemy men die; something like that.

[Michaël Samyn]

Fascinating. So Marmoset is a game authoring tool?
Does anyone know any games created with it?

[God at play]

Fascinating. So Marmoset is a game authoring tool?
Does anyone know any games created with it?

It's a custom C++ game engine developed by 8monkey Labs. That tool is the level design/scripting tool called Habitat; when I used it, it was fairly limited in features, being supported by our 2-person programming team and pretty focused on the game we were working on at the time, Darkest of Days. I think that's the only shipped title that's been developed with it. The model viewer Toolbag is used by the public at large, mostly by AAA game artists in the Polycount community.

[axcho]

I just read the old book Mindstorms, by Seymour Papert, after Bret Victor recommended it so highly in his article Learnable Programming.

It's a good one - got me inspired about education again. Still trying to figure out how to actually apply these ideas and the example of Logo to a game-making tool...

[axcho]

I've just discovered another awesome Bret Victor project, this time it's the most artist-friendly visual programming system I've ever seen, Substroke.



It's mostly an academic thing, though I think he's made some sort of prototype of it. As it stands, it's still pretty arcane, but it's a big step in the right direction.

I really think "programming via visual storyboards a la comics" is the way to go. Like this. Maybe supplemented with a natural-ish language "script" that it translates to, where you can edit at either level.

[axcho]

I finally understand how functional programming can work for real-time interactive graphical applications! There's a new functional language called Elm that compiles to HTML, CSS, and JavaScript for making websites and games.

The way it works is called functional reactive programming, which basically means it recalculates the state of the virtual world whenever input values (keyboard, mouse, timers) change, and the graphical representation is calculated from the state of the virtual world so that updates too. All the code for the game basically describes the way this data flows and is transformed (through lots and lots of nested functions). As a result, I think it could lend itself very naturally to a visual representation. It's basically just a big tree, a network of data flowing and combining, and if you see this structure you see the entire program.

This could be great for both R-mode readability and building with functional (no pun intended) pieces in real time.

You can see a number of simple examples, including a detailed explanation of the code behind Pong.

Not exactly the prettiest code at first glance (probably more confusing than the kind of programming we're used to). I think the real potential here is in making it visual. We all know how Scratch looks, trying to make normal code visual. I think functional programming would actually look better in visual form than in text.

And in the long run, I bet functional programming would be much more amenable to programming by demonstration - that is, expressing general logic through specific examples.

[axcho]

I'm a bit late with this, but... behold, Bret Victor does it again!

Stop Drawing Dead Fish

That's the kind of programming-by-drawing that I've been trying to figure out how to do for a long time now. He's actually got a simple system that totally works. Now I just have to figure out how to apply it to games instead of just procedural animations...

[God at play]

I really hope there's some people implementing his research in the field of videogames.

Also, it's important to note that he has a great system for programmatic animation, but he hasn't really figured out logic yet. Right now his solution is choosing pre-made actions with sentence syntax. It'd be great to see someone taking his approach and going after logic.

[Michaël Samyn]

Indeed. Bret Victor always strikes me as someone with good intentions but too little imagination (or too shallow awareness of what makes visually inclined creators most productive; let alone of what they might want or be able to make).

[God at play]

Oh. Well I find him to be incredibly imaginative. But he's just one guy, and moving things around seems like a good first step before logic. I just hope there are other people out there building off his ideas. IMO they're too good to just leave alone.

[axcho]

Yes, he's just one guy, and these are all baby steps. But they're in the right direction. It is amazing how few people are running with this. I'd really like Linden Lab to dive into this stuff, but I'm not sure I can make that happen...

[Mick P.]

This is a really long thread, I don't know if I can possibly read it, but I was just about to make a thread about this subject, so I will leave a link here afterward.

I don't think though that you really want visual programming. It sounds like a good alternative, but it's going to get you to a place that is a jumble of knots impossible to untangle. I think you want literary programming...

EDITED: http://notgames.org/forum/index.php?topic=853.0