Re: CF: Split engine vs rules?

[Mark Wedel <mwedel@scruznet.com>]

Commander Gros wrote:
> 
> 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 !).

 Anything is possible.  What it really comes down to is time it takes to do the
code.

 There was discussion a while ago about going to c++.  I think it more or less
came down to that if we want to go in that direction, we might as well start
coding from scratch than try to adapt what we currently have.

 Certainly, crossfire has changed a lot over time.  I only got started around
.89 or .90 (I think about 10 years ago?).  I don't have a list of all the major
changes done since that time, but a big one certainly has to be the
client/server split.  There are still bugs being uncovered by that change.  But
certainly, the model for updating information with the change has to be thought
out.



> 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.

 but someplace, what that action does must be known in the code (or interperted
via the object).  So if you go by Frank's suggestion and add callbacks,
someplace you need to know what that callback is and set it.


> 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.

 I wasn't planning on it - at least from the rules standpoint.  By general
objects, I meant things like buttons, exits, grates - stuff the player may
interact with, but does not directly apply.

 Certainly equipment must be with the rules portion of the game.  A laser gun,
for example, would need specific code to support what it does, and probably can
not be easily generalized.

 But it does sound like perhaps a more scaled back approach is desired by at
least some on the list.  Presume crossfire as the default gaming system, and
thus its set of statistics and the like - the rules will still take care of
dealing with that, but that then simplifies things and may allow for more
general case objects.


> 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...

 That would certainly be possible - there would be nothing preventing that. 
However, at current time, since it is largely distributed source based, that did
not seem to be a big point worth bringing up.


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

 This is perhaps a different topic, but the main things for 1.0 as I recall:

 1) stability of the game.  I think this is slowly getting there.
 2) balance of game.  This needs a bit of work.
 3) quality & completeness of maps:  Also needs a bit of work.

 I suppose there is nothing wrong with saying 0.95.5 is the start of the
codefreeze for 0.96, and the redone object stuff will be for crossfire 2.0

 Now there are some issues on this.  I think from a few recent messages on the
mailing list that buttons are a bit of a nightmare - I'll start a seperate
discussion on that.  but one big problem is that expected behaviour for a lot of
stuff really is not documented, so achieving some of the above could be
difficult.


> 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.)

 But that example presumes that as a player/GM, you like GURPs enough for all
your gaming needs.  I don't think that such a generalize system can be done for
crossfire that it would be so customizable that just by changing objects you can
now switch to something else (say AD&D).  Certainly you will need some
supporting code on that.  Or perhaps another way would be that it would be
easier to re-write the rules for AD&D instead of trying to put in support to
read those run time values.

  That doesn't mean that crossfire will ever be that state - it may be possible
that code deviation from the crossfire rule set really is minor adjustment and
not a completely new game system.

 It does strike me that the rules side code must be compatible with each other. 
For example, you could not take Gurps equipment and apply it with the same
values to AD&D style rules and expect sane behaviour, and I think the same will
be true for this.  The equipment in the game must be compatible with the player,
which must be compatible with the spells ( a charisma spell doesn't make a lot
of sense if you have no charisma attribute).  monsters and players are basically
the same object, so they need to be compatible with each other also.

 So using function pointers to call apply & time & other related actions won't
logically do anything a lot different than calling rules_apply with the
approaching switch statement in place.

 Note that one change I do plan to make in the rewrite is to reduce the number
of object types and go more into subtyping of objects.

 Perhaps what may make sense (going back up to the c++ discussion) is having the
engine in C, since that is a lot of the code that does work as expected and
won't need to be changed, but make the crossfire rule set c++ based so that
subtyping and the like does work better.  Of course, now the problem is we are
mixing C and C++ code which can get a little messy, but it should just be
function calls back and forth.
-
[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]