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

Re: site for project building



>>>>[From Frank Tore Johansen]
    
    Note that I haven't given this careful thought yet..this might not be
    the most efficient way of doing things.  And other people probably
    have more experience than me on this way of programming.

I haven't had more experience at that sort of thing.. but I WAS planning
to do the client/server port, so I have given it a lot of thought,
although with a few other people.

    About client/server:  I don't think a total rewrite is neccessary, only
    a "few" central functions needs to be changed.

True.. technically, a "total" rewrite is not neccessary at all. However,
1) almost everything to do with displaying a player has to be scrapped.
2) you have to define the new protocol, and implement it in the server.
3) the code isn't QUITE as modular as all that, with respect to
    displaying a player. It mainly is, but I seem to recall there are a
    few nasties that would have to be tracked down and changed for a
    client/server model.

[Frank continues..]
    I'm afraid the project might stagnate if we try to do too much at
    once.  Let's just concentrate on making a common release first, to
    spawn some more interest in the game.
    
Since there seem to be a lot of volunteers, we COULD have a two-tier
development team. It would take a lot of professionalism.
People could work on specific bugs (and ALWAYS use RCS).. patches to the
display routines would be ignored by the client/server group. But patches
to the main server code could be hand-diffed in.

This would of course mean that nothing TOO drastic could be done to the
old code, or that big mods have to be added in a modular way.


    Like most others (it seems), I vote for letting the client handle only
    display-specific things, like scrolling inventory, clicking on objects,
    etc.  No need to transfer the whole objects to the client, only how they
    look, what color they have, their animations and a few flags (and
    probably a few things that I forgot).

You really really really have to transfer animations to the client.
Animations are a MAJOR drain on the server. There's no reason that the
server should handle animations. It should only handle whether animating
objects are visible or not.

Other people were voting on the client having "read-only" access to game
objects. That does not preclude having the client know about object
types, etc.

  The main issues that came up were "what to do about pixmaps?"
If you distribute a static set of pixmaps with the client, then adding
new objects becomes nasty.
  On the other hand, if you DON'T, you have the problem that the -pix
option has: a really long startup time loading ALL the pixmaps.

  What I and Eric Mehlhaff eventually agreed upon (I think :-) was that
clients should come with an agreed-upon standard set of pixmaps. The
client should ALSO have the capability to add more pixmaps on the fly.
This could either take place at game start, or on a new map, or on
demand, depending on how flexible we wanted to be about new pixmaps,
custom player pixmaps, etc.
[This makes for "interesting" startup pixmap negotiation, but is quite
  doable]

    All objects on a map should probably have a flag for each client,
    which is set if the object has been created, moved, or if it has
    changed in any way since the given client was told how (and where) it
    looked.

Why not just tell all player clients in the vicinity [within 10 squares
or whatever] anything that has changed since last update? I don't think
the special caching for each client is going to be much of a gain, if at
all.  How would you implement this? Have "Boolean move_for_client[100]" in
every single object? You SURE this would be worth the hassle/memory?

It would be nice to have the client do more in the way of map caching.
But actually implementing anything nice gets ugly fast.
[In other words, you can't really, IMO]