Infinifactory worst solution8/4/2023 At the start of the game, when the devices you’re building are still relatively simple, it’s a decent enough system you’re given sufficient space to experiment and refine your code, building a program that would qualify as “good” by basic programming standards and which covers off all required use cases and - this is important - all additional edge cases that you can think of. The inputs and corresponding target outputs are helpfully displayed along the bottom of the design interface, and each device has set of test cases that are supposed to cover off most of the use cases that device would typically encounter you can’t complete the puzzle until you come up with a program that can successfully pass all test cases. Said integers are supposed to represent the input state of some real-world device that you’re supposed to be designing - a card key operated door lock, or a smart rangefinder for a firearm - and you’re supposed to take that input and generate a set of integer outputs that matches the desired behaviour of the device, such as unlocking a door (or not). Each of Shenzhen’s puzzles gives you one or more input source that spits out integers between -999 and 999, either as a constant steady signal that can be read at any time or as a more discrete series of packet values that must be individually (and explicitly) shunted between components. To begin with it works quite well - as long as you don’t mind writing programs in assembler, that is. What Shenzhen is trying to do here is create puzzles out of the conflict between writing code in pseudo-assembler, where you have to be very explicit and long-winded about operations that could easily be done in a single line in a better language, and the limited space available in each processor component, which require that you fight for every single spare line of code and refactor repeatedly until your program is as pithy as it possibly can be. And while the assembler pseudo-language has a fair degree of functionality (loops, conditionals, execute once markers) this is still not a lot of space to work with, to put it mildly. There’s a small processor that takes up to 9 lines of code and can store one variable, and a large processor that can accommodate a whopping 14 lines of code and two whole variables (although you can only do arithmetic operations on one of them). There are several different types, but what dismayed me a little bit is how little opportunity Shenzhen provided to use interesting bits and pieces like the RAM/ROM modules, instead preferring to have 95% of its puzzles require only the two core microprocessor components – these are the standard blocks with a series of inputs and outputs and a space in the middle into which you can insert lines of code. So not only are you writing your pseudocode in a fake language that requires you to be absolutely explicit about every instruction, but Shenzhen then saddles you with further restrictions via the components you use. Almost nobody programs in assembler any more since this is the 21st century and we have a whole host of nicely interpreted languages that trade off some efficiency 1 for minor quality-of-life features such as “being able to run on more than one architecture” and “not driving the people who have to write in it completely batshit loco”. And not just any code, either Shenzhen’s pseudo-language is styled after assembly programming, which is a notoriously finicky language where nothing is handed to you on a plate and you have to do absolutely everything. Shenzhen takes the SpaceChem system of connecting together individual components that each do a segment of processing to gradually build a desired output, but instead of a pair of waldos manipulating atoms and molecules Shenzhen has you writing actual, literal computer code. Previous Zachtronics games such as SpaceChem or Infinifactory might have been heavily based around programming concepts, with easy in-game analogues you could point to for things like functions and arithmetic operations, but by packaging them up as an assembly line that built molecules/fully kitted-out living rooms instead of writing lines of code they were successfully insulated from real-world programming in a way that allowed the puzzles to co-exist quite peacefully with the much broader programming elements. What’s surprising about this, though, is what a mistake it’s turned out to be. After carving out a niche in the market by making puzzle games that were secretly about programming, it was inevitable that Zachtronics would eventually cross a line and make a puzzle game that was actually about programming.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |