2014 Strategy/ Space Shooter developed by Anisoptera Games
The joy of playing with Lego was, for me, always tempered by the fact that whatever monstrous fighting machine I ended up building (and it was, inevitably, a monstrous fighting machine I ended up building), never actually did anything. There are games now which cater for the disappointed evil engineer in all of us, and I would like to talk about one of them and the surprising lessons it has to share, here.
Reassembly falls into a genre which is difficult to pinpoint, but which I will be calling “engineering” games. The important thing about an engineering game, is that the player makes virtual machines to influence the game world—and that making these machines is integral to the gameplay. The general category encompasses a wide variety of games like Space Engineers, Factorio and Kerbal Space Program. Engineering games generally tend to fairly open ended, with a good deal of space for player experimentation. They are also, for the most part, not really about anything other than the machines and mechanisms that one builds. They have of course, semblances of story lines and settings, but this is almost always a simple narrative scaffolding. The real interest of these games, their important themes and their best story arcs, are all about the player coming to understand the game world in which they are situated and using the materials at hand to try and influence or control that world.
What is wonderful about all engineering games is the space of possibilities they provide for player expression. By this I do not simply mean the ability to draw pictures, or make a nice looking space ship (although these things are often not ruled out). Instead I should like to treat player expression in this case, as being to do with problem solving and experimentation. There is rarely a single way to solve a problem in an engineering game, and as a player I enjoy them most when I am trying to work out a solution to a problem by combining what I know about the game world, with what I know I can build. Player expression in an engineering game is bounded by the hard facts of the game world—what kind of machines the physics engine will cope with, the relative toughness of various materials, and how the game treats of its different entities. Much like real world engineering then, good solutions in an engineering game, are suited to the environment and rules of that game and it is in one’s attempt to appreciate and understand those rules and limits that players experiment and express their creativity. If these games tell us stories, they tell us them on the basis of what they do, not what the basis of what they say.
Reassembly might have a story, hidden in a text document somewhere, but I have not encountered it, and have not felt the lack of it. The basics become clear soon after starting the game up. You are a — 2D, viewed from the top-down— spaceship, one among a faction of space ships that share a bright, neon, color pallet (chosen by yourself), and a faction specific set of component parts with which to make more spaceships. The space around your faction is full of other factions, with their own ships, and if there is a goal in the game, it is to find and re-build your faction’s space stations in order to claim territory. Later on in the game one will also encounter other player’s creations, which they have submitted to the cloud. The physics have a satisfying, semi-realistic weight (although ships feel less like they are in space, and more like they are underwater) the music trance like and the visuals are simplistic, arcade cambinetesque, but beautifully drawn in a strong electric color pallet.
The unique thing about Reassembly is that one can reconfigure one’s ship on the fly and at the drop of a hat. A single press of a button will bring up one’s ship design on screen, where pieces can be dragged, dropped, enlarged and rotated to one’s heart’s desire. This process is Lego-like, in that each part has a number of possible connection points on each facing, which match up to other connection points. One takes parts from an infinite pallet of simple geometrically shaped hull bits, engines and weapons. One’s design is limited only by the “P” or power rating of one’s ship—which can be increased by spending the game’s currency “c” (which can also be spent to unlock new kinds of block), although hull blocks are always free to add—but add weight that degrades the efficiency of the engines. All ships in Reassembly slowly rebuild themselves after they are damaged, and one must factor this in to the design of one’s ships. Blocks which are connected by only one other block to the rest of the ship rebuild the fastest, but are brittle, whereas a solid mass of blocks is tough, but slow to restructure. After a while one will unlock the capacity to add a ship-constructor onto one’s own ship, which, provided that you have the “r” (resources) can spit out any ship that you have designed. These ships in turn can have ship-constructors on them, and so on and so on, until it can be difficult to make out your ship in the bright neon colored blob of self-replicating machines. At no point does Reassembly ask you to do anything very difficult. There is, of course, difficulty to be found if one goes looking for it, in the shape of other human player’s creations. Otherwise the game is quite content to let one potter about with its systems and its design, and this can make play almost trance like. One floats across the galaxy to weird, relaxing electronic theme music. One can simply stop and admire the symphony of color and shape, signifying destruction and conflict, playing out in concentric circles of decreasing intensity around one’s own ship.
What makes Reassembly compelling, and worth talking about at some length, is the kind of stories that it tells. Reassembly tells a story about the player to the player. One starts out in ignorance, and comes to find power at first by luck, but eventually through knowledge—but only after a litany of failures.
The first few ships that the player makes in Reassembly are likely to be complete failures, or at the very least deeply mediocre. When first confronted by a set of parts, and unsure of how those parts do what they do, important components get left out of a design or simply left on the shelf because one has an inadequate idea of that they do. This is often the result of attempting to apply preconceptions of what is going to be “good” in the game, onto the game itself. For me, in Reassembly, this took the form of a long line of what I now know to be extremely slow ships. I thought that I was being very clever in making sure that I had an equal number of thrusters in all directions and on every side (omi-directional thrust, awesome right?)—I also bought too few thrusters. I did however load up on guns. Applying what I knew from other games I reasoned that rate of fire was my best bet for weapon systems, and so I strapped a bunch of what were essentially machine guns onto my engine ball. The result was… underwhelming. I had essentially a senile dog, it was slow in any direction and dribbled ineffectually on everything it tried to chew.
The machine-gun like weapons I had covered this butterball with had exactly the punch of a baby and the range of a cup falling from a table. This butterball went through a few variations, and it took me a long time to notice how damn slow the thing was, so I stuck a few more engines on it and changed the guns for something punchier, but a disappointment it remained. As I was progressing through the game, I decided that I needed to change my flagship into something that could build other ships, so I set about designing something like a capital ship. It was ugly, but it had a bunch of engines pointing one way (because of the increased weight it made sense to have a bit more oomph), and two racks of missiles providing its teeth. I thought it would be slow and purposeful, a backline support unit. The result was not that at all, it was a terrible support unit. However it was also the most terrifically dangerous apex predator I had seen until that point. The thing moved like absolute stink (in one direction) and the missiles scythed through most computer generated foes like they were hardly even there. I was flabbergasted, it was the first time anything I had made in the game had actually proved itself useful, just not for the reason I thought it would. I decided to give the machine the name I had given it in testing “Warmother”, a name that seemed apt. She was an ugly, awesome, aberration.
This kind of event is a recurring one in engineering games, it is the first breakthrough, and generally comes about via failed experiment. One creates something to do a job, and it ends up doing something else really damn well. Or at least, the machine performs well enough at some task to give one an insight into how to do that thing well, if one needed to. The process is like a kind of intelligent evolution, an ignorant human combining what might as well be random pieces of digital genetic material and smashing them against the game world until one ends up surviving. It is also the first step in gaining some knowledge of how the game actually works. One can read a great deal about a design game, contemplate that and process that into a design philosophy, but it is when the rubber hits the road and philosophy enters into practice that learning really occurs. Before that point one might be able to appreciate in abstract what design parameters one is going for—say, omni-directional thrust or a torpedo throwing boat— but the application of that idea into a reality requires an appreciation of all of the rest of the moving parts of the machine one is making. When a breakthrough happens, one comes to see an element that one has been ignoring, or simply not appreciating, clearly and distinctly. One sees just what one was missing by seeing that element in its ideal operation.
Eventually one enters a plateau of confidence in one’s abilities. One can design tools that, while not perfect, are good enough. One starts to design projects based not merely on a conception of the game in the abstract, but on an understanding of how things actually work and on a good conception of how one’s tools shape the material available. For instance, in Reassembly I slowly started to learn how to arrange thrusters in such a way that a ship could be both fast and easily maneuverable. After a while I came to have a standard set up that I would simply apply to any new design, a proven engine that would make things go mostly how I desired them to.
Complacency, however, is just a sign that one does not properly understand what is going o, and eventually that complacency will have to confront change. In Reassembly this change comes in the form of ships made by other players and uploaded to the cloud. These “agent” fleets are placed on the edge of the map, but slowly approach the player’s territory over time. The first player fleets one encounters tend to have been made by new players like you who uploaded their fleets either by accident, or just to see what would happen (one uploads a fleet by flying one’s ship into a wormhole). These fleets can generally be dismantled as easily as one is no doubt dismantling all the AI ships one meets. This sparks a hope, that maybe you are actually good at this game, and that you fleet has just hit a winning formula. This was a notion that I was violently disabused of. I had unlocked everything with the first faction, so I started up another game with a different faction, enjoying the refreshingly different selection of parts. After a while I had maxed out my ship’s “p” rating, and was sailing the stars in a battleship. Pottering out to the edge of the map, just to see what was there, I came across a blip on my map indicating an agent fleet. Feeling adventurous, and having just crushed of number of (in my estimation) shoddily designed player ships, I rode out to meet the enemy at full speed. There was hardly time to understand what happened, as in front of me a giant black rectangle, seemingly taking up half of the screen, screamed out of the void towards me. I opened fire, throwing a few gobs of virtual energy towards it, missiles streaking out from all directions around my gaudy yellow and blue neon ship. Its weapons on the other hand, were uniform and numerous. My ship was enveloped and disappeared beneath the tidal-wave like attack, like half a biscuit soaked too long in tea. This chain of events repeated itself a number of times, my ship re-constituted each time at the nearest friendly construction bay—of which, as that black, terrible fleet bore down upon my colorful little flotilla, there were fewer each time.
Of course, in Re-Assembly a defeat is not a defeat, hardly even a setback. There is no real lose state, the game simply churns on. One does not, however, need a game to tell you when you are beaten, and defeat has a way of making itself known. The question is, how does one respond to defeat? Reassembly is quite an easy game to bounce off, because one does not need to be especially good at it in order to “progress” in the sense that the game recognizes progression. The currency to unlock new parts is relatively easy to come by, and one unlocks new factions to play with by destroying ships of that faction worth a certain amount of “r”. Thus with one or two workable designs it is a somewhat trivial matter to bound around the map unlocking everything. Once it is all unlocked, what keeps the player hooked, if they are going to be hooked, is the prospect of getting better at the game.
Reassembly, then, presents us with a microcosm of the problems that we all face in developing any skill. If one is to develop any skill, one must first face one’s own mediocrity. Statistically speaking, at any endeavor one sets out to master, one is likely to be inherently average. There are, of course, those few of us who naturally excel in precisely their field of interest, but one is most likely not among their number. Mediocrity, and even outright incompetence, are the normal state of affairs for human beings. We are taught to expect excellence in ourselves and others, morally, physically and in pursuit of a goal. That expectation of excellence can drive self improvement in some, but in many others, smothers it. Facing the fact that one is deeply average is not a pleasant experience, and quite be quite emotionally difficult. This is especially the case when we are being asked to accept such harsh truths by an otherwise facile activity. The task is also not simply one of a correct apportioning of blame—to oneself instead of the game—but further demands that one not simply accept that the ways in which one are average are immutable and beyond one’s own control.
Learning this in real life, and coming to accept the ways one can change oneself, and take control of one’s surroundings is an incredibly difficult task. Furthermore, the process end only with the rest of life, living is never easy and so long as we breathe there is always something new to learn. Engineering games present us, as players, with a means of moving through this process with a minimum of difficulty and—if we choose there to be—with a finite end point. This depends on two facts about engineering games. Number one is that failure in an engineering game is often hilarious and silly. One only has to observe people playing Kerbal Space program to understand why people stick with it, even failure is a kind of reward. The second fact is that in an engineering game all the important facts about whether we fail or succeed are either under our control, or easy to detect, while trying again is often as simple as pressing a reset button. Thus the process of learning that takes one from putting together a failure, to making something a success is, generally speaking, shortened to a manageable cycle.
If one sticks with Reassembly, past the plateau of complacency, one will immediately start finding out the depth of the game. One will start trying to find out what exactly it is that one is missing. A painstaking series of experiments will follow, and your personal analogue of that terrible black fleet will descend on one’s forces again and again. Sometimes one will do better, sometimes one will do worse. By monitoring the changes carefully, trying out new things, and looking into features that one had never really thought about before, eventually one will come some understanding. In this, Reassembly differs little from something like DoTA 2, or Leauge of Legends. There are two ways however in which Reassembly does differ. First, the systems that undergird Reassembly are purposefully simple and easy to grasp. While there are advanced techniques, all of the relevant data is presented on its face and without the need for any great insider knowledge to unpick the system. Second, one’s final understanding is represented in a visible, virtual machine—a talisman of one’s success, and a living history of one’s virtual struggle. In Reassembly this process is terrifically satisfying, partly because building and re-building ships takes so little time. I found myself trying to understand exactly the process by which my ships were taken apart by my opponents. Like a biology student dissecting a frog, I carefully observed layers of shielding and hull being stripped away by enemy fire. I studied the ways in which the movement of a ship could be affected by the placement of different configurations of thrusters.
My results were promising. The first thing to do was to re-jig the layout of the engines again, to give the ship a better chance to avoid incoming fire, as well as removing all the systems that were not contributing to the destructive effect of the craft. I started putting more space between my generators (which have a tendency to catastrophically explode if looked at askance) and my vital command module—the only part of the ship that cannot be rebuilt by the ship’s repair systems. Further, I started to add concentric layers of hull and shielding, putting some empty space between blocks so that explosions would not penetrate so far into the ship’s vital systems. Weapon systems moved from the very outer layers of the hull towards the centre, allowing them to fire for longer before being overwhelmed and destroyed. Hours of careful work, planning and observation later, I had created something that looked unbelievably weird, but moved like a panther and hit like an eighteen wheeler truck.
Still a proud neon yellow and blue, my fleet moved back into attack position, new and re-formed. Gleaming in their garish livery, with my ship at their head, my forces gathered; giant attack cruisers with punishing, long range, cannons, supported by a thousand swarming fighters, which were mostly gun and engine. This time it was us that bared down like a torrent upon the enemy, smashing them to useless hulks with repeated hammerblows from our updated weapons.
The best thing about Reassembly, is that after this story is done, and that terrible foe is defeated, one moves on and finds the next challenger. After, of course, uploading one’s now impressive fleet to the cloud in the hope it becomes someone else’s nemesis. Thus, the story starts all over again, with a different challenge, and potentially on and on forever—so long as there are new, player designed, fleets to fight.
The story of playing Reassembly, that of coming to understand the world and have control over it by chance and experiment, should perhaps make us reflect on what we expect from people. The pursuit of happiness, or whatever it is we are up to in life, is certainly a great deal more complicated than an endless box of laser spewing Lego. We cannot, and should not expect people to get it right first time, or even second time. To be honest the fact that any of us ever “get it right” seems to me a strange phenomenon. We can, however, experiment. In paying close attention to what works, and what does not, maybe we can even improve. Perhaps then we can mirror the progress of the player through Reassembly, and equip ourselves with the tools to face a nigh endless set of new challenges. Or maybe we can just have fun observing the fireworks of failure.