The Right Glue
May 2011

Functional archeology

By Dean

An inexorable fact of software development is scope creep (which is why it's the core mechanic of Vapourware). Software systems start as one idea and over time develop layers of other functionality that push the limits of the original software specification. There are many causes of this phenomenon including developers adding things they think are cool, managers wanting their pet features added and needing to immitate competitors' products. The causes aren't important, what's important is that scope creep exists (or will exist) in all software.

As systems take on new functionality there will come a point that a new feature is so alien to the original design of the software that it actually can't be added. Using the Lego metaphor, this building a giant castle on a small turntable block. Eventually the castle will be too big to be stable and you can't add new supports because doing so will force you to lose the ability to rotate. Originally the turntable just contained a cannon turret, and the castle was just built up naturally around it. It was never meant to handle anything so big.

I feel it's important to make a distinction between scope creep — software gaining new functionality over time — and insane bugs wherein systems are merely poorly designed (i.e., the Minecraft effect). In a well designed system, new features can be added incrementally usually without affecting other features and causing nonsense bugs. Software engineers know that scope creep is inevitable and strive to write software that is capable of being changed later. In our Lego example, even though the turntable castle is unstable, it has no bearing on the giant Lego robot you've built nearby.

The important thing to understand about scope creep is the need to redesign the fundamental system occasionally. Once your rotating castle becomes unstable, you need to step back and build a more robust rotating base and move the castle onto that foundation. The trick is knowing the difference between when additional functionality has forced a redesign and when the new functionality is still covered by the original concept.

Assuming that software is designed incrementally, and that at every stage of development the software is re-evaluated logically to determine whether large parts need to be rewritten, it should be possible to examine software as it currently is to make educated guesses as to the nature of previous iterations of that software. In other words, functional archeology should, in theory, be possible.

Looking back upon our rotating castle, let's assume we have no idea that the castle can rotate. What we see is a castle that has a very perculiar shape due to its original requirement of balancing on a single two-by-two Lego block. We can also see that structures nearby (such as the giant robot) have very robust construction. Our conclusion is that this castle was built unstably not because of the inability of its architect, but because of a limitation in its foundation. More poking will reveal the turntable, but that is beside the core point: the limitations of the original design are what shape the perculiarities of the current design.

The same is true in software: areas where an application feels like it ought to be able to do something but can't even though the rest of the software seems complete and competitors' products can do it are very likely to be so far outside the original specification of the code that it simply can't be done without a fundamental architectural overhaul. If you see enough such holes in the application you can get a feel for what the original software probably was. Like an archeologist uses ground-penetrating radar to find buried ruins, you can find the original design in a scope-creeped system.

I'd like to use the recently released first-person shooter Brink as a case study to demonstrate what I mean. Brink is a great example, because it's a modern game that is similar to other games (such as Dystopia) while lacking some very obvious functionality (and having additional unexpected functionality) which I believe betrays a different original design.

Brink a standard cops-and-robbers team game. There's nothing about it that is particularly unique, rather it's just a combination of game mechanics seen in previous games, though not necessarily all together in one game. The important features are matches are team-vs-team games, characters are highly customizable, weapons are highly customizable and characters can gain new abilities as they level.

Each of those seem normal. TF2 actually has all of these features, albeit to a lesser degree. In fact, a lot of games have these features. Games that have features like this tend to have something in common: you level up in game, and you can do your resultant customization and levelling right in the game. This is not the case in Brink: though the game tells you you have gained a level and can choose what your new abilities are going to be, you must log out of your current game in order to do so. The same is true if you want to customize a weapon to make it more suitable for the current circumstances in your game: you have to log off, which defeats the purpose.

Our ground-penetrating radar reveals another out-of-place piece of functionality: when Brink is started the first time it presents to the player a short video detailing the two sides (cops and robbers) and why they are fighting. Fair enough. But then the game asks the player to pick a side before he can proceed. This would be as if TF2 asked the player to choose red or blue before allowing him to continue. In fact, Brink lets the player choose either team when he's in a game, so his original choice has absolutely no bearing on the gameplay. And he can take his cop character through the robber campaign and vice versa, so this choice has no bearing on the story either. It is as nonfunctional as a feature can be.

Why does Brink behave this way? Why is its functionality so weird in spite of being so otherwise polished? Why is it missing functionality that similar games have always permitted? I have a theory: Brink was originally designed to be significantly more RPG-like, wherein players would set up one character with one set of weapons and play this character as he was defined at the beginning. So he would have one team, one particular set of gear and a set of skills that wasn't meant to change very often.

Then, in playtesting, they realized that players needed to be able to change team in game, and class, and they could level up during a match. They tried to add these features to the codebase, but their network protocol wasn't able to handle in-game character updates, because it was never designed to do something like that. So they forced in team- and class-changing features but were unable to allow character, weapon or skill customization because their metaphorical rotating castle was already too big.

At least that's the best explanation I can conceive for Brink's oddities. I admit my functional archeology is nascent. I hope that Splash Damage realizes that its castle needs a better foundation.

Latest comments:

Programming games

By Dean

Programming is fun. Now that your mind is blown let's talk about games that feature programming as a core mechanic.

As you're well aware, I love board games. One board game that I enjoy is called Robo Rally. In Robo Rally each player takes control of a robot, each of which need to reach the same set of locations on the board in the same order. Players have cards that serve as commands for their robots, and the robots can interfere with one another.

The catch is that the players have to place their commands face down before the movement phase of the game begins. They have to program their robots in advance, without knowing what the other players are programming their robots to do. Once every player is finished, their programs run simultaneously, usually with disastrous results (did I mention the robots all have lasers?). Because the robots cannot change their programming and because the game board is so hazardous to all life (artificial or otherwise), small changes in conditions can carry dire consequences for the poor robots.

Robo Rally covers two very important programming gotchas: bugs and concurrency. In Robo Rally, if you place a left-turn card instead of a right-turn card, your robot will go on a magical journey into a bottomless pit, or perhaps take a conveyor belt ride directly into a laser death trap. After a few mixups like that players learn something all programmers know: run through your code in your head before deciding it's correct. In other words, Robo Rally teaches players testing and debugging.

Likewise, other players' robots move and act at the same time as yours. The robots can push each other around, ruining a perfectly good program and leading your robot to its metallic death. Luckily the game provides a method for resolving two simultaneous actions through the use of sequence numbers. Every action has an associated sequence number. The smaller the number, the sooner the robot moves. So players can strategize whether to use fast or slow moves during turns they think they'll be near other robots. This doesn't exactly correlate to common solutions to concurrent programming but at the very least it provides a powerful demonstration of the complexities involved in simultaneous code execution in a fun way, which I think it fantastic.

If you've been following me on Steam then you'll know that I've been playing a lot of SpaceChem lately. (In fact I've been playing more SpaceChem than Portal 2 — which is saying a lot considering I haven't beaten SpaceChem yet but I've beaten Portal 2 one and three fifths times.) SpaceChem is not a chemistry game from Zachtronics Industries (known for great games the Codex of Alchemical Engineering and Infiniminer (which was where Notch got his idea for Minecraft) both of which I played years ago), but is in fact an engineering game from Zachtronics Industries.

In SpaceChem, the player's job is create specific chemicals by recombining, fusing and splitting other chemicals. The player does this using a versatile tool called a Waldo, which is, essentially, a program counter. The Waldo follows a path defined by the player, and executes actions along the path as it passes over them. These actions range from "grab atom" to "fire giant mining laser at aliens".

One of the big constraints in SpaceChem is space: each instruction takes up one unit of space (of which there are only 80), and often instructions need to be placed in specific regions in order to work properly. More importantly, there are very few control structures (other than loops) available, and those that are available are rather limited. This means that Waldo paths can get very complicated very quickly unless you have a good strategy for solving the problem beforehand. But it's not so bad, because in accordance with the Lego metaphor Waldo instructions are easy to change and modify while your plan of action changes.

A few levels into the game, the player is given access to additional reactors, adding more complexity to the types of puzzles that can be solved. But the really important feature is that reactors can be saved and loaded: the player can create reusable functions for common tasks. In fact, some of the levels have puzzles that are based on the same fundamental idea that needs to be applied in a more and more complex manner. The game therefore encourages users to create a bank of efficient reactors they can use in later levels. The game encourages smart, modular software design!

With multiple reactors comes another interesting facet of programming that's leaked into SpaceChem: the time and space tradeoff. The more complicated a reactor, the longer the reactor takes to complete its task. Adding another reactor to a puzzle adds more space for the Waldos to work in, but in splitting the task up among more Waldos each individual portion of the task is made simpler and therefore faster. In other words, with many puzzles adding more reactors allows the puzzle to be completed in fewer steps (i.e., adding more space reduces the time it takes for the program to finish). It's neat to see that come up such an accessible game considering it's seen as an excuse to hate programmers. One more example for the good guys.

Programming is fun. Robo Rally and SpaceChem prove it. Robots and chemicals and lasers and aliens are around every function call and return statement. It takes a real hero to be able to win games and write software. That hero could be you! (But in reality it's me.)

Latest comment:
This is some kind of footnote. This webpage is awesome and can be viewed in any browser. Even ones that suck ass like Safari and Firefox. Isn't that awesome? This site is best viewed with browsers that aren't maximized on large-resolution displays (> 1024 pixels in width). But then again, if you are running a large resolution and browsing maximized, then you're a terrible person so you don't really deserve to see this site at its finest. Jerk. I mean, seriously. I spend all this time making a nice site and your silly browsing habits ruin its look. That's really cold, man. If you're using IE6, then in order to see the cool avatar effects you need to enable JavaScript. This site conforms 100% with the laws (both known and unknown) governing physical reality. No rights reserved by Dean Whelton (who is awesome) of any of the content, images, design, backend or electrons used in this site. Steal at your convenience. None of it is worth stealing anyway, so there. I have even made an RSS feed for more efficient theft of my intellectual property. Now, don't say I'm not generous. I guess if you want to know more about me, you can visit the about page. I actually made a real about page! It's more like a FAQ, though. You can contact me, too, if you feel like it. Are you really wasting time reading this? Go outside or something.