As was posted last week, after seven months of development Ultima Ratio Regum v0.3 has been released! You can read a lot more about it and download it at this link. However, this particular IndieDB update is about an obscure aspect of the game's code you may or may not have spotted - that unlike some roguelikes, certain tiles differ in appearance from certain angles.
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. Originally I only had z levels, and that means certain areas would have to look different. 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! I had to find a solution to this. 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.
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. Until then you can keep up to date on my devblog, Facebook page, or Twitter feed. The devblog is updated weekly or fortnightly generally on Mondays, Facebook a few times a week, and the Twitter roughly daily.
