> 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 a

> 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.