Conditions After Periods Equal New Lines!

February 25, 2011 at 5:49 am (IF design, Inform 7) (, , , , , )

Yet another bad design decision, courtesy of the modern artists over at I7:

You are one ugly dude. [if DirtyHands is true] Your hands are dirty.[end if][if WetHands is true] Your hands still smell like pomegranate.[end if][if BathCat is true]Your hands are scarred due to misadventures in cat-bathing.[end if]

Instead of one status paragraph, the above code produces one paragraph for each condition that is true. This doesn’t make sense, as nothing in the paragraph clues you in that the language will behave like this. I filed a bug on this and it was rejected because “It’s been that way since the beginning.”

It doesn’t matter what GAMES will be broken; it matters whether this makes the LANGUAGE more consistent, more English-like, and easier to learn. How many revisions of Inform have broken games, anyways? Just about every other one, right? Yet this won’t be fixed. *facepalm*

Inform 7 itself has become a grande example of how NOT to design a language; either you live up to your goal of making code that reads like English, or you design yet another halfbreed language that requires users to learn specifics instead of principles. This all feels like I voted for “hope and change” and got $4.00/gal for gas, 10% unemployment, a crushing debt, union violence, and my health care in the hands of government.

Anyways, this is a bad decision because:

  1. The functionality is invisible. Nothing in the code informs the author that a line break is included after each sentence.
  2. The functionality is illogical. Why does a period indicate a new paragraph? It doesn’t in English, and yet Inform 7 claims to generate code that reads like English.
  3. The workaround makes no sense. The answer is to put a period in the next part of the condition instead of the first part, yet why would anyone naturally do that? It’s silly to have to break up complete sentences because the Inform 7 preprocessor will automatically throw in line breaks if you don’t! Again, the author is forced to know the particularities of the preprocessor in order to write the game. So much for that Natural Language Programming thing, I guess.

Again, Inform 7 is like natural language, only when it isn’t. I can’t wait to get done with New Cat so that I can turn my back on this mess once and for all.

Permalink Leave a Comment

More Bad Design Decisions (Named Actions)

February 6, 2011 at 7:18 am (IF design, Inform 7) (, , , , )

I7 strikes again.

Instead of doing anything except kwhirling’ (source text, line 1795), which seems to introduce a rule taking effect only if the action is ‘doing anything except kwhirling’. But that did not make sense as a description of an action. This looks like a list of actions to avoid: ‘kwhirling’ only made sense as a named kind of action, which can be used on its own but not in an action list; so I am unable to place this rule into any rulebook.

This code will produce the above error:

Smelling the tree is kwhirling.
Climbing the tree is kwhirling.

Instead of doing anything except kwhirling:

The problem here is yet another bad design decision, specifically, inconsistent design. All actions can be placed in an action list except named actions, which forces the user to remember that there are multiple kinds of actions and furthermore, to remember that some can be used in some places, and others in other places.

Sigh. The I7 designers really need to learn a thing or two about being consistent.

Permalink Leave a Comment

Bitten By Bad Design Decisions (Backdrops)

January 16, 2011 at 11:44 pm (IF design, Inform 7) (, , , , )

You know, sometimes programming sucks, especially when you’re at the mercy of other people who use English like silly putty.

Recently, I decided to use backdrops in Inform 7. I went and read the docs (3.9). Ok, all was well and good. I had a statement like this:

Carpet is a backdrop in Urinal Mint City, Defecatory, and Turdopolis.

Defecatory is a room.

Etc…

When I compiled and ran the game, the first room turned out to be Urinal Mint City! I was stunned, and it chewed up probably an hour of my life figuring out what had gone wrong. So, I opened a ticket. In return, I get this.

Yes, I feel that the documentation is inadequate. That’s mostly because the DOCUMENTATION SAYS NOTHING AT ALL ABOUT LISTING A ROOM IN A BACKDROP DETERMINING WHERE PLAY BEGINS.

The problem here is that Inform7 attempts to use natural language — only when it doesn’t. So you have a freshly-minted newbie trundling along only to hit a pothole; he says, “huh?” and extricates himself. Then it happens again, and again, and again. Or, you have the case of a programmer who is trying to make the switch to a psuedo-NL construct and finds that he really can’t trust anything he reads or types.

Specifically, to say that listing an item in a list “defines” a room is so foreign to me and probably most other people that I’m speechless. What sort of definition does it give to an item? None! It says that backdrop is in that, but what that is, is wholly unknown. Even if you wanted to say “From the compiler’s perspective, it indicates that the items are rooms and that they exist”, that’s fine — except that there’s no defining of the room in English! It’s a forward reference people! That’s all! It’s no definition! And anyway, why is being listed in a backdrop, from a human-understanding perspective, saying “This is where play begins”? No-one would ever deduce that by looking at it, and I thought the goal of Inform7 was to make readable code? The website definitely implies it!

The problem here is that instead of making a design decision that makes sense — listing items in a backdrop will place them into a backdrop — and leaving it at that, I7 has decided this: “The writer must know that placing rooms in a backdrop will tell the language that the rooms are being defined, and thus, that game will start in the first room listed.” This forces the writer to understand what’s going on in the compiler, which means that the entire abstraction of Inform7 has been discarded.

Now we have to be aware of what the compiler is doing when we write code. Lovely. If we’re going to do that, why don’t we just use Inform 6? This whole ping-ponging back and forth is so tiresome. Just when I think I’ve got my game done, I’ve discovered another shortcoming of Inform7, and worse, when discovered, I get some holier-than-thou blowback about it “being by design”. Why don’t the people at I7 just admit that they don’t have a consistent design philosophy except that the language is assembled by whim?

I don’t mind learning a new paradigm, but when the paradigm is just what a handful of people have decided to do, then learning it is impossible, because there is no regularity.

Permalink Leave a Comment

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: