Re: [Adonthell-devel] More v0.4 design issues

[Alexandre Courbot]

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

This is exactly what I had in mind. That way you could start fighting
against 2-3 ennemies, but then enforcements could arrive. The idea is
even better when in multiplayer mode: if you see someone of your "clan"
is fighting (I don't know exactly how to represent fights on the map,
but as the arena is built from the surrounding squares, I think we
should put something on these squares indicating there is a fight in
progress, and as you said once someone walks into these squares they
enter the battle), you could give him an hand, for example. I think this
idea is the good one.

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

Right, and quite easy to put on.

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

Well, the principle of submaps is that you can switch from one to
another without any delay. Also, I don't think it's that serious if an
object that is used only once is in memory - I mean, I don't think it's
worth the pain of checking when entering a submap whether an object is
loaded or no :)

> 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:
> 
>     +------+------+------+
>     |      |      |      |
>     |      |      |      |  ...
>     |      |      |      |
>     +------+------+------+
>     |      |
>     |      |  ...
>     |      |
>     +------+

What if you enter a dungeon which would be an entire map? I think we
should also allow exceptions for cases like this one.

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

Hehe. More pain for me ;)

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

Wow - you mean you load 3 tiles each time the player makes a step? It
will be a pain, imagine that you have to find these tiles in the file,
check whether there are gfxs to be loaded for these, and perform some
huge memory operations to place them on the map. I fear it'll be
unplayable that way. Also, loading huge blocks of maps isn't better, as
the cost of the operation will undoubtly result in a game lag.

As you know, I'm rather for having different maps connected to each
other by certain points, which would result in a loading when the player
leaves one map and enter another. It certainly breaks the game
continuity, but will consume much less ingame ressources and is much
easier to put on. Moreover, think that the next mapengine will be much
more complicated than the current one (several walkable layers, and so
on...), and such real-time loading will be extremly hard to do.

About the virtual channels, I like the idea. It will need some further
thoughts. For example, I don't know whether the example of the map is
well chosen: when you sent such a thing as an entire map, it means that
the game is in loading process, and that you anyway can't continue
without it. Others critical in-game packet will be quite small, I think,
and won't deserve being cut. But in the case they will, this is a good
idea.

Alex.

-- 
http://www.gnurou.org