Browsed by
Tag: It Should Not Be

Wander: A Little Research

Wander: A Little Research

Okay, this is another post about the process of my creating a game with Wander that’s not really about Wander itself, so much as it is about an aspect of game creation independent of the system.  Honestly, I don’t know how much more I’ll have to say about Wander until I finish my game with it.  If I run into any other interesting aspects of the system that weren’t evident on first examination, I’ll certainly bring them up; otherwise I may just find other things to blog about as I continue working on the game.  I’d go ahead and mix in some posts on the next game in the list, except that I want to finish up with a year at a time, and Wander is the only game for its year.  I’ll certainly be mixing in some more posts on current game creation systems, including probably Super Tony Land—it turns out the editor will still sometimes load large levels; it’s just not reliable; and once it’s loaded I can keep editing it, so I may try to finish up the levels I was working on anyway.

Hm.  At this point I’m worried the preamble may end up being longer than the main topic the post was supposed to be about, so I’d better get to it.

Read More Read More

Pondering Puzzles

Pondering Puzzles

Okay, while in this post I’ll be talking about the games I’ve been creating in Wander, this post isn’t really about Wander specifically, but about text adventure games in general.  And more specifically, about puzzle design.

While planning out one of the games I was going to create with Wander, “The Eye in the Forest”, I kind of stumbled into a stupid trap of game design.  Fortunately, I think I stumbled back out of it.  I’d come up with a particular puzzle I was fond of, involving the player’s reaching a certain platform, but then later on it occurred to me that, given some of the available objects in the game and their possible interactions, there was another course of action that logically should also allow the player to get to the platform.  Of course, I already had a solution in mind for the puzzle, so I wrestled for some time with the question of how to rule out that unintended alternate solution. It wasn’t until the next day that the answer finally occurred to me, and when it did it was obvious:

Don’t.

Read More Read More

Many Unhappy Returns

Many Unhappy Returns

So, once I started reimplementing the Wander interpreter in Javascript, it quickly became obvious where that limitation on synonyms comes from that I mentioned in the post on the limits of the Wander language.  Basically, the interpreter stores each word as a structure (that in, in the C code, a struct) with four fields: one holding the word itself as a string, one holding an index to the “root word” of which it’s a synonym (or 0, if the word is a root word), one holding the flags described in the Wander language overview post, and one holding the location of the object referenced by that word.  (Naturally, these last two fields don’t apply to verbs.)  The problem is that in the C code the index to the root is of type char… which means it can only hold values from -128 to 127, which means, since the index is never negative, that only the first 128 words in the word definition list can have synonyms.  (In practice, that means the number of words that can have synonyms is a lot less than 128, because for all but the last the synonyms themselves also have to be among those first 128 words.)

Read More Read More