The nature of computing in Shadowrun is, at best, inobvious to anyone familiar with modern computers, and at worst nonsensical. Why is a computer’s power measured in megapulses (Mp), with memory and computing power apparently being identical? What is a megapulse anyway? Why are so many of them involved in Shadowland posts? And why is it so hard to make a secure computer system? Here’s my take on the matter.
The basic technology of Shadowrun computing is the quantum pulse element, usually just called a “pulse”. Its basic nature is that it’s a cluster of quantum dots and wires (or maybe some funky proteins embedded in a crystalline matrix, if you want computing to be completely optical in nature) that can be reconfigured into a different set of logic elements on the fly. If you want it to turn into a group of flip-flops, it can become memory. If you want it to be an Arithmetic and Logic Unit instead, it can switch to that in the middle of your program.
Quantum pulse elements are so much faster and more convenient than other forms of computing technology that the old silicon stuff has become quite obsolete. With the universality of quantum pulse elements, you have access to processing that’s as parallel as you want it. All programs are compatible with other computers, as long as the computer is big enough to run it. Programs from older computers can easily be run on an emulator.
Naturally, programming and debugging with such elements is incredibly difficult without computer assistance. People seldom write compilers from scratch any more; the equivalent of assembly language for quantum pulse elements makes programming for massively parallel RISC machines look simple.
When someone refers to a megapulse as a measure of size, that’s the number of bits that can be stored by 1,048,576 (220) quantum pulse elements configured for uncompressed memory storage only. (A megapulse of computing logic can usually store more than a megapulse of raw data, since it can be configured as mixed memory and compression logic.)
The computing environment of Shadowrun is a descendent of the applet-filled Java world currently growing on the Internet right now. Everyone has their favorite word processor or other editing program; some people post by speaking to the computer, some by sending in the bits over a direct neural interface, some use keyboards. When you ship your message up, it could be as small as the Unicode or even ASCII representation of your post, or it could be a multimedia extravaganza with an animation of your Matrix icon speaking your post out loud in your voice (or a synthesized one) and all the software needed to run such a thing independently (instead of making someone download a viewer). Naturally, when it gets converted to text for a paper sourcebook, you wind up with the usual posts we’re familiar with. This is, by modern standards, horribly wasteful, but memory and storage are cheap, and the same phenomenon that makes Microsoft Word take up 30MB on your hard drive today hasn’t gone away.
The difference between data and executable in Shadowrun is almost nonexistent. Sensibly paranoid deckers keep a suite of trusted programs for reading the myriad different data file formats, rather than risking the possibility that the file handed to them could be hostile. Most cyberdecks have a diagnostic mode that allows the decker to freeze the deck into read-only mode and run comparison utilities on their personal computer, making sure that a virus hasn’t snuck into the software. (The notion that a virus can sneak into firmware— seen in the “Escher loop” in Lone Star and the “Worms” IC in VR 2.0— lacks believability. If you could do that in software, you wouldn’t need optical chip encoders.)
Mainframes hooked up to the Matrix tend to be pumping around large amounts of executable content as various utilities running on the mainframe talk to their creators’ sites to pick up the latest updates and access data that’s not worth keeping at the local site. Decking, in my view, is the art of corrupting the data streams going into a mainframe in order to gain access to the system.
If that rationalization isn’t strong enough for you, here’s an extension of the notion:
Bellcore did a study back in the late 1980’s that showed that with a sufficiently high-speed network, it could be more efficient to have data in constant circulation, rather than being provided on request by a server: if the data goes by faster than the request-response cycle, and you have bandwidth to spare, you might as well just have the data being pumped by. Computers on the network could then simply grab whatever chunk of the operating system or the Encyclopedia Britannica they need at the moment.
The Matrix could be a phenomenon of this nature: the routers handling Matrix traffic might be keeping data “pumped” throughout the network, and the biggest cost of taking your mainframe off the Matrix is that you’d have to buy gigapulses and gigapulses of memory to store all the software your mainframe might need, rather than just picking it up off the Matrix. Entire data havens could hide inside that incredible flow of traffic, being quietly rebroadcast along with all the other information.
Requiring an encephalon to be slotting a decking skillsoft in order to get a bonus during decking doesn’t make a great deal of sense to me. To keep the same game balance while improving believability, I suggest that the skillsoft be replaced with a program of the same rating and space requirements as a specialized decking skillsoft, with the purpose of properly utilizing the encephalon’s capabilities during decking. In particular, this program would interface to the deck and make it possible to provide extra information at the level of skills and memory: instead of having to read statistics about whatever the decker was perceiving, they would simply know them.
“The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life.”
—the Player’s Litany
Decking, as represented in Virtual Realities 2.0, doesn’t always make a great deal of sense when you contemplate how computers actually work. This problem is endemic to most cyberpunk, in fact: William Gibson’s Neuromancer, which is perhaps the classic decker book, was written by a man who wasn’t even computer-literate at the time.
I take my inspiration from an out-of-print work of cyberpunkish fiction titled The Long Run, by Daniel Keys Moran. His work contains the only believable depiction of decking I’ve seen in fiction. (Daniel Keys Moran’s day job is, of course, being a computer programmer.)
There are some different terms in Daniel Keys Moran’s universe of the Continuing Time. Garden-variety deckers are called webdancers, the Matrix is called the Crystal Wind, and the top-notch folk like FastJack are called Players.
Despite numerous depictions of deckers responding to computers in milliseconds, this is not actually the case. There is simply no way that a human being, whose thoughts take place at the speed of ions diffusing across semipermeable membranes in a complex network of of wet tissue, can keep up with the speed of the computer world. A decker needs a program to intercede for him between the computer world and that of human reaction times. This is the job of the Master Persona Control Program. The MPCP is a program the represents the decker in the Matrix; it carries as much of the decker’s decision-making capability as they can get down into code. On its own, an MPCP following verbal orders should be capable of a great deal of work without even a decker directly attached. With the decker present, the MPCP becomes an extension of the decker’s will, a customized interface to a world where the speed of light is an important limit on reaction time.
The MPCP, under ordinary circumstances, never gets used as anything other than a way of integrating the other persona programs (which are basically libraries).
Decking is supposed to be addictive. However, there is nothing in the source material to suggest why anyone would stay in the Matrix when they weren’t breaking into systems— and there’s no way anyone would spend all their time doing that, as they’d be bound to screw up eventually.
So why do deckers spend all their time out there on the Matrix? Part of their time will be spent in working on code for various projects, of course. Another part will be satisfying their curiosity. The World Wide Web of 1997 is already addictive: it is very easy to waste hours chasing down interesting information with search engines and sites filled with links, and taking part in USENET newsgroups.
Deckers should be information addicts to some degree or other. They may be in the habit of wandering around with an unobstrusive fiber optic cable snaking into their datajack, feeding information into their encephalon and display link, or be nearly impossible to tear away from the data feed. They should feel naked if they can’t glance up at the sky, wonder about the weather, and download real-time pictures from a satellite and check them against the forecasts from the meteorology services, or are out of range of being paged when one of their automated filters finds something of great importance. (For instance, a decker once surprised by an earthquake might set up a filter to monitor global seismology stations and page him immediately if the magnitude and distance are right for him to notice it; such a filter might get there in advance of the first crustal waves.)
The whole notion that there needs to be a correspondence between iconography in the Matrix and the purpose and power of the programs the icons represent is nonsense. Computers don’t care about icons. Human beings may demand that software conform to certain standards in order for them to have a better chance of understanding it— but why is a decker going to make life easy for them? A powerful attack program may manifest as a huge flaming sword to comply with iconography, but it could just as easily be a petite derringer, a poisoned dart shuriken, or completely invisible. A deck’s Sensor module would pass the important information on to the decker, but a sarariman doing his job would probably have no idea what was going on.
It may help the computer-literate to consider what the parts of a cyberdeck are doing at a programmatic level.
The Bod program is a hybrid descendent of Purify and virus-checking software. Its job is to perform huge amounts of error checking, enforcing memory protection, perfoming constant checksumming on code while it runs, and more: all the work of preventing a decker’s running programs from being corrupted.
A deck’s Evasion code is concerned with making it difficult to find the decker’s programs in order to do anything to them. Its techniques include spawning extra processes with similar characteristics to the important ones the decker is running, shifting executing code to different spots in the machine’s address space, and leaving false trails in all the locations that monitor system resources.
The Masking code attempts to cloak the decker from discovery. In addition to shifting the appearance of the user’s icon to an appearance appropriate to the local host, it also camouflages the characteristics of the decker’s utilities to make them appear to be legitimate programs running on the system. This includes activities such as talking to license servers, accessing the appropriate support files for a given utility, and inserting the user’s code into a running utility program to steal its resources.
Sensors make sense out of the chaos of the computer world. Any good decker knows that icons are nothing more than an illusion wrapped around the true reality that happens in the computer; frequently, these illusions are dangerously deceptive. The deck’s Sensors provide annotations to other icons in the area, and supply vital statistics about the system as the decker operates it. A very large part of the Sensors suite is the heuristics for knowing which information to feed the decker at the right time. This is the major place where an encephalon helps out with decking, as the sensors can simply feed the information directly to the decker’s short-term memory without requiring additional time for conscious processing.
FASA’s treatment of IC is occasionally lacking in an understanding of computer technology. Here’s what I’ve done to make sense of it:
Killer IC is a straightforward, half-tamed descendent of Core Wars, designed for the modern computing environment. It attempts to scramble code, free allocated memory, kill processes and threads, deny permissions, and similarly cause a decker’s programs to become unstable and crash. A Data Bomb is just specially triggered Killer IC, and Tar Baby IC is just Killer IC targeted against programs that attempt to do a particular thing.
Crippler IC is designed to attack the sorts of code that are used in the appropriate deck attributes. Acid IC targets Bod by setting its own hostile callbacks on requests for memory protection and attempting to separate the Bod code from the programs it protects. Binder attacks Evasion by invading the decker’s address space and leaving haphazard data trails that make it obvious where the decker is. Marker breaks Masking by blocking access to license servers and protecting other utilities running on the system from invasion. Jammer goes after Sensors by intercepting requests for system information and returning hostile code or nonsensical data.
The nature of quantum pulse elements is such that it is possible to burn them out through executing an appropriate series of instructions. (One of the major parts of compiler design is searching for possible errors that could lead to this sort of problem!) This makes it possible for IC to actually damage a decker’s burned-in utilities. Blaster does exactly this, and the different Rippers are just like the Cripplers above, but sending code on down to the deck to attack the firmware of the routines they’re attacking.
Scramble is a complete misnomer for that kind of IC, and Decrypt is definitely not the right name for the program that defeats it. Scramble doesn’t work through encryption; it works through destruction. Decrypt should be named Unscramble, and the description of everything makes perfect sense as long as you ignore any references to actual encryption.
Sparky simply doesn’t make sense. I sincerely doubt there are any deckers who allow anything other than a fiber-optic cable into their head, and it’s far too easy to (a) build a cyberdeck whose power supply can’t be affected by the code running on it and (b) run your actual visualization code on a protected processor that won’t transmit such a thing to the user. I just don’t believe Sparky, as a concept, would survive one round of the SOTA. Substitute Blaster for Sparky where you find it.
Tar Pit is explained quite well in the source material.
Worms cannot truly invade the MPCP; if it were possible to put code into an optical chip through running programs that interact with it, you wouldn’t need optical chip burners to create cyberdecks. What Worms do is target particular security checks in your MPCP and burn them out, and then hide in the “shadow” that this leaves.