inform 7 practice exercises?

I was just wondering if there exists resource(s) for practice exercises for I7. Something along the lines of “Create a room with multiple instances of a rock kind” or something. I don’t really know what I’m asking for, now that I think about it. Maybe something like or or, where they teach you a concept, then try to test you with a problem or two based on the concept taught while still incorporating past concepts.

I am sort of trying to do this as I read through the sections of the documentation manual, but it’s been difficult trying to come up with my own practice problems to test my understanding.

1 Like

Dunno if this is along the lines of what you’re looking for, but there were a few coding tasks on the forum a few years ago… they might be more involved than what you’re looking for, though.

The Recipe Book is pretty much this, although it’s more in the form of “How would we implement a money system with coins?” and then an example.

If you are learning mainly from the official manual, you might be able to use some of the unofficial tutorials (like this for practice. I.e. for a given task in one of the tutorials, you could try doing it yourself before you look at the tutorial’s explanation and sample code, and see how your result compares.

For me, the practice exercises for the last decade have been as follows:
(1) attempt to do something seemingly simple. Get incomprehensible compilation or runtime error.
(2) Fix spacing and punctuation issues. (Inform really cares about those blank lines and periods.)
(3) Rename all identifiers with underscores to spot identifier mismatching issues.
(4) Search Mantis for bug reports.
(5) Google for obscure forum comments about undocumented limitations.
(6) Search through the plaintext copy of manual for relevant comment (since it’s poorly organized, the headings are not helpful). Curse at the developers for not releasing a reference manual.
(7) Read through Standard Rules trying to understand what went wrong.
(8) Read through I6T template code to figure how what is going on “under the hood” which is breaking my code
(9) Search other people’s games for similar source text.
(10) Curse at the developers for not releasing the source code to ni. Diassemble it to get at the strings.
(11) Devise small test cases to test various theories for what’s going wrong.
(12) Beat at them until they compile.
(13) Write documentation or develop extension to fix problem for other people.
(14) Lack the energy to publish it. (I’m finally getting expert enough to start avoiding step 14. :wink:

Through this procedure, you will get enough practice exercises, though you may not develop a game for the next 20 years. :mrgreen:

More seriously, you make a good point, and if I manage to write my own manual for Inform 7, I might include exercises testing the concepts. It would make particular sense in the format I’m thinking, which would be focused on the high-level conceptual structure.

My question, neroden, is what the absolute heck are you trying to make Inform 7 do, exactly? It’s an engine for text adventures aimed toward authors rather than code-bashers, and though I’ve had frustration with it, only on rare occasion has it ever required fourteen steps plus I6 tinkering to solve.

If you’re not going to meet it halfway, instead of forcing your square shape through a round hole, with all due respect, perhaps you should consider TADS or another more code-structured platform.

The answer, in short, is that I’m super picky about exact inputs accepted and exact output produced, and I like designing complicated behavior. And Inform is far more capable than TADS.

I actually love Inform 7. It really is an excellent and powerful language. The developers have created something with truly exceptional power… The rules system and the text substitution system are both swimmingly wonderful. I liked Inform 6 a lot, but I want to use the amazing rulebook system. I love the ability to have whitespace in identifiers, which I think is a very wise decision for a genre which requires a lot of identifiers.

Inform 7 is very much a language suited to code-bashers. At least for those of us who like elegant declarative programming. The artificial division between “authors” and “code-bashers” is somewhere between stereotyping and condescension. The conceit that Inform 7 is “natural language” is nothing more than a conceit, however. To quote Dannii Willis: “Inform 7 is a very easy language to read, but not to write. It arguably strongly violates the principle of least surprise by being far from transparent about which natural English constructions it will understand.”

What I don’t love is the severe lack of documentation, and it caused me to give up twice when my life got busy. It’s frustrating to have such a powerful language, which is so well suited to its genre, be so poorly documented, and it is poorly documented specifically in the way Dannii Willis describes: there’s no good reference for what constructions are accepted, and often not for what they do, either. The best semantic reference is in the I6T files, and the best syntactic reference is in the Standard Rules, which is why I keep ending up reading them.

Most of the stuff I try to do can actually be done in one-liners in Inform 7, once I figure out what the line is, and I have to love a language which makes that possible.
I haven’t been able to write my own manual yet but I have a draft in progress.

Of course I hit something very hard on my very first attempt, namely accepting multiple pronouns (“him” and “her”) for one character. Solved now.

One thing about this:

Have you used the General Index and the search box in the upper right corner of the IDE? I use these more often than the headings, when I don’t know what I’m looking for.

Only if you infer there is no overlap in the Venn diagram of authors vs coders.

Inform 7 has an odd learning curve. It goes “Wow this is easy - Good heavens, why is this so complicated and hard? - Oh, I can make it do anything.”

Thanks for the suggestion. That is very similar to searching the plaintext copy of the manual. However, it has one downside: the window closes up and goes away when the IDE crashes. The Linux IDE has a nasty habit of crashing about 1 out of every 10 times when I hit run. (It’s a known bug reported in Mantis, but I haven’t quite had the heart to attempt to download and build it from scratch and start debugging it, especially since I don’t know GDK. For me, patching the Inform libaries is one thing, but debugging the interface between the IDE and the OS is one step too far away from actually trying to write games.) As a result I’ve been keeping the manuals in another window.

Hanon – you’re so right about the learning curve. I spotted the “I can do anything!!!” aspect early, which is why I’ve been so interested in Inform 7, and then I spent a very long time trying to figure out how. I am hopefully that I will eventually be able to write documentation which will be useable by others.

Well, that was kind of my point. The attempt to target it at “authors” should not make it more difficult for coders, because they’re often the same person. Writing the manuals with a condescending and misleading “Don’t worry about coding, it’s all natural language” attitude was harmful. Renaming standard programming concepts (like replacing “type” with “kind”) was gratuitous.

Sorry, this is getting way off topic. :frowning: It’s been an irritation to me for a decade. I’ve been developing a mental outline of how a manual for Inform 7 should go (first, explain declarative programming and Inform’s strange syntax with periods and blank lines; next, explain identifiers with spaces in them and the issues that creates; then explain the kind/type hierarchy; then explain event-driven programming and rulebooks; only after that explain procedural programming and phrases/subroutines; give absolutely explicit syntax for everything) – if you have the right structure, it becomes clear how to set practice exercises for each major concept. Without this structure, it’s not even clear (until you’ve dug very deep into the system) what the major concepts actually are, which makes it hard to set practice exercises for them. for a static link.

As for the off-topic argument, I have the strong feeling that if you write your I7 manual you’ll wind up with the perfect I7 manual for you. This would be great to add to the collection, but it won’t be more generally usable than Graham’s or Aaron Reed’s. (EDIT: And Ron Newcomb’s, and…?)

You know, I never found that before. Thanks. Sigh

It is my assertion that the problematic learning curve for Inform 7 is not inherent to the language, and is in fact caused entirely by the weak state of the manuals, specifically the lack of a manual structured as a reference manual.

The standard learning curve for computer programming languages goes:
– learn from “intro manual”
– as you get more advanced, switch to looking stuff up in “reference manual”
– finally, get to the point where you don’t need a manual and can learn from looking at other people’s code

Step 2 is not possible for Inform 7 right now which is what causes the blockage in the learning curve.

This is, of course, also the standard learning curve for human languages.
– learn from class or intro book
– as you get more advanced, learn the formal rules of grammar and look up vocabulary in dictionaries
– finally, get to the point where you just learn by reading books

It becomes much harder if there are no dictionaries and no grammar books.

Another manual would be great! But I do think that you’ll get a better reception if you don’t spend as much time attacking the existing manuals. A lot of the things you’ve cited as problematic are things that helped me learn–the periods and blank lines to delimit code instead of weird punctuation, the multi-word identifiers instead of goofball underscores and CamelCase things (which is important to having object names displaying correctly without extra commands), the fact that it starts off telling you some stuff you can do instead of making me read terms like “event-driven programming” in your face from the beginning–all that helped me learn the language by gradually working through the manual. As opposed to my standard learning curve for programming languages like Javascript and Ruby, which is Read intro manual–>intro manual is a bunch of crashingly obvious stuff mixed with stuff that makes no sense and after three chapters manual hasn’t taught me how to do anything that the language is designed to do, as opposed to “99 Bottles of Beer” stuff that’s better suited to BASIC–>forget it.

Which is just a question of my style! Your style is different, and that’s fine, and having a reference manual would be extra fine. Just, there’s no particular

Also, part of the reason for the learning curve you encountered is that you did something that required messing with parser internals, which have been described as a “spring-loaded can of worms and razor wire.” If you can do some documentation that makes that easier, my hat will be off, and I’m not wearing a hat.

One thing I learned over time…you actually can simulate nearly anything with words. Sometimes it takes some abstract planning and creativity to do so. In some cases, it’s easier and preferred by the reader to cutscene something instead of make it interactive. I always use a the brushing-your-teeth metaphor: is it fun to implement a toothbrush with bristles that are a supporter for measured amounts of toothpaste, then verbs BRUSH UP, BRUSH DOWN, BRUSH LEFT, BRUSH RIGHT, SPIT, for the player? Or does it save time and hassle to just add in a conditional paragraph; “You glance in the mirror and realize you need to brush your teeth. Okay, that’s done!”

One thing I learned early on is to love ‘Use unabbreviated object names.’ Relations are one of those things that look great in theory, but when it comes to implementing you’re usually better off with a list based approach (sadly). The thing I dislike most about the documentation is how the special syntax for extensions isn’t really mentioned, you have to learn from examples.

Ron Newcomb’s manual was mentioned but I don’t think it was linked. A HTML copy can be found here, and while it is a few versions out of date it’s still an invaluable reference.

Yes, that’s good if you have namespace clashes! For readers, that forces the source code text to refer to objects by their full names, which takes care of any possible confusion between the “big rock” and the “rock.” (But if you have an object called the “big rock” and no object called the “rock,” it won’t let you refer to it as the rock.)

What do you mean exactly? I’ve found relations pretty useful, but different people have different styles of programming.

Which special syntax do you mean?

Yes it is! I think I linked the PDF version in another thread, but if you’re coming from a more programmery perspective it’s definitely a good resource (and I had forgotten about the HTML version, so thanks for linking it).

It also forces me to think of good non-ambiguous names for the things in my story.

Relations work very well for smaller subsets, but it scales geometrically with number of possible references. When you’re dealing with clothing and body parts, you can easily have about 10 parts per related to about 5 pieces of clothing per actor. For 10 actors you then have 100 * 50 possible relations, which actually starts putting a dent in performance.

Most of it is documented (now atleast), but the *: syntax for getting the copy code button isn’t mentioned.

Oh yeah, many-many relations can clobber performance if your game gets big.

Right, the syntax for writing extensions–I had to learn that one by example too. Also you can’t put comments in your extension examples the way they do in the manuals.