First off: as mentioned on a couple of other places, a hotfix was applied to Beta 54, replacing it with “Beta 54a.” This fixes a couple of major crash bugs that were in Beta 54; one of which had to do with the new tooltip system interacting badly with the code that was supposed to provide data to them for characters. I banished this very hastily, although it took me all of Saturday and a good bit of Sunday to figure out how to do it. The other crash bug was me forgetting to save something in the save game file, and the game being reliable enough to… kind of… operate without it. It’s patched up now and so far Beta 54A seems to have been really stable (except for on a few people’s machines; I’m looking into these now.)

Back when we said “Beta” the indication was that we were shifting towards completing the game and getting it out of Early Access into the next phase, which I guess you would call “Access.” A larger portion of this also involves finishing little stuff that I’ve been putting off and can put off no longer put off. I have been instructed to write about this stuff today.

Let’s start by looking at two videos by “Call Me Al”, otherwise known as our very own Alephred on the forums. The first was from when we announced Beta 51:

and the second is his most recent creation, from Beta 54A.

You will see a huge amount of UI polish has gotten in between these three revisions. (If you want an even more jarring indication of how much progress has been made, feel free to take a look at videos from the *start* of Early Access, 2 years ago. Hoo-wee.) But let’s just look at the progress since May, or whenever we made our beta announcement. A few things immediately stand out:

• Characters have new and resplendent tooltips, and so do items.
• Workshops and offices now live in common windows, not floating windows. The one exception to this is the stockpile window, but it’ll… get wedged over there… somehow.
• We have a command stamping system, which – while not perfect – has stopped players from screwing themselves over by making 40×40 tree chopping plots and then wondering why nothing ever gets done.
• We finally, FINALLY, fixed the kerning of the letter “j” across the game so that it doesn’t look weird.

I like to informally measure the success of these operations by where the dialog shifts to on our forums and what people talk about. For instance, today people are talking about build orders on our forums, which is great and makes me feel like Sid Meier or somebody. The theory is that bad UI, or UI/UX that needs work, causes friction. The more friction you have, the more time you spend getting stuck. The less friction you have, the more time you spend talking about the game.

The master list of “UI/UX stuff that needs to be polished” has now moved onto one of the many whiteboards in our office. The good news is that it fits on a whiteboard. The bad news is that it’s a large whiteboard. Once any of it has been fixed, we cross it off in addition to closing our JIRA tickets. We do this in the hope that it will provide some sense of vague, measurable satisfaction. Some of these things are visually and immediately noticeable to players – some of them are much more subtle.

So what are some things that are on the UI polish list that we have done, and what are some of the things that we haven’t done?

First, and most excitingly, we finally have the keybinding widget. This got put on my lap because I thought that I’d have to write a whole bunch of special case code for it to hook the key state, parse it, save it, load it, and that it’d have to be jimmied on top of the existing UI framework in a horrible way. Interestingly, this didn’t need to happen, and SDL even provides a helpful function to tell you the name of the key you just hit, which may even work for Unicode keyboard configurations. So that’s nice; the entire thing was quickly done and took me about three hours.

Second, every button in the game now makes a sound when you click it. (You’re welcome.) A thing that is also needed is sounds when alerts go off, so that you have an audio cue as well as a visual one to indicate that something important has happened; also, they need to bounce a bit so that you pick up on the motion in your peripheral vision and recognize that an alert happened. So we’re working on that.

Third… some of you may have noticed that in the current build, your civilians are homicidal lunatics. Fixing this required a change in the decision tree for civilian military decisions, so that a civilian will only move into “attack mode” when there is a nearby enemy AND no military are within a certain radius. This wasn’t terribly plausible until we had the grid-based acceleration structure previously mentioned, because otherwise finding out “if something is within a radius of X” would be very unpleasant. I’ve also propagated that grid structure to a bunch of the other queries that the spatial dictionary lets us make, and it’s proven to be surprisingly effective.

(As a follow-up, two questions that I got were “why don’t you use quadtrees?” and “why didn’t you use bloom filters?” We do use quadtrees for visibility queries, and I think they’re great for that; I don’t think they’re great for “closest distance” queries. As for Bloom filters – well, classical Bloom filters have a small percentage of a false positive, which could be bad. They should be in my toolbox more often for things; they’re not a tool I commonly reach for. The Bloom filter-esque scheme proposed by the commentator was essentially “flip a bit in a cell when food is added to it. When food is removed, check to see if any food is in the cell or not and if so clear the bit.” Problem one is that we would need to have one bit-index for every tag in the game, and tags are definable by the scripting language in an ad-hoc fashion. This is something that we don’t exploit as much as we should, but it’s very powerful and I hope to see people doing a lot with them once the game is out and attracts modders like moths to a flame. Problem two is that I think you probably hit the “I removed an object” case a lot – even just moving a character around the world immediately affects whether or not a bit in the filter is flipped or not, so you’ll spend a lot of time every time a character moves shuffling through the characters to see if any of them are still in this cell – in other words, one of those blasted O(n) loops I keep running into in this game. Moral of the story: the efficiency of any good algorithm depends on understanding its access pattern, and I think the current pattern represents an appropriate balance across all of the ways in which the structure is accessed. Hooray for breadth-first search and all that.)

A bunch of the impending polish that needs to be done involves the building creator. Again. There are a handful of small issues (“the wall that a door is on will occasionally render the texture upside down”) that are, frankly, not necessarily shippable blockers because nobody other than a developer will really notice them. The major UI/UX issues here are that a) when you have a building with a lot of modules in it, it’s very hard to see what’s going on and to edit it; and b) it is too easy to create buildings next to buildings. I am currently adding an adjacency buffer of 1 tile around buildings and modules where you will not be able to place other buildings and modules, so that there has to be some sort of alley-way where you can pass through. (This should also prevent you from effectively putting a massive building around your colony; a good example of a “players will abuse the system” scenario that shows up a lot in sandbox games.) I’m still thinking about what to do to make the visual language of the building creator cleaner which can be accomplished quickly and efficiently.

Anyhow… yeah. Quietly polishing this week. It’s a thankless job, and one not usually talked about in game development, but it’s gotta be done.