Ratings and Reviews by Dan Fabulich

In 2012, Ryan Veeder published "The Statue Got Me High" as part of the Apollo 18+20 tribute album project. As the game begins, it appears that you have to solve a tricky logic puzzle, but it turns out that you don't have to solve it at all.

The reveal in "The Statue Got Me High" is funny, because gathering the clues to solve a logic puzzle like that would be boring. It was surprising but inevitable in hindsight that Ryan would give us a fun game instead of a boring logic puzzle.

In contrast, the purpose of "The Little Match Girl at the Battle of the Gray Peaks" is to be boring.

You do, in fact, have to solve the logic puzzle to win this game, and it is very boring work. In fact, when you win, the game explicitly acknowledges how boring it is, as part of a bonus puzzle.

I feel like this game is a practical joke played on the player. "Ha ha, you dork, you wasted your time solving a boring logic puzzle!"

I think I wouldn't have bothered if I weren't a fan of Ryan's work in general.

In addition to solving the boring logic puzzle, there is one basically legit "aha!" puzzle here, but I think even that puzzle didn't have enough hinting. IMO, good puzzles, like good jokes, have solutions that are surprising but inevitable in hindsight, but this one wasn't.

(Spoiler - click to show)
When assigning units, when you win the war, you lose the game.

The clue to winning the game is the remark, "She had survived the war with no more than a few scratches—but she was hurt all the same, by the memories of the Reptons and dinosaurs who had suffered and perished under her orders. She would turn the problem over in her head night after night—she would realize, after a few years, exactly how she could have done better—and the knowledge would haunt her for the rest of her life."

When I read that, I read it as referring only to the Reptons and dinosaurs who were acting under her orders. That mislead me from the real solution, which is to set up seven stalemates.

The eye-blinking mechanic is wild. You've just gotta try it.

The game is short, but I think I couldn't handle an eye-blinking game any longer than this one!

Don't make the mistake I made, of reading all of the written metatext material in the GUIDE before you start playing.

Instead, just start by typing PS 1 to read the first footnote. (Whenever you see footnotes in brackets, e.g. [CAS 1], you can type the text in brackets to read the footnote.)

The first footnote includes a tutorial, allowing you to start playing and familiarize yourself with the characters before you dive into the metatext.

(Unfortunately, some of the metatext implies that you need to read the metatext first, and in particular, that you need to read every page of the metatext just to find out how to read footnotes, to find out how to access the tutorial. IMO, this is a bug in the tutorial, and I hope it gets fixed.)

I, myself, really didn't enjoy this game, because I spent an hour scrutinizing the metatext before engaging with the characters.

But you won't make that mistake. You'll like this game much more than I did, because you read this review.

I like a lot of the ideas in this game, and many of the puzzles were solid, but I became totally dependent on the in-game HINTS command, and I felt I had to conclude that a lot of the puzzles weren't fair.

(Spoiler - click to show)A number of the puzzles (including three of the compound spells) require you to LOOK UP X in the book where X is a term you haven't seen mentioned in the game yet. That could be OK if the answers were extremely clearly right in hindsight, but I kept finding that I tried a bunch of reasonable LOOK UP X commands, and then I'd check the hints, and then… womp womp, none of my reasonable guesses worked. Instead I should have looked up Y.

I don't think it makes sense to have "guess the topic" puzzles unless the author provides support for a lot of topics (or, at the very least, a lot of synonyms), and at the minimum help me out with "warmer/colder" hints. Otherwise, after a few failed guesses, I'm forced to assume that there's no puzzle to solve here at all. Good puzzles have to seem inevitable in hindsight, and none of the "make a wild guess about what to look up" puzzles ever did.

In addition, the puzzle in the cavern was… not good. I'd put the obsidian slab in the obsidian block, and didn't realize that I could bring it back out again. But even if I'd brought the slab with me, I put a bone on the altar and it didn't seem to do anything, so I never discovered that the bone would disappear.

The object of this one-room game is to open a safe in the center of the room. The safe has a large red button. Here's what it says when you push it:

If it were as easy as that, the bank probably wouldn’t have needed to call a superhero, don’t you think?

That sounds like "you can't push this button" to me. But, instead, you're just supposed to "push the button" again. At that point, the safe asks for a password, on a countdown timer. If you don't have the password (or the (Spoiler - click to show)companion you need to get the password), there's no way to discover and use the password before the timer runs out.

This puzzle is "Nasty" on the Zarfian cruelty scale. The game doesn't benefit from a countdown timer at all, and there are multiple puzzles where you have to just do the same action repeatedly to get a surprisingly different result.

Furthermore, the game is buggy.

In this game, you can fight a wolf or a bear. During the tutorial, you fight the wolf, and then the bear. You can't defeat the bear in the tutorial, so you must run (or lose the fight).

At that point, the game lets you "nap" in one of two locations, the field or the forest. If you nap in the field, you have a random chance of meeting a trader. If you nap in the forest, well, the game is then supposed to give you a random chance of meeting a trader or fighting a wolf or bear, but, in fact, you'll only meet a trader.

This game is distributed as Python source code, allowing me to read the code to debug it.

The problem lies in the "random_events" function in Handler.py. It computes a max value "a" (for example, a=9), then computes a random value "b" from 0 to "a", as if rolling a die with 9 sides. The game then never uses the random variable "b", but instead uses the variable "a", as if the player had always rolled the maximum value on the die. As a result, the player only ever meets the trader, regardless of whether you nap in the field or forest.

This was all preventable if the author had followed common-sense guidelines, such as the IFComp guidelines for authors. https://ifcomp.org/about/guidelines

The guidelines there say to playtest your game and to credit your beta testers. But the "credits" command (which only works when you're not in combat or trading) credits only the author, and no beta testers. I think that if anyone had beta tested this game, they would have discovered this bug, and the author would have fixed it before now.

Furthermore, the guidelines recommend using an IF authoring tool like Inform or TADS, and not to implement your own parser implementation in Python. Distributing the game as Python made it unnecessarily difficult to play.

Finally, upon reviewing the code, I see that there's no way to "win" the game. Even if the randomizer bug is fixed, at best, you might fight the bear, drink a few health potions, and win the fight, but you just get a few more units of meat, bone, and fang from winning. The more experience points you earn, the higher your "level" is, but leveling up doesn't do anything.

There should be a way to win the game. Perhaps the game might end saying "you win!" when you defeat the bear. Ideally, there would even be some kind of story, giving me a reason to fight wolves and bears.