Band-aids and Surgery

Today’s bit from Douglas Hofstadter relates to realizing you made a mistake back at the beginning:

…suppose you had written [a program for deriving theorems in number theory] but had forgotten to include TNT’s Axiom 1 in the list of axioms. After the program had done many thousands of derivations, you realized your oversight, and inserted the new axiom. The fact that you can do so in a trice shows that the system’s implicit knowledge is modular: but the new axiom’s contribution to the explicit knowledge of the system will only be reflected after a long time — after its effects have “diffused” outwards, as the odor of perfume slowly diffuses in a room when the bottle is broken. … Furthermore, if you wanted to go back and replace Axiom 1 by its negation, you could not just do that by itself; you would have to delete all theorems which had involved Axiom 1 in their derivations. Clearly the system’s explicit knowledge is not nearly so modular as its implicit knowledge.

A fundamental system in your game is broken or inadequate. You know it, the developers know it, everyone can see the proud nail sticking up. Why do they keep making tweaks to make the game work around it rather than just fixing it? Because fixing something upon which a lot depends is difficult, time-consuming, and risky. Adding something new is relatively easy.

When baking a cake, you accidentally mixed in two cups of flour instead of one. Un-mixing cake batter is theoretically possible but not something you can sanely do at home. Your options are to throw it all away or double everything else in the recipe. Adding is easy, and starting over is easier than un-breaking it.

Some part of your game’s accuracy system does not work properly, you just discovered two years after going live. Axe-wielders were not just whining; something is odd about how the code handles two-handed slashing weapons against non-moving targets in medium armor. There is no single value to change, any more than you can point to the part of the cake where the chocolate is. Which is less likely to break your game: adding an accuracy bonus to two-handed slashing weapons or re-writing 3% of your combat code? You could re-write that code, but your entire combat system interacts with it, so you would need to re-test literally everything to make sure the new code does not break something else. Try every weapon against every armor, make sure that it does not break monster AI, and then spend months discovering how many places someone hard-coded things that depended on some detail of the original code. Why couldn’t Carl have documented that the roc-hound’s attack sequence depended on how piercing weapons interacted with the movement speed of mounted targets?

Fixing the fundamental only gets worse once you already have a dozen band-aids on the wound. You must tear them all off and throw them away. But at least you get to do all those things you wanted to do if you had it to do over again.

: Zubon

5 thoughts on “Band-aids and Surgery”

  1. Very, very true, Zub, and very well put. I would like to point out something else, though…with an MMO (unlike non-MMO games), when you’re baking your cake, you’re working in an open-air bakery on a crowded street, with thousands of people begging to taste the batter. A portion of those that do immediately start telling everyone else in the crowd that your cake sucks, the balance between sugar and butter is waaaaay off, and it’s not going to matter how much frosting you put on it at the end, it’ll still suck.

    If you realize you screwed up the recipe before you put your cake in the oven, you’re going to lose some credibility with the crowd if you chunk it and start over. Unlike cooking up a single-player cake, everyone’s watching every move you make.

    If you don’t realize you screwed up the recipe until the cake is done and you’re frosting it…well, those people are waiting to pay you for a slice of cake (they’re practically screaming for it at this point), and you’ve got payroll to meet.

    Let them eat cake. :)

    And in answer to the “Why didn’t the baker listen when the batter-tasters said it was screwed up!?!” question: Well, since over half of them didn’t say anything (they were just in it for free cake batter), and of the ones that did complain, half of those griped about the batter having too much paprika in it. There is no paprika in it, you’ve looked and you don’t even have any paprika in the freakin’ kitchen, but you can see how the nutmeg/cinnamon combination would make people think that, so you ignore them all, since you don’t have time to filter through the millions of stupid comments to get to the ones that would actually help you bake a better cake.

    Good lord, Z…now I want cake.

  2. That raises the rather obvious yet oft-overlooked question of why any sane game designer — ignore, for now, the contradiction in terms — would allow any one equation to take input from so many other portions of the game.

    Maybe it’s just me. I think from a Cisco networking viewpoint : each layer should be as independent of other layers as possible, while still getting its functionality done. But looking at City of Heroes or World of Warcraft, and I don’t see any reason that the accuracy system should depend on that many values. The same goes for a damage scalar that relies on twenty other variables, or drop rates that think the phase of the moon is a good metric.

    (for that matter, the accuracy system in City of Heroes is often cited as being unnecessarily complex. Despite that, in my experience on the Current Defender Issue list, the vast, vast majority of issues tend to be basic number errors. Those that did involve code changes, such as the big Defense code change, required minimal changes outside of its domain.)

  3. As a programmer in the day-to-day world (as opposed to the online world), I definitely understand the “joys” of finding a huge oversight early on and trying to fix it. Sometimes, it’s just easier to program around it because if you fix it, you may end up breaking more in the process. And from there, it just trickles on :-\

    Now I need to call you before you come out here… all this talk of cake… :D

  4. A fundamental system in your game is broken or inadequate. You know it, the developers know it, everyone can see the proud nail sticking up. Why do they keep making tweaks to make the game work around it rather than just fixing it?

    You’re exactly right on this point, but there’s something else that might also factor into the decision not to remove the system. That is, the fact that most MMORPGs ultimately resolve down to being the same game.

    Yeah, this is like saying all fighting games are the same, or all first-person shooters are the same. Yet, actually, they are.

    Details may vary tremendously, of course, and enthusiasts will see how the various subtle differences between all those games require different strategies and what-not, but to a casual player this doesn’t matter for much, and it also doesn’t hide the fact that the games all feature similar paradigms for games that should be as different from each other as night is from day.

    I think some developers might stick with broken mechanics because they identify their game, they make it different from the others, they help to hide the ultimate similarity between it and Generic MMORPG Archetype. They’re sharp edges and corners that exist for their own sake, because the alternative is becoming a round ball, free of any individuality.

    City of [Hero|Villain]s’ inventory-less system is an example: I remember reading an interview in which a developer said that he thought most casual players thought inventory and item manipulation was too complicated to fuss with, so they just left it out of the game, with the exception of the rather bland inspiration and enhancement system. Then World of Warcraft showed up and showed how misguided that opinion actually was. Since then, they’ve taken various half-measures to adding more collectable abilities to the game: temporary powers, salvage, and most recently inventions, added to inspirations and enhancements.

    Each of these features has its own UI, when a single inventory system could encapsulate them all easily. So why don’t they just move to a full inventory then? I suspect it’s because they see the game’s lack of one as an identifying characteristic. It would make the game seem unlike what players perceive as CoX.

    Well, that’s how it looks from my end anyway….

  5. “Fixing the fundamental only gets worse once you already have a dozen band-aids on the wound”

    I think this is always the biggest problem with the band-aid approach. With each fix, we have to ask “am I saving money by using a band-aid rather than recreating a new solution, or am I only postponing the inevitable investment required?”

    If we have to keep adding bandaids, then that may actually cost more in continued maintenance than it would cost to re-write the core modules and re-test everything. But you have to analyze the costs, and the opportunity cost of other things there are to work on, and decide what the best investment is.

    After all, we all like to create elegant solutions, but the bottom line is the solutions have to either make or save money.

    I definitely prefer to just rewrite the core pieces so everything is nice and ordered and easy to maintain but just like your post indicates I have to check myself since I can get carried away and the time I spend rewriting and testing is sometimes to the detriment of time I should be spending on other things, and to my customers waiting for their fancy new apps.

Comments are closed.