 |
lua-l archive |
|
|
||
|
|
Vincent,
I completly agree with you that it can be done this
way.
One of the things I want to avoid is to have
mappers (which will script their NPC maps as well) to get lost into
scripting. Truth is Im not
aiming to implement game code in a scripted
language, but to give mappers a way to easy put more life into their maps
through scripting.
In the final implementation , the scripter should
not even care what interpreter the underlieing scripting engine uses, nor make
any assumptions
about what are its abilites. He should stick to the
interface offered , and if he needs another script command he must ask us to
implement it.
Keeping this in mind, I am aiming to implement
event handling INSIDE the scripting engine code, and only allow a very narrow
set of events
to be processed by a script thread (for example , a
"thread" (function, method) whatever ) to be called on NPC spawning , take
pain, hurt 50% , etc). In rest , he should not
care about an event such as "finished moving to new vector", he should not even
know that such a event is processed inside the scripting engine.
Anyway, even such a method as yours can be looked
as a a very particular case of a thread dispatcher. We have here
"pseudo-threads" (methods to be called ) which
are dispatched by scripting engine core on very specific events.
However, your post made me think that a paper
talking about using Lua in games, or in general any other interpretor in a game
, should talk
about different scripting engine designs for games
as well. In fact I think is much more important to talk about designs and
designs caveats
then about calling C++ from scripts.
Ciao, Dan
----- Original Message -----
|