glob2-devel
[Top][All Lists]
Advanced

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

Re: [glob2-devel] scripting language


From: Bo Lorentsen
Subject: Re: [glob2-devel] scripting language
Date: Wed, 25 May 2005 00:28:06 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20050331)

Stephane Magnenat wrote:

Actually, glob2's scripts load/save are not handeled properly. Source code is loaded, script is compiled, and then always run from beginning, even if a saved game is reloaded.
I understand why, as stopping in the middle of a script and then do a resuming a little later (and even persist in between) is not easy to do. The idea looks like some kind of cooperative multitasking project. This is possible but not pretty nor easy.

SGSL does not have any variable except areas and flags, which are stored in std::map and indexed by strings. Areas are square on map that can be used in conditions. Flags are the normal glob2 flags. Both are global and shared by threads. There is pointer to glob2's internal structure for flags, but as the script is recompiled on each reload thatok,
It sounds to me as a quite limited language, but it shows me something about the task a future script need to fulfill.

Now we all agree that this is bad. So in the idea of a better script, we have to fix those issues, but that also means that changing the script engine doesn't break map format excepted that the old scripts will not compile. There is no much old scripts :-) Only the tutorial, turretDefenseForTwo and the campaign are using it.
But if there was I guess making an SGSL -> TEA converter would not be that big of a task, as they would map 1:1 in functionality and framework.

Just once requirement. A script for glob2 should have function overloading. It is very usefull for things like show("blabla") and show ("blabla", fr). Do you think it will be difficult to add to tea?
I will give it a shot in my current revision, as I already have thrown myself into the task of making the executer a real VM (stack based) and not just a simple dump parser like structure. This a a somewhat large task, so why not include function overload too, so yes I think this would be possible, indeed.

SGSL.h gives a quick overview. Story is a thread and Mapscript the script interpreter. Mapscript::parseScript is the parser and token compiler. Mapscript::syncStep does execute the threads by calling Story::syncStep.
Ok, I will take a look at it tomorrow, and thanks for the hint.

/BL




reply via email to

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