Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CF: Split engine vs rules?




 The comment Bob made about making various tweaks to make the game more to his
liking got me thinking.

 I am in the process of slowly cleaning up/redoing the code for the 0.96
release.  And my thought was whether the game engine should be seperated from
the game system.

 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.

 I realize that this is already done to a good extent in the common & server
directory split.  However, there is lots of stuff in the common which probably
isn't all that common, and if you want to play a different game style (say
science fiction with laser guns and not really spells), you are talking about
probably changing most every file.

 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.

 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.

 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.

 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.

 My thought on pros for the idea:
 - crossfire could be used as a game engine for many game genres, and presumably
the engine itself could get quite stable.  Since the engine itself would be much
more seperated from the actual game system, changes to the game system should
not cause the engine itself to fail.

 - the editor itself could also become much more extensible.  Like the
game itself, the editor itself could completely operate just within the
engine code.  Only if you need to change specific object attributes does
specific game system modules for the editor need to be written.  Most editing
could be done without that - the editor would just push the objects around/copy
them without really caring what the private data for the game system contains.

 - may get more developers as people who like the idea of the graphical but
don't like the current ruleset join in.  Also, discussions about personal style
issues in the code become less relevant, as the game system becomes more
localized and you could have your own private system but still get up to date
fixes without major rewrites/reporting of your code.

 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.

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

 - the client would need to be made a bit more generic - as part of
login/negotiation, the server would need to tell it some information on what to
display (ie, stat 1 is is strength and is unsigned 8 bits, stat 2 is hp is
unsigned 16 bits and should have a status bar, stat 3 is a string with default
label of range, ...)

 Thoughts?
-
[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]