[CF-Devel] multistage map

[crossfire-devel-admin at archives.real-time.com]

tchize wrote:

>
     
      Someone argued me this:
     
     >
     
      "why coud you aim at player below, while player below can't see you? It's 
     
     >
     
      dangerous, better not allow aim down for fair play"
     
     
  Probably true.  Of course in a historical sense, one side having a distinct 
advantage isn't uncommong (eg, arrow slits behind a merlon, while the person 
outside the castle is in the open).

  But if you do have elevation, you do get odd issues - if we pretend the roof 
is flat, then a player at the edge of a roof should be able to see directly 
below and other people him.  However, if that player was in the center of the 
roof, then players against the outside walls should be invisible to him, and him 
invisible to those players.

  But to really do this would then mean knowing the height of each level 
relative to the size of a mapspace.  If we pretend each map space is 10' square 
for indoor stuff, but for this particular map, each level is 20' high, those 
calculations are different than if each level is 10' high.

  I would note that if players above can't interact (eg, attack) players down 
below, then there has to be some means for the player to know he is on a higher 
level (spaces down below look different or whatever).

  But then we start to get the question - if these players can't interact, how 
much advantage do we really get from this map layering?  Some maps already use 
'fake' layering just by copying the base map to the place you are supposed to be 
able to see around.

  And in some cases, that is really the only way to do it, eg, maps where the 
terrain you are viewing is say part of the bigworld map, where with your code, 
it would be more difficult to do due to map size mismatches.


>
     
      The info from map below is just used as a starting point. I use the  classical 
     
     >
     
      code after to calculate what is visible. And in classical code, when you find 
     
     >
     
      a floor object, behaviour is "forget everything about faces, start again from 
     
     >
     
      this floor"
     
     >
     
      So if there is a floor in the upper map, nothing, at this tile, is drawn from 
     
     >
     
      below map. Simply floor is bottom and if there is nothing on floor, we only 
     
     >
     
      send one face to client, like in classical map when there is only floor at a 
     
     >
     
      tile.
     
     
  Ok - that's good - wasn't clear from your previosu message.


>
     
      That's already done, in some part, since when a P_NEED_UPDATE is handled at 
     
     >
     
      the bottom level, when calculations is done, it ask the above map to 
     
     >
     
      recalculate the concerned square too. That's how it is possible to see player 
     
     >
     
      below moving.
     
     
  That's also good.  But one could have to be careful about using stacked maps - 
if (as I think would be correct) you could have multiple stackings of maps on 
top of each other (5 story building), it would mean that a firebal going off 
would now mean 5 times the number of map updates, as each map above would need 
ot see if its view changed.

  This is really the only way to do it, but this does impose a bit of extra cpu 
computation time.


>
     
      And i did alos implement something less obvious but which laid to strange 
     
     >
     
      behaviour in my first attemps:
     
     >
     
      Don't swap map below while the upper map is still in memory....
     
     
  The way the tile code handles this is that whenever a space in it is 
referanced, the map swap time is reset.  I'd think something similar could be 
used in this layering - if an upper map looks at a lower map, reset that lower 
map swap out time.

  IF that upper map looks at a lower map, and that lower map isn't in memory, 
bring it back into memory.

  After all, suppose you have a dungeon that have puts and whatnot where the 
player starts on the top.  In this case, the lower map isn't going to be in 
memory, but there are cases when the upper map may need to access it, so it 
should be brought back into memory.

  The idea of having pits where you could see what is below you would certainly 
add some interest to the game (wow, there is a dragon down there?  I don't want 
to be heading down there anytime soon).



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel