Re: MAP, UNMAP and ITEM

["Carl Edman" <>]

From: Kjetil Torgrim Homme <>
> The three commands MAP, UNMAP and ITEM are really key to the
> performance of the protocol, and it is important that the
> implications of this division is understood.

I agree.  Those are the three big ones.

> As the protocol proposal stands, the semantics of MAP is twofold:
>   1. Tell the client that items at (x,y) are now visible
>   2. Tell the client that the floor at (x,y) looks like <image>

Exactly.

> (1) is fine, but (2) is just a special case of ITEM without a
> descriptive text. This isn't a big deal with Carl's model, because
> the server will have to retransmit all items at a coordinate when it
> comes back into view, and having names for the floor isn't vital,
> although it is nice at times.

Couldn't agree more.  


> But I guess you've gathered that I think I have a better suggestion:
> 

> 1: MAP <x> <y> <light value> [<x2> <y2> ...]
>     I mentioned this earlier: <light value> == 0 means UNMAP, other
>     light values give different amounts of shadow. It is left to the
>     client to render areas with little light appropriately. The
>     client is allowed to ignore the different levels of light when
>     rendering.

Well, as I said before (and wasn't responded to, I think), this is very  
nice.  However in the most common case in which there is any lighting  
i.e. in a dark map with the player carrying a light source, this means  
that you have to send MAP commands for every single visible square  
every single time you take a step.  That may add up to signficant  
amounts of bandwidth very quickly.  Is lighting (which I would like to  
have as well) worth this cost ?

> 1: ITEM <tag> <x> <y> <image name> <descriptive text>
> 2: ITEM <tag> <x> <y> [<image name> [<descriptive text>]]
>     Like Carl's proposal. Note that the coordinates can be changed by
>     itself.

Absolutely.  I think I said something like this before somewhere, but I  
forgot to mention it in the draft.  However, you do need one more bit  
of info which I also forgot:  quantity.  If a client is to deal  
sensibly with items with quantities (like e.g. allowing the player to  
split up a stack of gold coins), it needs to know about numbers.  I'd  
use this format:

ITEM <tag> <x> <y> [<quantity> [<image name> [<descriptive text>]]]

Here <descriptive text> of course means the short form, like you'd see  
in an inventory or when clicking on a square, not the long form which  
some items have (and for which I think we need an examine command).

> 1: FLOOR <tag> <image name> <x> <y> [<descriptive text>]
> 2: FLOOR <tag> <image name> [<x> <y> [<descriptive text>]]
>     This is like an ITEM, except it should be rendered below the
>     items. The object shall not move. The <image name> can change
>     (ie., for earth walls). Like an ITEM, a FLOOR can be removed by
>     specifying "<x> <y>" == "IN VOID". The FLOOR which is most
>     important to render is sent first. The client is free to display
>     as many FLOOR-objects as it likes, including none.

I'm not entirely sure I like having a tag for each floor.  It will  
probably be similar in length to <x> and <y>, so why not just use this  
?

FLOOR <x> <y> [<image name> [<descriptive text>]]

Also, as MAP and FLOOR will frequently be sent together and for the  
same squares, maybe there could be some hybrid form which can send all  
the data in one command ?

> On a completely unrelated note, you forgot to specify animation
> sequences in the image format, Carl! That is a pretty vital point.  I
> think there should be a separate file format for animations, which
> just sends (duration, image name) pairs. (I'm not sure whether
> allowing recursion is useful.)  Important note: the name space for
> animations and images is the same. The client will not know whether
> the filename is an animation until it is told via <type> in TRANSMIT.

Absolutely.  I didn't say anything at all about binary standards.  Your  
idea about composite "animated" images is a good one though, in  
particular if we use a standard format which we couldn't alter to have  
the animation information inside the image itself.

	Carl Edman