Re: CF: Windows 95, NT

["Mark Wedel" <mwedel@pyramid.com>]

On Oct 12,  4:33pm, Michael Martin wrote:
> Subject: Re: CF: Windows 95, NT
> 
> 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? 

 get the crossfire-0.92.4.client.tar.gz file - this contains a partial
implementation of true client/server.
> 
> 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. 

 This is a compromise.  The client above gets images as needed.  This
has the advantage of a quick startup time (don't need to send 2500 images
or negotiate what images to send.)  The disadvantage is that you are
potentially wasting a bit of bandwidth by sending these each time.  I think
local caching is a good idea, because depending on the system, you may have
a better image format than XPM.

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

 This has been discussed a bit before.  I think on the client side animation,
the server just tells it how fast to animate, and what images (for example,
the power crystal has variable animation speed depending on how much power
is stored in it.)

 I know someone else was working on another game similar to crossfire on
the bebox, last I heard they were being held up a little waiting for software
for the bebox.


-- 
 --Mark