Archive for the ‘Puzzle’ Category

Recently, I saw a new game from Zachtronics Industries, TIS-100, which was released on Steam as an early access title on the first of June. In some ways, calling it a game is overstating it: it’s little more than a collection of programming problems, with a little story to give it some structure. The catch is that you’re programming in an assembly language on a virtual machine with unusual architecture; problems beyond the simplest will generally require you to take advantage of parallelism (which is the primary distinguishing feature of the VM), resulting in novel solutions for ordinary problems.

Obviously, a game like that has a rather limited target audience. Case in point: I have myself previously created a little VM with a fake assembly language to play with. The game is clearly made just for me, but how many others are likely to be similarly interested? About 11,000,1 so far. It’s a minor hit.2

The concept of programming as gameplay isn’t new. Indeed, Zachtronics’s earlier game, SpaceChem, is also an exercise in parallel programming, though dressed up in fancier clothes. Way back in the mists of time,3Robot Odyssey challenged players to program the titular robots to solve puzzles. And on the more-programming-than-game end of the spectrum, we have Core War4 and a multitude of web sites in the vein of Project Euler or CodinGame.

I’ve been enjoying TIS-100, but more than that, I think it’s singularly impressive to release a game of this kind. Certainly, there are games that trade on their difficulty (Super Hexagon, I Wanna Be the Guy, etc.) and some that take pride in their difficulty of interaction (Surgeon Simulator, Ampu-Tea, QWOP, etc.), and simple ‘retro-style’ graphics are de rigueur for indie games, but the very minimalistic functionalism of TIS-100 is astounding.

TIS-100 is difficult because the thinking required to solve the puzzles is difficult. It is perhaps inaccessible, because it consists of nothing else but the tools to solve the puzzle. Its graphics are simple because everything you need to solve the puzzles is a text-mode interactive debugger, and that’s what you get. Like a sudoku puzzle or a crossword, TIS-100 is a completely pure puzzle game: the game takes place in your head, and the software keeps score.

It is not by chance that TIS-100 so distinguishes itself from other games. During the production of Infinifactory, Zach Barth, the founder of Zachtronics, wanted to make a game with a smaller team–something more-indie-than-indie–to get back to his roots as an indie developer. The project turned out to be too great in scope, but from its wreckage was salvaged a programming minigame which became TIS-100.5 Viewed as an indie developer’s attempt to make something even more indie, with the understanding that it was a small part of something larger, the design makes sense.6

The game’s manual, too, reflects the niche targeted by the game. Who reads a manual, you ask? When it is positioned as a technical document describing the instruction set of a virtual machine, the answer to that question is: programmers. The manual is presented as the in-universe manual for the TIS-100 computer, previously the property of the player character’s Uncle Randy, including handwritten notes and highlighting. This was part of Zachtronics’s attempt to make a game with “an irresistible value proposition. For us, that’s a game with a 14-page technical manual that we designed, printed out, marked up and scanned back in again.”7 The manual is reminiscent of the feelies accompanying Infocom games, among others, in years past.8

Like its predecessor, SpaceChem, TIS-100 encourages players to perfect their solutions, optimizing for either execution speed, least number of nodes used, or least instructions–goals which are often contradictory, requiring multiple solutions.

Perhaps unsurprisingly, given that it is a game about programming, the players of TIS-100 have created some auxiliary tools, including TIS-100 PAD,9 which allows users to more easily share solutions, and a variety of TIS-100 (the virtual machine, not the game) emulators.10

In addition to this unsolicited community participation, with the release of the specification editor, which allows players to make their own puzzles, a puzzle design contest was announced. Twenty-five puzzles will be selected from the submissions for an official bonus campaign.

The feel of TIS-100 is both nostalgic and quite modern. It’s an intriguing combination, and I recommend it to anyone still interested after hearing me call it “a collection of programming problems.” Coders, no prior experience with assembly is needed. Others, if you like this game–try coding. You’ll probably like that, too.

Also from 1984, described in a Scientific American article, [Dewdney1984]. It’s based on a still earlier programming game, Darwin, which was played in 1961 and described publicly in 1972. See [McIlroy1971] for more. ↩

The details of TIS-100‘s inception, and more, are discussed in an interview published by Gamasutra, [Wawro2015]. ↩

However, Barth wrote in a post mortem of SpaceChem, [Barth2012], that SpaceChem was too difficult and inaccessible. New titles were forthcoming: “New titles, I might add, that are hopefully more accessible than SpaceChem!” ↩

Patternia is a 1992 Tower of Hanoi game published in Game On in December 1992, with programming by Henrik Holmdahl, graphics by Simon Leijnse, and music by Kaspar Dahlqvist and Jakob Hellander.

Patternia really can’t be compared to any of the previous games in terms of graphics–it leaves them all far behind. The difference, I presume, is that all of the games I’ve reviewed up to this point, except Pyramidon, were written in BASIC, and were often type-in games, which severely limits how nice the graphics can be.

Patternia is controlled with the joystick, like Die Türme von Hanoi. In contrast to that one, though, Patternia does not animate the movement of the discs. And it’s a good thing! There’s a timer in Patternia, and if you don’t complete the puzzle within the time limit, you lose. Even for me, it was a close thing, on each level, and I’ve played dozens of Tower of Hanoi puzzles in sixteen different Tower of Hanoi games prior to this, so the optimum strategy is quite well fixed in my mind.

You’re given points at the end of each level depending on how much time you had left, and how many moves you used, including a bonus if you solved the puzzle optimally. I gave up on the 7-disc puzzle, but it was actually pretty fun, racing the clock.

Patternia beats the earlier Tower of Hanoi games in music as well: first, because it has music; and second, because the music is pretty good. I won’t be adding it to my playlist (which contains more than enough video game music as it is), but it’s not bad at all for background music.

If you’ve an urge to play a Tower of Hanoi game for the Commodore 64, Patternia is absolutely the best choice.

Die Türme von Hanoi is a 1989 Tower of Hanoi game by Nikolaus Heusler, published in 64’er Sonderheft #42.

This one is pretty good looking, and has quite a different style, with the dark coloration, than the others I’ve played. The animation is quick, and the pulsing from light to dark of the discs looked rather nice.

I did have one difficulty with it: GB64 lists it as controlled by keyboard, but it is really controlled by joystick in port 2. It took me some time to figure this out–I’d tried every key on the keyboard and used two different emulators before I realized that GB64’s metadata was wrong. Let the player beware.

I really prefer using the keyboard to play these games; it’s quicker to type the numbers than to select stacks with a joystick. The joystick controls in this one are much better than in Pyramidon, however, so it’s not too bad. Die Türme von Hanoi gets points for its unique visual style, too, and I note that it has an automatic solver that can be used at any time to complete the puzzle.

Die Türme von Hanoi ranks along with Pharao’s Super Nadeln as one of the best ‘pure’ (i.e. no plot or anything like that) implementations of the Tower of Hanoi puzzle. Still not something you’ll want to spend much time on, but a worthy piece of software, all the same.

Towers of Hanoi by Daniel Miller is a 1987 update of his 1985 Tower of Hanoi game of the same name.

While substantially the same, this game is much improved compared to its predecessor. The animation of the discs is much quicker, which cures the major problem with the previous game, and it also registers when you’ve won, rather than just going on forever. The game also beeps when moving discs, though that sound effect is quite primitive for 1987.

Towers of Hanoi was published in Loadstar #39, as well as Best of Loadstar #4. Hard to imagine a simple game like this being included in any kind of ‘best of’ compilation, but there it was.

Wow, is this game different from the last dozen or so I’ve reviewed. Just look at that lovely title screen! It’s got sound, nice graphics, a plot, everything you could ask of a game. Well, almost everything. It’s not much fun, but nobody’s perfect, right?

As far as I can decipher (German is not my strong suit, I fear), you are an astronomer who has discovered that a comet is on its way, and will strike a pyramid. Naturally you decide to save the pyramid… with a flying saucer. I’m not too sure how you got your hands on one of those, but… well, maybe you’re an alien astronomer.

You may choose between three difficulty levels, the harder difficulty levels having you rescue larger pyramids. The easiest, Menkaure’s pyramid, has three levels (corresponding to the three-disc Tower of Hanoi puzzle); the second, Khafra’s pyramid, has four; and the hardest, Cheops’s pyramid, has five.

Having selected the difficulty, you’re presented with the pyramid you chose in the center of the screen, and your task is to move it to one side by lifting the layers and solving the Tower of Hanoi puzzle.

While you’re doing this, a meter at the bottom of the screen shows how far away the comet is. Should you succeed in moving the entire pyramid before time runs out, you’re given a score based on how much time was left. You’re also treated to an animation of the comet smashing into the Earth where the pyramid used to be. Should you fail, you still get to see the same animation, but it destroys the pyramid and you get no score. Bad astronomer!

Unlike most of the other Tower of Hanoi games I’ve reviewed so far, which are more like computerized puzzles, Pyramidon is really game-like–it even gives you a score at the end. Unfortunately, the flying saucer moves very slowly; it took me ten minutes to beat the highest difficulty level, and I doubled the emulation speed after a while because it got too boring waiting on the movements to finish. I guess you have about fifteen minutes on the timer when you start, and it takes most of that time.

The game also has a slight problem with the controls. When the flying saucer is moving up or down, you can reverse direction, in case you started moving by accident, which is very convenient. When moving left or right, though, you can’t do this–you have to wait for the flying saucer to finish the movement before you can reverse it. Perhaps accidentally going the wrong way wouldn’t have been a problem on a real C64, with a real joystick, but the analog stick on my gamepad made it pretty easy to go the wrong way, so this missing feature made an already seemingly-interminable game take even longer.

I regret that the first really polished looking Tower of Hanoi game I’ve come to has such poor gameplay, but I’m afraid that’s how it is: I recommend against playing this one, unless you’re quite patient.

Blocktower is a 1987 Tower of Hanoi game for the Commodore 64, released by Wicked Software.

This seems to be exactly the same as Blocks from the previous year, with the title changed, and both seem to be copies of Glen Fisher’s Tower of Hanoi games. Blocktower was published in The Big 100, a collection of games. It seems they just copied a bunch of games from wherever–in fact, it appears that four of the hundred games in the collection are just copies of four others, with different filenames. That’s quality.

Blocks is a 1986 Tower of Hanoi game for the Commodore 64, released (according to GB64) by Robtek Ltd.

This one seems very much like a recolored version of Glen Fisher’s Hanoi. I’d be surprised if it weren’t based on it or one of its successors. As a result, my opinion of this one is the same as with those–it’s functional, but not worth a second look.

Towers of Hanoi by Daniel Miller is a 1985 Tower of Hanoi game for the Commodore 64.

This is just your standard Tower of Hanoi game, with a couple of differences: first, it doesn’t seem to be able to tell when you’ve won, instead requiring the player to press F1 to quit; second, pressing F1 during play will offer the option of having the computer solve the puzzle.

The animation of the discs moving is quite slow, making it rather boring to solve–it takes fully seven seconds to move a disc from the bottom of the left stack to the bottom of the right stack.

This would just be a rather poor Tower of Hanoi game, worthy of no particular notice, if it weren’t for one thing. Towers of Hanoi was published in the June 1985 issue of Ahoy!, a magazine for Commodore users–in fact, it was mentioned on the cover–and the writeup for the game is really great. It gives Lucas’s story about the priests in the temple moving discs about, counting down to the end of the world; it discusses the number of moves required to solve the puzzle; and it also describes some programming tricks the game uses quite lucidly. It’s a lovely little article, the sort that I really enjoy reading. It’s just a pity it wasn’t attached to a better game.

Stack by Glenn W. Zuch is a 1985 Tower of Hanoi game for the Commodore 64 with stunningly bad design.

I’ve opened this on a rather strong assertion, but it’s really deserved. For all the games I’ve reviewed so far, the worst thing you could really say about them was that they were unoriginal, boring, and ugly. Certainly flaws, but totally common ones and not entirely the fault of the authors.

Stack takes badness one step further–or a dozen. Behold:

Both the bars and the stacks are numbered, and rather than, as with every previous Tower of Hanoi game, selecting the source and destination stacks, you first select the bar you want to move, and then the stack you want to move it to. So solving the two-bar game, involves moving bar 9 to stack 2, bar 11 to stack 3, and then bar 9 to stack 3. Why weren’t the bars numbered 1 to 5 instead of 3, 5, 7, 9, 11? Who knows. But that’s not even the worst of it. Observe the game when a few moves have been made:

Each time you make a move, Stack redraws the stacks below the old ones, but it doesn’t tell you what the numbers are. So, you’ve got to keep in mind that in this case the medium sized bar is number 9, when you want to move it. How much worse it would be with five bars.

This is a horrible design choice with really no excuse. It’s a poor decision even if you’ve never seen a Tower of Hanoi game before, but by 1985 there were plenty of better examples.

This was a type-in game in the December 1985 issue of RUN (Issue #24), and the description there is priceless. It was written, I presume, by the author of the game, and repeats how easy the game is to play, while the underlying puzzle is difficult–not quite. Best of all is the one-sentence blurb introducing Stack: “Moving a few bars from one pile to another sounds easy, until you try this game.”