Review – TextCraft: Alpha Island

Finally, after years of being harassed by the java updater, something that needs java to run!

This program wins my own personal Banana of Discord. On one hand, a tremendous amount of work has gone into its production and it goes the extra mile to get some things just right. On the other hand, I don’t think most people with play with it for more than a couple minutes.

The overall objective is neat: to give the player a toolkit and parts and see what they build. From the title, I infer that the player is supposed to build things from text objects in the same way that a Minecraft player creates items out of raw materials. Both games require exploration and combination of found items to produce novel things. In Minecraft, an individual player would have to discover what resources are needed to build new things (or hear about them from other players), but it should be even easier to figure out how to combine items described in text to achieve specific objectives.

When I fired up the game, I was pleased to see a number of play testers credited, and certainly having an ASCII artist as part of the game design team was icing on the cake. In addition to the game itself, the author has created a number of detailed resources including an online wiki. The wiki provides a walkthrough and explanation of the various solutions possible, and also goes into some detail regarding game background and design considerations.

[Some spoilers follow beyond this point]

The game opens with a recap that the main character has made a bet that s/he can survive alone on a desert island for a week using only the raw materials that can be found there. The player is then presented with a prompt and exploration commences.

At this point, I usually run through some typical commands to get oriented and see what sort of game this will be: about, help, hint, x me, i, and so on. When I started doing that, I noticed that regardless of what I was doing, the game was printing updates about the environment, thirst, and so on. I just sat back and watched as I slowly dehydrated in the tropical sun and died. I got a sinking feeling: this is not a turn-based game. Worse: it has daemons that I thought had been exorcised from adventure games decades ago. I understand why a survival game would have hunger and thirst counters, but the rate the clock ticks away made me feel like I was playing russian roulette with a chess clock. The game provides a command to view statistics like health, energy, food, and water, but considering how central they are to survival, I am surprised that the author did not put them in an always-visible status bar.

With the need to explore, try things, and fail, this timed-event approach means that the character will have to do a lot of dying to make even marginal progress in the game. That is simply not for me. If the point of the game is to be creative, I’d like time to do so. There is a pause command, which freezes time as well as a wait command that fast-forwards. I would have appreciated if the author made pause the default or provided some way to lock the game into that mode (perhaps a question at the start: does the player want to play with training wheels, turn-by-turn, or in slow, fast, or immediate death mode).

The parser in this game is not friendly, so players who have grown accustomed to feature-rich parsers will be frustrated with the limited scope and understanding of this one. Dealing with a balky interface is only exacerbated by the time pressure.

The parser does not implement a number of out of game verbs, such as undo and restart, and it only recognizes a small subset of the standard verbs. To make matters worse, some of the standard verbs are replaced by more generic verbs that are heavily overloaded and made specific by a helper preposition. For example: instead of “enter”, there is “go in”; instead of “climb”, there is “go up”. Maybe this strained circumlocution makes the grammar easier to handle computationally, but it forces the player to spend a lot of time trying to come up with just the right awkward sounding phrase that the parser requires.

The in-game help highlights a few additional commands tied to game’s central focus on making and using found items: “wield/unwield [a tool]”, “use”, and “craft”. The wield/unwield pair sounds like a carry over from equipping and unequipping a weapon in a combat-oriented RPG. In this game, it serves the purpose of replacing the phrase “with [a tool]”. I am not sure that is a true economy. Rather, I would argue that it would be more helpful to allow certain actions to take place implicitly if the appropriate tool is available and obviously useful without the playing having the specify the tool.

The syntax for the “craft” verb is particularly complex and subject to misunderstanding. Even in cases where players have the right idea of the sort of thing they want to craft, they might not guess the game’s word for that object. Since multiple source materials must be named in the same command and they are also subject to finicky naming, a command that is a combination of all these terms has very little chance of succeeding.

Finally, I have to rail against “use”. I have a hard time believing it makes the programmer’s job any easier, since it could mean so many things in so many contexts. For that matter, since any object could have many potential uses, how does a player communicate which use they have in mind?

I think the point here is clear: this parser is a train wreck, and bears out something that has been said many times in the past few decades: it is very difficult for one person to create a new general parser that performs up to people’s expectations. The ones that are in common use have evolved over a long time and with input from many talented folks. Of course it’s the author’s prerogative to develop their works in whatever system they want. Not trying new things would lead to stagnation, so new does not equal bad, but if an existing tool would have served, why reinvent the wheel?

I would be curious to hear (after the comp) from the play testers — how did all this get by them? Were they focusing only on proofing the text, but not game play? Did they raise these issues, but were ignored? Did the lack of facility to produce game transcripts impede feedback to the author?

Regardless of whatever happened in play testing, I anticipate that there will be plenty of feedback on this work during the comp. I think that the parser issues are “beyond economical repair”, so I don’t know what I would recommend if a post-comp revision of the game is planned. One consideration would be scrapping the current code entirely and bringing the concept and as much of the writing as possible over to something like Inform.

Evaluation

Story: 2

Voice: 2

Play: 2

Polish: 4

Technical: 8

JNSQ: 0

Preliminary Score: 3.6

 

Leave a Reply

Your email address will not be published. Required fields are marked *