MAP, UNMAP and ITEM

[Kjetil Torgrim Homme <kjetilho>]

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.

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>

(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.

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.

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.

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.

An example where a square enters LOS, vanishes, and reappears:
(';' is just shorthand for '\n')
   "MAP 1 1 grass;ITEM 1 1 tavern Goth's inn
    ITEM 1 1 axe a rusty broadaxe"
   "UNMAP 1 1"
   "MAP 1 1 grass;ITEM 1 1 tavern Goth's inn
    ITEM 1 1 axe a rusty broadaxe"
becomes
   "MAP 1 1 9;FLOOR 1 1 grass;FLOOR 1 1 tavern Goth's inn
    ITEM 1 1 axe a rusty broadaxe"
   "MAP 1 1 0"
   "MAP 1 1 9;FLOOR 1 1 grass;FLOOR 1 1 tavern Goth's inn
    ITEM 1 1 axe a rusty broadaxe"

No gain? Well - the client can now draw a nice tavern on a grassy
background if it wishes. It got no hint on how to do complex graphics
like this before. The client also knows that it is impossible to pick
up the tavern. And we can support light sources later.

If we allow the client to be smart, and remember all data about the
current map, the above transaction would look like:

   "MAP 1 1 9
    FLOOR 1 1 grass;FLOOR 1 1 tavern Goth's inn
    ITEM 1 1 axe a rusty broadaxe"
   "MAP 1 1 0"
   "MAP 1 1 9"

There's a lot to be gained there!

-----------

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.


Kjetil T.