[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Embedded scripting language (again)

From: Stéphane Magnenat
Subject: Re: [glob2-devel] Embedded scripting language (again)
Date: Tue, 21 Feb 2006 11:10:02 +0100
User-agent: KMail/1.9.1


> The checkpointing thing is only a convience for the scripter, not a
> requirement, and with no other choice, it can be ignored.

Sorry but I do not agree. If you want the same feature-set in a map without 
checkpointing, you have to do a lot of housekeeping in the beginning of the 
script in case the game was loaded. In fact, some maps that are state based 
(for instance several objectives step by step) and whose state can't be 
deduced from the map itself won't be possible any more. I think a script 
should ease the life of the scripter.

> The 
> multi-threading task shouldn't be an issue whatso-ever in any
> language, and if you intend to do pre-emption, the scripts must run in
> steps rather than threads, or you could put a nasty callback inside an
> executed function or a trapper of some sort, but thats going to look
> quite ugly.

Well, what we are speaking about is neither plain preemptive scripting (such 
as in Java) nor plain co-routines (such as in Modula 3), but rather a system 
of coroutine that can be interrupted if they are using too much time and use 
elements from the game itself as synchronization primitives (such as 
wait(nbWarrior > 2)).

> Hacking on a big language is easier than you think, though it depends
> on the language and interface.

I agree that it depends of the design of the language and the VM, but in 
general, the bigger the runtime is the harder it will be to add deep things 
such as checkpointability and our special sort of threading. Furthermore, it 
will be harder too be reasonably sure that there is no security hole in it.

Have a nice day,


reply via email to

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