[CF-Devel] multistage map

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Lundi 11 Août 2003 09:13, Mark Wedel a écrit :
>
     
      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.
     
     >
     
     
     
You forgot to mention the fact visible faces (not speaking of los here!) of a 
map are calculated on a map basis, not on a player basis.

>
     
        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.
     
     >
     
     
     If think there should be some interaction, but it takes time to put in place 
which. At least, falling is one of the most obvious one.
What i thought is if player is surrounded by 'can see the sky' (mean nothing 
at same place on higher maps) squares, then this would mean he would be more 
interested in seeing the roofs than the ground. Since around him roofs and 
ground is the same, there would be no impact in surroudings interactions.
>
     
        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 big world use map tiling. If on a tile i put a higher stage map, am not 
forced to tile this higher map on whole bigworld (thanks god). however, to 
prevent the feeling of world cutting (when on the upper map, what you see is 
limited to upper map size, unless this uppermap tiles too), this could be 
needed to surround this map by a transparent tiling (1 map distance should be 
enough). You would argue: 'yes but what happens if am flying an goes to the 
border of this upper map tile? the same problem arise again and you end up 
with covering bigworld to prevent it'. Am still looking for solution, perhaps 
having something like a 'no_pass' force flying player to try to go down 
automatically, or better a no_fly. Investigating.

>
     
      > 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.
     
     >
     
     
     
What i did the first time is when upper map loads, loads lower map too, which 
messed me wince lex loading code wasn't recursive :P
Anyway here is how it works for now
When trying to swap a map, look if there is an in_memory upper map.
If that is the case, don't swap (this upper map needs almost always infos from 
lower map).

But i plan to implement a more generic way. It is a pain to see in a quest the 
first map has been reset while the treasure map at the end is not reset and 
so empty. I plan to implement some kind of block-reset block-swapping system 
in which several map can be linked as being part of a same reset-block or a 
same swapping-block. This would mean, for example, i could enter the second 
cave of a quest cast a case cold to kobolds, then go safetly up, without 
wondering after 2 minutes if the map was swapped out and thus my cold not 
killing kobolds anymore. This may also help synchronize the fact sometimes 
random map are not coherent with their final map (dunno if corrected now)


>
     
        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
      
      
     -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/N1hdHHGOa1Q2wXwRAsYaAKDfIr31hZLBEZfWty+dY3/BtP8tcQCfRfHW
zbODLVWASiAp1ugX2VMEN/Q=
=9/c1
-----END PGP SIGNATURE-----


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