Note: The following article contains moderate spoilers for 20th Century Food Court and SHENZHEN I/O.

Computers took over the world because they are the polymorphic machine. Other appliances are built to carry out a limited number of functions, usually one. They separate cotton from its seeds, they wash and dry clothes, they ventilate a building, etc. A computer is a calculator and a typewriter and a simulator for the stressors on a plane and a regulator for an industrial mixer and a camera and a hundred other things. While upgrading machines to perform new jobs is often a lengthy and involved process, many computers can be taught to take on new tasks in a few minutes through software installation.

The computer's adaptability is also why so much of computer science and programming is highly abstract. There are task-specific development tools for computers, but you'll be hard-pressed to find a programming language just for writing word processors or just for simulating plane physics. They're more broadly applicable than that, largely because software tools can operate on a wide range of data. Take conditional statements: operations that tell you if some variable meets some criteria. You could use them to program a microwave so that its alarm goes off if, and only if, the timer on it has reached "0". Or, there are loops, which run the same set of code repeatedly, usually until some condition is or is not met. You may notice loops implement conditionals and build on top of them. Imagine you're playing an MMORPG in which you cast a spell that buffs your party. The software will use a loop to cycle through every adventurer in your group and run the code to apply the boost to each one. The loop terminates when it has passed every party member. These operations don't care about the purpose of the data they're operating on, which is why they're flexible.

On the hardware layer, consider that you can't crack open a processor and find the part of the computer that specifically calculates wind speeds or the memory address that will always hold the first character of your document. Like the building blocks of software, the constituents of hardware are more use-agnostic than that. Take, for example, logic gates. Logic gates are elements of a circuit that take some signal/s as input, perform an operation on that data, and output it. If this sounds like a foreign concept, remember that addition and subtraction are also operations that digest some input and spit out a result. When I say "signal" in this context, I'm just talking about whether a wire or copper trace has electricity running through it; whether it's charged or not charged.^[1] Typically, we take an electrical charge to represent a "1" or "on" state and no charge to mean a "0" or "off" state.

The simplest logic gate is the NOT gate which gives an output opposite to its input. If its input wire is on, its output wire will be off. If its input is off, its output will be on. Another common player is the AND gate, which outputs an "on" or "1" signal only if all its inputs are "on" or "1". Otherwise, it outputs a "0". Here is a table showing what output the AND gate will produce based on what data is fed in:

For one last example, let's examine the OR gate. An OR gate outputs a 1 if any of its inputs are 1. It will only output a 0 if all its inputs are 0. Here is the OR "truth table":^[1]

These logic gates might look so abstract that you can't imagine how they could perform constructive operations but consider this AND-OR latch. The AND-OR latch is a collection of logic gates that lets you store a 1 or 0 and read that value back. It looks like this:

The circuit will default to storing a 0, but sending a charge through its upper input wire will set it to a 1. Sending a charge through the lower input wire will change it back to a 0. The stored bit is sent out of the output wire. The circuit below is a "full adder": an assemblage of logic gates that can add up numbers:

Understanding these schematics in full is not important. What is important is internalising that elements that can do many different jobs are integral to computers. The machine's output must change depending on the software and data fed to it. Therefore, it's full of parts, both soft and hard, that change their output based on the input. Many of Zachtronics' video games are about engineering machines out of instructions or parts that are ambivalent to their functions, and so, can be applied to a wide range of tasks.

The commands to route particles in SpaceChem don't care about the kind of particle they're routing, and the mechanical arms in Opus Magnum can pick and place any atom. In SHENZHEN I/O, the studio even has you build and program single circuits that must be able to take on a variety of different tasks, embodying the shapeshifting nature of real computers. One stage has you develop a smart window that must open or close based on pollution levels. Another challenges you to build a vending machine that calculates and dispenses correct change, even when the inputs and item prices are in constant flux. In 20th Century Food Court, one character in Zachtronics' Last Call BBS anthology, all the machines we build must be similarly adaptable. Both through the circuitry components that Food Court includes and the ones it's missing, the game shows why the parts we've discussed, like conditionals and logic gates, are crucial to adaptive machines.

20th Century Food Court is a game in which we build hardware that takes food orders as inputs and produces a tray matching that order as output. If you've played it before, feel free to skip the remainder of this paragraph and the one after it. During puzzles, Food Court's screen is spliced in two. On the right side, we can place food dispensers, conveyor belts, sensors, and other items, but the logic to run this circuit, we dictate via the gubbins on the left side of the screen. On the left, you'll find racks where you can install gizmos with input and output ports, and you can use those ports to wire parts into each other. "Out" connectors generally send a charge when some event in the circuit has occurred, while any charge coming into an "in" port will cause a part to perform a function.

For example, you might wire the "Start" output on your circuit to the "Ice" input for a freezer. This would make it so that when the machines start up, a signal will be sent to the freezer to make it dispense ice. Or, there are machines called Sorters which can push items that land on them in different directions. You could route the "Sense" output for a Sorter to its "Left" input, meaning that when it senses an item sitting on it, like a food tray, it will push it to the left.

A lot of us think of a circuit as a bunch of straight copper lines connecting parts on a flat wafer, but there's no reason the connections can't be slack or that you can't mount the widgets on a rack instead of a board. However, just as it can be difficult to see how you get from logic gates to a whole computer, much of your fight in 20th Century Food Court is straining to cobble together simplistic input/output devices in a configuration that would make something as complex as a chef. More than anything else, the complicating factor is that your mechanical cook needs to fill multiple possible orders without hardware modification. You won't be furrowing your brow figuring out how to hook the pretzel order output to the pretzel dispenser input. Yet, problems quickly arise when there are extra processing steps between reading input and sending output.

In the "Wine O'Clock" puzzle, we get a dispenser that can pour either red or white wine and must use it to fill a glass based on the customer's stated preference. The headscratcher is that you need two squirts from the wine container to fill the vessel, but conveyer belts move continuously outside of your control. You can't just sense when the glass falls under the tap and dispense wine then because you'll only have half a glass of alcohol heading to the exit slot.

A couple of levels involve constructing a burger. A tall hurdle in these stages is ensuring that all the ingredients get stacked onto the bottom bun before you place the top bun on because the top bun is effectively dispensed directly behind the bottom bun.

If both halves of the bun reach the Stacker in the same form they're dispensed, it will place the top bun on the bottom bun, and you'll end up with an empty sandwich. Part of your challenge is to route the top bun elsewhere and time the machine's operations so that the top arrives at the Stacker after all other ingredients. Yet, it's not easy to pre-program a time for the top bun to be delivered because, based on how many toppings the customer ordered, it may take more or less time to construct the rest of the burger.

There are obvious solutions. On the wine puzzle, you could send the glass to the correct dispenser and then drag it around a loop that whisks it back to the station for a second pour. For the burger trials, you could install bins to throw away redundant items. You wouldn't have to worry about holding back that top bun for the right moment if you routed it into the trash. When it's time to add the top bun, you dispense a whole bun again but drop the bottom half of that one into a bin. Yet, these answers are exorbitant and still don't tell our appliances when to dispense their foodstuffs. Ideally, this would be where conditionals step in to save the day. Time in 20th Century Food Court advances in steps. Imagine that we've built that wine vendor with the loop in it and know that the glass falls under the spout on step 5 and step 10. We could write code like:

"IF order = red wine AND (step = 5 OR step = 10), dispense red wine".

That would lend a specificity of operation to the wine machine that it lacks. If we could write a function that looped through every item on our burger and counted them, we could deduce the right time to place the top bun. But with no coding in Food Court, there are no conditional functions and no ANDs or ORs. We feel the absence of elements in proportion to their usefulness and the lack of these components in Food Court hurts. Yet, because computer hardware is made to execute software, it can perform the same functions as software. So, we know there must be physical parts that can do the equivalent work to conditionals or loops or boolean operators. Our reliance purely on physical circuitry lets the game emphasise the instrumentality of hardware like logic gates. The logic gates in Food Court are not called "logic gates", but they're in there.

We have the basic Multimixer, which takes up to four inputs and routes their signals into up to four outputs. In the Rosie's Doughnuts level, we must cover all chocolate or berry doughnuts in sprinkles, but not any plain doughnuts. So, we could set up a gate that either funnels the doughnut towards the sprinkle machine or doesn't. Then, we could connect the "chocolate" and "berry" outputs into a Multimixer and one of that mixer's outputs to the gate exit that moves in the direction of the sprinkler. Like so:

In other words, the Multimixer allows us to say, "IF the doughnut is chocolate OR berry, activate the part of the circuit that covers it in sprinkles". When we attach our interfaces with wires, we effectively build a conditional, and the base Multimixer serves as an OR gate.

There is a slightly more elaborate Multimixer that connects up to three inputs to up to three outputs. However, it only makes that connection if its "enable" port has an active signal entering it. This is useful in the Chaz Cheddar puzzle, in which we need to figure out whether or not to place meat on pizzas. We can create one circuit that detects when it's time to dispense the meat and another that saves whether the "meat" option was selected by the customer. We channel the part of the circuit that remembers whether we should dispense meat to one of the inputs of the Advanced Multimixer. Then, we connect the module that calculates when the pizza falls under the dispenser to the Multimixer's enable wire. So, if the part receives the "meat selected" signal AND the "meat time" signal, it will produce meat. The advanced Multimixer works as an AND gate.

There is no way to fabricate the sprinkle or meat system we just discussed without these gates, so you can see why they'd be essential to building computers. You might have heard that the invention of the transistor was a breakthrough in modern computing. If you've wondered why, consider that transistors let you build these logic gates on a miniature scale. When we route signals in 20th Century Food Court and SHENZHEN I/O, we also get a feel for how engineers use electrical charges to stand in for concepts like numbers, characters, or the need to pour cola. It's not that circuits consciously understand these concepts or that there is an innate signal that represents any one of these ideas. Electricity is always just electricity. It's that by making the signal pulse in different patterns or enter circuits with specific functions, it contextually works as the signal for "7" or "A" or "cola". There's no mechanical distinction between the electrons in the wire leading to the Freezer and the one leading to the Sorter; you assign the meaning to them through the fact that they lead to the Freezer or to the Sorter.

Yet, AND and OR are the only two gates Food Court gives you to define those purposes. Especially hampering is the lack of a NOT gate. In the level Sushi Yeah, we must serve every dish on the menu on a plate, apart from the soup, which we must serve in a bowl. If we could connect the soup input to the plate dispenser and put a NOT gate between them, the machine would place a plate on the belt whenever the order is NOT soup. Alas, we get no such luxury. Or there are Counters in the game that output a signal when they reach 0, but not on any other number. If we could combine Counters with NOT gates, they would be useful for, say, telling a machine to dispense 6 roast beef slices. You could have a Counter that's set to 6 if the order for 6 slices comes in. Every time a piece of beef is placed on the belt, you subtract 1 from the Counter. Then, you wire the Counter's output to a NOT gate and that gate to the dispenser. As long as the Counter's number is "NOT 0", it will keep sending the dispenser signal.

Three other logic gates: NAND, NOR, and ENOR, effectively incorporate the NOT gate, and so we're actually down four gates rather than one through its exclusion. It's possible to build the EOR gate in this game, out of AND and OR gates, but it's resource intensive and often too obscure to be useful.^[4]

There are workarounds to implement an analogue to NOT logic. For example, there is a more expensive Counter that outputs a signal when its variable is positive. Positive is almost "NOT 0". Or you can set up a bunch of OR gates to route any of the rice orders to the plate dispenser. However, these solutions consume more space and money while making your circuit harder to understand. Frequently, they also don't cover all the bases the NOT gate can. "Positive" is not the same thing as "NOT 0"; you've also got minus numbers.

Counters are your best friend as they're the only store you have for data entering the device. There's no RAM or on-chip memory, and you can't build latches. Memory storage circuits require gates beginning with "N". But all Counters start at 0, and you can only add to or subtract from that count using the numbers set via 2-4 pre-programmed inputs. As stated, you can also only get them to output a signal on 0 or any positive figure, so you can't freely write numbers into or read numbers out of these registers unless you want to work in binary.

You don't need me to explain to you why a computer requires memory, but again, the game makes the requirement abundantly clear by showing you what it's like to work without proper storage. As the only form of memory, Counters also serve as your timers. You can't count up to or down from a number if you have no way to remember what figure you're at. Therefore, you have minimal means to decide the "when" of an operation in the circuit without timers. In both Zachtronics titles and real hardware, the "when" is everything. This is one side of adaptivity in computers: circuits need to be able to bend not just to accommodate different inputs but also different timings with which those inputs arrive and outputs send.

A recurring theme in Zachtronics games is synchronising components: taking a screen of parts that don't innately know what the others are doing and getting them to cooperate on the same operation, doing the right job at the right time. However, 20th Century Food Court demands you exchange information between components with the correct timing to a greater extent than any other Zachtronics game.

Networking is important in SHENZHEN I/O. As the output of its circuits must change to match the input, some chips in its devices must inform other chips of the relevant data they'll need to produce that new output. For example, in the aquarium cleaner level, maybe you have one microcontroller that works out what operations the computer must do based on inputs and another that moves the cleaning head. That first chip would need to send data to the second chip. However, with SHENZHEN's modules acting as canvases for your code, there is a greater focus on setting the internal logic of parts over trading data between them. They can each remember and process a fair bit, and therefore, don't need to send data to other components to be stored and crunched. TIS-100 gives you fewer lines to write each screen of code with and forces you to pass information across its level's grids. The game thereby splits the difference between components processing data for themselves and exchanging it with their neighbours.

In 20th Century Food Court, your components must adapt to the changing inputs. However, you can set only a little of their internal logic at most, and many have only the practical power to relay signals to other components. With less processing capability per component, making a functional circuit means splitting all the processing between more parts. And that thin slicing of all the logic is what defines Food Court as a Zachtronics creation. If you play TIS or SHENZHEN, you'll discover that portioning out the program to different brains isn't just a case of performing the same logic in a few scattered text boxes. Instead, you need to design the hardware or software for the circuit's fundamental purpose and do the extra work of implementing an infrastructure for communication. For example, in SHENZHEN, you often need to come up with codes that chips can send to one another that represent modes they should operate in. Maybe for your aquarium robot, you use "0" to tell the chip to move the cleaner head left and "1" to move it right. Or you may have to ensure that one chip is listening for incoming data on the same tick another is transmitting it.

As Food Court is spreading the tasks thinner, it demands you implement more networking than ever. It's how it becomes a game about circuitry as much as about the components in the circuit. It's why you must tie cat's cradles of cables over the faces of your machines. It's the reason you're placing down plenty of Multimixers so that multiple components can speak to one particular input of another component. It's having one element reduce the value on a counter each time it does its job so that the timer can activate another element at the right moment. As Katie Salen and Eric Zimmerman observed, scaling up a problem often does not mean just scaling up a solution. Instead, the new solution must often include features the previous did not. In Food Court, it's normal to implement a feature, then add another feature to manage that first, and then perhaps add another feature to manage the management. But that also doesn't mean that you can expand your circuit as an alternative to engineering it efficiently.

As in all these system-builder games, you can throw more hardware at a problem instead of thinking through how to better optimise the hardware you already have. But implement enough components in Food Court, and you can confuse yourself with the new complexity of your machine. Even if you don't, if you're careless about what parts you install in your creation, you will run out of space. You might also create a circuit that works but is slow and costly, preventing you from competing seriously on the leaderboards. Limited resources and leaderboard metrics are another Zachtronics staple. In this sense, the studio's games don't act like puzzle titles as much as strategy games or management sims. In other puzzle games, you can often run up against hard limits that stop you from implementing a suboptimal solution. In Zachtronics titles, you usually can execute a flawed solution. Yet, you pay a resource or score cost for it, and when you have limited resources, it's often a lot of little problems that prevent you from implementing your solutions, not just one being flat-out "wrong".

Understanding everything going on in your circuit and being able to creatively realise different approaches is how you avoid these traps. Arguably, Food Court should be giving you more robust management tools, considering the number of parts you have to juggle and their abstraction. Opus Magnum, SpaceChem, ChipWizard Professional, and TIS levels don't contain too many actors to manage, and SHENZHEN lets you label elements in your circuit. By comparison, Food Court has shelves full of plastic and no labels to hand. There's no better way to relearn how your machine works than by turning it on and tracing the route that charges take through it.

But even if you could circle regions of the circuit and attach descriptors, it's unclear how you'd draw all the boundaries of these circles. The processing is crushed into a fine powder, and efficiency dictates that multiple components share the shame Multimixers, Counters, or other parts. Therefore, you can't have, say, a complete coffee machine module in one corner of the rack and a water boiler module in another. Instead, each module blends into one or more other modules, forming a logic soup. These gradients also make modifying a production line an involved process in which you have to be sharply conscious of its mechanics. Because each part is heavily reliant on those around it, when you take one piece out of the puzzle, you often need to change a lot about the neurons skirting it to compensate.

Again, recall that that network wouldn't be as complicated if you weren't building a machine to react to any possible order. The minimalist components and the spaghetti plate of wires that you hook between them are both the joints that let you flex into so many tasks and the complications that create hardship in solving problems. That's the life of the circuit engineer. But one of the great joys in these systems-building games is seeing some complex construct you've made acting under its own will. Because 20th Century Food Court has you making more system to do a job than any other Zachtronics title, there's more to be proud of at the end. There's nothing quite like seeing a screen of wires light up, and counters blink down to 0, somehow thinking without consciousness, rising to any challenge you can throw at them. They might even be able to get a burger out on time. Thanks for reading.

Notes

1. Boolean Logic & Logic Gates: Crash Course Computer Science #3 by Amy Ogan and Chris Harrison (March 8, 2017), YouTube.
2. Diagram by A-disciple, licensed under Creative Commons Attribution-ShareAlike 4.0.
3. Diagram by Trex4321.
4. Basic Gates and Functions by Wale Sangosanya, David Belton, and Richard Bigwood (1997–2005), University of Surrey.

All other sources linked at relevant points in the article.