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

Re: CF: Windows 95, NT





On Fri, 11 Oct 1996, John W Klar wrote:

> Java...
> 
> The XPM library does not compile under Java, so an implementation is called for
> there.  I'm not convinced Java can handle the load that CF puts on the client
> but I've been surprised before.

I looked at the source for libXpm 4.7 and it looks like quite a bit of
work to rewrite it (or at least the key parts) in Java.  How about using a
different format?  I would suggest either GIF (reading GIF files is
already in the Java AWT) or PNG (if someone does a Java port of libpng). 
But if you *have* to deal with pixmaps, Java supports the calling of
"native" (i.e. non-Java) functions, so it might be possible to have Java
call functions in libXpm.  Considering that Java can smoothly
double-buffer full-window animation in a window larger than the standard
Crossfire window on my humble Intel-Linux/X P90 box, I think Java can
handle the load. 

I've been working on learning Java for the past couple months or so
(following a self-taught crash course in C++), and it seems to me to be an
ideal language for the client.  But, having taken a peek at the Crossfire
code, I don't know how easy this would be (my first glance says, "highly
non-trivial").  The client.c file in the client/ directory apparently
doesn't do much (just parses command-line options, a little preliminary X
work, and network socket handling).  But the "real code" (e.g. the stuff
that draws the window) isn't there.  It looks to me like that code is
spread across both the common/* files and server/* files.  Is this
correct?  Can someone tell me where the split between client and server
source is?  What types of internal data structures does the client need? 
Obviously it has to keep track of the player's inventory, the current map
view, the list of objects on the ground (beneath the player), some player
stats, and text messages.  What else?  Does it keep track of the player's
entire data structure?  And how exactly does the eutl library fit in?  I
get the impression that Crossfire doesn't really implement a "true" 
client/server architecture (except where it uses the X client/server
stuff).  Am I wrong? 

As I understand it, the pixmap data has to be sent to the client every
game session (during gameplay, in fact?). IMHO, it would be best to have
all the graphics (pixmap) data handled at the client end.  The server
should only have to send over the current map and player data (referring
to objects by name or number, I guess), and the client then figures out
which pixmaps are needed and displays them.  I guess animation of
"in-place" objects (like the "glowing" effect of a wand, for example)
could be handled at either end.  (If by the client, then it would have to
know somehow whether the wand had any changes left, since "used up" wands
don't do the animation.  If by the server, the server could simply
instruct the client to display frame #x in the pixmap sequence for the
given object.  The latter method's probably a lot easier to implement). 
Of course, you need to make sure the client and server are synchronised,
so the server would also have a copy of the game objects and their
pixmaps.  When the client connects, the client (or server) initiates a
dialog wherein they determine whether the client has all the pixmaps it
needs, and if not the new ones are then transmitted before the player
enters the game.  This way only new objects created on the server would
actually have to be transmitted after the client is installed (with a
default set of pixmaps included in the client distribution, of course). 
If the server administrator adds an item which uses new pixmaps, the new
ones (only) are copied to the client (which stores them so the data only
has to be copied once), and then the gameplay starts.  This scheme would
make sure that the client has the pixmap data as soon as it's needed,
conserve a great deal of network bandwidth during gameplay, and put less
strain on the server.  Any comments on this strategy?  Now, I'm not
suggesting that the Crossfire developers should do a rewrite to implement
something like this (that'd most likely be a *lot* of work which could be
spent on feature coding).  These were just some thoughts I had. 

This might be stupid on my part, but I think I'll throw this out here
before I quit: Is there anyone familiar with (or willing to learn) Java
programming who would be interested in working on a somewhat
Crossfire-like game?  What I had in mind includes a full client/server
interface (with a good graphical client), multi-player support (of
course!), and a lot of Crossfire-like gameplay attributes (too many to
list here).  Another option would be to do the server in C++ (if you know
C++ instead, or just prefer it to Java).  Why "re-invent the wheel",
instead of just hacking on the Crossfire source?  Well, this type of game
is very well-suited for OOP (resulting in cleaner design and less bugs, I
think) and the Crossfire source is a maze (at least to me).  I have a
number of ideas for the design of such a game (at least a few of which I
think are good ones :), but not nearly enough time to write a working
implementation.  If others were interested, I would be willing to give it
a try.  A simpler (?) short-term project would be to put a Java client on
crossfire, but I don't think the current code would allow this in an easy
fashion.  (If someone can show me otherwise, I might be willing to give it
a try.)

-Michael