There's a certain ugliness that graphical-tile-based skins of over roguelikes and other TUI-iconography games have, that you don't tend to see with graphical-ti

There's a certain ugliness that graphical-tile-based skins of over roguelikes and other TUI-iconography games have, that you don't tend to see with graphical-tile-based games that were designed to be such — i.e. where the tiles and the tileset are a compression mechanism for scenes originally conceptualized without tiles. I'm quite sad to say that — at least judging from the screenshots here — DF's graphical skin here seems to share that "thin graphical skin over a TUI game" look. What I'm talking about here is best exemplified by looking at this image: https://cdn.arstechnica.net/wp-content/uploads/2022/12/df4-1440x810.jpg https://cdn.arstechnica.net/wp-content/uploads/2022/12/df4-1... . There are two types of snow tile (full snow, and patchy snow) here, surrounded by grass tiles. The full-snow tiles are connected, RPG-Maker "9-cell brush-texture"-wise, as if they're little dug-out ponds full of snow. The patchy snow tiles are all individual, with no ability to blend into one-another, and so end up looking like a bunch of individual objects on a clear grid — like ore deposits in a rock face in Runescape. Neither of these (square-grid connected runs, or non-tesselatable one-tile blocks of varying intensity) is a good choice for depicting snow on grass. A graphical designer who wanted to portray the scene of "a field patchy with snow" in a tile-based game engine, would not create these particular visual elements as the primitives to depict said scene. These primitives are instead only used here because they are the ones that can have a 1:1 mapping with particular underlying DF TUI tiles. I feel like it would be quite practical, if you were building something like this from the ground up, to write an algorithm to extract from DF's raw tile data here, an "elevation map" of snowiness (heck, maybe it's already a pass available internally in the engine, before it gets quantized out as tiles!); to do some smoothing over said snowiness-map; and then to have grass/dirt/sand/etc tiles consume said "snowiness map" as a shader pass over their textures. (I know that all this terrain is deformable. So what? Regenerating a 2D snowiness-map over a slightly-past-the-viewport crop of the tile data [i.e. a very low-res sample grid] would take less time than pressing the key to dig a hole. It could be done every frame, even.) And you could do all sorts of other things like that — e.g. have the lava in https://cdn.arstechnica.net/wp-content/uploads/2022/12/df1-1440x810.jpg https://cdn.arstechnica.net/wp-content/uploads/2022/12/df1-1... be a flowing mass of liquid rather than a bunch of particular static grid tiles. I feel like the only reason the developers of these graphical adaptations of TUI games don't do this, is because they are trying — at least partially — to serve the part of the existing player-base who prefers the TUI version of the game; rather than focusing solely on the part of the player-base who doesn't like TUIs but plays the game despite that, and the untapped market of people who aren't playing the game because of how ugly and gridlike it is. (And if you're wondering, this sort of higher-level adaptation doesn't have to be to the detriment of gameplay. "The grid" just becomes a UX feature, an extra lens and maybe an always-on fade around the player and/or the cursor, rather than something evident in the design of the levels. Compare e.g. Sim City 2000 [evident grid] with SC3000 or SC4 [UX-layer grid] for what I mean here.)