RAMbots began life as an almost unrecognizably different game. In December of 1999, John Cooper and I began trying to design an Icehouse game revolving around the idea of neural-nets. In this hypothetical game, you would have a bunch of pieces (“neurons”) laid out in a grid in front of you, with each neuron having up to four orthogonal neighbors. A given neuron would either be pointing at one of its neighbors or standing upright on its base. You could activate a neuron, and events would occur based on the colors and sizes of the pieces involved. Perhaps an activation would cause other neurons to fire, creating a chain-reaction of activity throughout the network. You would probably have ways of adding and removing neurons from your network, and changing their orientations. It was all very vague, of course.
We did create and test some simple rule-sets based on these ideas. I don’t remember the details, but I do remember that the games we played weren’t very satisfying. For one thing, we never managed to create the kind of propagation effects I wanted to see. Our rules were much simpler than that. On your turn, you would point to one of your pieces and say “I’m activating this neuron”, and then you would perform some simple action based on the color and size of that piece, and perhaps of the piece it was pointing at. That didn’t feel very neural-net-like to me. A more serious problem was that the range of activity wasn’t very interesting. About all there was to do in this game was to change the structure of your own network in some way, or change someone else’s. We had no idea what the goal of such a game might be, and nothing interesting suggested itself.
I decided that the whole thing might be more compelling if there was (say) a chessboard in the middle of the table with pieces on it, and your neural-net determined how the pieces would move. I soon began thinking in terms of little robots. Each player would own a robot (represented by a large Icehouse piece), and the neural-nets would tell the robots how to run around on the chessboard, smashing into things and accomplishing as-yet-unspecified goals. I started thinking about ways to make these neural-nets generate behavior for little robots, but I soon began to feel that the whole network idea was too indirect and unintuitive. Most people (including me) don’t have a good feel for how to structure networks to produce behavior. My programmer’s mind naturally began to drift towards more procedural ideas, in which a line of instruction pieces would represent a linear string of “code”. I toyed with the idea of creating a full instruction set which would allow for “if-then”-type statements—for instance, “if the closest object is a small red piece, move towards it”, and so on. However, it was almost immediately clear that even these ideas were too elaborate. Inexorably, my thoughts gravitated towards the simplest and most obvious idea—set up a simple line of pieces behind a screen, lift your screen, and then execute your instructions one at a time. The direction that each piece points will tell your robot which way to move next.
Of course, there’s nothing original about this idea. I’d heard of RoboRally, although I’d never actually played it. (In fact, I decided that I didn’t want to play it, or even to learn anything more about it, until I’d worked out my own ideas for such a game.) The idea of a robot-programming game is a pretty obvious one, even for someone who’s never heard of RoboRally. Perhaps my idea to create a robot-programming game for the Icehouse pieces was a bit more inspired, but even that wasn’t a great leap. In fact, as soon as I thought about it, I realized that if I didn’t do it, someone else was going to. So I started working on it.
The Obvious and the Not-So-Obvious
Designing the initial framework of the game was surprisingly easy. I envisioned that each player would begin the game with an identical “code pool” of pieces—a small, medium, and large piece of each color. Each player would lay out a certain number of these pieces behind some kind of cardboard screen, and then everyone would reveal simultaneously. These instruction pieces would be executed in order from left to right. The direction that an instruction piece pointed would tell a robot which way to move; the size of the piece would tell it how far to move. If the robot wasn’t already facing in the proper direction, the first “pip” of the instruction would reorient it in place. (I did have some early thoughts about relative movement, in which a piece pointing away from you always moves your bot forward, a piece pointing to your left always turns your bot left, etc. But John quickly convinced me that absolute direction was superior, because it was so much easier to see.) I figured that an upright instruction piece could cause a robot to fire a colored “energy beam” out in front of itself. I didn’t know exactly what these beams would do, but effects like pushing, pulling, and damaging were obvious candidates.
Now an interesting and difficult question presented itself: what should determine the order in which different players’ instructions run? The obvious solution—execute one instruction at a time, moving clockwise around the table—had a serious problem: it was boring. In fact, I now think that if I hadn’t come up with something more interesting, I probably would have ended up dropping the whole robot-programming idea and moving on to something else. However, after a day or two of thinking about it, an idea popped into my head: I could use a stack of four medium Icehouse pieces to indicate the precedence order of the four colors. Combined with the three size ranks, this would generate 12 unique ranks altogether. So, for instance, you could compare the players’ upcoming instructions and execute the one with the highest ranking color. If there’s a tie for highest color, you could execute the largest tying piece (or maybe the smallest—I wasn’t sure yet). I figured that at the beginning of each programming round you could randomize or rotate the color precedence stack, so that sometimes red actions would be fast, and sometimes they’d be slow. This system seemed juicy and promising; now I was designing in earnest.
I knew that there were plenty of unresolved issues with that precedence idea, but I wasn’t worried—I figured we’d work them out in playtesting. However, in order to even start playtesting, I needed to come up with some kind of a goal for the game, even if only a temporary one. My first idea was that you could try to damage other robots (causing them to lose pieces from their code pools), while trying not to be damaged yourself; the last player left with code-pool pieces would win. However, that idea seemed likely to have an accelerating-win problem, and also threatened to end by grinding to a halt rather than escalating to a glorious climax. Furthermore, John and I really wanted to stay away from the idea of player elimination. John suggested that the object of the game could be to push others off the edges of the board while remaining on it yourself, but once again, this idea required player elimination.
A more promising idea was to have all of the players racing to accomplish some task. Robots might damage other robots, but only as a means to some other end. Player elimination would (hopefully) be impossible, or at least very unlikely. So, what goal might the players be racing towards? Well, it occurred to me that there were four small pieces—one of each color—that currently weren’t being used for anything. Why not incorporate these pieces into the goal of the game? The most obvious thing to do with them was to put them out onto the board with the robots. Once I had that idea, it wasn’t hard to envision the goal of tagging these “beacons” in some specified order. Of course, now you’d need some way to remember which beacons you’d tagged. The obvious solution was to give you a “goal stack” of pieces which represented the order in which you need to tag the four beacons. Whenever you successfully tag the beacon matching the color on top of your goal stack, you take that piece off of your stack and add it to your code-pool (which would give you a nice little extra reward for tagging the goal). The winner would be the first player to tag all four colors in this fashion. This idea seemed so good to me—and I was so pleased with its efficient usage of every single piece of the Icehouse set—that I hardly even needed to try it to know that it was right. Indeed, this system has survived almost intact throughout the entire development of RAMbots.
(We modified the goal system only slightly over the course of the design. At first, we had players build their own goal-stacks at the beginning of the game, using pieces from their own code pools. However, everyone naturally made their own stacks as easy as possible, so everyone almost always got their first goal on the first round. We decided it made more sense for each player to build a goal-stack for the player on his or her left, so that everyone would begin the game with difficult goal-stacks rather than easy ones. The only other modification was the addition of beacon activation and deactivation, and the corresponding idea of being able to tag RAMbots as well as beacons. More about that later.)
The Precedence System
Now that I had a goal, I was ready to return to the knotty issues of precedence. The first problem I tackled was: when two players have identical instruction pieces ready to execute, which one should run first? It seemed that the only way to break this tie would be to establish an order of player precedence. And of course, there was an obvious way to do this: simply compare the color of each player’s RAMbot to the color precedence stack. However, I was afraid that this might affect the desirability of the different RAMbot colors. Consider: whenever (say) the red action has the highest color precedence, the player with the red robot will always have the highest player precedence. This means that the red RAMbot is the only RAMbot that can fire the fastest-possible red beam. (Of course, when red is on the bottom of the stack, the red RAMbot has the slowest-possible red beam. Mathematically, this balances perfectly, but practically speaking, it may not.) Unless the four color actions turned out to be perfectly balanced (an unlikely occurrence), one of the RAMbots might turn out to be slightly more desirable than the others. In an attempt to address this concern, I went as far as to suggest making a second precedence stack to indicate player precedence, or maybe having a “player precedence marker” which passes to the left at the beginning of each programming round. However, John once again convinced me that the simplest answer—using the precedence stack for color and player precedence—was vastly preferable, and that it wasn’t worth worrying about until playtesting actually proved that it was a problem. (It never did.)
Another question regarding precedence was: should size take precedence over color, or vice-versa? In other words, when deciding which instruction to execute next, do you first look at the precedence stack, and only look at the sizes of the pieces when there’s a tie? Or do you first look at the sizes of the pieces, and only look to the precedence stack when there’s a tie? John and I wasted a lot of time arguing about which system was better. Ultimately, the matter was only settled through playtesting. John’s intuition was correct: size first, then color. Not only was the resulting game more interesting (because the four color actions were always available in the top four precedence ranks), but it turned out that size precedence was easier to see than color precedence, so it was better to check for it first.
Yet another question was: should larger pieces execute earlier than smaller ones, or vice-versa? At first, I didn’t even consider this question; I just assumed that larger pieces should execute earlier. This wasn’t based on any kind of gameplay analysis; it was just an intuitive sense that stronger pieces ought to be able to muscle their way in front of weaker pieces. Perhaps I was conceptualizing an instruction piece as a “bid” to execute next—and of course, it then feels like the “highest” or “strongest” bid should win. Another more distant analogy would be to compare instructions to cards in a trick; once again, the highest number wins. Nevertheless, after John and I played our very first two-player tests, we both began to realize that something was amiss. Not only did the small pieces do a lot less, but they executed so “slowly” that they felt almost useless. The solution dawned on us both at about the same time: we should make smaller pieces execute before larger ones. We tried this, and of course it worked like a charm.
(I refer to this kind of balancing solution, in which some action is more powerful in one way, but less powerful in some different but inversely-proportional way, as “the ol’ criss-cross”. I find it to be extremely pleasing… when it works! Perhaps the most interesting element of this story is not the solution itself, but the fact that it took me at least a day to shake off my previous assumptions and come up with a new thematic gloss that helped me feel good about the solution. As I wrote to John via email: “of course the small pieces execute first—they only take one nano-second to to perform their actions, while the medium and large pieces require two or three…”)
I had one final question regarding precedence mechanics. In our initial playtests, we quickly developed the following convention: after everyone finishes programming and lifts up their screens, each player slides his or her first instruction forward to the middle of the nearest board-edge—an action which we began referring to as “loading the program register”. The precedence system dictates which of these instructions executes first. Now, after the first instruction executes, should that player immediately slide his or her next instruction forward to be checked along with all the others? Or must that player wait until all the other loaded instructions have run, at which point all players slide their next pieces forward? My strong intuition was that the former idea was significantly deeper and more interesting, but it was difficult to be certain, especially at this early stage of the design. However, once the basic rules had stabilized a bit, a few decisive playtests put this question to rest for me. If players wait to load their program registers at the same time, the precedence system becomes flat and uninteresting—you know that your fifth instruction is going to run (more or less) along with everyone else’s fifth instruction. If, on the other hand, you load your next instruction immediately, you might run your entire program before some other player’s program even begins to run. The result is a fascinating interweaving of the different programs, creating a delicious tension between executing early and getting more work done. When combined with the movement rules, the color-action rules, the shuffling of code-pool pieces via damage, and the emergent setup of the board at the beginning of each new programming-round, the precedence system generates a wealth of juicy decisions for RAMbots programmers.
The Rest of the Rules
It took a few weeks of playtesting with the Core Four to hammer out those precedence-system details. This process was made more difficult by the fact that we were simultaneously tweaking the the movement system, the damage system, and the color-action system. This process continued long after the precedence system had solidified; indeed, as is my wont, I was still making modifications a year and a half later.
Nevertheless, much of the basic design was already in place. I’d decided that a pointing instruction moves your robot, while an upright instruction fires a colored beam of energy. When you ram into something (a beacon, a robot, or a whole line of objects), you push it out in front of you, unless it’s already against a wall. When you ram into the beacon that matches the top of your goal stack, you “tag” it for a goal. Pretty simple so far. (Incidentally, it was around this time that we actively started thinking about a name for the game. I suggested things like “Juggernauts” and “KillDozer!”. John suggested “RAMbots”, with its cute double-entendre—not only do the robots ram into things, but they also access precious RAM when they steal an opponent’s code or tag a beacon for a goal.)
I wanted code-pool pieces to change hands over the course of a game, in order to mix up the distribution of resources. I also wanted players to be able to ram each other and shoot each other with lasers. These two ideas meshed nicely. However, there were still lots of messy details to work out. For instance, when should ramming damage occur? It was tempting to suggest that any time two RAMbots came into contact with each other (even when being pushed by another RAMbot), one of them would damage the other. Indeed, I initially came up with just such a system—a complex set of rules determining the order in which RAMbots get damaged when they are pushed into other RAMbots, and so on. Our first four-player test convinced us that these rules were way too messy. We decided that the active RAMbot should be the only one that can ever cause damage, and it can only damage the RAMbot that it directly rams or shoots.
Other questions about damage included:
1) How many pieces should you get to steal when you RAM another bot? I figured that the size of your instruction ought to play a role, but even then, there were lots of options. Sometimes we played that the number of times you actually contact the other RAMbot determines the amount of damage (if you move two spaces and then run into another RAMbot, you only get one pip of damage); other times we played that damage was always based on the full size of the instruction. Sometimes we played that a large instruction could cause three pieces of code to be stolen, and sometimes we played that it would cause three pips worth of code to be stolen. And so on.
2) Which piece should a player get to steal when he or she damages another player? For a long time, we allowed players to choose which piece(s) to steal, interjecting a little bit of free-will into the otherwise deterministic execution phase. Later, we decided that even this should be deterministic; pieces should be stolen according to precedence (you take the smallest piece available, and when there are multiple colors to choose from you take the one that’s highest on the precedence stack). This eliminated any chance of analysis paralysis in the execution phase, and helped balance our final system by making damage slightly less painful (because you can’t just choose to take the most damaging piece).
The Color Actions
Working out the details of the four color actions was by far the most difficult aspect of RAMbots’ design. I knew from the beginning that I wanted the red beam to be a damage beam, and I wanted the yellow beam to be a tractor-beam which would pull objects towards you. This left two more actions to be determined. A push-beam was an obvious compliment to the pull-beam, but I wasn’t convinced it would be useful enough, so John and I discussed other options.
Of my own ideas, the one I liked best was “shields mode”. I figured it might be interesting to allow one of the color actions to set your own RAMbot upright on its base, indicating that it’s temporarily shielded. In this position, it cannot be damaged, either by the red beam or by being RAMed. As soon as you execute another movement instruction, your bot tips downwards, and then continues on as normal. We decided to give this action a try, and assigned the color blue to it.
For our forth action (the green one), we decided to try an idea of John’s called “repair”. In this idea, damage doesn’t immediately cause pieces to change hands. Instead, when a RAMbot is damaged, some of its code-pool pieces go into the “global repair stash”. The green repair action allows players to transfer pieces from this global stash into their own code-pools. I had my doubts about this idea, but we decided to go with it for our initial playtesting session with the Core Four.
As I suspected, the repair action was the first casualty of that session. There were two glaring problems with it: first of all, there was no good place to physically put the global repair stash; every inch of available table space was already being used by goal-stacks, code-pools, program areas, the game-board, and so on. Second of all, the repair concept made the red damage beam (and RAMing, for that matter) a lot less interesting, because even if you managed to shoot or RAM another bot, you weren’t guaranteed to reap the benefits of your own action. We axed the repair idea, and simply said that whenever you damage another bot, you steal pieces from it directly.
A Better Green Action
Of course, this left us with an unused green action. Since the only other idea we had at that time was the old “push-beam” idea, we decided to give it a try and see how useful it actually was. As expected, people didn’t use it very much, but it had the benefit of simplicity (it was almost exactly like the pull-beam), and we couldn’t think of anything better.
Occasionally, during the following months, we made half-hearted attempts to spice up the push-beam. For instance, I once suggested changing RAMing so that it doesn’t actually push objects out in front of you. So if there’s some object in your way, you either have to push it with the green beam or move around it (which requires many extra instructions). We tried this idea once or twice, and it actually did have the desired effect—the push beam became much more useful and interesting. However, the overall gameplay was affected for the worse—the board felt more constricted and less active, beacons didn’t move around as much, and so on. Many of these issues fell under the jurisdiction of Kristin Matherly’s role in the Core Four—the game just wasn’t as fun when RAMing didn’t push objects around!
At one point, John suggested replacing the push-beam with a completely different action: “reverse gear”. Under this rule, an upright green instruction would move your RAMbot backwards for one, two, or three spaces (depending on the size of the instruction). We tried this a few times, and it certainly was interesting and sometimes useful. However, it wasn’t obvious that it was more useful than the push beam, and the push beam seemed more elegant. Ultimately, I wasn’t really satisfied with either one, so I kept them both in mind, and alternated between them based on my mood. Sometimes I just asked playtesters before a given game which one they wanted to use.
During one such playtesting session (at the Y2K Origins, as I recall), Andrew Plotkin suggested combining the two ideas. The green beam pushes away any object it hits, and it kicks your RAMbot backwards in the opposite direction. I thought that this was a brilliant solution, and I immediately adopted it as the new green action. (“Zarf, you’re a genius!” I said after we tried it. He shrugged noncommittally.) Later, our friend Peter Hammond dubbed it “Newtonian Push”—a name of which he was so proud that, when we included him in the credits page of Playing with Pyramids, he asked to be listed as Peter “Newtonian Push” Hammond. (Unfortunately for him, RAMbots had by then evolved beyond this idea, as you’ll see below. Perhaps my recording of it here will provide him with some small consolation.)
Trouble with Shields
Now I’m going to backtrack and talk about the evolution of the shields idea, which occurred during the same period of time as the evolution of the “Newtonian-push” idea. In contrast to the original “repair” action, everyone initially seemed to like the blue shields action. However, after a few weeks of playtesting, some problems started to crop up. Although people did sometimes use the action, there was a general feeling that it wasn’t quite useful enough. It was difficult to justify spending a precious instruction to stand upright in place, guarding against some (usually only potential) threat, when you could use that same instruction to move further toward your goal.
We came up with a number of different ways to address this problem, and we tried them in isolation and in combination with each other. For instance, we tried making shields more offensive by saying that anytime you’re RAMed or shot while you’re shielded, you get to steal damage pieces from the aggressor. This provided more motivation to use the shields action, because, as with the red action, it might actually increase your power for the next round. Another idea was to provide a way for the color actions to function even while you are in shields mode. The idea was that if you execute an upright instruction while you’re standing on your base, you would fire beams outward in all four directions. This provided a lot of extra incentive to use shields, because now you could actually get work done while you’re shielded—for instance, you could shoot out yellow beams to pull multiple beacons toward you. On top of this, we sometimes considered further rules, such as: you can damage people or tag beacons by pulling them into you while you’re shielded. Nowadays, we consider rules like these to be unacceptably complex and fiddly, but we weren’t quite as sensitive to such issues in those days.
There was, however, a different kind of elegance issue that I was sensitive to at that time. The “damage”, “push”, and “pull” color actions were all “energy beams” that shot out from your RAMbot and affected other objects, while the “shields” action was not a beam at all; it just directly affected your own RAMbot. Furthermore, the size of the blue “shields” instruction had no bearing on the strength of the shields action, while the sizes of the other three colored instructions dictated the strength of the push, the pull, or the damage. I was bothered by the exceptional nature of the shields action—I wanted all four color actions to follow a similar pattern.
After thinking about it for a while, I came up with a partial solution to the problem. My idea was that, whenever you execute an upright blue instruction, you turn your RAMbot upright and then stack your blue instruction on top of it to represent your shield. A large blue instruction piece would therefore represent a stronger shield than a smaller one. Of course, we had to change the damage rules to incorporate the idea of shield strength, but that was easy enough. The real point was: now the size of the instruction piece mattered—so my elegance problem was at least partially solved. Not completely, of course; but it was better than nothing.
With these newest shields rules in place, and with the adoption of the Newtonian-push idea, I felt that we had a pretty solid rule-set. We made few, if any, additional rule modifications during the following months of play. However, over the course of time, I began to feel less and less happy about those darned shields rules. Sure, I’d figured out a way to make the size of the shields instruction matter, but I’d done it in such a strange way that I nullified the gain in elegance that had motivated the change in the first place. Not only that, but I was still bothered by the fact that the shields action was not a beam, while the other three were. As time went on, I began to view this as the deepest pattern that all color actions ought to follow—they ought to all be beams. Furthermore, all the extra rules that we’d added in order to make shields even worth using were beginning to feel unwieldy. And last but not least, I began to dislike the way that shields encouraged sitting in place rather than actively moving towards your goal. All of these thoughts added up to a very clear conclusion: it was time to axe the idea and come up with some completely different, beam-based action.
This was a daunting task; we’d struggled just to come up with the four moderately interesting actions that we currently had. Nevertheless, I held firm in my conviction that shields had to go, so one afternoon Jake, John and I sat around in John’s living room and brainstormed about other possible actions. I remember talking at length about having a beam which knocks instructions off of the end of people’s programs, but we finally discarded this idea as too chaotic, and not very interesting strategically. Eventually the conversation turned to the possibility of tipping beacons onto their sides, and to the idea that only upright (activated) beacons could be tagged for a goal. Suddenly, a new type of action presented itself—an “activation” beam that turns beacons upright, preparing them to be tagged. This was simple to explain, it fit nicely into the “energy beam” paradigm, and it would clearly be an action that players would be motivated to use—indeed, they’d need to use it to win. It added some spice to the challenge of tagging beacons, and it also led to the possibility that the red beam could deactivate beacons, giving players yet another way to mess each other up from a distance. I loved it.
A few days later, I made yet another breakthrough in our quest for elegance. It occurred to me that the beacons were beginning to seem more and more like little dormant RAMbots. Elegance suggested, therefore, that we should make beacons and RAMbots as much alike as possible; for instance, all beams should affect beacons in the same way that they affect RAMbots. Our new activation beam should stand any object up on its base, whether it’s a beacon or a RAMbot. That thought lead to this breakthrough: why not go all the way? Why not allow a player to tag an upright RAMbot for a goal, as well as a beacon? I knew that this idea was “right” the moment I thought of it. Not only was it beautifully elegant, but it promised to add a whole new level of excitement to the play of the game. Tagging an upright RAMbot would be tricky (because as soon as it moves, it tips down on its side and becomes “deactivated”), but it would be glorious when it occurred. This is a terrific example of my principle that insisting on elegance just for the sake of it often leads to unexpected improvements in gameplay that never would have been discovered otherwise.
(An interesting aside: once we’d hashed out the details of this new “activate” action, I decided that it made more sense to assign the color green to it. Green often has the connotations of “go”, and it made a nice complement to the red “damage” action, which sort of represented “stop”. Blue and yellow, the other pair of complementary colors, would be used for “push” and “pull”. I remember feeling a little trepidation about switching these colors around, since the game had already been published on the web at this time. However, I took the long view that any confusion or frustration I caused would seem pretty insignificant when I looked back on it after a couple of years. And, of course, looking back on it now after a couple of years, it’s clear that I was correct.)
Although the following portion of this little tale discusses a feature of RAMbots that was ultimately eliminated from the game, I would be remiss if I didn’t mention it at all, because we spent an inordinate amount of time thinking about it, discussing it, and playtesting it. It’s a classic case of a designer (me) getting stuck on a pet idea that’s just too complex to support its own weight.
From the very beginning of the design, I wanted beacons to be able to shoot out beams of their own color in all directions. My initial idea was that when you shot a beacon with the red beam, instead of damaging the beacon (since beacons couldn’t be damaged), it would “trigger” or “activate” the beacon, causing it to shoot beams of its own color in all four directions. This had all sorts of fun side-effects. For instance, if you shot the yellow beacon with a red beam, it would shoot out yellow beams, one of which would hit you and pull you toward it. If you shot the red beacon with a red beam, it would hit you (for no damage, since you would just steal from yourself), and might possibly damage multiple opponents. Even better, those red beams could hit other beacons, triggering them to activate and shoot out more beams, etc. Never mind the fact that this rule generated all sorts of questions and exception cases. I thought it was neat, and that was that.
By the time we came up with the new green “activate” action, I’d learned a bit more about the value of elegance, and I’d begun to dislike the way the red beam had an exceptional effect on beacons. However, rather than let go of my pet idea altogether, I saw what I felt was a much more attractive possibility—I could incorporate the beam-shooting phenomenon into the new green action. So when a green beam hits an object, that object turns upright, and then fires out four beams of its own color in all four directions. Certainly, this was a move toward elegance; the beam-shooting phenomenon meshed well with the setting-objects-upright phenomenon, and the action treated RAMbots and beacons identically.
However, there were three niggling little problems. First of all, how do you decide in what order to activate things? Second of all, how do you keep track of what things still need to be executed? And finally, if the green RAMbot shoots the green beacon, or if the green beacon is activated and then shoots the green RAMbot, how do you handle the infinite regress that results? The two objects will continue to shoot each other with green beams forever.
I can’t even begin to describe all of the convoluted solutions we proposed for these problems, but suffice to say, it wasn’t worth the energy we poured into it. The solution I preferred was fairly simple—activated objects only shoot out three beams (one to the left, one straight ahead, and one to the right, in that order). But not only did the ordering of the beams seemed arbitrary and inelegant; I had to explain why the blue beacon didn’t kick back in the fourth direction when it shot its push-beams out in the other three. Basically, it was just a mess.
In my own defense, there was a respectable reason why I continued to try to make this idea work. For each of the four color actions, I still wanted the size of the instruction to indicate the strength of the beam, and I couldn’t think of any way to do this if the green action was just “stand the object upright”. Nevertheless, once I’d beat my head against the problem one too many times, I finally gave up and did the obvious thing: I let the idea go. I consoled myself with the knowledge that the four color actions—push, pull, activate, and damage—were now very simple, and they all followed the same basic elegant pattern.
(Incidentally, in our final version of the game, the size of an instruction doesn’t affect the strength of the green beam or the red beam; it only affects the strength of the yellow beam and the blue beam. I find this kind of sub-division into complementary pairs—reminiscent of Gnostica’s swords/pentacles and wands/cups pairings—to be an acceptable level of elegance.)
A Major Paradigm Shift
The design of RAMbots at this point was cleaner and more solid than it had ever been. Once again, months passed without any real change to the rule-set, and we began telling people that the game was done. It wasn’t, of course.
As we continued to play more and more RAMbots, two problems gradually began to surface. First of all, as ingenious as the “Newtonian push” was, and as much as it really did solve a tricky design problem, I finally had to admit that it didn’t really meet our standards of elegance. It was the only beam that caused the position of your RAMbot to change, and the simplicity and elegance of the newest rule-set caused this exception to stick out like a sore thumb. Why didn’t (say) the red damage beam also have this kickback effect? There was no explanation in game-world terms; the simple fact was, the kickback effect was tacked onto the blue beam because it wasn’t useful enough without it. It was a patch.
The second problem was surprisingly similar to this one: after repeated play, we found that experienced players pretty much stopped using the red beam. As with the push action without kickback, the damage action just didn’t seem worth spending a precious instruction on. At this time we were still experimenting with different damage systems—sometimes we’d try stealing damage by pips, sometimes by pieces, and so on. It was tempting to try to solve the red beam problem by increasing the level of damage the beam caused. Red action not good enough? No problem! We’ll just keep increasing its power until players won’t be able to resist using it! This is what I’ve come to call “game design with a sledgehammer”, and I was deeply uncomfortable with it. We tried various versions of “double damage”, and, as predicted, they did increase the motivation to use the red beam. However, each one felt like a band-aid, just like the kickback action we’d added to the push beam.
So, there we were with our problems: two of our four color actions were simply not quite useful enough, and we couldn’t see how to make them useful enough without adding some inelegant, kludgey rules. One night, at John and Gina’s monthly “First Friday” party, Dale Newfield made an interesting suggestion. He suggested that the red action could move your RAMbot forward and then shoot out the red beam. That way, if your beam doesn’t hit anything, you’ve at least been able to advance toward your goal. Of course, this idea is just as kludgey as the kickback idea. However, it was a very important suggestion, because it helped me shift my focus away from trying to solve the problem by increasing the power of the red beam. I began to realize that the problem wasn’t that the damage beam and the push beam weren’t useful. There were plenty of times when you wanted to push an opponent or a beacon in order to screw someone up, or to damage someone in order to replenish your code pool. The problem was that if your beam missed your target (which often happened), then you’d accomplished nothing else with your precious instruction. In a game where the ultimate goal was to keep moving toward your goal, the opportunity cost of using the push beam or the damage beam was way too high. So maybe the solution was to find a more elegant way to allow players to use these actions and move towards their goal at the same time.
I remember the moment when the breakthrough actually occurred. (I was pulling out of a Blockbuster Video parking lot, as it happens.) I thought: instead of having this dichotomy between movement instructions and color-beam instructions, why not merge the two? Why not say that every instruction moves your RAMbot, and then fires a beam? So a flat red instruction will move your RAMbot in the appropriate direction and then fire a red beam, in keeping with Dale’s suggestion. A flat blue instruction will move your RAMbot forward and then fire a blue beam. In both cases, the action of the beam can be useful and important, but if it ends up not hitting anything, your instruction isn’t wasted. Of course, elegance demanded that these rules be extended to the other two color actions as well; so a flat green instruction will move your RAMbot forward and then fire a green activation beam, and so on. Unlike previous “fixes”, these new rules worked fine when applied to all the different color actions. Now, what about upright instructions? My immediate thought was that the upright orientation could now be used to represent the old concept of “reverse gear”. Therefore, an upright blue instruction would move your RAMbot backwards and then fire the blue beam… just as it already had been doing! But now there was a different explanation of why it was doing it, and this conceptual shift made all the difference. Now the phenomenon applied to all the other color actions as well; for instance, an upright red instruction would cause your RAMbot to back up and then fire a red beam, and an upright yellow instruction would cause your RAMbot to back up and fire a yellow beam. (Incidentally, this last possibility was an unexpected bonus. It essentially provides the ability to move backwards while dragging an object along in tow. Many months earlier, Jake had expressed a desire to be able to “drag beacons around” somehow. And here, out of the blue, was a rule that unexpectedly caused that very phenomenon to emerge! Once again: insisting on elegance for its own sake often leads to unexpected improvements in gameplay that never would have been discovered otherwise.)
I was ecstatic about these ideas, and I felt sure that they would solve our remaining problems. We gave them a try, and, in fact, they not only solved our remaining problems, but they ended up improving the the game in other subtle and intangible ways that we couldn’t have predicted. For instance, I discovered that, under the new rules, it became easier to come back from a bad position to win the game. In previous versions, it felt as though it was almost impossible to win if you got (say) two beacons behind, but this no longer seemed to be true. I think the reasons for this are highly complex and emergent. In general, you can now get more work done per instruction, so when you get behind it’s more profitable to take some risks and try to tag multiple goals in a single round. I also think that under the new rules, it’s easier to hamper the leader while moving toward your own goal at the same time. There are probably other effects here that I’m not even aware of; suffice to say, I’ve seen some amazing comebacks occur under the current rule-set. (Perhaps the most memorable example occurred in the final game of the RAMbots tournament at Origins 2002, when Andy Looney lost all but two of his code-pool pieces on the first round, and then came back to win the game and the tournament!)
In general, the new game was more snappy and more active; there were more ways to approach any given situation, and more ways to mess with your opponents. The programming phase contained an even higher number of juicy decisions, as you had to consider the effect of every instruction’s color-action. The ordering of the colors in the precedence stack seemed to matter even more than they did before; the precedence system and the action system became even further intertwined. In short, the new rules were just more fun. And, as Kristin Matherly will tell you, that’s ultimately what it’s all about.
Wrapping it Up
Those were the last big changes that we made to RAMbots; after that, all we had to do was tie up a few loose ends. For instance, we still hadn’t quite decided whether damage should be based on pips or pieces, or neither. However, now that we were free of the need to make the red beam “good enough” for people to use, we were able to go with the simplest option: the red beam (or ramming) should always just steal a single code-pool piece. (This had a pleasing side effect, which was that a flat red instruction often caused two pieces of damage—one by RAMing someone, and then one by the immediately-following red beam. The result was a purely emergent version of “double-damage”!) In this way, the red action felt even more like a complement to the green action; they were both simple atomic actions which didn’t pay attention to the size of the instruction, while the push and pull actions, being more movement-based, did.
The last issue I remember dealing with was: when should an upright object be knocked over? The three possibilities were: when it’s damaged (i.e. RAMed or shot with a red beam), just when it is RAMed, or just when it is tagged for a goal. We went round and round about this for a while, but the option we finally settled on (and published in Playing with Pyramids) was that an upright object only falls over when it is RAMed (whether or not it’s tagged for a goal). For the record, I think I’ve changed my mind about this one; I think upright objects should also fall over when shot with the red beam. Our initial reasoning was that it would be annoying to run toward your own goal with a flat red instruction and knock it over by accident, and that people might often forget to follow the rules in this case. However, my experience indicates that most people intuitively feel that the red beam should knock over objects, so I suspect it’s ultimately a better rule. I also like the way it reinforces the elegant pairing of the red and green actions: green is “activate”, and red is “deactivate (with damage)”. Perhaps someday I’ll playtest this and update the web rules; maybe we’ll even change it in the next printing of Playing with Pyramids. Then, of course, we can finally and truly say that RAMbots is done.