I’ve been wondering about the state of the I7 manual. I don’t find it terrible (apparently, some do); I find it quite useful for reference. I’ve noticed, however, that out of all Inform-related posts, the ones I love the most are posts that demonstrate simple techniques with a broad range of application. The specific examples demonstrated in the manual are in no way bad, but its perspective is aimless to my mind. Quite often when I read them, I find myself distracted by the presence of an unrelated (and unfamiliar) use of rules or phrase structure that I didn’t know could be done.
But I digress. One of the things I like, as I said, are the small techniques. I’d love it if we could have a thread or two in which we simply posted all those small tricks that we keep going back to. It’s daunting, though, because half of the members seem to be inordinately skilled at I7, making me fear accidentally revealing my own ineptitude. But since I proposed it, I’ll start.
This is a simple way to convert the names of things into proper title case (applied in this case to rooms). In other words, you can declare
The dark side of the Force is a room.
and (assuming it compiles and you’ve given it a definite article), it should display as “The Dark Side of the Force” in-game.
To say (term - indexed text) title-capitalized:
Let Line be indexed text;
Let Line be "[term in title case]";
Let Prepositions be a list of indexed text;
Let Prepositions be { "the", "of", "in", "and", "or", "for", "at", "by" };
Repeat with exp running through Prepositions:
replace the text "[exp in title case]" in Line with "[exp]";
Let First-word be word number one in Line;
Replace word number one in Line with "[First-word in title case]";
Say "[line]".
Rule for printing the name of a room (called the place):
say "[printed name of the place title-capitalized]" instead.
Anyone else have some nifty shortcuts they might want to share?
I always capitalise & write the room names in the code exactly as they’d appear in prose, for the purposes of listing exits as prose which I like to do rather than the unhelpful “You can’t go that way.”
Oh, and I use this a lot:
To decide which number is the chosen row: (- ct_1 -).
Damn. low whistle Phonatacid, after reading it through a while I can see how useful that code is (and Ron’s too, but his was short enough for my reptilian brain to grasp in one go). Neophyte as I am, however, I still don’t quite see what’s meant by the “decide on” statement.
Eleas’s example can be made tinier by omitting the line “let Prepositions be a list of indexed text”; it’s fine for this to be a list of ordinary text.
The purpose of the last “decide on” statement is to return the object passed as argument. If it weren’t here, either the compiler would trigger an error (“it seems this phrase should return a value, but I can’t find the appropriate decide on statement”) or would return 0;
But this kind of phrase:
is possible because object are passed as references. In other words the object that is treated by a routine is the same as the object treated by a subroutine of this routine.
It’s not the same with block values (lists and indexed texts mainly) : those are copied before being passed to a routine/phrase. Thus
wouldn’t work : it’d produce “abc”, not “test”.
As for the second trick, it’s just a way to cast an arithmetic value to another arithmetic value. I think i’m only using it for casting number values (lengths, times, etc…) to numbers. But it can be dangerous ; Let’s consider you have a short time value specified by “1’0” ([second]'[decisecond]):
wouldn’t produce 00:01 as one would expect it. Actually 60’0 translates into I6 as a number -600- and 00:01 translates as 1. Consequently your 60 seconds (=600 deciseconds) would turn into 600 minutes. It’s really a low-level phrase, and i’m not really sure why i’m using it.
But i have quite a few other useful phrases that i wrote thinking “wth man ? why is this not in the standard rules ?”. They are dispersed throughout my I7 extension files, i might gather them one day, probably when I’m making the jump to 6F95 (i’m still waiting that jesse updates his Dynamic * extensions).
That dynamic property changing phrases should definitively be in the standard rules though.
This is a general comment, not specifically related to your example … your example is just a handy hook to hang it on.
It strikes me that a lot of the things people are trying to do with I7 are in the nature of programming tricks. They have little or nothing to do with storytelling. With your example, if you want a room called “The Dark Side of the Force”, why not just call it that and then move on?
The original conception or primary attraction of I7, it seems to me, was/is that it allows people who are not conversant with programming and don’t want to become conversant with programming to write interactive fiction. This is a laudable goal, and I7 accomplishes it in a fairly tidy way.
If you want to do tricks like putting ASCII animations on the screen in real time, creating huge collections of objects dynamically, performing floating-point calculations, or whatever – why are you using Inform 7? Why not use a more suitable language?
This is more or less a real question. I’m not asking it rhetorically. Why are people jumping up and down on I7’s pointed little head trying to make it do things other than provide a framework for telling stories?
I think I’ve always just divided by 1 unit to turn a Unit into a number. Although, knowing Inform, I wouldn’t trust it to optimize-away the div-by-1 in the assembly. Hrm.
On a related note, you can break things faster with this typecast:
To decide which K is the (mystery - a value) as a (name of kind of value K): (- {mystery} -).
Which’ll change anything into anything else. Granted, that might be going a bit overboard.
Just like i7 and the standard rules. They are just a programming language and a world model. There are very few things that directly deal with story-telling : description/printed name could be considered as defining a linguistic item. There is nothing in I7 that implements concepts from theories of narrativity, enonciation or interaction.
Actually, natural language processing is quite a high end technology. Stanford’s parser source code is more than 170,000 lines long. And it relies on statistical algorithms. Thus, it needs floating-point numbers and dynamic objects (probably huge collections). And ASCII animations are just so cool.
The problem of i7 is that it is a programming language and framework that allows you to write interactive fictions in the style of interactive fictions. It’s actually quite difficult to diverge from the idea of what IFs should look like according to i7 because of several limitations :
-lack of standard low-level phrases.
-lack of memory structures at the i6 level.
-glux is not powerful enough.
As I said, i7’s framework is limited to a certain idea of what IFs are and is absolutely not prepared to handle complex algorithms that would implement natural language parsing or complex conversational systems (like Façade).
I chose to develop with i7 because literate programming looked like it was more convenient (and it is). And i didn’t want to write my own IF system because of my lack of experience but also because i wanted to be part of a community : maybe i’ll never finish my project, but at least people’d be able to enjoy the few extensions I wrote.
Even though this is a general comment, I can only answer for my specific choice. In this particular case, I wasn’t going for programmatic trickery. Ever since reading an article by someone or other (can’t remember who), I kept wanting to write the room names without capitalization in my code (i.e. “The dank hovel is a room.”) and still get the proper casing effect in-game. IMO, other than being more particular, it’s not much different from the “say [text] in title case” phrase.
My idea in starting this thread was to promote sharing simple/basic ideas and functionality. This is why I split it up into two blocks: one generic text operation, and one rule for applying it where needed.
I see what you’re saying, but I wouldn’t couch the dilemma in those terms. True, no tool is perfect, and some effects could be considered garish and perhaps unnecessary. But to me, there’s no one way to present a story. If a system provides you with many options, is this such a bad thing?
Also, not all stories are equal. For one trivial example, I recall Robert Heinlein spending several weeks on a passage from one of his stories. I don’t remember the exact circumstances, the protagonists were travelling in a spaceship, and Heinlein wanted to get the numbers just right so as to improve realism. This would not be easily accomplished using integers.
(Floating point conversion in particular is useful in many different ways, and while I’m not looking to use them right now, I feel much happier knowing I have the option.)
Two reasons, I think. One, they already use I7 and want to see its limits. Two, they feel they actually need those effects in order to deliver their story more effectively.
This. I greatly enjoy I7, both for its unique perspective and its ease of use. This feeling of having somehow missed a vital clue on how to do things has frustrated me on many an occasion, however. I can’t make an honest attempt at a game without being able to trust the system to have my back, and that trust falters every time I have to jump through hoops to manage something seemingly trivial.
Then again, I don’t think poor documentation is necessarily the culprit (matter of fact, I’m not sure the manual is all that bad). Maybe it’s just that I7, in departing from a few regular coding conventions, attracts a much broader user base. If that’s the case, it would make sense that they have different ways of looking at Inform, and different needs.
I felt the official manual was an entertaining read. The main two problems I had with it are (1) there is not enough advantage to reading it sequentially (too many references to functions and syntax that have not yet been specified), and (2) too much reliance on the accompanying examples to do the heavy lifting on teaching core techniques. Especially since in the text file version, the examples are not printed with the chapters they are meant to illustrate; they all seem to be printed together instead. This makes searching for key concepts in the consolidated text file more annoying than it needs to be.
One text file, with new vocabulary as sequentially introduced as possible, so that almost no syntax is put into use (even in examples) unless it’s been defined earlier in that text file: that’s the setup that would work best with my usual assumptions about how to search a giant text file about a programming language.
To Jim: I’m sure there’s plenty of people trying to write works in Inform while avoiding all programming education possible. Still, when such an author finds themself off in the weeds, it’s nice to have just-for-the-sake-of-it people who can give direction. “Hey, I wove this cool basket out of those weeds, see? Oh, and you want to go that-a-way and turn left at the bonsai.”
Pulling this thread back on topic of cool things, how about an action applying to a stored action?
Still, when such an author finds themself off in the weeds, it’s nice to have just-for-the-sake-of-it people who can give direction. “Hey, I wove this cool basket out of those weeds, see? Oh, and you want to go that-a-way and turn left at the bonsai.”