[CF-Devel] Future crossfire changes/projects <Basic's ideas>

Mon May 28 01:59:26 CDT 2001

 My general impression with your suggestions it that these would probably be
good things to do if we were still early in development (ie, if we decided to
make crossfire now, much of this should be done).  But with the current status,
I would rather look forward with new featuresw than go sideways - keeping the
same feature, but how those features are used end up being different.  But some
notes below, as there arre some good ideas:

Bob Tanner wrote:
>

      Change: Convert archfiles to xml

 First, I note that currently more than just the archfile uses a commom format -
the map file is basically the same as the archetypes file, as is player save
files.  So at minimum, either legacy support for the older format is needed, or
conversion tools would also need to be written.

 My biggest question on xerces is what is the performance like, and how is the
data represented to the program using it.

>

      An up to date handbook would be as simple as using cocoon, some stylesheets and

     >

      the archfiles for html/web presentation.

 That seems a bit dubious to me - the majority of the handbook is information
not derived from archetypes.  Now that information can also be put into the
archetype file, but that would seem a bit odd.

>

      Conversion to other formats (like PDF via FOP) would also be simplified.

 I'd really like to get some real world examples on what would be done with this
archetype information.

 I know the concept of xml - self describing.  So if you have a phonebook (lets
say) in xml, then your can trivial convert it to presentable format, even if you
organize it different/have different information (maybe you do have e-mail
addresses in addition to real addresses, while someone else doesn't store that
information).  Being able to convert a phonebook into something presentable
makes sense.

 It strikes me the arch data doesn't fall into that category nearly as easily. 
This could be useful for the spoiler, but of course you still need filtering
support.

>

      Because XML is self-describing, additions to the format would be easier.

 I personally don't think adding stuff to the current arch structure is hard -
there just seems to be some amount of apprehension from developers to do this.

 The real hard part isn't the parser, but typically doing something with that
data and everything related with it.  Adding the Pow stat a while back wasn't
hard from a parser/save issue, but updating all the code and archetypes to use
it is the hard part.

 To me, the biggest reason not to do this is the fact that we already have a
working parser.  If we were starting out and lacked a parser, it would be very
compelling to take something that already that worked.

 The biggest reason to do this would be that it provides more standard parsing
abilities for many languages, as you mention.  However, localizing the current
parser could probably done with less overall work (and really, the parser needs
to go with the map to be useful in most cases (ie editors), and I think that
would still be true with xml)

>

      ==================================================================

     >

      Change: Re-write crossedit in java

 I don't think you will get much disagreement that a new editor is needed.

 In all cases, probably abandoning pretty much all the current crossedit code
would be prudent, simply because a lot of the code currently used with the
editor is pretty intermixed with the Xt code there.  OTOH, a C (or c++) editor
can at least recycle the current parsing and loading code.

 If it remains in C/C++, then perhaps it at least possible to do something like
the client - keep all the non graphics code for the editor localized and not mix
it with the graphics code.  But this is probably much harder for the editor, as
pretty much everything it does is interact with the player, so there really
isn't that much common backend.

 My one really big worry about java is performance.  If the performance is just
too slow, people aren't going to use the client anyways, and so someone ends up
writing a new one in probably a platform specific mode (ie, unix, windows, or
mac only).

 Perhaps make the editor in SDL?

 To me, ideally, the moioier common ground that can be kept between all
components, the better.  That means the core developers can in theory at least
do minor updates to all pieces.  I think you are more likely to get people to
learn to modify the editor if its in C and a common toolkit than something like
java.

>

      ==================================================================

     >

      Change: Re-write client to use SDL

 A SDL implementation of the unix client may not be a bad thing.  I only
recently learned GTK - I'm not likely to learn SDL anytime soon.

 The client was written to try and keep the graphic vs non graphic support
separated, and it works for the gtk/X11 client.  SDL could certainly be added on
top of that.

 But there is still nothing preventing yet some other person do decide they
would rather do say a Mac client and not use the code or modify it such that its
now divergent.  I don't know of any way to prevent that - an SDL client may
still not, simply because someone may want a more native look, or wants the
style different, or whatever else.

 A client written in anything but C will obviously need to diverge from common
code.

 I may be wrong, but a very quick look suggests that SDL is really a low level
toolkit.  So to be useful, implementation of things like scrollbards, buttons,
pull down menus, etc would need to be done.  Perhaps there are already toolkits
that build on top of SDL.

 But my other worry in general is number of required applications needed to
support the application.  I know that I have personally given up on installing
some programs after finding out there are a dozen dependencies I need to solve. 
This isn't that big a deal with linux which has prepackaged rpm's for even
obscure stuff, but when on solaris, this can be a real pain.

 I will note that there is a gtk+ for win32.  I have no idea how good it is -
its at 

     http://user.sgic.fi/~tml/gimp/win32/.

       If its at all decent, that means
that in theory at least, there already is at least a cross platform/open source
client for windows - someone just needs to compile it up.

>

      ==================================================================

     >

      Change: Support WorldForge Atlas protocol

 Once again, if we were just starting out and didn't have a protocol, this would
be more compelling.

 We already have a protocol - not ideal, but from what I see on their webpages,
probably more mature than atlas (albeit specific for just crossfire).

 My biggest worry look at the referance is the comment which was basically 'this
protocol is preliminary and text based, but will change to binary (incompatible)
in the future'.

 This protocol seems just way to early in development to be considered for use. 
And I really don't want to rely on something like an external program that is
that early in development for such a key piece. 

 Maybe in a year, relooking at this might be reasonable. But right now, I don't
see this really gaining anything, so seems like an awful lot of work for
nothing.

 I would also presume by the very extensible nature and the fact that a proper
client can run on any server that writing a conforming client would also just be
a lot harder (as you can not presume anything about form or data, so you need to
support in theory any number of attributes for the player, items, maps, etc,
requiring then a very general purpose client, which obvioiusly gets much more
complicated).

 My guess is that for most part, people writing the client would not do that,
and instead write for the data they are expecting.  I would also think that
gives better results for a specific game engine - ie, the data important to
crossfire may be different than the data for another game system, even though
the data is the same (ie, you want that data displayed more prominantly (say in
form of a scrollbar) when playing crossfire, but not that other game.

>

      Could have many different types of clients. Text, 3D, iso, etc..

 Just as a note, the current protocol does not preclude that in any way, or at
least not in any way that an atlas client would allow - no matter what the
underlying protocol, there is still some set of underlying data that is being
sent, and the client can do what it wants with that.

 In theory a 3d client could be written with the current protocol - it would get
image names from the server, and could then have an idea what to draw based on
that information.

 Realistically, a text implementation, while possible, would probably be
difficult (just from play point of view - there are so many monsters, that just
having a letter represent them may not be all that useful - fitting that in the
standard 96 viewable characters would be difficult.  And if you are presuming
you can have your own font or other special viewable characters, whats the
point?  To me, a text client could be useful for things like the smaller devices
out there).