[CF-Devel] multistage map

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

David Delbecq wrote:

>
     
     
     >
     
      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.
     
     
  Not positive if I follow what is being said there.

  One can obviously start to make different decisions what to show.

  For example, you could very well have a map on which some portion is a 
building.  The groundfloor layer of that map would be the inside of the 
building, the second store version would be the roof.

  If the player is outside, and thus has blocked view from seeing inside, he 
could see the roof instead

  this would be cooler, but starts to get really messy.

  How do spell effects go across maps?  I'm thinking most obviously about things 
like light spells (presuming a dark map) - now th light level should probably 
propogate to some extent up as well as out (eg, a player (or torch) on an upper 
map should provide illumination to lower maps, as well as maps above.

  This really starts to get quite complicated.

  I'd think to properly do such 3-d stuff would really require a much more 
extensive change of code, which isn't something I'm all that wild about seeing.



>
     
     
     >
     
      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).
     
     
  This is the wrong approach.  The access logic instead should be smarter - if 
when needing to look at lower map, it isn't in memory, load it in at that time. 
  And when accessing that lower map, update its swap out time so it doesn't 
disappear from memory immediately.

>
     
     
     >
     
      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)
     
     
  Be very careful about implementing this.

  A 'grouping' of maps for resets is fine.
  A 'grouping' of maps for swaps is completely unnessary IMO.  And doing so 
probably has more bad effects.

  Eg, you're going down a dungeon, killing things as you go. That group of maps 
all swap out at once.  Lets say it is 5 levels for simplicity.  You miss a few 
generators on level 2. You get down to level five, clean up, and start heading 
up, only to find out that level 2 is jammed packed with whatever monsters were 
generating.

  Is that really a good thing?  I don't think so.  I'd much rather have a few 
generated monsters be that, but it not being jammed packed.

  One could argue the swap out time may be too low.  But at the same point, if 
your not on a map, I don't necessary see a lot of reason why you shoudl get 
credit for kilsl on it.  The current code keeps that relatively simple - you'll 
get some exp for kills as long as that map is in memory, but not for ever.

  Remember, at the same time, while your spell may not be killing objects after 
the map is swapped out, at the same time, the map isn't generating monsters or 
otherwise changing - it is basically frozen in time.  Seems fair both ways to me.



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