State Vector April 2024

I’m afraid there is a slight delay with the next update. While progress on the game has been excellent for the time I could spend on it, April threw quite a few wrenches into my time management. There was the spring vacation of the kids, which obviously always comes with a couple of special demands, there was that weekend that I took off to get myself beat up with swords because I like doing that (though I really have to work on maxim 13!), and there was a kerfuffle at work where I had to do some significant overtime because of unclear specs. It turns out that one feature that I had considered very exotic and low-priority was suddenly very important for fulfilling a rather big contract. You know, the way it usually goes with features that you think noone will ever use, while alot of features that were considered essential during planning turn out not to get used at all. So, nothing extraordinary, but certainly annoying.

Sound is coming!

I had worked on sound off and on since December, keeping it on a back burner for whenever I felt like working on it, as it mostly consisted of searching sound effects and cleaning and cutting them. The kind of relaxed work that I can put in when I’m too tired to code but still want to make some sort of progress. And then, some fine day at the beginning of this month, I unexpectedly realised that I actually had everything together for a basic UI sound scheme. We’re not talking music or anything special yet, just sound effects for the UI, so things feel a bit more responsive. Button presses, sliding sounds for the very basic UI animations that are currently there, sounds to indicate good or bad things, that sort of stuff. When I realized that I had everything I needed I took another pass and brought my somewhat lackluster sound architecture up to speed so I could actually configure things reasonably easy and in one place, and then it was done. I could have released that. Could release it right now. But while I think it’s an essential feature going forward, it doesn’t really add enough novelty to ask people to play it, so I decided to hold it back until the next job type is done.

Recovery jobs

The centerpiece of the coming update will be a new job type for recovering dead objects. In this new job type you will fly out to a piece of junk, and will need to EVA to catch it and secure it to your spacecraft. Since it’s junk, not functional satellites, there’s not really any designated points for your RMS (remote manipulator system) to grab on to, so you’ll have to do it the old fashioned way. Meaning shepherding it in by manual labor while being strapped to the RMS (which you also control, because you’re solo). Needless to say, there’s ample opportunity for things to turn FUN. In fact, the next update may make orbital margins the first game ever that lets you vomit into a space suit! Adrift doesn’t count, that could just make you vomit for real. If you know of any other games with this feature please let me know, so I can correct this information and also go play the hell out of that game. The EVA is not quite as demanding as maintenance EVAs though, as a small concession to the fact that now you have to bring the piece of junk back to civilization and fill out the paperwork for it.

The whole thing is implemented and seems to be mostly working by now, but I’m still writing all the text. It’s also not very thoroughly tested yet. At this point I decided that it was time to pull up an old ticket from the backlog to save me some time in the future, but will delay the update some more. Word is about some proper debugging tools that let me test the various branching possibilities in the “challenge stories”, as I call them. This will save me some serious time going forward and greatly reduce the danger of the game suddenly CTD-ing out when branching into a faulty node that I just hadn’t hit during testing.

Concerning test-driven development

I’ve also written a unit test to test the connectivity of these stories (another thing that was hanging around in the backlog). This tells me in seconds whether I screwed up badly during their definition and whether everything connects in a way that makes sense, and if all the nodes can be built. Which, sure enough, lead to the discovery of quite a few inconsistencies in the definitions of the currently existing ones, which should make the next release a bit more stable. It doesn’t tell me if there are any issues with completing the nodes, however. Unit testing all that reliably would require a damn lot of setup.

Fair warning, the following might contain some triggers for zealous TDD-disciples. It’s just my opinion and experience, you guys do you! My structure would actually allow me to set up the game in any internal state that I want to and execute actions in it just as a player would, completely without the frontend attached. This in itself is already rather remarkable for a game. I’m achieving this by a technique which I call CROW-DI. Which is short for “Completely, Radically and Overwhelmingly wrong Dependency Injection”. I might talk about it in detail at some other time. The weird naming is mostly to let DI-disciples know upfront that I know I’m doing it wrong, because I feel that’s important for a happy life free of tyring, but otherwise inconsequential debates. Sometimes it feels like everybody in this industry has read the pragmatic programmer, and half of them managed becoming “the dogmatic programmer” anyways…

I’m sorry, this short rant might be a bit difficult to understand for people that only have experience with the gaming industry, where there seems to be more concern these days about whether to pronoun or not to pronoun than about software architecture. I guess I have that shoe yet to drop one me…

In any case, there’s three reasons why I don’t write complete unit tests to fully test the flow of challenge stories in the game, even though it would be technically possible: The first one is, writing these tests would take a lot more time than writing the actual code. Now, this in and of itself is not a good reason. Unit tests quite frequently take up more time to write than it takes writing the code they are testing. You write them because it might be faster than writing that code and testing it manually in sufficient coverage, and because it’s definitely faster than chasing after bugs once the code is deployed. However, these stories are going to change a lot going forward, which would require changing the tests along with them. Again, that’s true for all unit tests, but what I’d be testing here is essentially content, not logic. Content that has a good deal of logic in it, true, but something that can at a whim be removed and replaced without touching any of the core code of the game. And there’s probably going to be quite a few such removals and replacements during development. In essence, this is not just content, it’s explicitly alpha-content. I really don’t feel like spending a lot of time to test that.

But there’s a third reason, which is really the major one. It’s that the tests would not just require a lot of work, it’s that they require a lot of complex setup, recreating states that would emerge spontaneously out of play. And while I certainly don’t shy away from complexity, the problem is this: It is my firm belief that if a test is not simple, it is not reliable. You have no guarantee that an overly complex test setup is actually testing what you think it’s testing. You’d have to write a test… for your test. An I know even this is being done sometimes in the software industry for vital pieces of code where a bug may result in millions of damages or loss of life. And I also know that there’s a strict rule for how to develop such code: The guy writing the test cannot be the guy writing the code. The guy writing the test for the test cannot be the guy writing the test. Otherwise you create a motivation problem that compromises the whole thing, and also you will have too many assumptions shared between the code and the test, which can lead to inadvertently cutting corners. So, at the end of the day, a game never crashing isn’t critical enough to justify the effort, and maybe more importantly, I am only one guy and therefore couldn’t do the job properly anyways. So I write some tooling in order to increase the probability of catching the worst of it, and I leave it at that. That seems… pragmatic.