In-game editors (Agustin, wait, it's ok, I'm not asking anything of you:)


#1

Nigec’s work on a game-editor got me to thinking again about editor design (kind of a specialty for me)
The FAIL in all game editors I’ve encountered is making logic easy. Problem is, it just can’t be reduced and you have to think like a logic computer to describe anything but the simplest of situations. Whether you are using a text language or a wizard, you will ultimately have to think the same. None of them really give any new power to the designer, just some convenience (and inefficiency) of doing something graphically.

This morning I had an aha thought and I just want to share it.
I haven’t seen an in-game editor taken to this level.
It essential expands the graphical design phase to the logic that drives the game, but instead of forcing the logic you start off with an open game and play it like it is supposed to play. The initial game logic is very simple (ie every node link turned on) and driven by defaults and then would get increasingly sophisticated as it is played through over and over. Eventually it appears to operate correctly and then you beta test the hell out of it.

This acts very similar and integrates with the in-game editor for building up graphics but the difference is that the editor is capturing WHEN things are being turned on or off, and using that with all the other elements in the game to create the logic.
That breaks up the design into two phases: phase one builds up all the default graphics and audio and logic-state of everything like a normal editor would.
Phase two would continue phase one activities but now everything has a default and when you change anything, WHEN it was changed is also captured. This is used to build cause-and-effect logic throughout the play sequence (‘sequential logic’). When you make a change to something, the state of everything else is captured as well and used to create ‘A = B or C’ type of logic (‘parallel logic’), like a 4-dial combination lock, for example.

How well this works depends a lot on how the particular game engine is designed. Dagon has some good structure for this, like the concept of node-sounds overriding room sounds.


#2

Haha! I have my own ideas for a very simple and “organic” (as you describe it) GUI for Dagon. Unfortunately, there’s still much work to do on the interpreter itself before dedicating time to such tool, but the time will come. The strongly objected-oriented nature of Dagon will greatly pay off, you’ll see :wink:


#3

I must admit “doing something” that aids speeding up the coding process is very simple, its when you consider what the user would want to do is when it starts getting pardon my French but feckin hard!
My idea was to use features I liked from other game engines, have the game assists listed so you could easily do the script for that item.
My waving at the moment is I’m learning as I go, getting help is often painful, to the point I’ve stopped asking I’m not that good at explaining things, I usually figure out the problem but probably not the best solution, even the poly draw is showing cracks with was what I considered the most complete part which was supposed to be released earlier in the week… I thought it was going to be a few error checking dialogs and a cleanup but noooooo lol

If your considering doing something shadowphile, my advice would be to get stuff working in the simplest form, my main nemesis is the saving and reloading, and creating items on the fly and being able to save/reload, this is what I consider my “Heath Robinson” designs and not happy with
I doubt I’ll get any integration with Dagon, I should of gone that last mile and skipped C# and went with C++

Ideally I would of like to have made a node based system that graphically linked everything, abit like how Blenders compositor works
Each node would have directional faces which linked to the next, it would be fairly easy to come up with the scripting part