Esoteric Update #323 - Partitions and Perceptions

Update time, and this one is unfortunately one of those technical ones.

Over the last few days, I've tackled a few technical issues, which are interesting but not really showable, so I'll need to discuss them. I've also still been writing, getting into the groove of using words again, and it seems to be going well. I'm feeling well and optimistic about my output, although I sometimes wonder why.

For the technical stuff, in no real order...

It all somewhat revolves around the name lists collected by Bear. They aren't directly usable in-game, as I mentioned earlier, because they contain tabular data that is difficult to reference. What's worse is that the data is not uniform, so not every file includes the same elements. There are features of naming in some languages/ethnic groups that don't appear in the majority of them.

As a result, I had to devise a method for handling this. I've decided to transform the data. The engine (not as part of the runtime) reads the tabular data and converts it into a format that it can reference live, during the game. There are a few different challenges to this, and the two I'm proud of are a way of expressing modular data handling and optimising access. 

Regarding the modular workflow for data transformation, it's an approach that I believe could be suitable for other data as well, when the need arises. There are already some situations where we have been collecting and building larger data sets, and this approach could be applied to them and to future additions as well. Regarding the access optimisation, it turns out that the name list is... large. Larger than anything else we have in the game. To maintain efficiency for lookups, we cannot simply store it as a single source of data. Now, this wasn't really anything complicated; it was more of a kind of AHA moment, where it was clear what should have been done once there. We're solving it by partitioning the data over a primary key, an approach that works remarkably well for our needs. Though as clear as it might have been, there were a few things needed for it, including one that I always find a rather fascinating part of programming - that there are two ways the modulo operator can work.

(Note: in some programming languages, -13 modulo 10 is -3, in others it's 7. The former is more mathematically rigorous, and the latter is more practically useful. It's a small thing I feel consistently conflicted about because my math brain wants the former, but I know that I actually want it to work like the latter for practical programming reasons.)

Furthermore, I looked into light and sound propagation in maps. The system, as it was designed so far, had an issue. While it was fundamentally correct in its operation, there was a specific problem with it - the units were abstract and, as such, difficult to estimate when assigning sources of light or sound intensities. After reviewing some information about physics online, I realised that I can just switch to using actual physics units and alter the code to 

Now, this will require additional work to implement later, but it's an interesting addition to the system for a specific reason. See, while doing this, I also divided light and sound into bands, which allows for non-human forms of perception and sensory deterrence. The game can support creatures that, for example, see in IR or are sensitive to high-pitched noises, etc. Theoretically, it would also allow the game to feature night-vision goggles for the player character. However, I'm not sure if it's a feature I want to pursue (actually, I'm reasonably sure I don't - but it remains an open possibility).

I started prototyping the new character creator, but I've not gotten too far into it yet. I mean, actually prototyping the code, the "on paper" design has been done since last week.