glob2-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]