I had a request some time ago for a blog entry dealing with programming in a z-level to a top-down, 2D game. It’s been delayed by several weeks due to working on the release, and now it’s been delayed by a day because I spent almost all of Monday on academic work. Now, however, I’ve managed to find a moment between editing chapters to put something about this up.

URR does not use cubes. Which is to say, a hypothetical map with a top height of 10, with some sky and some ground, does not look like the thing on the left, with cubes of each substance stacked upon each other, Minecraft style. I obviously considered doing this, but then realized I was using up an unnecessary amount of memory if I did it that way. This isn’t a construction game, and this isn’t one where you can dig. Those are the two fundamental reasons why cubes of terrain are simply unneeded, and inefficient.

Instead, URR actually only has one cube of terrain in each x/y coordinate square, regardless of the height of that square. So, square [0][0] might have a ‘z’ value of 1, square [0][1] might have a ‘z’ value of 2, and so on. Each square has its own z value. Squares then have a ‘true z’ value, which reflects if something has been ‘built’ on them, for instance a tree, or a wall, or whatever. These are almost exclusively things you cannot see through.

Thus, when then generating the field of view each turn, the game ignores any squares that are blocked and on your level – for instance, by a tree – or any square with a true z level greater than that of your head (the player is two levels high, as are all humans). Monsters, in turn, cannot see creatures with the same requirements, and like you can climb or not up areas of various z levels depending on their height.

But, I hear you cry – what if you have a wall on a square, and the square’s z level is 10, and the wall is 5 squares high, so that square has a true z of 15. If the wall is destroyed, giving that the true z is the important value, surely the true z is still 15? When a structure is destroyed, the game recalculates what the true z of that square should be according to the height of the thing on the square, and then sets it.

But, I hear you cry (again) – what if you have a BUILDING, with multiple floors? What if you have a tower with sixteen different floors in, but the square can only store one z level? Well, buildings – although in their very early stages – are simply loaded separately. There is still fluid movement between buildings – there’s no load screen, things can go in/out of buildings at will, and for gameplay purposes, there will be (once buildings are fully implemented) no gameplay difference between a building here and a building in, say, Dwarf Fortress. The data is simply stored differently. While splitting ‘land’ and ‘interiors’ up has provided extra work in the short term, I deemed the massive reduction in required storage and the massive increase in game speed that game with it to be more than worth it.

And with that, our next update will be in a fortnight, when I will unveil a skill tree. Excitement!