Scripting

[ravenger7]

So I've got this scripting requirement in the game and in my current project but it's a bit different than your average scripting engine:

* able to execute commands simultaneously
* able to sequence commands in order
* does not require another thread
* does not block the calling thread
* able to take the same time input and reproduce the same results every time
* able to take any time input and produce results quickly

So it seems to me that this is really more of a deterministic state machine. The commands have a known element, time, that is essential to the process and the results. Because it is deterministic, variables are not allowed except at initialization time.

Major advantages:
* reproducibility - most languages require backtracking to return to an earlier state
* time based - the system is well aware of a timeline and the ability to scrub forwards and backwards
* simple - variables only used for initialization
* low resource overhead - multiple scripts can be "running" without a large number of threads
* low processing overhead - execution doesn't waste threads that are blocked waiting for animations to complete
* scripts can be paused, reversed, speed up, slowed down
* scripts can be "ticked" as needed, speeding up as necessary, round robin ticking on multiple scripts, etc.

General architecture:

Script Context - contains information about running scripts, variables, executing commands
Command - base class, getDuration, tick, getChildren, setTime
Batch Command - executes multiple child commands (container of commands)
Sequencer Command - executes child commands in order (container of commands)

Misc Commands:

Loop
Delay
Counter
Fire Event

Start Animation
Stop Animation
Set Animation
Set Texture
Set Position
Set Rotation
Set Scale
Play Sound
Stop Sound
Play Music
Stop Music
Set Shader
Set Shader Variable
...

[Schmendrick]

I have to admit the lack of variables makes me leery; it looks like this confines scripts in a very literal way -- scripted events. Unless I'm misunderstanding you...

[ravenger7]

Yes, that's what it's designed for. Running a series of move-to, scale, animations. You'd be surprised at how often you have to do this in 2D and some 3D based games. It would be different if we're playing an FPS. There might be some scripted objects but generally you'd write an "AI" to control a platform or elevator or a door. Door are surprisingly complex BTW. We're not writing a "reactive" game like an FPS. In an FPS, you let physics and collision and the player do most of the interaction. For Ironseed, there's going to be lots of "open this panel, make a button glow, lift a lever".

I do want to make the distinction between UI script and game object scripting. UI stuff would do most of the "on button clicked, open this display, turn on these sub displays, hide this other display". But the UI scripting is not necessarily going to be controlling the objects in the world and moving them around in 3D space. I really think those are two different things.

If you've got a different viewpoint, I'd like to hear it. Scripting is becoming an issue for my work on the rewrite and figuring out how to handle the new version. I'm deciding how much control we allow down from the scripting into the engine. Is it all scripting or just events? Just UI or game logic? It's a question of control. I've been looking at Scaleform or some sort of Flash based system for UI. The question is do we allow it to more? It's certainly possible but I need to know where to draw the line between the engine (developer) and the UI (designer).

[Schmendrick]

Ok, I was misunderstanding; I didn't realize you were only talking about UI scripting.

As far as separating deciding how game scripting is integrated, I know adept wanted to push most of the game itself into scripts, to enable extensive modding. Given the direction we're going on making most of the game universe procedurally generated (something I'm not entirely comfortable offloading into scripts), I'm not sure where that leaves us.

[nuke_bloodaxe]

This is one of the most interesting aspects {scripting systems} of what is currently being worked on in my opinion, but I do have one thing to ask.

Do you have a diagram of the current proposed architectural layout of the engine? [where the various scripting layers are, order of proposed execution modules etc]

The reason I ask this is because for those of us looking in every so often the current development is very opaque. This is not a negative comment, just an observation, I'd like more information

[ravenger7]

I'll post something in the blog when I get a chance.

[nuke_bloodaxe]

Thank you

I now have a better idea of where things are going.

I see you mentioned AngelScript, its a good system, and one I already have some familiarity with. If you were to use it I doubt that too much could go wrong, the guys keep it up-to-date on a fairly regular basis