Sometimes, as developers, we let crash bugs live. They’re not worth the time to figure out. Most games (and other apps!) ship with tons of bugs. And glitches — things that don’t look right but generally don’t corrupt your data — those might be all over the place. Or they might not. Me, I’m not too happy about that. I really don’t want to have crash bugs hanging about. I’d rather get code working great first, then move on to the next feature. This is why some game and tech companies say “it’ll be done when it’s done.” It’s hard to put a date on when a conscientious developer will be happy with the stability of code — and this attitude is also at the heart of agile development.
Three light glitches (one fixed)
I’ve got a glitch in my lighting algorithm. I’ve got several, actually. Here, take a look.
One of this glitches is fixed now…. so, uh, it’s a screenshot of two lighting glitches plus a bunch of stuff that works correctly. The heart-shaped area labelled B is a junction between four voxels: one outside corner, two inside corners, and then the full voxel (at the top). It used to look like the inset: the black triangular piece looks completely out of place! The problem was the wrong lighting levels set on that triangle, and the fixed involved going back into this code, cleaning it up, and identifying the bug — which was several things, and I won’t get into them here.
Most pro shops use a bug-tracking system; some track severity (crashes always vs sometimes glitches) and others track priority (FIX IT NOW vs meh ignore it). Some track both. For now, I’m just looking at severity. So there’s three types of coding bugs: crashes, glitches, and then everything in the middle (“bugs”).
My first preference is to make sure that the standard user experience is crash-free, bug-free, and glitch-free. But software development isn’t free or instant; and that’s why sometimes we let crash bugs live. If the bug is really obscure, isn’t in the main line of use, and sometimes just if it’s really hard to fix — those crash bugs stay in the code. As a coder, I’m not really happy with that. But as a business owner, it’s sometimes something you gotta live with. Ship a product with some truly obscure bugs? Or don’t ship a product? Eventually, we gotta eat. Smart project managers plan for the extra schedule time needed, and are also willing to change schedules if it means getting a better product.
Today, I’m at the glitch stage with what I have in the “production” build of the project. I want to make sure everything in there works and works well. I think this is especially important for visual bugs in a game, where many people will decide to buy a game or not depending on how it looks rather than how it plays. As a programmer this is sometimes grating (because making stuff pretty is often far easier than making stuff functional) but I definitely understand it as a player.
There are 39 different voxel shapes in SteamShards, and each one can be rotated in 24 different ways. They all have to look correct, be textured correctly, and be lit correctly. For the most part I don’t commit code until it works, but in this case there’s just too many combinations to exhaustively test. I’ve got unit tests that run through some parts of the computations, but (including occlusion) there’s like 27 thousand different cases that I’d need to look at — and some of those are actually judgement calls and not simple factual yes/no tests.
So that’s what I’m donig right now. De-glitching the code. I’d love to show off more subvoxel terrain, but I want to get it looking great first.
Oh, the other two glitches? Area A is a glitch caused where two cell boundaries abut. This is every 16 voxels. The result is an extra-bright voxel edge here & there. Area C is a side-effect of using subvoxels with a lighting system that’s voxel-based. I think the “correct” solution for C is to do occlusion sampling [no, that’s not a phrase that anyone else uses], and that’s a week-long task. I’m currently planning to work on that sometime in late July.
