[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 |
Hi,
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.
-Remco
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Rpge-devel] The GUILE API,
Bras Remco 7057 G65 <=