Improve the Tiles Build

The purpose of this page is to list suggestions of how to improve the Tiles build of DCSS.

For a guide to tiles creation, click here.

Zombified monsters (zombie, skeleton, simulacrum, spectral thing) should display the original monster type. It's not actually necessary to add a zombie tile for each zombifiable monster. A distinction by shape would already be a great improvement. Here's a handy table for the various shapes:

Of course, we'd also very much welcome more tiles to e.g. distinguish between canines and other small quadrupeds, or actual worms vs. snakes.

As of 0e76c93 and df2f54e in 0.11, there are suiting tiles for all above zombies. — Claws 2012-07-21 17:38

See Tile Image Adjustment Suggestions.

• Blink Frog uses dog skeleton, but giant frogs use giant frog-like skeleton. Inconsistent or intentional?
  • We don't currently have any frog skeletons, though frog zombies do exist. Were you thinking of those? — jpeg 2011-03-25 22:42
    • These are normal quadruped_small and quadruped_large, fitting the zombie sizes. I don't get why giant frogs, giant toads and spiny frogs would be ZOMBIE_LARGE – ie, larger than humans; the tiles are correct though. We're not really expected to have a complete set of skeletons for every single monster – unless you volunteer to draw all of: skeleton, zombie, spectral for all of them. — KiloByte 2011-03-25 23:04
• Death Ooze is just a darkened regular Ooze - too similar in current design (I admit to getting confused) (3546) * “Possibly put in some green or red stripes to represent matter or provide a blackish halo or something.” (XuaXua)
• Water elemental (2008)
• detected panlord tile
• Alligator snapping turtles
• Eye of Devastation – candidate under 3185
• Most tiles that look like the player doll
  • I'm looking at you, Frederick…
• Variations for the Killer Klown to use in animations — co: working on this
• The tile for the shadow imp is of a flying monster, but shadow imps don't fly (see 2202). This also applies to the tile for Grinder the unique shadow imp.
• The tile for Agnes is of a human, but she's a spriggan in trunk.
• Shedu have been drawn by a good for nothing hack, and are beyond abysmal.
• Silent Spectre and Rotting Hulk could use some touching up
• Fix the gnoll's shield / left arm positioning. A completely retouched gnoll tile like the Goblin and Kobold would be cool too.
  • Wait, I don't think they even use shields at all!
• The tile for the iron devil doesn't match the tile for the iron imp at all, now that the latter has been improved.
• Blizzard demons have replaced blue deaths, but still use the blue death tile.
• Gnoll sergeants are not guaranteed to have shields anymore, but their tile shows them with one.
• Sixfirhies can't pick up or use weapons, but their tile shows them with a trident.
• Hell hounds are described as black with red eyes, but look like hounds re-coloured red.

The large pandemonium lord tiles should also be used for detected panlords rather than the outdated demon one. I'm thinking demon_body_normal + a generic head (maybe helmet) without wings would work fine.

New plant, fungus and bush tiles would be nice - I'd love to have more variation (not only recolours!) on these. The plant “monster” could even be represented by a bunch of different plants aside from the tentacle-looking thing that it currently is. — coolio 2011-01-08 13:45

Varied plant tiles were added with 04fdece in 0.11. Variations for fungi and bushes may also be good, though, and certain vault monster plants could have distinct tiles besides recolours (withered plant, demonic plant, petrified plant). — Claws 2012-07-21 17:53

We'll need more tiles if we want to add more clickable displays, e.g. for abilities.

Counter-opinion to the “de-gridding” section: curved edges make movement more difficult. Also sandy floor contrasts badly with stone walls and the green autopickup border and hides small items like needles, darts, stones and bullets. — ortoslon 2011-01-05 12:24

Ideas for improvement:

• a grid overlay
• darker floor tiles
• darker autopickup border
• stone walls should be replaced by Shoals-specific rock tiles

• Distinctive tiles per portal vault entrance, maybe also a matching stone arch type for deactivated portals.
• Differentiate clear rock and clear stone walls. (They currently use the same tile.)
• The gloom cloud tile is supposed to be a sort of wispy magenta overlay, not just a solid overlay. Add a version with disturbance too. — galehar 2010-12-26 00:03
• Other than all other wall tiles, green crystal uses perspective, which looks a bit odd, especially when juxtaposed against normal dungeon walls as happens in a couple of entry vaults.
• Metal wall variations.
• Shafts. They've already been touched and are now more visible than they were in 0.5.2, but they're still kinda hard to see on the dark Dungeon floor.
• Improve icon for general store and add tiles for antique stores.
• Different tiles for gold piles with different amounts of golds, on a very rough scale (few, normal and lots).
• Variations of existing features for greater variety (floor, walls) or animations (lava, fire).
• Replace bazaars' shop “pedestal” tiles with something nicer. They look really odd with the shop itself having a front view but the surrounding pedestal being viewed from high-up, which has the effect of making it look like a wall surrounding the shop. Maybe copy the ASCII idea (light from the shop flooding the surrounding cells) and add lantern tiles that can be overlayed on floor tiles in front of, to the sides of, or surrounding a shop tile.
• Animated abyss entrance – the faces should be moving.
• Improve ice floor tiles.
• Animated Nemelex Xobeh altar - in the vein of Jivya / Xom, animate the Nemelex altar as he represents Las Vegas / Atlantic City. Something obnoxious and neon-flashy, or (if animation works in order), his name scrolling across the banner.
  • No idea where this comes from, but IMHO such a tile could only be accepted if it was done in a pseudo-medieval-conforming way, i.e. replace blinking neon lights with something that makes sense in a fantasy context. Something about cards makes more sense, anyway. — jpeg 2011-03-10 21:05
  • * NX existing altar is already a hot pink banner; her overall concept is gambling if you consider the altar plus the cards. If someone added a new in-game casino reference, I'd wager it'd get applied to NX as well, so the request for (any) animation is coming from her overall “Vegas” feel. — XuaXua 2011-04-04 18:11

• small letters (a-zA-Z) at a size of about 7×12 for the item slot overlay, preferably white and shaded like the numbers
  • I found a reference to the old rltiles set containing a complete set of letters, so I dug them out and they're perfect. Might even come for 0.9 already. — jpeg 2011-04-01 20:51
• smaller armour brand tiles for: running, resist fire/cold/poison/magic, positive energy, preservation, spirit shield, protection, darkness, see invisible, levitation (Yes, that's pretty much all of them… :( — jpeg 2010-01-27 19:45)
  • 4527
• mouldy overlay for rotten corpses
• display glowing monsters (Corona, etc.), e.g. by using a recoloured version of the TSO halo, maybe in yellow

Currently, when transformed, the player looks like the monster that comes closest to the transformation. That is basically okay but can be confusing if the same monster happens to be around the player at some point.
We've got special tiles for pig, bat, lich and statue form now, and the latter two even display the wielded weapon, yay! Thank you ever so much!

Still missing:

• spider
• ice form
• dragon

• female versions of the new Ghoul and Minotaur doll tiles
• distinctive tiles for all runes
• various wizlab tiles

Currently, the Shoals look much nicer than any other branch because both sand and water tiles align seamlessly with tiles of the same type (we're also working on transitions between different terrain tiles). It would be nice if we could apply the same concept to other branches. For this, we'll have to:

1. Remove the subtle border around some (natural) floor tiles.
2. Tweak said tiles to make the edges of all tile variants align smoothly, both horizontally and vertically.

The same applies to wall tiles, though here we only need to worry about making horizontal walls align correctly. There's no need to pretend that a row of walls along a corridor is really one really high wall.

Optionally, once all natural terrain tiles have been “degridded”, add special transition tiles akin to the Shoals' new shallow water “waves”.

Since a properly degridded dungeon layout carries the risk of information loss in the form of making distance estimations more difficult, we should at the same time supply the player with the option to overlay the level with a replacement grid. Ideally, this should be toggleable in-game, so you can normally play gridless and turn the grid on for dire situations where each move is important.

LoginError: On the subject of smooth “de-gridded” walls, I was faced with a similar problem in a roguelike game I was briefly trying to develop, and I came up with a clever way around it using binary math. The game died due to me painting myself into a corner code-wise, and the fact that I never was able to successfully run it on my cellphone, which was the goal of the entire project. It's probably not that noteworthy, but I would like to share the algorithm on the off chance that it's useful to someone.

  public int getDynamicTileID(int x, int y) {
      int up = 8;     //1000
      int right = 4;  //0100
      int down = 2;   //0010
      int left = 1;   //0001
      int output = 0;

      if (Gamestate.theMap.isWalkable(x, y - 1)) {
          output = output | up;
      }
      if (Gamestate.theMap.isWalkable(x + 1, y)) {
          output = output | right;
      }
      if (Gamestate.theMap.isWalkable(x, y + 1)) {
          output = output | down;
      }
      if (Gamestate.theMap.isWalkable(x - 1, y)) {
          output = output | left;
      }
      return output + DYNAMIC_TILE_OFFSET; //dynamic tile offset in this case was 4, to skip the 4 special cases.
  }

The java function to calculate a dynamic tile would take a map of regular tiles similar to crawl's, and iterate over them to figure out which special tile they should be transformed into. In the case of this game, there were no walls, only bottomless pits, so it was actually dynamic floor tiles being generated here. The same code should work for walls easily with minor modifications.

What the code does is assigns the four neighboring tile spaces a binary single bit value. By filling in the binary values for the neighbors, you wind up “building” the id of the final smooth tile. For instance a tile with pits (“walls”) on both left and right sides would have 4 and 1 added to give a tile ID of 5. Here is the tiles image, ignore the first 4 tiles, as they were special cases, the tile in position 5 after that is indeed the one with two pits on the left and right. The code always generates the right tile assuming that the tile images are stored in the proper order. Here is a screenshot of it in action, complete with eye searing programmer-art.

This may also be useful for the Kraken tentacles or other such 8way features. Also, if there's somewhere other than the wiki I should be putting this, let me know and i'll move it over.

jpeg 2010-03-07 13:43:

I'm distinctly uncomfortable with the thought of storing 30-40 tiles for all combinations of the compass directions, and we might still end up having to overlay them if there's e.g. deep water to one side, and shallow water to the other. Thus, my preferred solutions is to overlay up to eight tiles dynamically, which would even work if each of the adjacent cells required a different transition.

Here's a very rough plan:

1. Add a vector of potential transitional tiles to env.tile. This vector will be usually empty but can hold up to eight dngn tiles to be overlayed over the main tile.
2. Add a boolean tile_changed to env.tile.
   • At level creation, tile_changed = true for all cells.
   • Whenever a cell's terrain changes, mark this cell and al adjacent cells as env.tile_changed.
   • Before drawing a tile in los, recalculate the tile vector if tile_changed. Set tile_changed = false.
3. Define a fixed order of terrain types that require transitional overlays, e.g. rock > deep water > shallow water > floor.
   • Even better, define a fixed order of base tiles, so that e.g. floor_grass > floor_sand > other. This should also cover recoloured floor/wall/water tiles.
   • Don't use transitions for any terrain/tile not handled in these checks or for two tiles of the same order (“other”).
4. When recalculating the vector, for each adjacent tile:
   1. Compare terrain with centre tile to see whether we even need a transitional tile in the first place.
   2. For diagonally adjacent tiles, also check horizontal/vertical neighbours in case they require a corner tile anyway, or override the corner tile type.
   3. Store the decided tile in the vector.
      • This may require some special checks to make sure the highest order tiles are drawn last.
5. When drawing the tile, apply the transitional tile vector on top of the main tile.

17:01 < syllogism> by the way, magical explosions look really plain on tiles
17:01 < syllogism> just plain white clouds
17:01 < syllogism> while ascii explosions are colorful and pretty

Perhaps the explosions and clouds could be “de-gridded”, as above?

This has admittedly really low priority, which why it is listed here rather than under the Tiles section above.

Proposed by an anonymous reporter in 2837264:

I think there needs to be a change in the Troll's player doll. It looks
like a bolt upright human with green skin. If you encounter a troll in the
dungeon it looks like a troll. I think the players doll should look the
same. Also when the troll is wearing a robe it should look like it is too
small perhaps a bit bunched up since it would not obviously not be made
for something so large.

My (jpeg's) reply to this was:

It's not only the tiles (where you'd have to take doll customization into
account, thus drawing additional variants for every equipment tile) but
you'd also have to make sure that the pixels work correctly together, i.e.
the cap actually sits on the Spriggan's head rather than floating high
above it, and the same for gloves, weapons, hair and layers of one above
the other.

Even if we ignore doll customization for small and large species
(something that's not really a good idea) and only provide tiles for the
base items, that's still a cloak tile (in 11 different colours), a dragon
hide and armour (in 7 different colours), and an additional design for
robe, animal skin, troll hide/armour, hat, and cap, each in several
colours. Also, the mutation tiles for hooves, claws and horns may need to
be adjusted. Some of the artefacts (crown of D., dragon mask, …) will
require a few more tiles.

The reason I am adding this now is that I feel it has become more viable with the recent automated colour changes. :)

Add an alternative monster tile set depicting the coloured ASCII glyphs. This would amount to about 70 new tiles (52 letters + numbers + special symbols) and the font would have to be nicely designed, but I think that designing a letter tile should still be less work than drawing a real monster. The tiles for features, items and special effects would be unchanged. As an example of a monster tile set using glyphs, see Geoduck's NetHack tile set as well as lagged's NH tile set (both of them copying from each other, with permission). Of course, we can't copy this directly because that's something you just don't do (we could ask for permission for parts of it, I guess). Some of the glyphs in these tile sets have cute details like feet or crowns; stuff like that could be added later but is by no means required. Adding the correct colour settings in the tile definitions will be another work-intensive step, but the actual coding requirement would be comparatively small.

An unadorned font (no feet, crowns, etc.) is entirely workable too. It's what's used in the tile/text interface for Sangband and in some ways it's actually ideal, as no embellishments are getting in the way of the text characters. — erisdiscordia 2010-03-13 19:21

I think that the best way to add this, once we have the necessary tiles, is to add an option that decides whether the glyph tiles should be used or the current ones. We could display monsters without their wielded weapons or use a fixed weapon offset for all symbols, and of course the status effects and overlays would be displayed normally.

If we allow the option to be toggleable in-game, this could even be a nice solution to checking demons' difficulty level. Generally, this could be a transitory step for someone wishing to switch from ASCII to Tiles or vice versa.

• — Porkchop 2010-01-26 14:10: This sounds like a really cool idea, sounds like a lot of work to complete and get useable. I checked out those tile sets in the link and they are really neat. An alternative or interim step to this feature could be a toggle to switch from tiles to console view. A simpler option would be to look at how version b26 '^x' would display the level map: It would display everything in ASCII - maybe something like this but restrict data on screen to what is in the viewport, and if possible add a sidebar with monster list like we currently have in console?

Well, there's a reason we use a compile flag for differentiating between Tiles and console: there are exceptions and differences all over the code, and I don't think that being able to toggle between ASCII and tiles would be worth an overhaul on such a scale. As you say, displaying the level map in a distinct menu would be easier (e.g. the dump command already dumps the ASCII map, so that's very much known) but that wouldn't help the player if there are many monsters on screen and he doesn't already have an idea of the mapping of tiles to glyphs. A monster list would be really nice but at least for my monitor/resolution there's simply no space. (Also wouldn't solve the problem regarding the demon difficulty rating.) — jpeg 2010-01-26 15:51

My NetTiles interface lets you switch between tiles and console with Ctrl-V. The tiles view is however less sophisticated than the local tiles interface (but you can play online). — Luca 2010-05-18 12:39

By 0.11, WebTiles has a usable glyph mode, though not local tiles. — Claws 2012-07-21 17:53

See Tiles Interface Ideas (Bulk).

Improve the Player Doll Editor.

See https://crawl.develz.org/wiki/doku.php?id=dcss:brainstorm:internal:clientserver.

This has been brought up frequently and we still haven't got a detailed plan of how to make this happen, though it is certainly on our agenda. See 2875771 for one such discussion. At some point someone should distill the most important points of said discussion into an itemized wiki list. :)

Tiles development can be an often overlooked topic. It got me back into crawl after many years, and introduces many new players to the game of crawl. Two things that console version has over tiles. 1) Quicker info at a glance, especially when you encounter a mass of '1's - threat level is established very quick. 2) The mid-right sidebar in console that displays a short list of monsters in sight. Somehow solving or providing this info at a glance in tiles would be very nice. Tiles server play will be a milestone of DCSS when it comes, and i am sure, much interest and many new players. — Porkchop

• Thanks for commenting! I added the monster list and demon difficulty to the interface ideas. — jpeg 2010-01-05 09:28

I actually have a couple of ideas as to how it might work, though I lack the programming knowledge to even try to put them into action, and for all I know they're completely infeasible. Feel free to ignore them, if so.

• One way might be sort of like the current nettiles implementation, except have tiles players playing in a larger terminal; the top-left 80×24 could be the standard view, translated via an overlay as with the current implementation, while the additional characters being displayed could contain additional encoded data, allowing, say, for the inventory display, minimap, distinguishing between flame clouds and walls, enemy hit point meters, and so forth. Spectators will only see the top-left 80×24 part.
• Another way might be to have the server and client run simultaneous, synchronized games. CAO would generate a long list of random numbers, which would get sent to the client, so both have the same list. Any time the RNG would normally be used, the random number is simply taken from the list, and all player inputs are sent to the server, allowing the server and client to, hypothetically, run identical games (I think). To ensure they remain synchronous, a hash function could be run over some aspects of the game's state every n turns (for some value of n), and the client and server can see if their results match. If they don't match, the game won't be scored (but the client can still finish the game locally, if the player wants).

Any thoughts? — dtsund

As a player of the nettiles version and thus one of the people who has to slog through all the annoying old graphics and shared tiles and apparent graphical “bugs”, the second version is exactly what I would like to see if it is feasible. The first one is just mitigating the problem a bit; even if it reduces ambiguity we'd still be missing all the pretty tiles that people put so much work into and it'd still look like there were graphical problems. One note: Make sure that the client's-side game checks before making a move that it's still connected to the server, or better yet that the client-one makes a move only after confirmation from the server-game that it's made the move, so that they don't become disjointed by one move if you lose your connection. — Brickman 2011-02-24 16:19

Just thought of two more comments. First, this'd probably be far easier on the server; it only has to send random numbers and hashes rather than the whole screen every move, and it can sit out anything that doesn't change the game's state (checking inventory, opening and then exiting a menu, showing menus at all). Second, it would be minorly cheatable if you hacked the client to not send the move immediately and to give you a chance at “undoing” moves for as long as it doesn't need more random numbers; you can mitigate this by discarding all unused random numbers after each turn, giving even the most determined hacker only one free move (and by that point he'd have to know enough about the code that he could probably almost just intercept and interpret the random numbers anyways). Random numbers would be sent in batches of twenty or so, with the client requesting more if the move has a lot of stuff going on (floor generation might be easier if the server just does it and sends over the state). — Brickman 2011-02-24 16:33

Locating corpses in piles requires stepping on the pile. This makes moving around to prayer-sac corpses after a large fight a bit annoying, same for chopping.

A few simple suggestions

1) Add a custom icon to let the player know a corpse is in the pile

2) Change the color of the ? to indicate there is a corpse in the pile

3) Add a 'mass sac' command that simply 'prays' to sac all adjacent piles.