4 ms·

>Because let's face it, masochism is what programming is about. True, but Zach is good at pulling out a simple representative subset for each game. There's no

by lfowles 10y ago

>Because let's face it, masochism is what programming is about. True, but Zach is good at pulling out a simple representative subset for each game. There's no arcane syntax for using registers vs IO in TIS-100 for example. It's just another dest/source that works with MOV. Then he adds something outlandish and gamey like adjacent core communication. I've played some other attempts at the programming masochism genre and they struck me as fiddly attempts to cram complexity into the instructions vs the problem.

qwertyuiop924 10y ago
This is why I like ZT games more than other excercises in masochism like BrainFuck. They're ultimately more about using a simple, well-understood set of tools to solve difficult problems than they are about using a deliberately obstructive set of tools. The fact that the tools are so easy to understand is what draws me to it over real asm programming: nothing's worse than trying to solve a puzzle when you have the sneaking suspicion that there's a few pieces you're missing that would make your job easier if you were to only learn them. Let the complexity emerge naturally. Because it will. By the way, if you like ZT games, and haven't checked out the work of Eric Wastl (The Synacor Challenge, and The Advent of Code) you should do so immediately. It's not as fun now that everyone else has done it, but it's still a blast.
- lfowles 10y ago
  Funny you bring up Braunfuck, I've toyed with making a brainfuck game[0], but gave up because working with terminal IO is the pits .... [0]: https://github.com/lfowles/brainporn https://github.com/lfowles/brainporn
- thaumasiotes 10y ago
  > This is why I like ZT games more than other excercises in masochism like BrainFuck. They're ultimately more about using a simple, well-understood set of tools to solve difficult problems than they are about using a deliberately obstructive set of tools. I tend to feel the opposite way -- the games are written to be deliberately obstructive; that's why we call them "games". It gets frustrating pretty quickly. Spacechem is a series of exercises in writing Befunge. I don't see how that could be characterized any other way than as "obstructive for the sake of obstructive".
  - qwertyuiop924 10y ago
    But they don't feel obstructive: allow me to put it like this: With many games of this sort, or with INTERCAL and Befunge, you are asked to build a device with broken, strange tools that don't work properly, and are designed to be as annoying as possible. The TIS instruction set, OTOH, is perfectly well designed and clear in how it works, it's just very primitive. This is akin to BF, but BF is so low level that it's far more irritating.
    - thaumasiotes 10y ago
      Spacechem is a ZT game just like TIS-100 is. All of your problems come from the fact that each thread's cursor has to physically travel to the next instruction in a very cramped area while avoiding other instructions that may have been laid out in between. (Also, if full cursors crash into each other, your program crashes.) With real tools, Spacechem programs would all be trivial. Feel does come into it, I guess, because I loved Manufactoria (also Befunge). Manufactoria is a lot more computational than Spacechem; your goal there is to manipulate a bitstring, not to traverse the environment for its own sake.
      - qwertyuiop924 10y ago
        But the tools are real! Just very primitive. I guess what I'm saying is that it doesn't give you a toolkit with a bunch of weird tools and impractical designs and bizzare edge cases (looking at you, INTERCAL), it's purely, "right, here's your tools, you knoe how they work, let's see you pull this off." Sure, it's less obviously linked to programming, but think about it: that sort of issue comes up all the time. And just because the goal is more overtly computational in nature doesn't mean it's actually a more computational game: I wouldn't know, because it's 9 o'clock here on USEast, and I'm typing this on my phone, so I can't play the game ATM.
        thaumasiotes 10y ago
        > But the tools are real! Just very primitive. If you're scheduling cargo shipments, it strikes me as both easier and more "primitive" to have one tool that can load, move, and unload cargo in response to commands, and an entirely different programmable tool that issues the commands.

by lfowles 10y ago

qwertyuiop924 10y ago

This is why I like ZT games more than other excercises in masochism like BrainFuck. They're ultimately more about using a simple, well-understood set of tools to solve difficult problems than they are about using a deliberately obstructive set of tools. The fact that the tools are so easy to understand is what draws me to it over real asm programming: nothing's worse than trying to solve a puzzle when you have the sneaking suspicion that there's a few pieces you're missing that would make your job easier if you were to only learn them. Let the complexity emerge naturally. Because it will. By the way, if you like ZT games, and haven't checked out the work of Eric Wastl (The Synacor Challenge, and The Advent of Code) you should do so immediately. It's not as fun now that everyone else has done it, but it's still a blast.

lfowles 10y ago
Funny you bring up Braunfuck, I've toyed with making a brainfuck game[0], but gave up because working with terminal IO is the pits .... [0]: https://github.com/lfowles/brainporn https://github.com/lfowles/brainporn
thaumasiotes 10y ago
> This is why I like ZT games more than other excercises in masochism like BrainFuck. They're ultimately more about using a simple, well-understood set of tools to solve difficult problems than they are about using a deliberately obstructive set of tools. I tend to feel the opposite way -- the games are written to be deliberately obstructive; that's why we call them "games". It gets frustrating pretty quickly. Spacechem is a series of exercises in writing Befunge. I don't see how that could be characterized any other way than as "obstructive for the sake of obstructive".
- qwertyuiop924 10y ago
  But they don't feel obstructive: allow me to put it like this: With many games of this sort, or with INTERCAL and Befunge, you are asked to build a device with broken, strange tools that don't work properly, and are designed to be as annoying as possible. The TIS instruction set, OTOH, is perfectly well designed and clear in how it works, it's just very primitive. This is akin to BF, but BF is so low level that it's far more irritating.
  - thaumasiotes 10y ago
    Spacechem is a ZT game just like TIS-100 is. All of your problems come from the fact that each thread's cursor has to physically travel to the next instruction in a very cramped area while avoiding other instructions that may have been laid out in between. (Also, if full cursors crash into each other, your program crashes.) With real tools, Spacechem programs would all be trivial. Feel does come into it, I guess, because I loved Manufactoria (also Befunge). Manufactoria is a lot more computational than Spacechem; your goal there is to manipulate a bitstring, not to traverse the environment for its own sake.
    - qwertyuiop924 10y ago
      But the tools are real! Just very primitive. I guess what I'm saying is that it doesn't give you a toolkit with a bunch of weird tools and impractical designs and bizzare edge cases (looking at you, INTERCAL), it's purely, "right, here's your tools, you knoe how they work, let's see you pull this off." Sure, it's less obviously linked to programming, but think about it: that sort of issue comes up all the time. And just because the goal is more overtly computational in nature doesn't mean it's actually a more computational game: I wouldn't know, because it's 9 o'clock here on USEast, and I'm typing this on my phone, so I can't play the game ATM.
      - thaumasiotes 10y ago
        > But the tools are real! Just very primitive. If you're scheduling cargo shipments, it strikes me as both easier and more "primitive" to have one tool that can load, move, and unload cargo in response to commands, and an entirely different programmable tool that issues the commands.