Version 4 (modified by nckmccnnll, 7 years ago) (diff)




  • We need layers as per this thread: (Nick)
    • Monsters - already exists in cave->monsters
    • Objects - already exists in o_list - should this go into the cave struct?
    • Effects - currently there is a "trap layer" defined by cave->traps; according to the thread, this probably should include light info (SQUARE_GLOW, player/monster lights)
    • Player, Location - these are combined in cave->info; I guess that should be split into what the player can see (SQUARE_VIEW, ...) and intrinsic properties (SQUARE_ROOM, ...)
    • Terrain - already exists in cave->feat
  • Do we need cave predicates? Can the same be achieved through terrain flags, trap flags, etc? Which is preferable, or a combination? I think actually how the layers are precisely handled needs to be answered first (Nick)
  • OK, I'm going to backtrack a bit here. I think for now I'd just like to keep the cave struct pretty much as is (Nick):
    • terrain has a grid-based arrays of numbers representing terrain types
    • monsters and objects have their own grid-based arrays of numbers too, which represent indices in a list
    • monsters, objects and traps also have an array of the appropriate structs (the lists referred to above) to keep all the actual detail on the instances that are at the relevant grid reference
    • all the other grid-based info can be dealt with using the info flags because it's pretty much yes/no information
    • traps are the anomalous case; maybe they should have their own grid-based array of indices too
    • I think cave (well, square) predicates are good and needed and should be used everywhere