Re: CF: Split engine vs rules?

[Commander Gros <gros@dontknow.magellan.fpms.ac.be>]

> To clarify the terms:
>engine: client/server socket code, map logic, general object logic, basic
>commands (north, south, perhaps pickup, drop)
>game systems: statistics, classes, spells, monsters, more specific object
>attributes, attacks, applying objects, etc.
>

One of the main problem is that the source code doesn't seem to be very
well organized. For example, the messages sent or received by the server
are not defined in a "precise" place", so it is not so easy to add or
modify one of them.
Perhaps we should try to make the code as generic as possible. It seems
that crossfire would have been easier to extend if it was written in an
"Object Language" (for example C++ or Java), because nearly all the game is
made of objects. Isn't it posible to think of a C -> C++ conversion (I know
it would be difficult, but it is just an idea !).

For the engine/game system split: it doesn't make much sense for me to bind
the "applying rules" or the statistics on the game system; it would be much
better if each object had his own rules binded with it. Each object could
then be treated in a unique way by the game engine.

>
> My general idea is that the engine would include the code that pretty
much all
>games would need - map loading, storage, rendering.  Basic object loading &
>saving, linked lists to insert/remove from map and other objects, and the
basics
>of movement.  In a sense, this engine would provide enough (with perhaps just
>very minimal additions) to be able to move around in a created world, but not
>really interact with it.
>

Agree with that. Note that it would fit well with my idea of implementing
actions inside objects: the game would only manage the basics, letting the
objects doing all the job.

> Some quick thoughts on how some things would work:
> The engine would handle loading & saving of objects.  When it gets an object
>attribute it doesn't know about, it calls the specific game system module
that
>should then know about these.  In this way, the engine can load walls,
floors,
>and these general objects, but things like monsters would largely get
loaded via
>the specific game system module.  SAving objects would be similiar (call
rules
>game system get_ob_diff).  The idea for implementation is to have the general
>object structure, and then a pointer to the game system functions whenever
>specific actions are needed.
>

Could be a good idea, but it also mean that no object would be "stand
alone". And I don't see why we should make a difference between the
monsters and the objects.

> EAch server would only be compiled with one game system, but swapping in
a new
>game_system directory (and appropriate archetypes) and a recompile is all
that
>is need to get another one.
>

Why not implementing the game systems as loadable modules (libraries ?) ?
Compiling the game again and again doesn't seem to be a very attractive way
of reconfiguring a program...

> I am not really sure if this is the way to go, but if it is, now is
probably a
>good time to start going in that direction.
>

Sure !

> Disadvantages:
>
> - a bit more work to make 0.96 happen.  OTOH, getting a working engine out
>would probably happen faster than it would take to get a complete 0.96 game
>under the current model out.

Of course. But why not fixing the bugs currently known and "frozing" the
game as the 1.0 version ? 

>
> - fragmentation of developers - you may end up with multiple game systems
being
>developed, which means that none gets concentrated on as much, so balanced
map
>and/or game system just really doesn't happen as much.
>

Again, if actions were performed by objects, the game system would not do a
lot of things, and an object could be used regardless of the environment. A
good idea to build "generic rules" is to look at what is done in "generic
RPGs" (I mean real RPGs, not computer implementations) such as Torg or
GURPS ? These rules are easy to understand and to implement, and are
adaptable to nearly any game environment (sci-fi, fantasy, etc.)


I know I insist a lot on the "object paradigm", but this is because I think
such an implementation could benefit to the game a lot. Now, you do what
you want with this, keep it or throw it away...

									Commander Gros
									Ad Dwarvam Aeternam!

-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]