adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] map structure


From: Kai Sterker
Subject: Re: [Adonthell-devel] map structure
Date: Sat, 13 Jul 2002 17:23:08 +0200

On Sat, 13 Jul 2002 15:46:13 +0200 Kai Sterker wrote:

Yet more design ideas! :)

The diagram in my last mail implies that a potential server does have
no own representation of the map. But the more I think about it, the
more sure I am that it doesn't need one! Wait a sec. with the bashing,
let me explain :)

Let's start with the more obvious, and less obfuscated stuff. All maps
are kept on server side, all the media with the client. That makes
sense, as the media (gfx, audio, etc) is too large to transfer during
network play. Transfering small map areas would be okay though. Even
better, if the map isn't available to clients as a whole, it might
prevent some cheating. (manipulation of the local map). 

Because of all that, I think it is enough if the client has it's
representation of the map (for rendering), while the server needs none.
Only the index to hand out map chunks as the clients request them.

But if each client has it's own map (and the server none), what about
items and NPC's and the like?

No problem at all! The server can have a representation of them. It
needs no map for this. In fact, the server alone controls them. 

NPC's are a bit critical, as they change their state fairly often. Maybe
they could be partly handled by the client. The server would only need
to set the schedule of each NPC. The schedule itself could then be run
by  each client. (Random numbers wouldn't be a problem: if we use a yarg
instance exclusively for NPC schedules, and initialize it with the same
seed, the outcome will be the same for each client). Of course, the
schedule code would need some changes for that to work. For example,
schedules should be kept on server side and also send to the clients at
need, to ensure that each client uses the same schedules.

Some synchronization might be needed nonetheless, but at fairly large
intervalls only, keeping traffic low.

Items are easier, as they wouldn't change their state too often.
Whenever a client manipulates an item, the change is send to the server
and from there to other clients. Of course, each item would need a
unique id, so it can be easily identified.


Well, so much for that. I'm not sure whether those ideas are any good or
just utter bullshit, but I thought I'd mention them. Client/Server stuff
isn't relevant right now, but that doesn't mean we need not waste any
thoughts on it. Means less code to rewrite later on :). Still, comments
and the like are welcome. Otherwise, I'll have to continue talking to
myself ;)

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]