FreeGameDev

The BGE does it somehow and the guys behind Crystal Space try to do it now to (http://freegamer.blogspot.com/2013/06/devcorner-underapprechiated-game-engines.html#disqus_thread):

I'm the project manager of Crystal Space and recently I started a new OSS project based on Crystal Space called AresEd. This is a 3D game creation kit. You make assets like models and levels and blender and then import them in AresEd. With AresEd you can then create the actual game by putting objects in levels and assigning game logic to them in a graphical manner.

Here is my reply that seems relevant to a larger audiance than just the old blog discussion there:

Personally I don't think "graphical" programming will ever get of the ground... it is just too limiting and once you have to deal with a mix of logic bricks and python code (see BGE) you have just added another set of complexity to it and not actually simplified the game programming at all (compared to just using python).

The best way IMHO is a well separated scripting environment (with an relatively easy script language) so that a user doesn't have to deal (or get confused) by the engine internals. Add to that an extensive set of well documented and self-contained game-play script, so that you hardly ever have to write something completely from scratch, but rather are able get something nice running by simply cut&pasting stuff quickly.
And while commercial game engines have realized that more or less, there is basically no FOSS engine that does it like that.

Any further thoughts?

IMHO, yes and no.
If there is really no need for more configuration than some AND/OR logic, it can and even should be done graphically. Also, state based and other primitive models can easily be covered with that.
Think of Kismet, the graphical DSL of UT.
Of course, planning and implementing this is really hard, because
a) you need to know exactly, what you will ever need. EVER.
b) the ergonomics shouldn't suffer. That means, such a GUI must play together with the keyboard, because advanced users won't put up clicky-clacky mouse.

Of course, it is also possible to implement full programming languages for GUI, but

a) point b) of the previous list is even much harder, then. You may want to implement a hybrid solution to offer a super modern autocomplete feeling. All solutions i have seen have failed at this. Also consider psychological problems like directly blocking the user from wrong input as part of the problem.

b) You need to worry about an own, well-performing, complicated runtime. Hell, even normal runtime languages are hard to implement.

That are also IMO the reasons that only a few commercial solutions offer graphical programming and OS games mostly use Lua.
Because hobbiest have better things to do and few companies have the ressources to do it properly.

EDIT: Oh, and I forgot: Which real improvement does such a graphical environment offer? Programming is always hard to understand and one must learn the language at hand. It doesn't matter if graphical or not.

So while it's theoretically possible, it's hard in reality, just like realtime garbage collection.

I'm not sure if users actually want real graphical programming to begin with. Trying to implement sufficiently custom behavior or large systems with logic blocks and wires would get so messy that most users would freak out at least as much as when introduced to a decent scripting environment. However, a UI that would allow you to assign physical properties and coarse predefined logic to your objects would certainly work and probably have demand too. By predefined logic, I mean something in the level of detail of static obstacle, rigid body, birdlike enemy, door and so on. If you could download (or script) new logics easily, it would hopefully be flexible enough while still being easy to use.

About the 'lose track' thing:

We're pretty much spoiled with stuff like Lua.
Remember, when game scripting meant that you had to tolerate some ad hoc language like early QuakeC or even worse?

Fortunately, not me, but I think GUI programming is in the state now as "normal" scripting engines where then.

Think about it: Most graphical environments are either like
a) you connect some boring grey boxes with lines. Maybe UML, but even worse. No keyboard support. Unfortunately, those boxes take up too much space on the screen, so you have to scroll or to zoom and then lose track or
b) you connect flashy colored puzzle pieces with miserable color contrast, then die of epileptic seizures and lose track of the program. Of course, mouse usage only.

All in all they look like programmers GUI design (the worse brother of programmers art) and are in no way well designed or ergonomically.
So you can prove me wrong by pointing me to a otherwise well designed graphical programming solution, but until that moment, to me losing track of the program is a matter of the actual implementation.

EDIT: After having a look at AresEd at Youtube, which - no offense! - seems like a clone of UnrealEd, I feel confirmed. It's category a). Again, no offense, I couldn't make it better.

Microsoft's proprietary Kodu is xbox360 Controller-driven. This of course is very limiting but arguably more effective than mouse input.

I have the impression that graphical programming environments inside of game engines like UDK and Unity3D are mostly useful to make entrance easier: getting results faster and getting into situations where the game designer knows what she wants to achieve but is stuck at the limits of the graphical programming will create more motivation to start programming than starting with a programming language as a complete beginner.

Well if we talk about some special cases: I think node-based GLSL shader code editors like in UDK are actually a great idea as for this specific purpose graphical programming makes sense.

Hi, I'm the author of AresEd. I do agree that in general it will be hard to do all game logic in graphical building blocks. That's why we will also support (python) scripting. The graphical editor is easy to have a quick overview and many easier objects will have only simple logic since they will be made out of pre-made logic blocks.

Greetings,

Another great tool was the Warcraft 3 Trigger Editor.
I don't think that lack of space is a problem in this solution, if you consider the mass of mods, that has been done using it.

jorrit {l Wrote}:Hi, I'm the author of AresEd. I do agree that in general it will be hard to do all game logic in graphical building blocks. That's why we will also support (python) scripting. The graphical editor is easy to have a quick overview and many easier objects will have only simple logic since they will be made out of pre-made logic blocks.

Greetings,

Welcome jorrit! Glad to see Crystal Space is still going after all this time. Whatever happened to Ecksdee? Perhaps something to port to AresEd?

charlie {l Wrote}:Welcome jorrit! Glad to see Crystal Space is still going after all this time. Whatever happened to Ecksdee? Perhaps something to port to AresEd?

Crystal Space is still going well (even after all this time). We got accepted for this years Google Summer of Code again so again we have 6 students working on nice stuff for us (like OpenGLES so hopefully you'll see CS running on some Android or iOS platform soon).

The author of Ecksdee is still active in the CS community but unfortunately his project died the death of so many OSS projects.

Sauer2 {l Wrote}:Another great tool was the Warcraft 3 Trigger Editor.
I don't think that lack of space is a problem in this solution, if you consider the mass of mods, that has been done using it.

I totally agree that the Warcraft 3 Trigger Editor was a great tool; in fact, it had a huge impact on my personal life as it helped me discover my love for coding. However, I wouldn't really call it a 'graphical programming' tool, as it really only ever was a fairly thin GUI wrapper around Warcraft's scripting language JASS. And afaik most advanced mods/maps directly made use of JASS or one of its variants instead of relying on the Trigger Editor.