Re: [Adonthell-devel] Ideas from yesterday's meeting

[Alexandre Courbot]

> > The basic idea, separating graphics from game data, is quite easy to get
> > - actually you just need to define classes without any gfx management,
> > and the client (renderer) would have another class that would be
> > dedicated the them. There's no problem with that. 
> 
> I'm interested in knowing how you store the graphics for Entities in the game.

For now, graphics are stored along with others datas. That is, for a
character for instance:
class mapcharacter
{
  .....
  vector<animation> frames;
  u_int16 posx;
  u_int16 posy;
};

Ugly, isn't it? We should move to something like:
class character
{
  ....
  struct coordinates position;   // Contains both posx and posy
  ....
};

And one class for the client only:
class mapcharacter_dontknowwhat
{
  ....
  vector<animation> frames;
  character * data_instance;     // Points to the character data
  ....
};

This is just the basic idea. It seems globally ok to me, how about you?


> The server maitains the game world as a whole, which includes avatar 
> positions, state of a door(open/closed/jammedshut/broken/etc.), and 
> everything else.  The client maintains it's local game_state which is in 
> effect a copy of the servers's game_world.   
> Which means that if someone opens a door on one side of the world, when you 
> get there it should still be open, unless of course someone has closed it.
> [....]

This means the server has to keep a trace of what information it sent to
who. When I arrive to the door the server must think "Uh, this guy
doesn't know the door is opened" and notify my client. This is quite
some extra work for the server, and it must keep trace of all data for
all clients. Unless you know of an efficient way to implement this?

> > Moreover, the map renderer cannot work with such parts of map.
> 
> Why not?  it should.  At least if you plan on networking it should.  If you 
> have a local game and the renderer can read the entire map file, then sure, 
> it's feasible that the game can look at the entire map, but as soon as you 
> get into having multiple human players in the same world, based on the server 
> client model, you need to have a client able to work with smaller map files. 

Currently it cannot, as often a tile has a pointer to another tile,
which is it's base tile (this is a complex mechanism that allows to
easily create (and quickly rendering) depth effects like walls you can
go behind and in front of. But, I realize that with a slight
modification, it could work only with a part of a map.

Another issue, however, is that if the client doesn't know about the
entire map (I mean, the map itself, not the characters), re-creating the
small map parts you get from the server when you move will be quite
time-consuming. The rendering is quite fast because map datas are
sorted, organized a way it allows the renderer to make assumptions about
the order to draw things. But placing a new object on the map needs
quite a lot of work for the software, so I fear doing so is not really
elegant. Characters doesn't suffer from this, however. Would it be bad
if the client only knows about the entire map terrain? Could a player go
far in cheating because of that?

Alex.

-- 
http://www.gnurou.org