Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old November 16, 2013, 00:02   #1
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 53
Posts: 7,590
Donated: $60
Nick is on a distinguished road
Layers

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.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old November 16, 2013, 01:01   #2
LostTemplar
Knight
 
Join Date: Aug 2009
Posts: 670
LostTemplar is on a distinguished road
Quote:
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.
LostTemplar is offline   Reply With Quote
Old November 16, 2013, 02:37   #3
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 53
Posts: 7,590
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by LostTemplar View Post
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.

Quote:
Originally Posted by LostTemplar View Post
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.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old November 16, 2013, 05:07   #4
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,913
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by Nick View Post
[*]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.
__________________
takkaria whispers something about options. -more-
takkaria is online now   Reply With Quote
Old November 16, 2013, 07:40   #5
LostTemplar
Knight
 
Join Date: Aug 2009
Posts: 670
LostTemplar is on a distinguished road
Quote:
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.
LostTemplar is offline   Reply With Quote
Old November 16, 2013, 07:53   #6
Antoine
Ironband/Quickband Maintainer
 
Join Date: Nov 2007
Posts: 1,007
Antoine is on a distinguished road
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.
__________________
Ironband - http://angband.oook.cz/ironband/
Antoine is offline   Reply With Quote
Old November 16, 2013, 09:01   #7
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 53
Posts: 7,590
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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!
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old November 16, 2013, 15:17   #8
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,776
Derakon is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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.
Derakon is offline   Reply With Quote
Old November 16, 2013, 16:48   #9
buzzkill
Prophet
 
buzzkill's Avatar
 
Join Date: May 2008
Location: Indiana, USA
Posts: 2,939
Donated: $8
buzzkill is on a distinguished road
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.

Quote:
Originally Posted by Nick View Post
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.
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.
buzzkill is offline   Reply With Quote
Old November 16, 2013, 22:42   #10
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 53
Posts: 7,590
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by Derakon View Post
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.

Quote:
Originally Posted by buzzkill View Post
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.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.