Re: Long-lived Guile scripts in a mono-threaded game engine

[Sylvain Beucler]

Hi,

On Tue, May 27, 2008 at 03:20:55PM +0200, Ludovic Courtès wrote:
> Sylvain Beucler <address@hidden> writes:
> 
> > Here's a sample script (very close to the C bindings, for a start):
> >
> > (define (hit)
> >   (if (> (sp_gethitpoints (current_sprite)) 10)
> >     (begin
> >       (sp_sethitpoints (current_sprite) (- (sp_hitpoints (current_sprite)) 
> > 10))
> >       (dialog1))
> >     (begin
> >       (say_stop "ARRRRrr.." (current_sprite))
> >       (sp_kill (current_sprite) 0)
> >       (say_stop "Uh, I was supposed to protect him, not kill him!" 1)))
> >   (set_honour! (- (get_honour) 1)))
> >
> > (define (dialog1)
> >   (say_stop "Why are you hitting me, player?" (current_sprite))
> >   (say_stop "Uh, sorry I won't do that again" 1))
> >
> >
> > Now every time we see a (say_stop), the script will pause for 2
> > seconds, so the player can read the text.

> IOW, `say_stop' does a `(sleep 2)' (or `sleep (2)'), or waits for some
> UI event, is that right?
---
> what is the nature of the pause? (I think that that might be important.)
> How do you interrupt the tight little say_stop sleep loop (if that's what
> it is) when you are using C bindings?

Basically, a timestamp (for 'say_stop' and 'wait') or more generally a
goal (coordinates for 'move_stop') is attached to the script. The game
loop, before refreshing the screen, passes on each active script and
see if it needs to be resumed.

If at a point the engine needs 3s to load a bunch of graphics and
sounds from the disk (e.g. during a screen change), the paused script
won't wake up during that, but instead will be awaken by the engine
when it's done with the loading.

So the script does not (sleep). In this game, the engine is a mini-OS
with a non-preemptive process model. This is often used in games for
efficiency and ease of debugging (no concurrency). In my case this is
because the code was like this before I put my hands on it :)

Currently when the script engine interprets 'say_stop("Hello");', it
will set the timestamp at now+2s, save the script resume point, and
return to the main game loop.


> > This would be pretty cumbersome. This is supposed to introduce
> > people to the beautiful world of scheme, not scare them to death ;)
> 
> Well, it's not necessarily that scary, and it depends on how often you'd
> have to use it.

Let's precise the audience: most often, 15-20 years-old with little
programming skills. If we get them to try out Scheme despite Lots of
Irritating Superfluous Parentheses, that will already be a success ;)

Maybe Guile support could then be reserved for Real Programmers, but
to answer your question scripting is used very often in this engine,
so I doubt CPS will please them.


> > call/cc has another issue: how do I return? Let's say I'm in the
> > middle of (dialog1) and I need to stop the script. Maybe with a set of
> > double continuations: one continuation at the top level to return to
> > the point before I called the initial procedure (which would stops the
> > script); and another one that is set at each (say_stop) to return to
> > the following line (to resume the script).
> 
> Yes, something like that: a continuation to invoke the "scheduler" (the
> engine), which would be passed the continuation within `dialog1' that
> needs to be resumed eventually.

Well, I don't think the engine should be called _by_ Guile. Rather the
opposite: the engine calls Guile, and does it one time per active
script or hook.


> It may actually be simpler to run the Scheme code in a separate POSIX
> thread, and have it woken up by the engine when it should start working.

Yeah, I was trying to avoid introducing threads in the engine :)
But it sounds like the only usable solution as of now.

Ideally Guile would offer a '(pause)' function that would return from
'scm_eval_string' or similar, with another 'scm_resume()' function
that would unfreeze it :)

-- 
Sylvain