Hi! I’m David Rusak, one of the designers at DrinkBox Studios. Here’s a recent episode from the creation of Severed that I thought would give a little insight into the twists and turns of the development process:
Severed’s world is split into several levels which each comprise dozens and dozens of nodes. For a while, when things went wrong, we were writing bug reports like: “When you walk into the first dungeon, the second outdoor area you get to, that node after the weird-looking tree with a path going East and West, has a misplaced piece of art…”
A lot of these kinds of requests made their way down to the design team, who would then have to sort out tracking the offending node down themselves. After a while, the designers wanted a better way to identify the nodes that make up our levels. It was easy to imagine that programmers could devise a system to do this automatically — but free coder time is often a scarce resource, especially when it comes to problems like this that are a little less than life-or-death, so (as often) the designers just went ahead solving this inconvenience in the least-janky way available to them.
They began to just put a ‘Node ID’ object in each node, visible when testing with debug visuals, that showed a number unique to that node. Ensuring each node’s number was unique was easy enough, since we can search object names in the level, and it really wasn’t such a big job just duplicating this ID object across the whole level one time, and then copying it along into any new nodes we added along the way. It was fairly lightweight and gave us a very convenient way of talking about single nodes.
But there comes a time when rough fixes must be sternly revisited.
We were going through a wave of big level revampings as we approached our Alpha milestone. New work had been done by designers less familiar with the Node ID ‘solution’, or who hadn’t yet gotten around to adding all the IDs back into still-half-rebuilt levels. The IDs were also now expected during testing. And the code team caught wind of our appallingly manual solution to this straightforward, systemic problem, dealing the deathblow to it.
This new node ID thingy may look similar, but it’s placed automatically, by code wizardry. It tells you the grid position of the node you’re in and the floor it’s on, providing even better info than the old arbitrarily-numbered IDs did. As a bonus, it became easy with these labels to add the ability to debug-jump the player to any specified node, causing QA to weep tears of joy.
Should a request to set up a system like this have been insisted on right off the bat, added to the avalanche of front-loaded work the programmers are already tasked with? The new system actually has some weaknesses compared to the old manual node-naming: if we moved a whole chunk of the level around, everywhere we’ve referred to those nodes by these location-based names would become completely inaccurate. But at this stage, it saves us tons of trouble — now that we’re at a point where we can take certain things for granted (nodes won’t be drastically moved around much from Alpha onward, they’re always on a grid, etc). This was a pretty extreme case because the code fix was pretty easy, but it’s one good demonstration of the principle that no production decision is simple — knowing The Right Answer to a problem is never enough. For many cases like this, the janky stopgap measure really is the right move, until things become better solidified. When you add new cogs to the machine, you never just solve a problem — you also create debt.