[CF-Devel] multistage map

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

tchize wrote:
>
     
      -----BEGIN PGP SIGNED MESSAGE-----
     
     
>>
     
       But you're sure to get other issues, eg, in your example, the player on
     
     >>
     
     the roof wants to fire down on the player on the ground (bow, spell,
     
     >>
     
     whatever).
     
     >
     
     
     >
     
     
     >
     
      That's a problem indeed. For now, rules apply to maps in a separate way. I 
     
     >
     
      need to prepare a list of what world interaction should cross the stage 
     
     >
     
      boundaries (typically a burning hands is horizontal, no stages crossing, but 
     
     >
     
      a magic missile shoud be able to target a monster down stairs.
     
     
  As I think about this more, the more of a can of worms this seems to be.

  Arguably, most spells should be aimed down, just like you could aim arrows down.

  But suppose you have a case where you have a courtyard surround by walls, with 
players (and monsters) being able to stand on top of the walls.

  If I fire an arrow (or other object), am I aiming at a target on the far wall, 
or something in the courtyard?  And how does one control that?  Having objects 
on the lower layer automatically go up when they reach an obstacle would likely 
cause all sorts of problems.



>
     
     
     >
     
      Visually speaking, it's more clever than no object = transparent
     
     >
     
      When the code when to collect the 3 visible faces for the top map, it use, as 
     
     >
     
      starting point, the bottom, middle, top info from map below at same position 
     
     >
     
      (i forgot to tell in implementation, each stage map must be same size).
     
     >
     
      I there was a top but no middle (typically a floor and only one object), the 
     
     >
     
      top reach the middle level (a tree in top map must draw itself above a 
     
     >
     
      monster in bottom map). Then the classical code is used to calculate the 
     
     >
     
      faces, so only difference is we don't start faces calculation with NULL 
     
     >
     
      objects in top middle and bottom, but with info from below map.
     
     >
     
     
     >
     
      Still need to do some fixing, since a middle object found in upper map should 
     
     >
     
      also draw itself over the middle object of bottom map.
     
     
  How do you deal with floors?  If there is a floor on the top map, you _must_ 
ignore all the objects on the maps below it.  From the description above, it 
sounds like you could have a case where middle layer is floor, monster, and top 
layer is floor empty, and it'd take the monster from the middle layer (since 
there is currently no used middle layer on the top floor).  That is just plain 
wrong.

  Also, you probably need some form of reverse precedent, eg, lower map knows 
that there is a map above that depends on it.

  That is simply because the way map updates are done - If something changes on 
the lower map, you must also inform the upper map of that change in case it is 
using spaces from that lower map.

  Otherwise, you get the case where the upper map is basically holding bad data 
- the look of the upper map isn't updated, because apparantly nothing has 
changed on that space, but the data itself isn't accurate, because it may be 
saying that the 'middle' stack looks like X, based on information it had before 
from the loer map.



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