<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: Thoughts: Shenzhen I/O</title>
	<atom:link href="https://scientificgamer.com/thoughts-shenzhen-io/feed/" rel="self" type="application/rss+xml" />
	<link>https://scientificgamer.com/thoughts-shenzhen-io/</link>
	<description>Science, gaming, and all things in between.</description>
	<lastBuildDate>Wed, 01 Jul 2026 22:05:15 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=3.7.36</generator>
	<item>
		<title>By: Anonymous</title>
		<link>https://scientificgamer.com/thoughts-shenzhen-io/#comment-61462</link>
		<dc:creator><![CDATA[Anonymous]]></dc:creator>
		<pubDate>Fri, 22 May 2026 11:46:06 +0000</pubDate>
		<guid isPermaLink="false">http://scientificgamer.com/?p=5235#comment-61462</guid>
		<description><![CDATA[&gt;Shenzhen on the other hand is supposed to be set in the 2030s so it’s absolutely nonsensical to be referring to what’s supposedly a paper manual the whole time
As an embedded engineer, I spend a significant amount of time reading manuals and datasheets. This will be the case for the future as well, so it&#039;s not nonsensical at all.

&gt;Shenzhen is teaching you to actually program – badly.
It&#039;s following the idea of assembly on highly constricted systems to a tee. I&#039;m surprised you ignore that this type of problem solving is deeply fascinating to programmers. Machine code writers of the 50s/60s were known to let opcodes double as program constants, which is a terrible idea nobody would do today, but one can&#039;t help appreciating the manic cleverness of this.]]></description>
		<content:encoded><![CDATA[<p>&gt;Shenzhen on the other hand is supposed to be set in the 2030s so it’s absolutely nonsensical to be referring to what’s supposedly a paper manual the whole time<br />
As an embedded engineer, I spend a significant amount of time reading manuals and datasheets. This will be the case for the future as well, so it&#8217;s not nonsensical at all.</p>
<p>&gt;Shenzhen is teaching you to actually program – badly.<br />
It&#8217;s following the idea of assembly on highly constricted systems to a tee. I&#8217;m surprised you ignore that this type of problem solving is deeply fascinating to programmers. Machine code writers of the 50s/60s were known to let opcodes double as program constants, which is a terrible idea nobody would do today, but one can&#8217;t help appreciating the manic cleverness of this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Bernström</title>
		<link>https://scientificgamer.com/thoughts-shenzhen-io/#comment-61336</link>
		<dc:creator><![CDATA[Peter Bernström]]></dc:creator>
		<pubDate>Sun, 02 Feb 2025 21:16:49 +0000</pubDate>
		<guid isPermaLink="false">http://scientificgamer.com/?p=5235#comment-61336</guid>
		<description><![CDATA[I find the barrier to entry really low. I rather recommend Shenzen I/O to someone new instead of telling them to buy a esp32 and soldering iron. The game is a quick and easy way to find out if you really like programming. I really enjoy the game.]]></description>
		<content:encoded><![CDATA[<p>I find the barrier to entry really low. I rather recommend Shenzen I/O to someone new instead of telling them to buy a esp32 and soldering iron. The game is a quick and easy way to find out if you really like programming. I really enjoy the game.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike</title>
		<link>https://scientificgamer.com/thoughts-shenzhen-io/#comment-61200</link>
		<dc:creator><![CDATA[mike]]></dc:creator>
		<pubDate>Fri, 24 Feb 2023 03:39:28 +0000</pubDate>
		<guid isPermaLink="false">http://scientificgamer.com/?p=5235#comment-61200</guid>
		<description><![CDATA[At least for me, this game isn&#039;t about teaching you writing good code.
Honestly I already write enough readable code at work. The real fun is writing hacky and unreadable code for the sake of saving just one line of code]]></description>
		<content:encoded><![CDATA[<p>At least for me, this game isn&#8217;t about teaching you writing good code.<br />
Honestly I already write enough readable code at work. The real fun is writing hacky and unreadable code for the sake of saving just one line of code</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thoughts: Möbius Front &#039;83 &#124; The Scientific Gamer</title>
		<link>https://scientificgamer.com/thoughts-shenzhen-io/#comment-60568</link>
		<dc:creator><![CDATA[Thoughts: Möbius Front &#039;83 &#124; The Scientific Gamer]]></dc:creator>
		<pubDate>Thu, 12 Nov 2020 11:13:54 +0000</pubDate>
		<guid isPermaLink="false">http://scientificgamer.com/?p=5235#comment-60568</guid>
		<description><![CDATA[[&#8230;] core idea of finding puzzle analogues for programming started to wear thin. This culminated in a rather ill-tempered review of Shenzhen I/O, a game which was literally about programming and which pissed me off to no end [&#8230;]]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] core idea of finding puzzle analogues for programming started to wear thin. This culminated in a rather ill-tempered review of Shenzhen I/O, a game which was literally about programming and which pissed me off to no end [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: i b</title>
		<link>https://scientificgamer.com/thoughts-shenzhen-io/#comment-35209</link>
		<dc:creator><![CDATA[i b]]></dc:creator>
		<pubDate>Sun, 26 Feb 2017 11:19:50 +0000</pubDate>
		<guid isPermaLink="false">http://scientificgamer.com/?p=5235#comment-35209</guid>
		<description><![CDATA[Actually, My concern is that due to this &quot;special syntax&quot; and not considering real world issues (like sampling an input signal) you actually get &quot;better power usage&quot; for not realistic code
=&gt;Bad practice programming? , the game is suppose to be about an Embedded engineer
(The hardware components however are somewhat realistic)
not such a good example: 


¥4 COST  285 POWER  7 LINES
  teq x0 100  
+ mov p0 acc
+ mul 4
+ sub 150
+ mov acc p1
- mov p0 p1
  slp 1

vs
&quot;Trying to somehow sample the signal (p0) to a register at first stage&quot;
¥4 COST  310 POWER  6 LINES
  tcp x0 p0
  mov p0 acc
+ mul 4
+ sub 150
  mov acc p1
  slp 1]]></description>
		<content:encoded><![CDATA[<p>Actually, My concern is that due to this &#8220;special syntax&#8221; and not considering real world issues (like sampling an input signal) you actually get &#8220;better power usage&#8221; for not realistic code<br />
=&gt;Bad practice programming? , the game is suppose to be about an Embedded engineer<br />
(The hardware components however are somewhat realistic)<br />
not such a good example: </p>
<p>¥4 COST  285 POWER  7 LINES<br />
  teq x0 100<br />
+ mov p0 acc<br />
+ mul 4<br />
+ sub 150<br />
+ mov acc p1<br />
- mov p0 p1<br />
  slp 1</p>
<p>vs<br />
&#8220;Trying to somehow sample the signal (p0) to a register at first stage&#8221;<br />
¥4 COST  310 POWER  6 LINES<br />
  tcp x0 p0<br />
  mov p0 acc<br />
+ mul 4<br />
+ sub 150<br />
  mov acc p1<br />
  slp 1</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mivexil</title>
		<link>https://scientificgamer.com/thoughts-shenzhen-io/#comment-34528</link>
		<dc:creator><![CDATA[Mivexil]]></dc:creator>
		<pubDate>Thu, 19 Jan 2017 02:11:41 +0000</pubDate>
		<guid isPermaLink="false">http://scientificgamer.com/?p=5235#comment-34528</guid>
		<description><![CDATA[Personally, I don&#039;t see the restrictiveness as a bad thing. In the end, in Shenzhen or TIS you&#039;re not really programming, you&#039;re solving a puzzle - the game expect you to figure out the right solution, not go ahead with the most obvious one and throw resources at it until it works. If you give the player too much breathing room, then the puzzles are either very trivial as the player bypasses the level&#039;s gimmick by just throwing in another microcontroller, or very frustrating as they get overwhelmed by the sheer size of the solution space, having to scrap a lot of work because they started with the wrong idea and the game was more than happy to give them enough rope to hang themselves with.

Constraining the player is a way to tell them &quot;hey, the intended solutions all need no more than two controllers. Don&#039;t get started with the third, the obvious approach doesn&#039;t work here&quot;. And it also means you run out of space quickly, so you don&#039;t feel like you&#039;ve wasted too much time pursuing the wrong solution (which, coincidentally, is why I&#039;ve all but shelved SpaceChem - I loved the idea and the first few puzzles, but then it quickly became infuriating as you realized reactor number 4 has no physical way to do what you want because you&#039;ve shipped the molecule from reactor 1 a square too far to the left, and it&#039;s all the way back to the beginning with you).

Agreed on the learning curve being a wall you&#039;ll smash your head against, but at least it&#039;s somewhat softened if you&#039;ve played SpaceChem and TIS-100. It&#039;s an odd decision to make this kind of sequel-but-not-really, though - it basically ensures you won&#039;t drag many new people in, which kinda doesn&#039;t match Shenzhen being aesthetically far more polished. As a programmer, I appreciate not being hand-held over what the register is, but I can see how it would be offputting.

I kind of like the datasheets. You&#039;re supposed to print them, tab dividers and all, so that you have a physical tchotchke - but I found that a second monitor works just as well. For better or for worse, they&#039;re pretty realistic (including, especially, the bad ones, the useless ones, and the one in Chinese. Terrible documentation isn&#039;t just a problem with coding), and they add to the immersion. 

And I think that a lot of the issues you have with Shenzhen stem from the way you approach it - as a coding challenge rather than a constrained puzzler. Because under the facade of assembly and coding, that&#039;s what it is - the goal is to find the single solution that satisfies the requirements, figuring out the tricks behind the level to find out what the creator had in mind when designing it. It&#039;s not good coding practice, but to me, it would be much more difficult for Shenzhen to provide an appropriate amount of challenge/frustration balance if it was the other way around.]]></description>
		<content:encoded><![CDATA[<p>Personally, I don&#8217;t see the restrictiveness as a bad thing. In the end, in Shenzhen or TIS you&#8217;re not really programming, you&#8217;re solving a puzzle &#8211; the game expect you to figure out the right solution, not go ahead with the most obvious one and throw resources at it until it works. If you give the player too much breathing room, then the puzzles are either very trivial as the player bypasses the level&#8217;s gimmick by just throwing in another microcontroller, or very frustrating as they get overwhelmed by the sheer size of the solution space, having to scrap a lot of work because they started with the wrong idea and the game was more than happy to give them enough rope to hang themselves with.</p>
<p>Constraining the player is a way to tell them &#8220;hey, the intended solutions all need no more than two controllers. Don&#8217;t get started with the third, the obvious approach doesn&#8217;t work here&#8221;. And it also means you run out of space quickly, so you don&#8217;t feel like you&#8217;ve wasted too much time pursuing the wrong solution (which, coincidentally, is why I&#8217;ve all but shelved SpaceChem &#8211; I loved the idea and the first few puzzles, but then it quickly became infuriating as you realized reactor number 4 has no physical way to do what you want because you&#8217;ve shipped the molecule from reactor 1 a square too far to the left, and it&#8217;s all the way back to the beginning with you).</p>
<p>Agreed on the learning curve being a wall you&#8217;ll smash your head against, but at least it&#8217;s somewhat softened if you&#8217;ve played SpaceChem and TIS-100. It&#8217;s an odd decision to make this kind of sequel-but-not-really, though &#8211; it basically ensures you won&#8217;t drag many new people in, which kinda doesn&#8217;t match Shenzhen being aesthetically far more polished. As a programmer, I appreciate not being hand-held over what the register is, but I can see how it would be offputting.</p>
<p>I kind of like the datasheets. You&#8217;re supposed to print them, tab dividers and all, so that you have a physical tchotchke &#8211; but I found that a second monitor works just as well. For better or for worse, they&#8217;re pretty realistic (including, especially, the bad ones, the useless ones, and the one in Chinese. Terrible documentation isn&#8217;t just a problem with coding), and they add to the immersion. </p>
<p>And I think that a lot of the issues you have with Shenzhen stem from the way you approach it &#8211; as a coding challenge rather than a constrained puzzler. Because under the facade of assembly and coding, that&#8217;s what it is &#8211; the goal is to find the single solution that satisfies the requirements, figuring out the tricks behind the level to find out what the creator had in mind when designing it. It&#8217;s not good coding practice, but to me, it would be much more difficult for Shenzhen to provide an appropriate amount of challenge/frustration balance if it was the other way around.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ilitarist</title>
		<link>https://scientificgamer.com/thoughts-shenzhen-io/#comment-34516</link>
		<dc:creator><![CDATA[ilitarist]]></dc:creator>
		<pubDate>Tue, 17 Jan 2017 07:52:57 +0000</pubDate>
		<guid isPermaLink="false">http://scientificgamer.com/?p=5235#comment-34516</guid>
		<description><![CDATA[Can you explain to me the appeal of those ultra-hardcore brain-intensive games?

I can understand just hard games. When I play RPG game I usually do it on highest difficulty setting cause I know this is where you need to use all game systems, otherwise you can most of them. I understand games that punish you for mistakes like Dark Souls which sends you back, or really most modern shooters without quick save requiring you to replay encounters from the beginning. If I ever play Fallout 4 again it will be cause of Survival mode which is supposedly where game is not a power fantasy. Outside of videogames I enjoy quizzes and have sort of reputation in that trade.

But those games... I am too a programmer by trade. Sometimes I even program in my free time. True, learning new development environment like a language or framework is even harder than those games - in the game you have at least some sort of tutorial, learning curve and feedback on your mistakes while new framework can just throw Unexpected Param AlQBidder$49 when you try to compile an example from documentation because you haven&#039;t adjusted timezone in some property file. Still after this initial challenge you get creativity, tasks that make sense, technical problems becoming minimal and tool truly becoming the tool, not the challenge. Games like that concentrate on the least fun thing about programming - frustration because of not understanding how the tools work - without giving you real world benefits of learning the tool.

I don&#039;t play Korean MMOs too, but as I understand they give you a feeling of progression by doing routine tasks and filling progress bars for all sorts of things. In a sense it&#039;s a total opposite of those kinds of game but they look to me as more fair... Hobby, if you wish. You spend time with it, you relax, you switch your brain to a menial task with steady flow of gratification. Perhaps those kinds of brain intensive games like Chemspace are good when your day job *is* about menial tasks?..]]></description>
		<content:encoded><![CDATA[<p>Can you explain to me the appeal of those ultra-hardcore brain-intensive games?</p>
<p>I can understand just hard games. When I play RPG game I usually do it on highest difficulty setting cause I know this is where you need to use all game systems, otherwise you can most of them. I understand games that punish you for mistakes like Dark Souls which sends you back, or really most modern shooters without quick save requiring you to replay encounters from the beginning. If I ever play Fallout 4 again it will be cause of Survival mode which is supposedly where game is not a power fantasy. Outside of videogames I enjoy quizzes and have sort of reputation in that trade.</p>
<p>But those games&#8230; I am too a programmer by trade. Sometimes I even program in my free time. True, learning new development environment like a language or framework is even harder than those games &#8211; in the game you have at least some sort of tutorial, learning curve and feedback on your mistakes while new framework can just throw Unexpected Param AlQBidder$49 when you try to compile an example from documentation because you haven&#8217;t adjusted timezone in some property file. Still after this initial challenge you get creativity, tasks that make sense, technical problems becoming minimal and tool truly becoming the tool, not the challenge. Games like that concentrate on the least fun thing about programming &#8211; frustration because of not understanding how the tools work &#8211; without giving you real world benefits of learning the tool.</p>
<p>I don&#8217;t play Korean MMOs too, but as I understand they give you a feeling of progression by doing routine tasks and filling progress bars for all sorts of things. In a sense it&#8217;s a total opposite of those kinds of game but they look to me as more fair&#8230; Hobby, if you wish. You spend time with it, you relax, you switch your brain to a menial task with steady flow of gratification. Perhaps those kinds of brain intensive games like Chemspace are good when your day job *is* about menial tasks?..</p>
]]></content:encoded>
	</item>
</channel>
</rss>
