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

Client/server..



Ok, its cool that we are finally getting some traffic on this mailing list. 
I have more or less read all of the recent posts and have a few thoughts.

  On the security thing, I think maybe it would be best to concentrate on
getting a working client/server. Keeping in mind that we may (probably) will
want to add a level of security down the road. Basically, lets put the 
security stuff on the back burner for now and instead focus on other things, 
like moving all display oriented stuff to the client.

I've given this quite a bit of thought and as mentioned earlier about objects:


The best way to approach this would be to distribute a standard set of
objects with the client and then build into the client a way to download objects
that aren't in the standard set. 

(Note : by "object" I am referring to an object as seen on the client side, with
only display oriented stuff it in. This is not just pixmaps, but color, name, 
animation speed, etc)  

I believe we should definately rework how the info window is used. Currently, 
It is used for both input and output. Perhaps we should move towards having an
input line and a then a message window where text based stuff is displayed, 
very similar to netrek. This would then make having to type "'" everytime we
wish to do an extended command. As for the message window itself, a lot of 
players here have complained about having stuff scroll off the screen before
they could read the things. (A good example is a player's spell list.)
I think maybe it would be a good idea to have the server send messages to an 
message buffer, then the client could have the capability to have "more" 
button or scrolling back through the older text.

We have discussed here at Chico about making the server side work in a similar
fashion to netrek, in that it would have one process updating maps/objects, then
have a process for each connected player that would have a shared memory
segment with the process keeping track of things. Actually, we already have a
very simple version of this sort of thing here at chico. It accepts a client
and sits there waiting for a couple of things, nothing major by any means.
I have talked with Eric Melhaff (i probably spelled that wrong :> sorry Eric.)
and he seems to think that no real advantage is gained by splitting things up
into different processes. What do you all think?

Anyway, I seem to have written a book here :> hopefully, we can start to get
some input on this stuff and start coding it :>

Tyler.
tvangod@ecst.csuchico.edu