[Adonthell-devel] More v0.4 design issues

[Kai Sterker]

As it seems that we more or less reached an end with the save game
discussion, here are a couple of new topics:

I won't say much about any mapengine features. Alex knows best what to 
do and how to do it. Just two things.


* Combat:

Should it take place on the map or on a different screen? So far we
headed for latter, and the question is how this will work in a
multiplayer environment.

One suggestion is that enemies are visible on the normal map (unless they
waylay the player). First of all, from time to time normal NPC's will turn
hostile and they are visible before. And second, having various creatures
walking around (both friendly and hostile) will add to the quality of the
environment. It'll also help player to avoid some battles if they want to.

Whenever a hostile creature comes into a certain range of the player, we'd
turn to the combat screen. A different player (or other enemies) that come
along the way would see them standing on the map, possibly with some
symbol telling that they are engaged in battle. And once they get close
enough they'll be "sucked" in.

For other players, their own battle screen will open and they also appear
on the first player's battle screen. As combat will be realtime there is
not much to take care of, as each creature involved would fight more or
less independent from others. Etc. ...

I think this should be pretty straightforward. More important and little
discussed so far is the map handling as such:


* The map

With v0.4 we should finally be able to have more than a single map :).
And, as I said numerous times before, it would be best if transition
between different maps would be as smooth as possible. The best thing
would be if you wouldn't notice it at all, giving us a continuous world.

This has a couple of consequences. First of all the server has to be able
to keep multiple maps in memory at the same time. At most as many maps as
there are players, as each player could be on a different map. Since the
server needs to have no graphics in memory that shouldn't be a problem.

The main problem is on client side. When switching to a different map, a
rather large amount of new graphics has to be loaded. Even if that is done
in a second or two, there is a notable slowdown. So here are a few
suggestions and ideas:

First of all, we shouldn't store graphics on map basis. Instead the client
should have a single cache or repository where it keeps it's graphics.
When loading a new map, chances are good that many gfx used by that map
are already loaded. Of course, unused graphics have to be freed from time
to time. This could be done via a reference count.

The next idea would be to move some gfx references to individual submaps,
especially if only that submap uses these graphics. They could than be
loaded in the background while we fade out and in to the new submap. That
would further reduce the amount of data that needs to be loaded when
switching maps.

Finally, I think the first submap of each map should (a) contain the 
"world map" and (b) have a fixed size. So the worldmap would be a regular
grid of (quite small) maps:

    +------+------+------+
    |      |      |      |
    |      |      |      |  ...
    |      |      |      |
    +------+------+------+
    |      |
    |      |  ...
    |      |
    +------+
 
     ...

Such a regular structure should be quite easy to handle. Especially it
should be entirely transparent to the player and map maker. Both would see
one large, continuous overworld. The map editor / map engine would do all
the actual work in the background. 

Any other submap could either be free in size and form, or we could apply
the same principle to submaps as well. I think first will be slightly
easier, although there remains one problem: what if a submap had entrances
on different maps, like a large cave?


At one point in time, a client had to have 9 such map parts in memory.
The one in the center where the player sits on, and the 8 surrounding
tiles. When the player leaves the center and walks a certain way into an
adjacent tile, we could load the 3 new tiles that lie in that direction in
the background and unload the 3 opposite tiles, so that the player would
be on the center tile again. The renderer had to handle a situation
where either 2 or 4 different maps would be visible at the same time.

If the tiles share a common graphics cache, the loading should be
reasonably fast. It can either be spread over several game cycles (as
the data will not be needed immediately) or put into a completely different 
thread. And since the map tiles are quite small, getting the map data
from the server shouldn't be much of a problem as well. For that it would
be useful if the communication between client and server would support
multiple virtual channels. Then the mapdata could be sent distributed over
several game cycles on a separate channel, without interfering with
necessary state updates.

Which already takes us to the next part: 


* The protocol

That's more or less new for me, so I don't have much of an idea how it
should look like. Therefore I won't go into the details. I just want to 
explain the multiple channel idea some more:

We've agreed that any class that is sent to the client, like a character
or a map is turned into a string representation. With a single channel,
you'd sent, say 4k of map data as a continuous stream, and at the other end
a new map class is filled with that data. Until that process is complete,
nothing else can happen.

With virtual channels, we could chop that 4k map into small pieces, say
about 256 or 512 bytes each. Those can be sent one after another, which
wouldn't make much of a difference to a continuous stream. However we
could also transmit other data between those fragments. That way we could
send less important stuff, like new map areas in the background without
interrupting more important data.

All the receiver needs to do is to distinguish between different objects
sent simultaneously and assign the data to the right ones. In case we
mainly send string/value pairs - yeah Alex, I'm still in favour of this :)
- we can easily divide a transmission into several packets and partly fill
in an object on receiver side until it is complete.

The first packet would have all the necessary commands, like NEW MAP AREA
TO BE PLACED AT POS 2,3 and a unique ID. All subsequent packets would only
have that ID in the header and are automatically assigned to that new map
object. The last packet would have an special flag set to indicate that
this transmission is complete. (Although that info could also be in the
data itself). Now the client knows that this map object is complete and 
can finally pass it to the mapengine. The process of filling in that map 
could have taken several seconds. But updates to NPC's, objects on the 
map, etc ... would have no problem to come through at the same time,
keeping the game fluent while new parts of the map are loaded.


Well, that's enough for now, I'd say. Please tell me what you think.

Kai