Stand = out?

Why not?

You can also form and express a judgement of Inform.
Criticism is a combat sport, and there is nothing more boring than complacency and blissful enthusiasm. Inform is a worthy opponent of this challenge.

Forget it.

3 Likes

I think Inform is a work of art – but still think it strange that STAND = OUT, even from a room.

2 Likes

I fully agree that Inform 6 is not perfect, and that STAND = OUT is weird. I can see that this stems from a compromise, making the world model simple enough to be easy to work with and also fit nicely within the constraints of the Z-machine version 3 (Yes, Inform 6 was designed to work with the z3 format). This is why an object can’t be both a supporter and a container, why player stances are not really considered and, in the end, why stand becomes a synonym of exit.

You can lose a lot of these simplifications by going to something like TADS3. And I’m just thinking that’s probably a much better choice for some authors. If you’re working with a tool you don’t like, and there’s a tool you’d probably like a lot more, how about switching to that tool and becoming a happier person?

3 Likes

…not to mention that every grammar and every source is customizable. You can simply replace routines in Inform 6 without changing the library at all. What I did: I created an optimized, advanced template for me, with all the stuff I want to have in / changed and this acts as a starting point for my adventures, just like Infocom did. You have all the right tools at hand to make yourself happy. Yes, some parser responses are weird but it’s easy to change anyway. And I believe that a parser is about understanding. So if a parser understands more than it should, that’s always fine. You can never be wrong with that. And there are scenarios where STAND may be an equivalent to EXIT, when you’re in a car for example.

2 Likes

Inform’s replace isn’t powerful as the TADS 2 one…

OTOH, that there’s strange decision in Inform 6 and its library, but for the compiler, I start to suspect that its origin as an assembler has some weight (looking at the proto-inform library and DejaVu’s source code is rather… interesting; indeed the long hunt for the lost pre-version 5 Inform was worthwile…)

on I5/6 library, I critique the READ = EXAMINE; in my ideal model world, examining a book is not the same as reading it (and I’m surprised of Graham’s model, he being an Oxonian academic, he should known well the difference…)

True that a book is not to be judged by its cover &c. but in my modest opinion, EXAMINE should give the description of the book in se, cover, spine, size, thickness, binding, and READ should give its content…

Best regards from Italy,
dott. Piergiorgio.

3 Likes

There’s a tricky balance between what works best for games in general and what makes sense in a specific game. Libraries have to think about the general case first.

For the READ/EXAMINE decision, you have to take into account that games include signs, notes, letters, and envelopes as well as books. It would be extremely irritating to type “X SIGN” and not be told what it said. So it makes sense for the library behavior to combine them, and allow games to make exceptions as desired.

(I would say that the same is true for SEARCH. It’s a historical anomaly that SEARCH is not combined with EXAMINE by default – a remnant of a design era that was really already over when Curses was written.)

Even for books, it’s a tossup whether the game is implemented at a level of detail where it makes sense for READ and EXAMINE to be separated. If you’re exploring the Bodleian library, sure. But not all games put that level of focus on books.

On the flip side, you can see some decisions of the I6 library that were consciously revisited in I7. The removal of SWIM, PRY, DIG, and so on is an example.

8 Likes

Partly agree, Zarf. On the sign I can agree, signs being usually intended to be read at glance. On letters and envelopes, examining an envelope should note things like colour, stamp, if sealed or open, and if open, what is its content. and on both, examining should note, for example, the graph (or typeset) ink colour.

Reading an envelope, this can be both realm of examine or reading, because usually on an envelope is written the sender (on back) and the receiver (on front)

Generally I assume that the adventurer hasn’t 40/20 (20/10) sight, like Chuck Yeager, and reading is a close range thing. My understanding of scope is that the player’s position re. thing on the location is… uh, abstract ? I mean, he can be near a desk or far from it, but when reading a note, the position is assumed to be near the desk. but for examining said note, is not necessarily nearby enough to read its content.

let’s visualize a bit:

in a study, X SOFA (that is, something not so nearby the desk), X DESK, X NOTE, READ IT you can visualize our PC looking to the desk from some distance, noticing that on it is a note, noticing, say, that there’s some writing and is roughly A5 in size, and moving nearby the desk, read what is writing on it.

Sorry for the long and winded (because I don’t handle english so well, being NOT my mothertongue…) explanation of my “design philosophy”, (or is a coreography ??) so to speak, and

Best regards from Italy,
dott. Piergiorgio.

1 Like

The question is still, is it better for the library to implement one action and let the author make it complicated (when desired), or for the library to implement two actions and let the author simplify them (when desired)? Nearly always, the first course is better for authors. It’s less to learn.

4 Likes

Why assume that people are unhappy with Inform? All posts on the thread are simply people not understanding why the library behaves a certain way. It would have been more productive if you just explain the rationale behind the decision, as other people have done. Or better yet, show coding example on how to override standard behavior.

I think people are happy with Inform, but the library is rather extensive and people need help navigating its features.

1 Like

I don’t. I was just reacting to Garry’s message.

Nope. Garry’s message “Grahame Nelson made some very, very strange decisions when he designed the Inform 6 library and I seem to spend most of my time undoing those strange decisions.” is not asking any questions, nor is it providing constructive criticism. And if you’re working with a library that (in your opinion) is so bad that you spend most of your time undoing everything that’s wrong with it, leaving less than half of your time to work on your game, I think you’ve found the wrong library for your needs.

I did.

I’d be happy to, but no one has requested it. I don’t think the OP even writes Inform code - it was just an interesting observation regarding a strange behaviour, made from a player’s point of view. This kind of discussion is useful and can lead to the library being improved.

2 Likes

As it happens, I did that the other day but deleted the post when I belatedly realised this is the Inform 6 category… I’ve created a separate topic here: Override "STAND = OUT" in Inform 7.

2 Likes

I feel that this specific debate is now out from this (Inform 6) category and into General design discussion: I suggest to move this debate on actions there…

Best regards from Italy,
dott. Piergiorgio.

1 Like

Holy mackeral. How could such a simple statement get so distorted and taken out of context and turned around to mean something completely different? I just made the simple observation that Grahame made some very strange design decisions. He has admitted this himself at various times. I am not the first to say so. It comes up time and time again, both here and elsewhere and has done so for the last 20 or 30 years.

And now I’m accused of hating Inform 6, hating every other language out there, get told that I’m free to pick another toolset or write my own library.

Crikey, I just want to write adventures. I don’t want to spend all my time writing yet another language or yet another authoring tool or yet another compiler or yet another library.

For me, Inform 6 is my language of choice. We have a love/hate relationship, but I still use it. I’ve been using it for years and I know all its warts. I use it because of its popularity, its versatility and the fantastic range of z-code interpreters out there that support just about every platform you can think of. Why would I change?

It doesn’t alter the fact that I seem to spend an inordinate amount of time customising the existing grammar for each game and writing custom actions to work around the strange design decisions that I alluded to. I’m sure every author does the same thing.

4 Likes

I don’t believe he thinks it’s bad, just behaves differently than expected. As Zarf said, this is intentional because it’s easier to expand library functions than restricting it. Fixing standard library behavior is “working on your game” so I don’t see why you have that negative POV. At least, you seem to push people away from Inform unnecessarily.

2 Likes

Yep. Me, too. That’s normal behavior.

1 Like

—Wondering whatever happened to that little balloon he let fly about something funny and quirky he saw in a fun game he was playing, Rovarsson decides to go and look where it may have flown off to.—

----After poking his head above the hillridge, he slinks off again, surprised at the amount of hubbub caused by his little fun balloon.----

5 Likes

Mah. I don’t critique or hate I6 or Graham Nelson, I only give my philosophical, so to speak, approach on IF.

Elsewhere I pointed on strengths and weakness of the various languages and libraries. this descend from my coding philosophy: first I determine the best language for the problem, then code in that language.

if the design needs NPCs, TADS3 is the best language, if needs unusual parsing, ALAN, if has a “theatrical” narrative flow, Inform 7, And so on… In this context, Inform 6 (and 5) is the “C language”; if I don’t need some specific forte of some other IF language, Inform 6, even 5, is the best one.

so, I can’t be harsh on Nelson on his choice as no one should be harsh on Kernigan and Ritchie…

hope to have clarified again, and
Best regards from Italy,
dott. Piergiorgio.

3 Likes

That reminds me of how I thought that creating a minimalist I7 implementation of every word in the XKCD ten hundred most commonly used words would be an interesting exercise and possibly even be a valuable basis for a library for producing more lifelike games.

Then I looked at the word list and realized it would would have been a surprisingly large amount of work and wouldn’t be all that useful for authors anyway.

1 Like

Nathan, Zarf happens to have collated what one can term a minimal but effective set of parser verbs in his “IF cheat sheet” (actually, a generic IF quick reference sheet…)

I think that a minimalist but effective parser dictionary ought to implement all the verbs in said two-page quick reference sheet…

Best regards from Italy,
dott. Piergiorgio.

Oh, I disagree entirely! That card is intended as a set of examples of verbs that might work in some game.

(We’re looking at http://pr-if.org/doc/play-if-card/ here.)

The upper section (EXAMINE, TAKE, DROP, OPEN, PUT, PUSH, PULL, TURN, FEEL) could reasonably be taken as a minimal verb set for a parser. But the lower section is not minimal at all. In fact it includes several verbs that are not in the I7 standard rules.

Part of the process of becoming familiar with IF is understanding what verbs are implied by the scenario, and trying them. The card is an attempt to spur your imagination in that regard.

6 Likes