I agree that it is worth the effort to make readable code. It’s easier to troubleshoot, easier to search and—this is important to me, too—easier to share with people.
I prefer using readable names for values. Using phrases, and writing rules individually.
You may prefer different things, but write code that’s easy for you to read. Inform 7 is very accommodating in this respect.
Also:
It’s worth trying to use the entire action processing sequence (before, instead, check, carry out, after, report). You can do a lot with instead, but that will hold you back later. Lots of threads on that here.
The reasoning for this is that most of the commands people type in your game (or any Inform game) are errors: trying to find exits, experimenting with actions, mistyping, getting things wrong. So the error responses are your game, in a sense. If you don’t change them, then the majority of your game sounds like Graham Nelson’s default voice (which can work, but usually doesn’t).
Another small point is that if you don’t put something at the end of a paragraph or on a separate line, people probably won’t notice it. Which is good if you’re hiding something, and bad if you want them to pay attention.
…they’re also even more impressive than I thought, because you’ve been testing without transcripts?
Ah - I have actually seen transcripts (at least for Mayor McFreeze - Gum E. Bear was written and tested in such a short space of time that I fear I’d lose all credibility if I owned up to that), but I believe my testers were simply copying and pasting manually.
Also, thank you so much for pointing out the source for Sting! It’s helpful to see this stuff commented up (even if it’s often quite self-explanatory in context). I see you’re using “understand” quite a bit more than I think I have been (particularly when it comes to verbs/actions rather than just nouns) and I wonder if that’s something I should be aiming for to avoid the “Guess how to express X” situation that I imagine is lowering IFComp ratings somewhat.
The reasoning for this is that most of the commands people type in your game (or any Inform game) are errors: trying to find exits, experimenting with actions, mistyping, getting things wrong. So the error responses are your game, in a sense.
Yes, this is a big chunk of the reason why this appeals to me for the Bubble Gumshoe games in particular. I went into the first one thinking that the slightly unconventional route to solving the mystery would be the main appeal and the sugar-noir setting would get a chuckle at best, but in practice the setting seems to be the main draw (and if anything I get the impression people responded better to more traditional puzzles anyway). I’d like to be able to make more of what doesn’t work in game terms still offer something appropriately sugar/noir themed.
If you are writing in Inform 7, there’s a really helpful extension called Object Response Tests by Juhana Leinonen that you can use when you are testing your game. You can use it to automatically test Inform’s built-in actions on all the objects in the area, for example, to make sure the responses all make sense.
You might find that you can save yourself some work by grouping some actions together. For example, pull, push, and turn are separate actions by default, but if there are no meaningful distinctions in your game between whether you pull, push, or turn something, you could, for instance, redirect two of those actions to the third.
There might be some actions you don’t use in your game at all, and you can save yourself some work by writing one response to deal with all attempts to use with that action, like “You don’t need to look under things in this game,” or disabling the action altogether (if it’s a less-commonly-used action, and removing it is unlikely to frustrate players).
You can make it so that all things in the game are either “far” or “near,” but “near” by default, so that you can easily write rules to deal with attempts to interact with “far” things. So instead of writing one rule to deal with the player trying to take the sky, and another rule dealing with the player trying to tie the dollar bill to the sun, you can write rules dealing with all “far” things, like
Before doing something when the second noun is far and the action requires a touchable second noun:
Say "[The second noun] [are] out of reach." instead.
When you are testing your game, in each location, try to interact with each noun that is mentioned in the room description. So if the room description mentions apple trees, a stream, flowing water, distant mountains, etc., type “x apple,” x “trees,” “x stream,” “x flowing water,” “x distant mountains” to make sure they are all understood. You don’t necessarily have to have separate responses for each thing–both “x apples” and “x trees” could lead to the same response about apples hanging from the trees–but the point is that the game should recognize every noun that’s mentioned in the text.
If you have a hard time getting a particular piece of code to work, and you finally get it to work, I suggest putting a comment on it to remind yourself why you did it that way. Otherwise, you might come back to it later, forgetting why you did it that way, and think to yourself, “Hmm, why don’t I just do it [way that doesn’t work] instead–that would be better!” and break it again.
I suggest trying to make responses to failed attempts helpful. For example, if a player tries something that makes sense, but is not quite right, it would be good to nudge the player in the right direction.
Extensions are the easiest way to slap up polish with little to no effort. I recommend perusing them and making note of any that may be of use.
Also, protip, if an extension hasn’t been updated but you still really want to use it, you don’t have to chase the extension author down or figure out how to fix it yourself. You can just roll your Inform version back to the last one that extension worked with. All the old versions are available for free download.
To this end, I often leave in, but comment out, code for failed attempts at doing something – along with additional comments describing why or in what way it didn’t work – to keep me from trying it again at a later date.
This is a really helpful response that gives a lot to go on - thanks! Some of this I’ve found myself doing already from time to time, but a more methodical approach (possibly involving some kind of spreadsheet) might go a long way towards making the world feel complete.
IMHO the best practice is exploiting to the hilt one of I7/10’s strong point, that is, the division in volumes, chapters, parts, etc. of the source code, whose allows easy organisation of the source, dispensing with the need of multiple files for large and very large files.
as working example, I could have posted the contents index of my current major WIP in inform 10 (whose sorely need some love, because I’m concentrating on the other major WIP, written in TADS3), for showing my source organisation in books, volumes &c. but for reasons known only to Lord Inform and/or the devs of the GUI, said index, can’t be cut’n pasted…
To make “exits” its own command, you’d add something like
Listing exits is an action out of world.
Understand "exits" as listing exits.
And where the “Bumping Into Walls” example says “Instead of going nowhere,” you would substitute “Report listing exits” or “Carry out listing exits” or something like that.
There’s certainly a lot of useful stuff here - I’ve already found an example of the volumes/chapters/etc. that @Piergiorgio_d_errico describes (and which I’ll definitely be using to break up my next game) - but is there any chance you’d be happy to pick out one or two things that you’d consider particularly useful to a relatively new author? That post itself is just shy of 3,000 words long, and it consists almost entirely of links to other resources: I’m most interested in finding out what key details/features someone well familiar with Inform7 might consider essential for any game, but a newcomer might simply not know to add.
This is a general programming rule: design for reuse. For instance, I needed a self-closing door, so I wrote one for my game. But wait - might I want that somewhere else? Okay, make self-closing doors a kind of door rather than a particular door. But maybe I want to have multiple kinds of doors, for instance one that self-closes from one side and is always locked on the other. Now we want to roll everything out of our game into a separate extension. Pretty soon you have your own collection of extensions that you can just slot in when you need them.
To this end, an Inform-specific code addition for giving players this functionality without it costing a turn can be found in §17.21. Understanding mistakes:
The Docs & Resources post is an imposing wall of text, but it’s worth looking through just so that when you’re struggling with something, it can ring a bell that something about that was one of the zillion things linked to.
I went through ALL the responses in Standard Rules. (The ones I didn’t change have comments. I catalogued them using RESPONSES 1, and inlcuded the then-current defaults in comments.)
This is a good catalog of responses you may want to change. The extension itself gets rid of the most “opinionated” responses from Core Inform, but I think it’s also useful as a template for figuring out where you want to put in your own opinionated responses. It also points out which ones are tricky and finicky (they needed extra coding).
In fact I wrote that extension largely as the baseline for another – still incomplete – extension, Compliant Characters, which exists solely to give parser error responses to commands like “John, take hat” when there is no hat available. I’m going to finish that one someday…
Oh, wow, thanks for sharing this! It’s a lot to work through (which I imagine is to be expected), but this should be a huge help in working out how to give my games a less default vibe.
