Ossa Sepia

This past week I worked on a significant refinement of Eulora’s data hierarchy, that core structure used to fully describe for the client the game’s endless, complex and ever-changing world. As it happens, this refinement was made possible as a result of a lot of previous work ¹: having recently gained full control over the creation of all graphical elements as I successfully grew my own mountains alongside GUI elements and literally everything else involved, I was also finally able to break up into more useful pieces and ultimately get rid of that sore anomaly of an “Outdoors” object that had previously catered to the requirements of the now-discarded “terrain plugin”.

For the easy part in getting rid of that bulky and spurious “outdoors” object, I had at least already in place the natural building blocks that would get used, namely the CSModel object as well as the ways to position and even name it, if desired. Even so, a change such as this, touching as it does the game’s own way of structuring knowledge essentially, can never be a very easy thing to get right, as there are many different connected pieces that have to fit – at least to some working extent – at all times. So I was a bit apprehensive about the amount of work it might end up requiring in practice and I made therefore a padded estimate of the time it might all take.

At first, I made the needed changes on serverside, where everything is defined and created in the first place anyway. There was initially more work than expected, indeed, but mainly as a side effect, a sort of slightly hurried growth, rather than anything else: while the change to the hierarchy itself was quite straightforward, the details pushed into being other parts that weren’t yet quite ready otherwise, although they were somewhere further down on the list for later, anyways. So I took more time than I had initially estimated to design and then add the needed embryos of these parts too, even though they still miss a lot of other parts that they in turn require and as such, they are sure to further change as they develop. This is expected and unavoidable though – it’s how everything else on serverside currently came into being as well, after all.

As the serverside work stretched even beyond my padded estimate for it, I was increasingly thinking that I’ll have no choice but to revise the overall estimate entirely, as the remaining time for the whole clientside work shrank and shrank. But then, when I finally got to update the data hierarchy in my own EuCore component on clientside, there was indeed very little required: simply the addition of the new object types, the deletion of the old one and a few updates (flagged automatically, too!) to take them as well into consideration when looking for broader categories such as “graphics vs non-graphics objects”. The rest of it – and moreover, the *more significant* and difficult rest of it simply worked and not by accident either: it was simply my previous design and implementation of both EuCore and its interfacing with the GUI saving me days of work now, as it handled entirely new types without skipping a beat and without requiring otherwise any change *at all*. How pleasant is this as code to work with and when exactly is the last time you encountered such ease when making significant changes to the code you are working on?

The second code change that made its way onto my list this past week was in principle a very simple thing to do, clientside entirely: as the water was now simply a CSModel like any other item in the world, it ended up nicely rendered but nevertheless surprisingly…solid, despite the data hierarchy otherwise holding enough information as to its “water” nature. In other words, there was clearly a need for the GUI part of the client itself to become a bit more discerning and create water as water (not solid and also reflecting things around, for instance). Since I had already written the code that successfully created water as such, this change was in principle just a matter of adding and using a flag, nothing more.

In practice though – in hindsight unsurprisingly, as it touched the remaining PS code – the simple change turned out to be not that simple and especially not as straightforward as expected: first, the water was rendered reflecting quite nicely everything around, so that it was clear that the discerning part worked as expected but… this “water” was still a solid, more like frozen ice perhaps than any water. Then it all got even more puzzling: the water was still solid *despite* my loader specifically *not* setting collision detection on it (in graphics terms, this solidity is simply a matter of whether one bothers to check /enforce any bumping into the object in question or not). Moreover, this unexpected solid was not even reliably solid but rather a weird half-assed sort of solid: one would walk on water indeed, for all the incredulity one might have as to the possibility of such feats but then, unexpectedly (a loss of faith, perhaps – whose faith, though?), one would sink deep into it and then… oh, then, one would get *stuck* in there, too, unable to move in any direction, if able nevertheless to spin as much as desired! Basically I had inadvertently created in there a sort of treacherous quicksands for all their watery looks otherwise.

Both the cause of and the resolution to the above unexpected wtf turned out to be of the same sort as previously encountered: the cause was a remaining bit of planeshift code and the resolution was to discard it entirely. Basically there was a spurious “psSolid” wrapping of the engine’s own collision detection object doing nothing other than getting in the way – it literally added *nothing* of its own other than the perpetrator’s name at the top of the file ² and otherwise another indirection layer in the way of anyone trying to make sense of the code overall. On top of this, some other bit of remaining PS code *also* took it upon itself to decide and add this half-assed psSolid thing to *everything* that went through it, just like that. As a result, there was this funny situation where simply bypassing it all solved the problem entirely – as usual, not playing along with the stupid has this magical effect of making all sorts of problems just… disappear. So I further deleted some of the increasingly less but sadly still remaining PS code and as a reward for it, I had my water being water again, nicely yielding rather than solid and otherwise letting one freely move through it at all times, instead of randomly trapping unaware swimmers in it.

Having previously trimmed and trimmed again at these same planeshift tendrils, this latest trim was otherwise quite effortless too, basically a very pleasant and rewarding way of improving the code from all points of view. How is this for coding work – effortless code *reduction* for added benefits and increased functionality, too. How does this compare with your current coding work and experience as to what coding even involves, hm?

1. This most recent work merely added, in turn, on top of full years of cleaning up all sorts of strata upon strata of a huge mess.[↩]
2. And I have to say that by now I had even guessed correctly the exact “author” name in that file, despite there being quite a few names scattered otherwise around the CS and PS codebase, you know?[↩]