Layers

[Nick]

This is something I (and other people) have been going on about for a while, and it seems worthwhile to put a summary down so there can be a common point of reference.

Traditionally, the Angband dungeon (or town) had three layers - where by layers I mean things that could be in any particular spot. These were

1. Terrain: Floor, rock of some sort, trap, door, stairs, etc
2. Monster: Maximum one per square, includes the player, restricted by terrain (eg most monsters can't be in rock)
3. Objects: Originally one per square, then potentially lots per square, only allowable on floors

Now this is roughly still the case, but some variants (notably S and NPP) have introduced another layer for "effects" - which includes things like traps, clouds of gas, spider webs, etc. In this model, some terrain like traps and glyphs of warding move to the effects layer, which allows traps on tings like doors and trees (if you have them).

But there is a lot more information about properties of dungeon squares, largely incorporated in the CAVE_* flags. This has started me thinking about what the layers "should" be, and I have come up with the following potential candidates:

• Monsters: Obvious
• Objects: Obvious
• Terrain: This becomes less obvious the more you think about it. There's an argument for there actually being two layers here - the floor, and what's on it. This becomes more forceful if you have terrain types like lava or ice.
• Lighting: Currently handled by CAVE_GLOW, and also affected by the player's light radius. Note that Sil makes a lot more use of light and dark.
• Location: The square is part of a room, or a vault, or something. This actually has lots of potential uses - themed areas of a level, for example.
• Player-dependent: The map as displayed is a combination of the world as it is and player knowledge - reflected in flags like CAVE_VIEW for visible squares, and CAVE_SEEN for squares the player has seen at some point. This is also relevant for the perennial issue of whether the player should see a monster opening a door on the other side of the level. Which bits are trap-detected is also part of this.
• Traps: Obvious - includes monster traps for variants that have them, and glyphs of warding.
• Other effects: NPPs gas clouds and FA's webs are examples.

So it would be fairly easy (conceptually) to establish nine separate layers, but I'm inclined to think that some of these are better handled together as currently. I think my favoured model is monster, objects, terrain (all), effects including lighting and traps, and location including player-dependent stuff. The main change there is to move lighting from location to effects; that's a gut feeling rather than a considered opinion.

Any thoughts welcomed.

[LostTemplar]

Player-dependent: The map as displayed is a combination of the world as it is and player knowledge - reflected in flags like CAVE_VIEW for visible squares, and CAVE_SEEN for squares the player has seen at some point. This is also relevant for the perennial issue of whether the player should see a monster opening a door on the other side of the level. Which bits are trap-detected is also part of this.

Regarding this I would suggest not to be greedy, and spent two bytes per tile to store "looks like" character and attribute. Initially all map looks like black space, and then player explore, it remembers last seen character/attribute. So if something changes out of player's LOS it is not shown immediately. Monsters should be drawn as an overlay on top of this. I currently use this and it seems to work. This also separates map drawing code from actual map updates.

Btw monsters/objects are not actually a layer, since they are stored as arrays, indexes on map are just to speed up access.

[Nick]

Regarding this I would suggest not to be greedy, and spent two bytes per tile to store "looks like" character and attribute. Initially all map looks like black space, and then player explore, it remembers last seen character/attribute. So if something changes out of player's LOS it is not shown immediately. Monsters should be drawn as an overlay on top of this. I currently use this and it seems to work. This also separates map drawing code from actual map updates.

Yes, thanks for that - I had been thinking along those lines, but neglected that aspect in the summary. I guess that really does require a layer of its own.

Btw monsters/objects are not actually a layer, since they are stored as arrays, indexes on map are just to speed up access.

Originally I believe the layers were a graphical construct - the choice of what you showed in the grid went monster, or if none then object, or if none then terrain. Still calling them layers is maybe a bit confusing, but I think it's probably no worse than any other word. And I'm concerned with everything that can be in a square and the relationships between them, so I do need to include monsters and objects.

[takkaria]

[*]Player-dependent: The map as displayed is a combination of the world as it is and player knowledge - reflected in flags like CAVE_VIEW for visible squares, and CAVE_SEEN for squares the player has seen at some point. This is also relevant for the perennial issue of whether the player should see a monster opening a door on the other side of the level. Which bits are trap-detected is also part of this.

I actually think that the player should have their own version of the cave used for display purposes and that player-dependent stuff shouldn't be in the cave layer at all.

[LostTemplar]

I actually think that the player should have their own version of the cave used for display purposes and that player-dependent stuff shouldn't be in the cave layer at all.

I use similar approach too, so I have a map-sized separate 'view' array, that have three possible values for every tile, showing that tile is invisible, visible or recently seen.

[Antoine]

You could put in a layer of compacted dead adventurers under the floor

(Steam roller them if necessary, or get a herd of mumaks to walk backwards and forwards over them a few times)

A.

[Nick]

I actually think that the player should have their own version of the cave used for display purposes and that player-dependent stuff shouldn't be in the cave layer at all.

OK, so this would leave monster, object, effect, player, location and terrain as the groupings for "stuff indexed by square".

So (currently in V) effect would include traps, glyphs and light; player would contain the in view, marked, seen and trap detect info, and location would contain vault/room info. Note that I'm ignoring the CAVE_WALL flag, which is terrain dependent only and so can be handled by terrain flags and/or feature predicates.

EDIT: Oops, did I ignore you, Antoine? Sorry!

[Derakon]

I actually think that the player should have their own version of the cave used for display purposes and that player-dependent stuff shouldn't be in the cave layer at all.

This is what Pyrel does. The player has their own separate map that works just like the game map, except only things the player has seen that aren't updaters (i.e. monsters) are put there. Each turn, the game draws (player's field of view + player's map memory).

One trick here is that Angband will have to be careful with memory management -- if you have both the game map and the player map containing a reference to, say, a sword, then what happens when an elemental crushes the sword? In Pyrel we're fine because item destruction just means removing references to the item; the player can still believe the item is there even if it's been removed from other locations. In Angband you have to do your own memory management, and can't have the player containing a reference to something that has been free()'d.

[buzzkill]

Let's have lots of them. IMO you can't have too many unless memory requirement become a problem which I don't envision on modern machines. Ehh, but what do I know, seriously.

Traditionally, the Angband dungeon (or town) had three layers - where by layers I mean things that could be in any particular spot. These were

1. Terrain: Floor, rock of some sort, trap, door, stairs, etc
2. Monster: Maximum one per square, includes the player, restricted by terrain (eg most monsters can't be in rock)
3. Objects: Originally one per square, then potentially lots per square, only allowable on floors

As long as this is going to be a rewrite...

TERRAIN: Below ground (buried bones/treasure/pits/null), ground_1 (earth/stone), ground_2 (water/blood/null), ground_3 (rocks/tree/wall/door/null), ground_4 thru ground_16 (same as ground_3), ON THE GROUND, IN THE AIR

ON THE GROUND: Monster_1 thru Monster_16, Object_1 thru Object _256, Trap_1 thru Trap_16.

IN THE AIR (0' to 10'): Monster_1 thru Monster_16, etc... (stuff that floats or flies low to the ground)

IN THE AIR (higher than 10'): just for kicks... (stuff that's out of @'s reach)

Obviously this a way more than Traditional Angband would ever use but if the infrastructure is built in it opens a world of possibilities for future expansion or fresh variants.

[Nick]

One trick here is that Angband will have to be careful with memory management -- if you have both the game map and the player map containing a reference to, say, a sword, then what happens when an elemental crushes the sword? In Pyrel we're fine because item destruction just means removing references to the item; the player can still believe the item is there even if it's been removed from other locations. In Angband you have to do your own memory management, and can't have the player containing a reference to something that has been free()'d.

Thanks for putting this so clearly - I was aware there was an issue here, but was having trouble pinning it down exactly.

As long as this is going to be a rewrite...

(snip expansive plans)

Obviously this a way more than Traditional Angband would ever use but if the infrastructure is built in it opens a world of possibilities for future expansion or fresh variants.

This is broadly the way I'm thinking, but I don't think there's actually the need to add in all the extra, unused stuff; the important bit is to make the code sufficiently general that it's easy to modify.

So, for example, having more than one trap in a square is currently not possible in V. When V has an effects layer, allowing that becomes a thing that could be done (if it was deemed good gameplay). And one could put in the code to do that, but not use it yet, but that's not the important part of the restructure. The important part here would be to make sure that there is no other code that is assuming "only one trap per grid" and then building a whole great structure of stuff on that assumption.

[LostTemplar]

"only one trap per grid"

I considered such things, and now I think that current Angband status quo is the best (or nearly the best), here is an explanation:

Objects are nice to have many in a single grid, since objects never harm our '@'. But this is wrong for monsters and traps. Currently I can e.g. detect then look for half a second on a screen, and then think "ok, nothing dangerous nearby and in the direction I want to go, so I can proceed", but more then one monster on a square will break this, I will have to read monster list and examine locations often for an equally cautious play.

E.g. when playing FAangband I never use monster list and rarely look at monster memory.

So I suggest that anything important should be limited to one_per_tile.