The Limits of Wandering

The Limits of Wandering

All right, so, I’ve come up with an idea for the game I want to write in Wander, and I’ve started coding it. (I don’t have the entire game and all its puzzles planned, but I have enough to get started.) Working title: “The Eye in the Forest”. I’m… actually afraid some of the puzzles might be a little too tough. There’s one especially near the endgame that requires some use of different mathematical bases… then again, while they may be difficult, I don’t think any of the puzzles are actually unfair, and I like the way they fit together enough to go with it… what the hey.

So now that I’m working with the language, what do I think of it so far? Well, like I said in the last post, I actually kind of like the quirky syntax of the fields. It takes a little getting used to, but once I got the hang of it it’s kind of fun. That’s not to say this would be my first choice of a language to write a text adventure in, of course, because it has some pretty significant limitations. So let’s talk about that a little.

First, let’s deal with the obvious quantitative limitations. These are hard-coded in the interpreter (and so can in principle be raised, but it would require recompiling the interpreter program). I’ve already mentioned one of them: there is a limit of 100 variables available for use, not counting reserved variables. That’s… not really that many, considering that, for instance, while the rooms have states, the objects don’t, so anything that might change about an object would have to be encoded in a variable. It’s tempting to try to figure out a way to use one variable for multiple things, but that’s not as simple as it sounds. It would be simple, if the system supported bitwise operators so you could use a given bit in a variable as a flag (like the interpreter itself does for the third flag on object definitions), but it doesn’t, and while there would be ways to get around that and still extract bits through other operations, given that there are also limits on fields and actions that may end up costing more than it benefits.

I mentioned the limits on fields and actions, so I may as well touch on those. First of all, each action can have up to eight fields. That means if there are more than eight conditions that have to be tested… well, again, there are ways around that, maybe testing seven of them and setting a temporary variable, then testing that variable along with the other conditions, but of course that eats up a variable, which as I’ve already said are in short supply. One variable may not be a dealbreaker, but then making sure the variable is reusable would eat up actions, as well. And what are the limits on actions? Well, each location can have up to sixty-four actions, which seems reasonable. But the limit on the global and pre- and post-actions seems like it may become an issue… a game can’t have more than thirty-two pre-actions and a hundred post actions. Hm.

On the other hand, the limit on locations is bigger… a game can have up to 1024 locations. (Though only 768 specific location/state combinations with their own entries.) So if I don’t need that many locations (which I’m sure I won’t), I may be able to use the extra locations to get around some of the other limitations. For instance, I can use the state of an otherwise unused location as an extra variable. Actually, since each location also has a count of number of times visited that can be set and checked manually, I can use that as another variable, too, and get two variables out of each location. It may actually be possible to use the locations to effectively get extra global actions, too, by invisibly shunting the player to a location to run the actions there and then returning the player to the previous location. I’m not totally sure that would work well, though, because I’m not sure just how invisibly the player can be moved, and if there’s a way to suppress duplicate location descriptions… and in any case that seems really hacky and I don’t think I’d like to do that unless I absolutely have to. I want to try to stay within the spirit of the system… though thirty-two pre- and a hundred post-actions really is potentially a pretty harsh limitation.

As far as non-qualitative limitations, things I wish the Wander language had that it doesn’t, well, let’s see; offhand here are some things that come to mind:

  • Subroutines. This is a big one. Again, there might be a way to emulate this by shunting the player temporarily to a different location, but I’m not sure; I’d have to experiment.
  • Bitwise operators. I’ve already mentioned that. Not a big deal, especially if some of the limitations were lifted a little, but it would be nice.
  • Objects having a state, like locations. For that matter, it would be nice if both objects and locations could have extra properties that could be set for them, but that’s maybe going a little too far from what Wander is.

Even with those limitations, I think I’ll be able to create a decent game with the language; many of the complaints I’ve seen about the Wander games are issues of implementation (missing verbs and synonyms) rather than of the system. But there’s one quantitative limit I haven’t mentioned yet. The maximum number of words in a Wander game is 768.

Okay, that seems like it’s not a big deal; unless I’m making a really enormous game, do I really need over seven hundred words? Well, no… but I do need over a hundred, and I’m not getting them. In practice for some reason the limit seems to be a lot smaller than that. I wrote quite a lot of code before I tried actually running it, and once I did (and fixed a few bugs), I found to my dismay that not all the words in my word definitions were being recognized… and I don’t have nearly 768 of them. Had I accidentally defined some verb twice? I had, as it turns out, but that wasn’t the problem. Wander can deal with that. I did some experimentation to figure out what was going on, and… honestly, at this point, I’m still at kind of a loss. First of all, it’s only synonyms that are problematic. The game will recognize as many words as I want that have their first flag set to zero (indicating they’re new words and not synonyms of the preceding word)—up to presumably that 768-word limit, but I’m nowhere near that—but past a certain point it stops recognizing synonyms. But I don’t know why. The number of words it recognizes isn’t a power of two, which would at least halfway make some sort of sense. And some other things I’ve tried to pin down the problem have been unilluminating. If I just have one “root” word, I can give it as many synonyms as I want and it recognizes them all. If I just have “root” words and no synonyms, there’s no limit (again, presumably short of that 768) to how many it will recognize. But once I start mixing root words and synonyms, it doesn’t seem to matter what pattern I try to put them in. I can give each word one synonym; I can give the first word one, the second two, and so on, but past a certain point the synonyms stop being recognized.

Well. I think I’m going to resort to something I’d been considering anyway. I’m going to translate the Wander program code into Javascript and make an online interpreter. (Again, there’s supposedly an online interpreter already, but I could never get it to work. Wait—that’s odd; it wouldn’t work on my laptop, but it just did on my cell phone. Oh, well; it looks like it’s only set up to run the existing games, so it wouldn’t help me anyway.) This is something I knew I was going to have to do anyway for some of the upcoming games on my list; for the 1980 system Six/Fant the language spec is available, and some game code, but there doesn’t seem to be any existing interpreter, so I’ll have to implement one myself… and even before that for 1978 TSAL there’s a conversion utility to convert TSAL programs to Inform, but no interpreters, per se, so I’ll have to implement one for that too. So I guess this can be considered sort of a practice run, in that regard? Plus, there’s the advantage that if I’m going to be reimplementing the interpreter, I can change those hard-coded limits and won’t have such a severe restriction on actions and whatnot.

Just for the heck of it, I think I’ll end this post with the first room description. Make of it what you will.

This area is dominated by an enormous tree, rising far into the sky above.  The bottom of
the tree is coated by a soft, spongy moss, which also thickly covers the ground around the tree
to a large radius.  Where not covered by moss, the tree's bark is rough and knobbly.

Bizarrely, about eight feet above the ground on the north side of the tree
is an enormous eye, which disquietingly seems to remain fixed in your direction, as if it's
watching you.
Spread the love

One thought on “The Limits of Wandering

Leave a Reply

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