[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] Embedded scripting language
From: |
Martin Voelkle |
Subject: |
Re: [glob2-devel] Embedded scripting language |
Date: |
Mon, 5 Dec 2005 10:53:20 +0100 |
> > But, what would happened if this execute step control, was droped ? What
> > are other RTS games doing to get this level of control ?
> >
>
> Well, this can be dropped for AI scripting, where it's easy enough to
> have the AI run on one computer, and orders sent to the others. In
> fact, it should be possible to have map scripted events be calculated on
> one computer and sent as orders to the other computers, which would
> more-or-less remove the need for synchronous scripting. That said, this
> depends on a complete rewrite of the order system, which itself isn't
> scheduled until after 1.1alpha1 is released. Part of the reason we
> don't talk about this is that it becomes too tempting to go and rewrite
> it :)
Exactly. Determinism can be dropped if the script is executed on one host only.
But saving and restoring state is a must have if you want to keep the
scenario state on the execution stack:
wait(condition)
do(something)
wait(other condition)
do(something else)
...
Otherwise, we could use a special state machine library and a big switch:
switch(getState()) {
case 1:
wait(condition)
do(something)
setState(2)
case 2:
wait(other condition)
do(something else)
...
}
In this case, the script is executed at each step from the begining
until we find a call to wait whose condition is false. The state
mutators modify a variable external from the script which can be saved
with the game.
A complete analysis of TCO for both approaches from the point of view
of a scenario writer is left as an exercise for the reader (drop it on
this list in a message with subject 'get the facts').
Marv
Re: [glob2-devel] Embedded scripting language, Stéphane Magnenat, 2005/12/04