[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Timing out LUA programs
- From: Björn De Meyer <bjorn.demeyer@...>
- Date: Wed, 19 Jun 2002 01:15:43 +0200
Sean Middleditch wrote:
> If I have 200 active agents, for example, even a very small AI script
> will eat up a few milliseconds - that equates to about 400 milliseconds
> per frame just for AI, and that is with a very simple AI. With a
> pre-emptive system, larger AI tasks (ones that have a lot of logic or
> math in them) will be auto-matically broken up. Plus, a good script
> schedular would be able to decide to only call a limited number of
> threads per lua_run_threads() call, so one frame 20 agents are updated,
> next frame the next 20 agents, etc.
Sure. This can also be handled with an event loop outside of
the lua interpreter. You see, there is always more than one way
to do it.
> One wouldn't want to just replace cooperative threading tho (I finally
> found a use for stuff ^,^ ) since it good for animation scripting:
> move_to (1.5, 2.0, 4.5)
> face_direction (NORTH)
> target = nearest_enemy ()
> ... etc.
Which is perfectly possible without coroutine support.
Did you do any GUI programming? Most GUI toolkist use
an event queue in which input and events are queued
and executed sequentially. The functions you mention here
could simply push events into an event queue,
which is processed later, at the end, or after the
evaluation of the lua script. That is the classic
way to perform highly interactive programming
without using threads nor couroutines. And it works well.
> The long and short of it is that callbacks are not sufficient for
> immersive behaviour scripting. Plus, any scripting language used needs
> to be capable of intelligently scaling down the amount of processing it
> does per frame, by breaking up tasks or multi-frame scheduling.
Hmmm... people have been writing "immersive behaviour" scripted game
engines without threading nor coroutines. There are other valid options,
such as the ones I mentioned. Of course, these demand more work
from the programmer. Of course, letting Lua doing it is less work for
the users of Lua, and more work for the Lua programmers.
> This is yet another reason so many game authors keep writing their own
> scripting language - no complete freely available language I know of
> handles this intelligently. Especially when you are writing a game that
> customers are allowed to modify/script, where you have non-professionals
> who don't know how to optimize efficiently.
Yes, but I think lua already offers the tools to make "immersive"
game scripting possible, provided a good framework and maybe a little
hacking. Don't get me wrong, I agree that coroutines can come in quite
handy. But there are other valid ways to obtain the same result. I get
the impression that there some are people here who have a coroutine
and to whom every problem looks like a coroutine nail. I'm sorry to
nag about this, but there are other tools in the programmer's toolbox.
These are also worth investigating.
"No one knows true heroes, for they speak not of their greatness." --
Björn De Meyer