By gamer_152 0 Comments
While most video games cut back on realism to produce more riveting play, there is a cottage industry of true-to-life interactive software out there. There are flight simulators that map every button in a plane's cockpit to your keyboard, and there are golf games where academic physics govern how the ball flies. But even these games butt up against an inherent barrier between how our world works and what entertainment software can model. Nine times out of ten, video games cannot be mirrors of real-world activities because the machines we use to play games don't contain the physical equipment that we'd need to perform those activities. No matter how realistic the physics of a golf game, it can't feel precisely like playing golf because the feeling of playing golf is dependant on material aspects of the sport such as the texture of the club in your hands or the sensation of hitting the ball. Computers can't convey those feelings because they do not have a real ball or club for us to use and have no way of precisely simulating many of the physical characteristics of these objects either. It's the same for sword-fighting or scaling cave walls or cooking dinner; a keyboard does not handle like a pickaxe, and a screen cannot give you the sensory stimulation of steam rising into your face. Some motion control games do feature the equipment or close approximations of it, and with VR, we can often visually immerse ourselves in worlds, but fully-realised simulations of activities are beyond almost every developer. As ever, realism is not a barometer of quality, but if we want to remain aware of the current nature and limitations of video games, it is crucial to understand the lack of a direct simulatory aspect to the medium.
Having said that, there is one category of activities that are exempt from this rule. Because audiences can play games on personal computers, developers have all the equipment in front of them to believably mimic any other task that requires a PC. Given the versatility of digital technology, that's a lot of different tasks. Creators could provide the illusion of navigating BBS servers as in the case of Digital: A Love Story, playing a game within a game as in the case of Cibele, or programming as in the case of SHENZHEN I/O. A game like Tiger Woods PGA Tour can only approximate the feeling of swinging a golf club, projecting a sense of weight and aerodynamics through the controller. However, a coding simulator like SHENZHEN I/O can conjure up the feeling of inputting commands into a keyboard 1:1 because you are typing on a keyboard in the offline space. And when you run your program in SHENZHEN, you and the game are not pretending that it is winding your source code through an interpreter; it's doing it for real.
The complication is, while everyone might understand what cooking food entails but never be able to perform that exact task in a video game, everyone has the opportunity to write a computer program in a video game, but might not understand what that task entails. Programming is a discipline mental enough that you can't pick it up by idly observing someone doing it, and when realistically depicted in narrative or visual media, it doesn't get the blood pumping. So, most television and film doesn't go there. But SHENZHEN does, and in it, you can find a layperson's window into how the dominant machines of our age think. That's not because the class of programming in SHENZHEN is the one that most programmers today use; it's because by getting to grips with even an atypical programming language, we come to recognise many of the underlying principles and skills involved in the occupation.
Every level in SHENZHEN I/O involves putting together a circuit to produce some desired output. That output could be dispensing the correct change on a vending machine, moving the drill arm on a piece of mining equipment, or something else entirely. We get there by arranging text boxes the game labels "microcontrollers" and writing code onto those canvases. In engineering, microcontrollers are tiny computers that we can program and place on circuit boards to control the circuit. Building a microwave or TV doesn't have to be all copper buses and logic gates; we can preload a device with the instructions for how these machines should behave and integrate them into the appliance. In SHENZHEN I/O, microcontrollers not only host code, but true-to-life, they can also store a number or two, and house pins which we can use to connect them to other microcontrollers.
To the untrained eye, the code we print onto those chips looks like a tangle of random letters and numbers, but by learning how programs are constructed, we can begin to translate this mysterious cypher faster than you might think. Computer programs are scripts for the performance that a computer will put on; they're lists of instructions that it's going to execute, with one line of code roughly equating to one instruction. An instruction might be "Display this text prompt to the screen", "Create a new number in memory", or any number of other operations. By default, the system performs the instructions in the order we list them, but programs also contain questions for the computer which decide what code it will and will not execute. For example, we could have a line that checks whether the "Caps Lock" key on the keyboard has been pressed, and based on the result, we would then have the computer either display upper case or lower case characters as the user types. Or, if we're coding a video game, then when the user presses the fire button, we might have the code check whether their ammo count is above 0 before we fire their gun.
But when I say computers need instructions, I mean they need them with no detail spared. If you imagine we're penning a recipe to make spaghetti, we might begin by writing:
>Fill a saucepan with water.
>Bring it to the boil.
If you were communicating the same steps to a computer, you'd have to structure it like this:
>Open the cupboard door.
>Get the saucepan out.
>Close the cupboard door.
>Turn on the tap.
>Place the pot under the spout.
>Wait for the pot to fill.
>Turn off the tap.
And on it goes. Even this is a simplification because it assumes that the computer knows the subtle series of movements that it needs to go through to walk or to grasp an object. Really, it would require the precise tensing and releasing of each muscle spelt out for it with all the necessary measurements. Of course, many jobs computers do are more abstract and mathematical than the one above. E.g. Lighting a virtual room or managing files, and even the spacial jobs are broken down into abstract steps, so the instructions most programs are chewing through look less like a human to-do list and more like this:
>Move the number from Port 0 into memory.
>Subtract 1 from it.
>Check if the resulting number is larger than 10.
But if we wrote computer programs in this way, they'd be very long-winded and small changes in punctuation or syntax would prevent us from having a standardised language which we use to talk to the computer. All computer languages are standardised to avoid miscommunication, and they're all written in a kind of shorthand. So, in SHENZHEN, instead of saying "Move the number from Port 0 into memory", we type "mov p0 acc" ("acc" stands for "accumulator", a small area of memory for storing figures we're working on). Instead of saying "subtract 1 from the number in the accumulator", we type "sub 1". And instead of saying "Check if the number in the accumulator is larger than 10", we type "tgt acc 10". If you can understand that, then you can code in an assembly language.
Most programmers these days don't have to write out every one of those low-level instructions by hand because other engineers have already written the code to do the common jobs on the popular technological platforms. They've also created sleek interfaces with which we can reference that code. This means programmers can use single instructions to dictate that computers do big, complex jobs like drawing a texture at certain coordinates or writing a string of text to a file. The computer takes the "high-level" code that tells it to carry out those tasks and breaks it down into the "assembly language" which is the tongue of those more basic functions I described above. However, historically, engineers have not had the luxury of writing in high-level languages, and even today, many professionals and hobbyists micromanaging the electronics must often wade through the muck of assembly.
As SHENZHEN I/O has us roleplaying an embedded systems engineer, we control our circuits in the game using assembly. There is no one assembly language because assembly is a series of instructions for a processor to dutifully execute on and processors vary in design. Therefore, the languages that turn the cogs of those processors also differ. The form of assembly that SHENZHEN uses is one that developers Zachtronics made up for the game, but the language's instructions and the wording and syntax of those instructions are identical to that of many real-world assembly languages. A systems engineer somewhere on the other side of the planet is, right now, typing commands like "add 1" and "jmp END", just as we do in this game.
SHENZHEN having us speak in assembly shapes the play experience in three transformative ways:
1. While high-level languages are rich with instructions, assembly languages are far more humble in that department. In SHENZHEN, a brief instruction set means that we can learn the entirety of the game's language in a relatively short time frame.
2. The SHENZHEN language is laconic, and the jobs we perform with it are modest in scope. Therefore, the programs we write are nowhere near as long as the ones an actual programming professional would design to complete the average project. This is useful because the game needs us to be able to work through puzzles at a steady speed so that it can vary play and ply us with regular rewards.
3. Without a high-level language, we can't absent-mindedly tell the computer our intention in our programming and then have it convert it to the necessary set of instructions for the processor; we need to figure out the right processor commands directly. As a consequence, we get some idea of how a computer performs the most basic operations. Part of the magic of this simulator is that it demystifies how a jumble of numbers and signals zipping around a silicon chip can run a digital scale or a laser tag vest.
A significant difference between SHENZHEN I/O and most other video games is that they don't have the same relationship between the inputting of commands and the execution of them. In real-time video games and even most turn-based strategies, you make an input, and the game responds to it immediately. If you tell the game to "Cut that rope", "Build a wall here", or "Move this tank to these coordinates", it will honour those commands, at most, seconds afterwards. And typically, interacting with a game involves a back-and-forth in which the game makes a move, you respond with your own move, it returns that with another move, you reply, and so on. Maybe the system tells us that the wall we built isn't resilient enough for its purpose and so we choose to reinforce it, and the game tells us that it's now hardy enough. Maybe moving that tank forward causes the enemy to flee so we give chase and the UI tells us we've cornered the opposing army.
In SHENZHEN, our individual inputs, that is, the lines of code, aren't immediately executed. Instead, we add our inputs to a queue of actions that are all performed when we press the "Play" button. We can't review how the game responds to each of our efforts, and then work out in real-time how we wish to proceed; we must submit all of our inputs to the system in one big glut with no ability to interrupt or course-correct if the scenario takes a turn for the worst. We may view our interaction with SHENZHEN as a back-and-forth dialogue, but only in that we submit our inputs in bulk, we learn what outputs they evoked, and we can then decide to change what inputs we submit next time around. The play is structured in this format because the game is emulating automation.
The goal of electronics and programming are to build software or hardware systems that can run on their own, in real-time, with little to no human intervention. Therefore, constructing them consists of a long phase of teaching the computer how to act and then a long phase in which we test whether it behaves as desired. Because we don't get immediate feedback on how our commands are going to change the system, we have to work out beforehand what will happen after each line of code runs, letting us know what state the system will be in when the following line of code is executed. For example, if we want the next line of code to operate on a number, we have to know that the previous code actually loaded the value into memory, or if we send a bit from one microcontroller to another, we have to know that that second microcontroller will process it. This means that to program, you have to run the code in your head as if you were the computer. Predictive ability is everything, but it's easier to talk about making the right predictions than it is to make them.
In real-life programming, you usually don't expect your code to run properly on the first pass, and it's often the same story in this simulator. There are so many elements in your program and so many different interactions between those elements that you're liable to have overlooked some clash of data or some loop never completing somewhere. If you have, your whole chain of cause-and-effect will come crashing down. Just as "rewriting is rewriting", programs usually come together in the reviewing and revision of code as opposed to the initial draft. Although, I have made SHENZHEN circuits so fundamentally broken that the best way forward was to abandon the whole board and start a new one from scratch. Work long enough with one program or circuit, and you might begin making weak assumptions about how to solve problems that you're not aware you're making.
There are countless wrong solutions you can devise in SHENZHEN because there are so many creative possibilities using its brushes. Programming languages are not just about hacking away at problems with our tools but are also about building new tools. The staggering abstractness of the commands in SHENZHEN's language is what makes us able to fasten those elements together in so many logical configurations. In another game, you might need a grapple to reach high ledges or a shotgun to vapourise zombies, and in SHENZHEN there are equivalents. Maybe you need a microcontroller that will act as a clock or one that takes inputs into the circuit and passes them into RAM, but instead of the clock or the RAM module being items you pick up or craft, you're designing and implementing these items yourself.
A fantastic demonstration of the malleability of our clay is that there are missions in the game which require us to create entirely original inventions without any explicit objective. There's even one challenge which has us designing a new puzzle and uploading it to the Steam Workshop. Few games invite and teach players to mod them this directly, and when SHENZHEN does so, it ensures that players are filling out its community space with plenty of levels to increase the game's longevity dramatically. Fans have even cobbled together cover songs and homebrew PC games in the simulator. It's intuitive to think that STEM tasks require logical reasoning while the arts are where we apply creativity, but science, engineering, and maths also have us engage our creative brain. In the case of programming, there's no prescripted solution to any problem because each problem is different, and so they all require us to imagine new machines and new software, something which takes keen creativity.
We should note, SHENZHEN I/O does take some liberties with its subject matter. While every instruction we use in the game is one we'd expect to find in an actual assembly language, SHENZHEN lies by omission. The game is set in the year 2026, but even assembly languages from decades before today contain utilities that this toolbox doesn't. For example, while the SHENZHEN code supports only 15 instructions (instructions being, for example, "add", "sub", "mul", etc.), x86, a popular assembly language first introduced in 1986, launched with 81. And fewer instructions means less functionality. I wouldn't blame you if you thought that there's no command to divide numbers in SHENZHEN because real assembly doesn't have that feature, and that is true of, say, the original implementation of the ARM language (1985), but x86 and MIPS (another popular assembly language set up in 1986) both have a "divide" instruction. Most of the assembly language written in the past few decades is capable of feats of logic and arithmetic that Zachtronic's puzzler isn't.
And if you think these software tools are lacking compared to their real-world counterparts, wait until you see the hardware. Up to this point, I've neglected to mention how significant a role the physical parts play in the experience, but SHENZHEN is a stern taskmaster. It doesn't just demand that we write programs to solve problems, but also that our programming conforms to the rigid constraints of the hardware. After cracking the first couple of puzzles, we find that the amount of code we need to write far exceeds the space in any one text box and that we can't store all the numbers we need on a single microcontroller either. So, we start having to spread our code out across many different chips.
However, none of our chips can see the values that the others are working with, or what jobs the others are carrying out. To solve this, we wire microcontrollers together so that they can pass information back and forth, but our parts only have a limited number of pins through which to connect to other parts, and we can't have two sets of wire occupying the same squares. Additionally, we can't rotate our pieces to make more efficient use of the space because the game, arbitrarily, withholds that option. So, sometimes, we need to implement yet more microcontrollers just to have enough pins or space to perform the job we want. The microcontrollers are also cleverly designed so that even if we sandwich two of them next to each other, most of the pins don't line up to allow a straight horizontal connection from one another. This means we must space the components out to make diagonal connections between them, which consumes a larger area of the board. By having us plop down multiple microcontrollers and wire them together, SHENZHEN expands from being a game just about programming to introduce electrical engineering to the simulation. This second topic is not only interesting in its own right but provides essential context for the functions of the assembly code. We don't just train the microcontrollers to spit out values into the void, we see those signals hopping around the circuit, and when we have to consider how to move data between parts, we learn how data transfer, input/output systems, and signalling work.
With these circuits, SHENZHEN is also replicating a familiar problem in I.T: not having the resources you need to do your job. We could devise elegant and efficient programming solutions to every conundrum in the game, but we frequently can't implement any of them with these bargain bin parts. So, we hack around the limitations of the components and make our machines more contrived than we'd want them to be. Those contrivances create other cracks in the edifice, but we whip up new complications to seal those up too. Long-suffering programmers have plenty of stories about working around their tools rather than with them, subservient to the ridiculous demands of outmoded and glitchy tech. Engineers are often not given more dependable appliances or systems because it can be faster and cheaper for a company to shoulder an old clunker of a database application or a software interface coming apart at the spine than it is for it to go back to the drawing board and make a whole new one. Both SHENZHEN players and real programmers also have to fight the documentation now and then.
Programming technologies frequently don't come with tutorials, and neither does this game, so we turn to the manuals for guidance. Too often, documentation elides vital facts and tells us what the parts do, but doesn't tell us how to screw them into each other or what issues we might encounter when we do. Software manuals, rather than being walkthroughs, are dictionaries, and sometimes aren't as detailed in their definitions as SHENZHEN's is. Some knowing details in the SHENZHEN PDF include a note from a previous designer filling in a blank the original authors didn't cover and a whole page in Chinese that was never translated. The faults we encounter in SHENZHEN's manual are a literal recreation of their real-world counterparts, while the problems we face with the hardware are more metaphorical. Just as the SHENZHEN language exaggerates how impoverished assembly instruction sets are, many microcontrollers that geeks were programming even decades ago weren't as threadbare as what lands in our parts bin in 2026.
The most capable microcontroller in SHENZHEN I/O is the MC6000 which boasts six pins, can store two three-digit values, and contains enough memory for fourteen lines of code. Compare that to the widely-used Intel 8051 series of microcontrollers which first hit the market in 1980. Each chip in that line of parts has forty pins, and thirty-two "registers" that could store any number up to 255. They also have dedicated pockets of memory for mathematical working, and a timer, as well as, at least, 128 bytes of RAM which would translate to about forty-two lines of code. And yes, it has "divide" and seventeen instructions in its set. You could try and discount this by saying that in SHENZHEN's smoggy, tacky future, companies use the lowest-end hardware possible and that's why these limitations exist, but if anything, these conditions would make a company buy more powerful microcontrollers. In real systems design, you don't want to stuff fistfuls of components into a circuit to carry out simple jobs because you'd be using up copious quantities of parts and labour. It's more expensive to use many basic microcontrollers than it is to use one or two average ones. However, we can explain this aspect of the game ludologically.
As realistic as SHENZHEN is on so many levels, it reduces the capability of its virtual hardware to remain accessible but challenging. The cramped memory on each microcontroller means we must split up our code across many isolated screens, and this forces us into positive organisational habits. That structuring serves its own simulatory role. In modern programming, we often need to do the same job more than once in the same piece of software. Instead of writing out the code for that job over and over, we often divide our code into named pages and modules, and then have the computer run those modules when we need the relevant operations completed. E.g. Maybe we have a "Save file" page of code or one for refreshing the screen. When we need the program to save a file, we don't tell it all the steps it needs to go through to do so; we just say "Reference the "Save file" method".
This not only allows for brevity but also keeps programs manageable and code easy to reference. Splitting up code by microcontroller in SHENZHEN has the same effect. You can have a microcontroller for moving a mechanical arm, one for reading ROM, one for processing input, etc. And through that atomisation, you get organisation. Another consequence of that rationing of registers, lines, and pins is that you have to optimise your code. The difference between an average programmer and a great one is that a great programmer will do with one line what an average will do with three. They will be able to achieve their goal with a few bytes of memory where another needs several. The iron vice that SHENZHEN places around our systems means we're not sloppy or wasteful with the semiconductors it gives us; our code says no more than it needs to and we're parsimonious when we store values.
The game further encourages us to optimise our code by ending levels with comparisons between other players and us, as well as showing us where we fall on our "friends" leaderboards. On these charts, we compete for the cheapest circuit, the program with the fewest lines, and the least power consumption from the board. You can't conquer every category with the same design; a circuit that is well under budget may also be a power hog, and one that's eco-friendly might also be exorbitantly expensive. Each type of circuit constitutes a different approach to the puzzles, and by rewarding them all, Zachtronics validates plenty of different playstyles and can create more tasks for the player without increasing the amount of content.
I stress that the game simplifies the electrical engineering aspect far more than it does the programming. Building the boards for today's doorbells and vacuum cleaners requires more than glueing down a few microcontrollers. Designers need to roll the minutiae around in their head, specifying where transistors, resistors, batteries, and similar small scale components will sit on the plastic. They also need to ensure that they have the appropriate level of voltage flowing in and out of each part, and much more. If you want to see the distance between playing SHENZHEN and being a real systems engineer, I recommend watching Kuit the Geek's series SHENZHEN in Real-Life in which an embedded systems engineer constructs the fake security camera from the game's first puzzle. It's a highly involved process.
But the intent to represent hardware design is there, and a thoughtful accessory to SHENZHEN is the addition of a Chinese solitaire minigame. At first, I thought it was just hastily bundled in to offer some relief from the more cerebral engineering and provide an opportunity to indulge in the programmer's favourite part of the job: procrastination. It does serve both of those roles, but in other senses, the solitaire is a miniaturised version of the core play. It's not as logically-driven as the programming, but you do find that it requires thought and patience to succeed. At some point, you'll probably also set up your stacks in such a way that you block access to the cards you need, just as when orienting your circuitry, you can cut off access to some pins.
I'm still in awe of how naturally SHENZHEN educates the player on the topics of pins, commands, and parts. Typically, when games need to get their audience up to speed with the basic play, they break their suspension of disbelief on two fronts. Firstly, the form in which designers deliver the tutorials often doesn't match the setting. E.g. The historical action game Ryse: Son of Rome begins with us playing a Roman Centurion slashing a bloody avenue through hordes of invaders. The combat is disruptively suspended by prompts that explain what buttons to press to perform which actions. This instruction is not couched within the fiction of the world: there is no character telling us how to fight, and the scenario depicted in the game is not one of the protagonist learning how to perform in war. Canonically, he is already an elite soldier, so a gameplay segment in which we're muddling through how to swing and block with him feels out of place. Secondly, the content of many tutorials doesn't make sense within the context of the world. A Centurion doesn't have a Y button or a combo counter, but those are the topics the tutorial and interface chooses to speak about when we're trying to roleplay Marius; it breaks the spell.
SHENZHEN's practice of emulating a computing task on a computer helps again here because our mode of input is not an analogue for the actions in the game; the actions are 1:1. When the game says "Type "add 3"", it doesn't feel incongruous with its premise because that's a command a programmer really would type, while an ancient Roman soldier has never had to press R1. Likewise, because both a systems engineer and we have to read a manual to get up to speed with the system, the game doesn't have to crowbar in some godly voice to read off lists of mechanics and risk taking us out of the moment.
Today, we've explored how computer games can excel at simulating computing tasks without breaking the audience's suspension of disbelief. We've looked at how computer programs are lists of instructions written in shorthand and how skilled engineers do a lot with a little. We've also talked about how real assembly programming and systems engineering requires juggling more concepts than we do in SHENZHEN I/O, even if there are realistic instructions and hardware facets at play in the game. But we haven't talked much about the narrative premise behind this experience, and there is a story context for the learning process we go through in SHENZHEN. The plot casts us as a programmer moving from the states to China to manufacture electronics, and our character's adaptation to this foreign environment works as a metaphor for our transition into the world of programming. As we learn new Chinese phrases from the HR representative, and we decode the Mandarin in emails and manuals, we also learn another new language: a programming language.
This kind of language isn't loaded with the cultural signifiers or emotional expression of written or spoken tongues. However, we can see in SHENZHEN that programming languages possess a clarity, intricacy, and elegance that many find beautiful. Assembly language, in particular, is entangled with the hardware such that the computer can never misunderstand you. It's in that direct, unobstructed ability to command the machine that coding can give us a sense of control and the capacity to construct elaborate systems of cause and effect. Thanks for reading.
1. We can tell the current year from the visa application form in the game's manual. On it, the "Date of your first entry" reads "2026/09/28".
2. A component called the "MC4010 Math Co-Processor" does allow us to perform more advanced operations such as division and raising numbers to powers, but this is only available in the sandbox mode and not in the puzzles. Additionally, it does not take input through assembly language but opcodes sent by a microcontroller.
3. Opcodes on the Intel 8051 usually consist of a one-byte instruction and two bytes of operands, totalling three bytes. If we divide the 128-byte memory into three, we get 42.6 which we round down because the processor can't work with two-thirds of an opcode.