AND NOW, a cross-post of this week's devlog update (
http://www.ultimaratioregum.co.uk/game/2013/08/08/viewing-direction-and-multi-layered-tiles/), about an aspect of ziggurats you may or may not have spotted:
Most roguelikes have a single z level and a single perspective. What I mean by the first of these is simple – each floor of the dungeon is flat, and there are never objects you’re too “high” or too “low”, vertically, to see. You cannot be too low to see over a particular barrier, and nor can you ever be too high to see something hidden below a ledge, for example. What I mean by the second, however, is that tiles look the same irrespective of the angle they’re viewed from. Viewing a wall tile from any angle is always a wall, whether you’re in the chamber the wall makes up, or the corridor that the wall is just one side of. Viewing a door will always look like a door whichever side you view it from. Obviously there may be modifiers – spells of effects that reduce your line of sight, or cause hallucinations, or similar – but the objects remain stationary in your view under normal situations.
URR is a little different. Originally I only had z levels, and that means certain areas would have to look different. This is much the same as Dwarf Fortress. Areas significantly above the player print as a filled-in ‘^’ icon; areas above you produce a ‘v’; whilst your line of sight is obstructed by areas that are too high above the player’s current level. This needed a lot of work to implement because the characters that need printing on each tile are not fixed but relative to the player’s height. However, there’s also a second aspect which is becoming increasingly important – tiles which look different from alternative angles, not just from alternative heights. In this first screenshot inside a ziggurat, you’re in the room with the relevant clue, and that displays correctly. That’s obviously what’s meant to happen, and it does so fine.
However, it is possible for the player to get behind this inscription and view it from the back. This could lead to the possibility that depending on the generation of the level, you could see a clue from behind before you actually reached that room with the clue! If the wall containing a clue was also a wall of a corridor leading to the clue, then you’d get to see the clue early (odd, but not a big issue), but also the player character would be able to magically read an inscription through the wall, which I deem to be a real immersion-breaker, and also warn the player about the location of a puzzle room in the dungeon. At the moment that final aspect doesn’t matter, but in the future with resource management and potential enemies, that kind of foreknowledge about the terrain might matter. So, I had to find a solution to this.
I considered what exactly the problem was; seeing the inscription tile, without being in the room the inscription refers to, should not show it. My first trial simply made the game notice which wall the clue was on, and print appropriately. If it was on the southern wall, any player north, north-west, north-east, west or east of the clue would see the ‘?’ whilst any player south of the clue would see the brick icon. This resulted in this:
Which worked great. What this meant, however, was that being below the inscription, even if you couldn’t actually see it, would have it reprint. Moving across the horizontal or vertical axis for a clue would make its appearance change even if there was no way to view it from behind. This worked to fix the original bug, but made other possible situations rather less elegant. If you were north of a north-wall inscription but couldn’t see it, it would still reprint. This meant that moving around would randomly keep redrawing the visible inscriptions according to each axis for each inscription that you crossed. As above, this did prevent the reading-inscriptions-through-walls error, but there’s really no need to hide the inscription in this case because you cannot view this from behind. I needed a system that would do what was shown above – inscriptions viewed from behind vanish – but only if they can be viewed from behind, so that the image below could also occur:
Without changing from the above code, the inscription to the south of me would vanish, for no good reason. So, I returned to the process and iterated it again. I added in a new piece of code that had it check whether that particular square can even be seen from behind. So, if an inscription is on the southern wall, it checks if the south-western, southern or south-eastern tile from that tile are “open” to the player, and therefore can be seen. If any of these registered as being open, then it would revert to the solution in the second square – being behind it print the wall instead. However, if they are register as closed – in the third picture it is on the northern wall, and the NW, N and NE squares are all walls – it doesn’t need to print anything new because you can never view that inscription from behind. This solution ensured that only in the very, very rare situation where the inscription can be viewed from behind will it print a wall instead.
This is part of a much wider requirement for the game. There are multiple other types of tile that have to display differently based on the player situation. For example, doors can only display if the player’s height is less than or equal to the door’s location. For example, if there is an area with a height of 20, and levels 18/19/20 contain a three-level door, then standing atop that tile must hide it, whilst being anywhere below it must show it. This means a hefty part of the rendering code is basically for “exclusions” – for showing things if the player is at certain heights, or certain angles. Most tiles can be trivially displayed regardless of your angle, but a few tiles of these sorts require special treatment. Indoor areas, because they lack height, are significantly simpler because nothing has to be rendered specially to take account of the player’s location on the z axis. I haven’t yet decided how to handle things like bridges that you can walk under, but it’ll probably be handled like walking underneath tree leaves. I don’t yet know how many other aspects like this there will be, but I’m sure more will arise as time goes by. In the mean time, however, version 0.3.1 will be released in the coming week with a set of minor bug-fixes, and will be the last version until 0.4 later this year, in which – I am proud to announce – you will be able to die. I’m hyped.
Author
Topic: Dwarf Fortress meets The Outer Wilds? "Ultima Ratio Regum", v0.10.1 out Feb 2023 (Read 634923 times)