[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua in a gaming environment
- From: Ben Sunshine-Hill <sneftel@...>
- Date: Fri, 10 Feb 2006 16:48:27 -0800
On 2/10/06, Guy Davidson <email@example.com> wrote:
> Some things have worried me about this during my investigations. In Rome the scripting language had a concept of game time, and you could suspend execution for a few seconds while the game did its thing. For example, you could direct troops to move thirty metres to the south, and suspend execution until they had done that. Given my earlier observation about execution being lined up in big chunks, I'm concerned this isn't going to be possible without fundamentally altering the way that Lua executes its commands. I'm a big boy, I can do that, I've been coding for many years, but it makes me shudder a little because it strikes at the heart of the language and suggests I'm in the wrong place.
> Additionally, we had interrupts. You could monitor an event (such as a general dying) and execute code when that event occurred. Additionally, you could poll for conditions, so that code would be executed when your (the scripter's) own kind of event occurred. I imagine I would implement this by putting a lua_pcall construct at the event dispatch, and calling the polling functions at every tick.
I've found coroutines to be ideal for this in the past, coupled with a
simple scheduler. Like this (well, kind of like this):
sayprocess = say("please come in")
bowprocess = bow()
In this example, the script is being run as a coroutine in the
scheduler. walkto(), say(), bow(), and open() spawn their own
asynchronous processes, and return handles to those processes.
waitfor() yields the thread, and instructs the scheduler to resume it
once the process given is complete. The result is that the character
walks to the door; after he reaches the door, he says "please come in"
while opening the door; after he opens the door, he bows, even if he
is still talking; and is finished when he has both finished bowing and
finished talking. The actual system was a bit more complicated,
allowing boolean wait-for conditions to be built up, but this was the