I sometimes add synonyms for regular verbs to be used in a single occurrence… and usually forget about it. I just hope nobody (except testers, maybe) will try and flush the doorbell. They usually don’t.
Sometimes I remember though: in Piccadilly, one can throw a coin (iirc) but the object must have the attribute “tossable” (sic) to give a head or tails.
@fredrik : I always wondered how one can end up with a double description (“there’s a coin on the floor. You can also see a coin”). I mean: are authors used to NOT reading back their own room descriptions?
Ps: Awakening was my first game. It’s big and sprawling and convoluted and you have to press a piece of soap onto a maze to replicate it so enuf said about quality — and yes, I coded it “on the go” while ideas popped out. I recommend NOBODY does this unless the game has three rooms. Or one, maybe. But, on the other side: I’d never have come up with the notion of a “Hyerotrope” if I didn’t do it like that, so YMMV. All the mythopoeia came from me writing a nonsense word as a room’s title.
One thing I’m currently paying a high price for is having ignored the possibility of segmenting my code into multiple files—in other words, with Inform, not having used from the very start the feature that allows to create extensions as a fundamental structural axis of development. Not just for all the gameplay mechanics, but for any cross-cutting aspect of the world model.
I thought I could avoid scope creep by laying down clear and categorical assumptions for the game universe. This is indeed necessary, but ultimately insufficient as the project grows larger. I’m now refactoring all of this and I can clearly see the flexibility it brings.
For example, consider a detective game set in a city, within a society organized into social castes—a game in which the character moves around using public transportation and can view billboard advertisements that are regularly updated. If I were to start programming such a game, the transport management system, the social caste structure, and the advertisement generation and rotation system would each benefit from having their own dedicated extension.
I am not sure what exactly you mean. Are you just putting grammar and entry point routines into separate files? Or do you also put content (that is items and rooms) inyo separate files?
I am considering the latter, as the .inf file is getting a bit unwieldy. The PC’s sister, Mia, has over 1,000 lines (granted, I am generous with lines to improve readability, for example giving curly brackets their own, individual lines) and the finished game is to have about 12 NPCs, most of similar size, 3 probably with more, so scrolling to different sections in the file is taking more and more time.
But I am not sure whether it is really a good idea.
Personally, I also use extensions to define NPCs and other objects. This allows me to standardize how they are constructed. Moreover, since on-the-fly object instantiation doesn’t seem to be possible with Inform, I have, for example, an extension for generating and recycling passersby, and another extension to catalog the kinds of objects for which I generate only the exact number of useful duplicates in the main program. In my case, I find this approach very appropriate because it allows me to apply specific versioning to each frequently modified extension and to document them—that is, to write directly in the extension what it contributes to the main program (as opposed to code comments, which I’ve found I can’t use effectively and have pretty much abandoned). This helps me stay organized and keep track of where I am in the process.
At a fundamental level, I imagine this is generally considered a good programming practice (though I am not a programmer). Even though I was aware of it, after reading Inform’s official manuals, I had the misleading impression that extensions were just an extra feature allowing you to benefit from the work of experienced programmers to add functionality to your project. That’s true, but it’s a very narrow view. I don’t really like using other people’s extensions—at least not without fully understanding them and adapting them to the needs of my story—but building my own (which are very simple and not technically ambitious), I can no longer do without.
I think that you ( @Deathworks ) are talking about Inform 6 and @Monsieur.HUT is talking about Inform 7, which have completely different ideas about project structure. Just in case you’re talking past each other without realising!
My apologies, you are right. I thought the topic was about Parser Game Programming in general, and since I’m not familiar with Inform 6, I seems that I wasn’t able to understand @Deathworks’ question.
This thread is meant to welcome any beginner’s mistakes for any parser programming - regardless of whether it is Inform, TADS, Quest, or whatever. You can post general issues, but also specific things that may pertain to certain configurations (trouble with implicit actions requires your setup yo include such actions, for instance).
And yes, I guess I failed to notice we talked about different versions of Inform.
But don’t let that stop you. If you think it is something a beginner in any parser environment could benefit from knowing before finding it out the hard way, go ahead and share it.
so, you can’t take the ladder until you have seen a tree you want to climb
I’m curious as to why you decided to implement this restriction, and how you phrase the refusal.
If you present a generic “You can’t take the ladder” type of message, I’d most likely assume that the ladder wasn’t usable in another location. If I then got stuck, read a clue, and found out that the ladder was actually the solution and the game was just arbitrarily preventing me from taking it because I hadn’t encountered the tree at the time, I’d be pretty angry.
On the other hand, if you present a message that explains why the game won’t let me take the ladder, that message will probably break my suspension of disbelief.
Maybe, but it seems like Chekhov’s gun — if a ladder exists in the game, it very likely has a use somewhere, so if my inventory allows it I’m going to pick it up and take it with me in the expectation that it will be useful soon. If it’s not going to be useful soon then the game is going to force backtracking later, which also tends to be annoying.
So stepping back, I’m not sure what purpose the limitation serves, as far as making the game better.
I could see making it cumbersome, so inventory limits would force the player to decide whether to carry it or keep hold of other items. Maybe it’s just a case of wanting something like that, but without having to implement an elaborate inventory capacity system.
There’s a polished implementation of that basic idea in the Inform 7 extension Bulky Items by Juhana Leinonen – the basic idea is that you can declare an item bulky, and that prevents you from carrying that item at the same time as you carry anything else, except for items that you declare insubstantial. (So you can declare, say, a paper clip as insubstantial, and it won’t prevent you from carrying the ladder you’ve declared bulky.)
