[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Rpge-devel] The GUILE API

From: Bras Remco 7057 G65
Subject: [Rpge-devel] The GUILE API
Date: Wed, 26 Sep 2007 13:23:28 +0200

as usual, here's a bit of discussion about just another not-even-done-yet subsystem. Of course, the subsystem this time around is our GUILE API, which Michael de Lang recently started work on and I augmented a bit with a table stub and a bit of REPL magic.
As far as design goes, I'd like to state my personal goal for this API: "Give the user access to the primitives and show him how to use them." For example, if we wrap our generic mob constructor in some simple wrapping code to have guile execute something like (make-mob 400 400 "blah.png"), which would make a mob, using the sprite in file blah.png at (400,400). Any specific ways to make mobs, like making one using tile as opposed to pixel coordinates, could simply be implemented in guile using some global state selectors implemented in the GUILE/C layer, which would be useful primitives for other purposes themselves.
In short, I'd say GUILE needs ways to manipulate the state of the engine and whatever abstractions GUILE users build on top of those primitives shall be entirely up to them. Besides being easier for us to implement, it forces us to produce a somewhat decent library of standard abstractions so folks can at least use our engine. Meanwhile, being easier to implement in the C layer allows C coders (i.e. us, for the most part) to only worry about the simplest, most primitive language.
On top of those primitives, GUILE users could implement their own languages, for example:
-On top of being able to define and redefine state, GUILE users could write their own language for saving the entire current state of the engine.
-On top of that, GUILE users could define a map transition language, which might support things like saving current state or retaining certain things like player mobs
-On top of those, GUILE users can define ways to enter and exit battle states (which would be a specific type of somewhat-morphing somewhat-retaining map transitions) and of course to have battles play out
-On top of that language, ... GUILE users could define something... like.. well... whatever they want
Normal games would force this stuff into the engine, which would make things very rigid. Personally, I'd say it'd write useless limitations into our engine, whereas by shoving the things into GUILE space, we could define the standard ways, have folks change those if they wish and just have only the limitations that.. well.. mobs and such are... mobs and such...
I guess this needs a lot more experimentation and discussion and really, designing a perfect API from scratch, especially as a design without any experimentation, is impossible.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]