Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: images and maps
- To:
- Subject: Re: images and maps
- From: (Scarrow)
- Date: Wed, 13 Apr 1994 13:04:09 -0700 (PDT)
- Cc: crossfire (at) ifi.uio.no
- In-Reply-To: <> from "Carl Edman" at Apr 13, 94 02:58:25 pm
> > player walks into a new map area, with 20 different monsters he's
> > never seen before.
> > His connection gets flooded with loading new information.
> > Meanwhile, the monsters trash the player.
> > We COULD make it so when you enter a map, you are "invulnerable", but
> > I think that's an unclean thing to do.
> Ah, yes, this is a real problem. I only have a few partial answers to
> it.
Well, here's a suggestion. Transfer, at the beginning, a set of bitmaps
designed to represent the default (i.e., a monster default, some wall
defaults, etc.). If the transfer of a bitmap takes longer than a certain
length, display the map using default bitmaps for those bitmaps which
have yet to be cached by the client. This may not seem like as good of a
solution as sending all the bitmaps at the beginning, but I for one don't
care for large delays at the opening which could be relegated to small
delays while playing. Of course, an intelligent client could cache these
images permanently to disk, and then you'd experience no delays unless
new bitmaps were sent. It could also be possible to key the bitmaps
somehow so that, say, revising an old bitmap could cause it's retransfer.
This key could specify whether or not the bitmap is local to this server
or not (have user defined bitmaps set some sort of flag, for example),
which bitmap it is, which revision of this bitmap it is, etc.
By the way, I think efficient LOS is possible (indeed, NetHack
claims to have gained an overall savings after having switched over their
code to a LOS based method), probably using precompiled tables of some
sort. I think a server should try to isolate to itself any mechanisms
which limit the amount of information the client should receive. The
client should receive only that information which is perceivable by the
player using the client. Netrek has gotten unreasonably complex and
irritating with it's RSA key scheme just because of the player written
client problem. I don't care if somebody writes a client that can play
a game of Crossfire better than I can, but I do care if somebody writes a
client that can play better than I can because it can see invisible
properties, see around corners, etc. Arguing that only a few people
would be able to do it is pointless, since once a few people have done it
a few billion more can usually get the source code and do it as well.