TIS-100 dev’s Shenzhen I/O launches out of early access

Share this:

SHENZHEN I/O [official site], the latest Zachlike from the creator of TIS-100 and SpaceChem, today properly launched after six weeks in early access. It’s a puzzle game about assembling circuits from components then writing code to drive them, while poring over a manual for help and getting to know your new co-workers a little. SHENZHEN I/O was already a cracking game when Brendan prematurely evaluated it in October but Zachtronics have given it a nice bit of polish since. Along with the usual bug fixes and balance tweaks you’d expect, they’ve also added new components, including a synthesiser, and oh, a bonus campaign of extra puzzles.

My favourite change from the whole early access process, mind, is this:

Added a new puzzle to the main campaign based on one of Zach’s failed business ideas from before he started Zachtronics.

Bless.

Here’s what Brendan concluded about the early access version, and I’d wager most of that applies to the full release too:

“The thing to take away, apart from a subtle sense of numberdread, is this: SHENZHEN I/O is a polished and compelling puzzler. It is also a very traditional Zachlike, which is not something I consider a complaint. These games have always elicited an appropriately binary response in me. It’s one of the few subgenres which can make me feel both like a dribbling buffoon and a superhuman genius who has come to take over the world’s technology firms using drones and maths – all within the same 30 minutes. To those not afraid to tackle the manual – get yourself ready. You’re going to need some brainspace.”

A small launch discount brings Shenzhen I/O down to £9.89/13,49€/$13.49 on Steam.

I did a stint in college learning to program, so I thought this would be a breeze. But the interactions between the xbus pins are frustrating enough that I just don’t want to deal with it. I’m sure it’s actually not that hard if you know exactly how they work, but I get pretty tired of the seeing the generic and nondescript read/write errors because one board is sending something at the wrong time.

The game doesn’t do enough to help you understand why you are failing, which makes it feel a lot less like a game and a lot more like work. And the documentation doesn’t actually help much in terms of actually troubleshooting when your programs appear like they ought to work, but don’t.

Not being able to figure out why a program isn’t working when it really appears as thought it should, is one of the frustrations of learning C++ that I didn’t particularly want to relive, and yet here I am. Except now there’s nobody around to point at it and say ‘hey here’s why it’s breaking, you didn’t do X’ and give me that Aha moment.

Mostly getting through projects comes down to a certain amount of luck and repeatedly hammering at different ways of doing the same thing until it works, without actually figuring out why it works when the other methods failed.

Again, feels just too much like work, in a way that SpaceChem and Infinifactory didn’t.

xBus pins (x0, x1, etc.) block flow and send a signal once. This means that they require synchronization, and any linked output will default to 0 if no value is supplied. Note that some xBus board inputs will repeat their values, meaning that you can fetch a packet as many times as you want in a single slp cycle.

Simple I/O pins (p0, p1, etc.) send a constant signal and can not be blocked. A p-signal will be repeated indefinitely until changed and allows for modules to function asynchronously. This can create race conditions — when this happens, try to use nop as filler.