3 ms·

> There's a certain ugliness that graphical-tile-based skins of over roguelikes and other TUI-iconography games have Yes. Your snow example is a good one. My

> There's a certain ugliness that graphical-tile-based skins of over roguelikes and other TUI-iconography games have Yes. Your snow example is a good one. My problem with reworked TUIs is that the graphics emphasize one element of the game and tend to ignore the others. Dwarf Fortress actually supports diagonal paths. With the graphics pack they look like a series of unconnected open rectangles even though a dwarf can walk down them without problems. With a "better" tileset you can see actual diagonal walls. (This screenshot doesn't have a diagonal 1-wide passage, but does have diagonal walls at the edge of rooms. https://i.imgur.com/tryTOUA.png https://i.imgur.com/tryTOUA.png) The graphics are made to attract people to the game not to best represent the fiddly details of the mechanics. I prefer the text because while it's not a perfect representation either at least it isn't actively wrong. > consume said "snowiness map" as a shader pass over their textures. Yeah, to get good looking snow you'd have to do something like this - without the discrete blockiness. In the case of snow this would be easy because DF doesn't have actual game mechanics connected to snow depth or anything it so it would just be a graphics tweak. > have the lava be a flowing mass of liquid rather than a bunch of particular static grid tiles. In the case of lava and other liquids though, the simulation itself is tile based. If you made the surface continuous it would make it harder to tell what was going to happen. > 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 I think DF is mostly the second category. Not hardcode roguelike fans but fans of the DF simulation which happens to be tile based. > and the untapped market of people who aren't playing the game because of how ugly and gridlike it is. I wonder how big this market is, for DF. If you want a game that looks good why go for graphical DF when you can go straight to Horizon or other graphics-first game. If you aren't interested enough in the mechanic to interact with it, will some 90s-era graphical skins make the difference? > "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. It would be interesting to maybe anchor building items into an easily understood and simulated grid, but where the grid was arbitrary in relation to the map and other grid-based elements. So you could point your fort in any arbitrary direction in relation to the terrain but the walls would still function properly. DF is a tunnel digging and wall building game where they have to contain fluids or block enemies and it wouldn't be fun debugging tunnels that almost met or had flow-blocking extrusions.

derefr 4y ago
> It would be interesting to maybe anchor building items into an easily understood and simulated grid, but where the grid was arbitrary in relation to the map and other grid-based elements. So you could point your fort in any arbitrary direction in relation to the terrain but the walls would still function properly. Oh, to be clear, I didn't mean with my suggestions that you'd have a non-quantized underlying geometry. (It is interesting to think about, but it would be pretty impossible to accomplish if your goal is to sort of do an "enhanced emulation wrapper" that just reads out a TUI state from a black-box underlying game binary, and renders it graphically.) What I'm suggesting here would still be "a GUI as an interpretation of an underlying grid-structured scene data structure." It's just that things could have greebles that stick out of or into their tiles, and that the textures for tiles would be dynamically composited depending on the contents of their neighbours, and so forth. My example of Sim City 4 was meant to be instructive. Look at this screenshot, for example (https://images.gog-statics.com/2bfe9edb18ccfdecc47bf1ddf132d7ee3897fe21a6841e147d0c2bd4b0ce3ada.jpg https://images.gog-statics.com/2bfe9edb18ccfdecc47bf1ddf132d...). • The underlying physics operate — in almost all passes — on a 2D grid of tile data. There's a height map, but it's very quantized, and only applies (IIRC) to the movement of cars and pollution. But graphically, you've got smoothly transitioning elevation, and even things like houses where the length of the driveway of the house changes in order to meet a sidewalk of a street that is closer or further away depending on where the house is relative to the slope of the street. • Likewise, look at the boulevards in the image. Physics-wise, each street side of each boulevard is "one tile" wide, with a "one tile" median, making it a "three tile wide" roadway. (Thus the 3x3-tile intersection.) But if you look at what the game is doing when it draws all of this, none of it is snapped to tile boundaries. The roadways themselves are slightly wider than one tile, forcing the median to be slightly narrower than one tile; and the existence of the roadways causes sidewalks and lamp posts to spring into existence within the boundaries of other neighbouring tiles, where those tiles, and not the roadway tiles themselves, then handle the visual edge transitions around the sides and corners of the roadway (where you can think of the tiles that meet the inner corners of the crossing of the intersection, as having "the responsibility" to draw a little bit of the roadway inside them, to fill in the gap left by the curve of the curb. Though more likely what's actually happening is that the JIT-composited tile data for those tiles leaves that area transparent, and the roadway overdraws on a previous pass, which then gets mostly covered over by those tiles.) • However, despite these render-time tweaks to how things look, the game is still "on" a 2D grid. Your city is fundamentally a grid of tile data; things can only be placed on grid positions, and there is only ever exactly one thing "in" each grid position, simulation-wise. If you have "grid visualization" on, then you get this: https://i.imgur.com/AiSuFKX.jpeg https://i.imgur.com/AiSuFKX.jpeg. And even when you have it off, a grid "spotlight" still displays in the immediate area around the cursor — so that you don't start drawing things on the edge/corner of a tile and then get mad that you selected the wrong tile. Even if you draw a diagonal road, that road still exists "on" a particular set of grid tiles.

derefr 4y ago

> It would be interesting to maybe anchor building items into an easily understood and simulated grid, but where the grid was arbitrary in relation to the map and other grid-based elements. So you could point your fort in any arbitrary direction in relation to the terrain but the walls would still function properly. Oh, to be clear, I didn't mean with my suggestions that you'd have a non-quantized underlying geometry. (It is interesting to think about, but it would be pretty impossible to accomplish if your goal is to sort of do an "enhanced emulation wrapper" that just reads out a TUI state from a black-box underlying game binary, and renders it graphically.) What I'm suggesting here would still be "a GUI as an interpretation of an underlying grid-structured scene data structure." It's just that things could have greebles that stick out of or into their tiles, and that the textures for tiles would be dynamically composited depending on the contents of their neighbours, and so forth. My example of Sim City 4 was meant to be instructive. Look at this screenshot, for example (https://images.gog-statics.com/2bfe9edb18ccfdecc47bf1ddf132d7ee3897fe21a6841e147d0c2bd4b0ce3ada.jpg https://images.gog-statics.com/2bfe9edb18ccfdecc47bf1ddf132d...). • The underlying physics operate — in almost all passes — on a 2D grid of tile data. There's a height map, but it's very quantized, and only applies (IIRC) to the movement of cars and pollution. But graphically, you've got smoothly transitioning elevation, and even things like houses where the length of the driveway of the house changes in order to meet a sidewalk of a street that is closer or further away depending on where the house is relative to the slope of the street. • Likewise, look at the boulevards in the image. Physics-wise, each street side of each boulevard is "one tile" wide, with a "one tile" median, making it a "three tile wide" roadway. (Thus the 3x3-tile intersection.) But if you look at what the game is doing when it draws all of this, none of it is snapped to tile boundaries. The roadways themselves are slightly wider than one tile, forcing the median to be slightly narrower than one tile; and the existence of the roadways causes sidewalks and lamp posts to spring into existence within the boundaries of other neighbouring tiles, where those tiles, and not the roadway tiles themselves, then handle the visual edge transitions around the sides and corners of the roadway (where you can think of the tiles that meet the inner corners of the crossing of the intersection, as having "the responsibility" to draw a little bit of the roadway inside them, to fill in the gap left by the curve of the curb. Though more likely what's actually happening is that the JIT-composited tile data for those tiles leaves that area transparent, and the roadway overdraws on a previous pass, which then gets mostly covered over by those tiles.) • However, despite these render-time tweaks to how things look, the game is still "on" a 2D grid. Your city is fundamentally a grid of tile data; things can only be placed on grid positions, and there is only ever exactly one thing "in" each grid position, simulation-wise. If you have "grid visualization" on, then you get this: https://i.imgur.com/AiSuFKX.jpeg https://i.imgur.com/AiSuFKX.jpeg. And even when you have it off, a grid "spotlight" still displays in the immediate area around the cursor — so that you don't start drawing things on the edge/corner of a tile and then get mad that you selected the wrong tile. Even if you draw a diagonal road, that road still exists "on" a particular set of grid tiles.