1. 6

    Picked this up on Early Access and it’s lots of fun. Personally the learning curve seems less steep as compared to other Zachtronics games, so if you got frustrated early with others, or haven’t tried any before, this is a good entrypoint. Presentation-wise, it’s top-notch. The pixel art graphics are crisp, the music is great as always, and the varied mission types make the gameplay more varied than previous Zachtronics releases.

    The puzzling is compelling enough to keep me playing, but the plot is unfortunately pretty underwhelming on this one so far. Hopefully that’s something that’s still being worked on, or that it turns a corner towards the end of the game.

    1. 3

      Let’s be honest these games are not about plot, they’re programming games. I really enjoyed TIS-100, didn’t like SpaceChem or Opus Magnum at all though. This one looks good: more like the former than the latter - actually involving writing code.

      1. 5

        Sure, nobody plays puzzle games for the plot, but the designers put one in, and IMHO feels half-baked enough to detract from the overall experience. The [rot13]Bar unpx, bar qeht qbfr[/rot13] thing is set up as if it’s a core mechanic but never really mentioned after the beginning, characters float in and out, and nothing I’m doing (hacking, battling, conversation choices in cutscenes, etc) feels like it has any tension or consequence beyond [rot13]nzhfvat RZORE-2 naq cbffvoyl pnhfvat fbzr yvarf bs pung va na VEP punaary fbzrjurer[/rot13], leaving me feel weirdly isolated in the world. (That feeling of disquieting solitude played to TIS-100’s strengths, given where that game goes, but I don’t think it works here.)

        edit: to be clear the game is good and everyone should buy this game

    1. 1

      I would add that repeating yourself, in some cases, is also essential in performance critical software, not just a matter of avoiding wrong abstraction or avoiding an ugly architecture design. I’m writing a painting application (like Photoshop, Krita, GIMP), and I could use the DRY philosophy on the function to plot the brushes, but I would have a serious performance drop if I did that, because the if/else abstraction would happen in the middle of a rasterization:

      void plot(...)
      {
      	while (row < bottom) {
      		while (col < right) {
      			if (plot.hardness == 100) {
      				/* Use simple plot */
      			} else {
      				/* Use plot with smoothness */
      			}
      		}
      	}
      }
      

      Now, imagine this with multiple parameters (hardness, roughness, density, blending, …). Instead, I copy-paste the function and rewrite with the specific algorithm inside of the nested loop.

      1. 2

        You could also assign the drawing function to a function pointer (or lambda or whatever) outside of the loop and just call that within the loop. No branching in the loop, and no duplicated code.

        1. 3

          But an indirect call (e.g. calling into a function pointer or a vtable, etc) is still a “branch” - it’s just one with an unknown number of known targets instead of two, which only adds more variables to the equation.

          In order for this to be equivalent to inlining the duplicate-for-each-algorithm code, one would have to convince oneself that the indirect branch predictor on the processor is going to reliably guess the CALL and RET targets, that the calling convention doesn’t spill more registers than the inlined execution would (ideally it’s a leaf function so the compiler can elide call prologue/epilogues), and that the processor’s speculative execution system doesn’t have its memory dependency information invalidated by the presence of the call.

          Caveat - the above might be less true if you’re programming in a managed runtime - if that function call can be inlined by the JIT compiler at runtime (many high-performance runtimes are very aggressive about function inliing, so it’s not an unrealistic thing to expect), then hopefully the above issues would be lessened.

        2. 2

          If you get a chance, there’s a chapter in Beautiful Code that talks about runtime code generation for image processing that, IIRC, singles out stencling and plotting as a running example, that you might find relevant to your interests.

          1. 2

            Thanks, I will make sure to check it out!

        1. 3

          I’ve often wondered about things like the connection between dependent typing and values in template declarations, so it’s nice to see an FP-oriented introduction to the topic.

          1. 2

            Would cubicles be better? That’s one cost efficient way to turn an office to a non-open office, I think 🤔

            1. 2

              Cubes combine the distracting background noise of an open plan office with having to sit by yourself :/

              1. 2

                Cubicles are far better than open offices in my opinion.

                1. 3

                  Agreed - while headphones can at least block out audible distractions in an open-office plan, there’s nothing to be done for people shooting hoops and reenacting last night’s Warriors game, or people trying to circumvent my “do not disturb” notice on Slack by waving their hands in front of my monitor (both actual examples at $OLDJOB). Visual distractions, at least for me, are just as bad!

                  1. 1

                    Not really. Noise is way more disturbing if you can’t see it’s source, apparently.

                1. 3

                  This is a great window into software jobs of the past. As much as I’m enjoying the 6502 assembly gore, what’s even more interesting are the quotidian posts, be it about bay area traffic (plus ca change), rooms for rent ($350/mo…cheap!), or the Great “What Do You Mean I Can’t Smoke In My Cubicle” Flamewar Of 1988.