Game #22: Packrat
By Bill Powell
Played On: November 4th and 5th (1 hour 50 minutes)
Platform: Inform 6 (Zcode)
They call you Packrat, but who’re they sending to wake the Princess? Not only has the faraway Prince failed to deliver, but it’s just come out that a hefty royal loan has had twenty years to accrue in default, and the repo giants are on their way.
Bill Powell entered the IFComp last year with a two-part game (MANALIVE 1 and 2) that, despite many problems, I still enjoyed. I expected this year’s entry to be more fun, well-designed, and a good deal more polished.
It could be more fun, but some poorly-clued puzzles (maybe based on a faulty design philosophy) and a variety of quirks and bugs keep it from shining. In the built-in help, the author says:
“I’ve done my best to make it impossible for you to make the game unwinnable without knowing it, but any decent game will require a fair amount of browsing, searching, and generally non-intuitive actions, just for thoroughness.”
It’s the part about non-intuitive actions that seems misguided. To build a puzzle out of non-intuitive actions, the player has to be shown a problem begging for a solution. The player must see a challenge, and then be able to deduce the non-intuitive action based on clues he or she has already seen or can find elsewhere. It’s not enough to just hide a puzzle behind a non-intuitive action, because a player will almost never stumble on it if unaware the puzzle even exists.
This would be easiest to explain by spoiling the specific instance to which I refer, but I’ll do this with a hypothetical (though similar) example. Suppose the player finds a large carpet, among various other items, inside a house at the top of a mountain. Exploring the house seems to be the goal, although it’s necessary to traverse a mountain path with a steeply sloping side to get there. The carpet is unremarkable, and it even seems a little odd (maybe even a bug) that the player is allowed to pick up an item so large. The path outside with the sloping drop-off is equally unremarkable, except perhaps that it’s described as being too dangerous. If a persistent player keeps trying to go south (down off the path), it’s discouraged but eventually allowed with an unhappy ending. Now… suppose that there is something down there, out of view and in no way clued (but which the player needs to find), and the solution is to go back outside, drop the carpet, and ride it down the steep slope.
To make a puzzle like this work, the author should (a) mention that something interesting seems to be down there, (b) hint that the player would slip and fall if trying to walk down the steep slope, and © mention something when obtaining the carpet, perhaps to the effect that it looks thick and sturdy. I’m not even sure that’s enough, but it’s a start.
In another area (which I will spoil, because it’s not really a puzzle), a staircase leads up from an underground laundry into a scullery above. In the scullery, the staircase is mentioned, plus an exit to the east. If you examine the staircase, an unhelpful, snarky, theme-breaking message likens you to MacGyver but doesn’t also mention that the staircase goes up as well as back down into the laundry room. Because the exit isn’t mentioned anywhere, I never even tried going up.
Beyond this, it has numerous other problems. Disambiguation (especially in an area with many doors) seems to be an issue. Synonyms are lacking in many places (such as when the “rubble” is frequently referred to as “debris,” yet “debris” isn’t recognized as a noun). Many objects aren’t implemented at all, even in areas where there really isn’t much else to see but those one or two objects. When going west in the dungeon hallway, it’s impossible to return to the east (the same room just keeps popping up, as if “east” references the same room). You can pick up the cook and add him to your inventory. “Get all” cycles through pretty much every implemented object. Some objects can be referenced sometimes but not others (such as “get” by itself implying “(the finery)”, yet you can’t say “get finery” without an error). Certain messages are static, as though they were intended to be seen in a specific room but are actually visible elsewhere as well. Others simply describe the state of something even after it’s no longer true (trying to go south after defeating the dragon is an example). Some things in a room aren’t mentioned at all (such as the sink in the scullery, unless “cell” was a typo). You can even put the gargantuan cake inside Packrat’s pack.
It also has a game-halting bug which crashes WinFrotz (and possibly other interpreters – I didn’t check). This has to do with tying the rope to two things at once, and then trying to interact with it (to untie, tie to something else, pick up, etc). Actually, I’m foggy on the specifics, but it happened twice, leaving me gun-shy about using the rope in any manner not explicitly described in the walkthrough. It’s also possible to tie the rope to something, drop the thing, leave the room with the rope, roam the castle, and never drag the tied thing along. Yet technically it’s still tied to the object you left behind. It looks like the author only checks for that in the one instance where you’re supposed to tie the rope to an immobile object.
Most of these issues are obvious, and would be found by anybody poking around without going strictly by the walkthrough. It’s a shame that, unless I’ve missed my guess, nobody had an opportunity to test the game other than the author himself. It really shows a lack of polish, and that makes an otherwise nice little game difficult to enjoy.
The writing is fine. If there were problems, I overlooked them in light of the more pressing technical issues. The story is fine too, although the interesting “packrat” theme just seems to give a name to what’s already the typical adventure game hero mindset. It’s used in character-building and in some backstory bits, but it never really seemed to factor into the medieval fantasy fairy tale except as an explanation as to why (and maybe how) the protagonist picks up everything he encounters. It has an auto-purloin mode that I missed until I checked the walkthrough (because it requires doing something that seems completely counter-productive and repeatedly discouraged at the very beginning), but this seemed more annoying than useful. I reloaded a prior save and continued without it.
With more polish and better-clued puzzles, it would be a very short game. Without it, though, it’s all but unsolvable without the walkthrough. Since I’m judging the latter rather than the former, the most optimistic interpretation of my scoring criteria puts it at “X” – below average. For my review set, I’ve added a “minus” to that. That’s for the evident lack of testing and some needlessly obscure, unclued areas. I’m positive the author can do better than this. Much of the game hints at better things, but a lack of testing is Packrat’s downfall.