unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Sylvain Beucler <beuc@beuc.net>
To: guile-user@gnu.org
Subject: Long-lived Guile scripts in a mono-threaded game engine
Date: Mon, 26 May 2008 23:19:00 +0200	[thread overview]
Message-ID: <20080526211900.GB14261@perso.beuc.net> (raw)

i,

I'm contemplating adding Guile support in GNU FreeDink, which is a
game engine for Dink Smallwood, a 2D scripted game.

Currently there's a "manually coded" scripting engine which is pretty
limited and buggy, though it works decently enough and was already
used for large extensions.

I'd like to add Guile as an alternative :)


Currently I'm facing several issues, the main one is how to manage
long-lived scripts:

The engine runs in a single thread, and the game loop essentially:

- passes over all sprites in a screen, and runs the scripts attached
  to those sprites

- detect collisions and run associated scripted hooks

- perform other non-scripted transformations such as sprite
  progressive moves, update the status bar, etc.

- the game screen is then refreshed with the new game state

- repeat


Scripts last more than a single game loop. They are not basic scripts
that describe what happens in a single engine step; instead they
describe what happens in the story.

For example, a game introduction will create sprites on the screen,
move them around, make them say lines that the user can read (or pass
using [space]), etc.

That script can also change the current screen (which kills all other
scripts in the current script).

Multiple scripts can run in a single screen, but they run the one
after the other, not in parallel. The order/priority is known.

Scripting is essentially frozen during the screen refresh. This avoids
putting mutexes everywhere.




How could I do something similar with Guile? I didn't find a way to
make a guile script pause (and return to the caller).

I guess one possibility is to run all scripts as independent threads,
and make them lock on a global mutex. However, as emphasized in this
article
http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/
I would appreciate non-preemtiveness, for simplicity.

I think what I'm looking for is similar to Lua's coroutines
(a.k.a. fake threads - one coroutine at a time)
http://lua-users.org/wiki/CoroutinesTutorial

It's also important that running scripts can be terminated by the game
engine if need be.


How would you do this with Guile? :)

Thanks,

-- 
Sylvain




             reply	other threads:[~2008-05-26 21:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-26 21:19 Sylvain Beucler [this message]
2008-05-27  7:58 ` Long-lived Guile scripts in a mono-threaded game engine Ludovic Courtès
2008-05-27  8:33   ` Sylvain Beucler
2008-05-27 13:20     ` Ludovic Courtès
2008-05-27 16:14       ` Sylvain Beucler
2008-05-27 18:08         ` Ludovic Courtès
2008-05-27 19:57           ` Sylvain Beucler
2008-05-27 20:30             ` Clinton Ebadi
2008-05-27 18:19         ` Clinton Ebadi
2008-05-27 21:49           ` Neil Jerram
2008-05-27 13:42     ` Paul Emsley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080526211900.GB14261@perso.beuc.net \
    --to=beuc@beuc.net \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).