Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Misc notes/thoughts.
- To: "Kristofer M. Bosland" <>
- Subject: Re: Misc notes/thoughts.
- From: GESTIONNAIRE DU Casino <>
- Date: Mon, 11 Dec 1995 14:58:26 -0500 (EST)
- cc: "Michael B. Martin" <>, Tadah <>, crossfire (at) ifi.uio.no
- In-Reply-To: <>
On Mon, 11 Dec 1995, Kristofer M. Bosland wrote:
>
> > Now, I admit to knowing practically nothing about how the current
> > client/server stuff works. However, IMHO, the client should handle
> > the game window(s), including keeping a list of the players inventory
> > and position. When there is an input event (key, mouse, etc.), the
> > event gets processed by the client and is forwarded to the server if
> > appropriate. The client should be in charge of managing map/item
I agree, else the game will always need bazillion of bandwidth...
> The Client should handle all X stuff, including all X type
> Binaries (i.e. XPM, AU), Windows, and Events. The Client/Server
> interaction should be moderately readable text, and asynchronous. The
> Server Should reference Display Items (such as
> pix/humans/players/barbarian) and the Client can render them as
> appropriate (Fonts, XPM, Animation). Should sounds be separate, or part
> of the "Image" of an Object? The later may lead to invisible objects to
> provide environmental sounds.
I think there should be a way for the client to download all the
archetypes/XPM/etc, because game masters may create new ones for their
own map upgrades...
> I also think that the Server should give the Client ids for each
> object, and these can be refered to during intercationn (so that each one
> does not completely need to be redescribed). I.e. object77 moves north 1,
> or object77 moves to 22,16. I think that you could get alot of
> functionality with a minimum of bandwidth this way. Occasional
I agree, but won't it use up a lot of memory, keeping all those handles ?
---
Casino