Give players a verb and they will use it! And it’s a place for some characterisation, such as:
>take galatea
Even if she were a manageable size, it would obviously be impossible to smuggle such a valuable piece out of the gallery. The sensors at the door would go off, even if (somehow) no one else noticed. Not to mention the trouble of trying to fence a unique and identifiable work.
Of course, you could just keep her in your living room. As a conversation piece.
>take Hubert
I lack the brute strength to lift such a large and ungainly figure.
>take alcaz
You extend your hand with the intention of seizing Alcaz, but he steps back, a surprised expression crossing his face. "Hold," he says, raising his hand in a placating gesture. "There's no need for such aggression. We are allies in this battle."
… but of course if you try to implement a response for every thing a player might think to type, you’ll be here until the heat death of the universe.
Yeah I already kinda expected I would have to rely on the standard library. For my One King to Loot them All game, I customized all verbs and responses, but that game took me months to write.
Although it would be nice to tweak things, e.g.:
> x me
You look like you're up for an adventure.
The default Inform 7 answer is:
As good-looking as ever.
And in One King, I tweaked that a bit to match the protagonist:
Your muscles ripple beneath your sun-tanned skin.
You are definitely as good-looking as ever.
>x man
Miyamoto Musashi is practicing his forms.
His movements are precise and unhurried,
each strike flowing into the next with quiet
inevitability.
In Miyamoto Musashi is a wooden sword.
Dang, getting the proper flags lined up and all is HARD.
It’s so frustrating watching you struggle and not being able to help! Even if I knew anything about ZIL I couldn’t, because I’m a judge. Hopefully @vaporware will have some advice for you soon!
This would seem to be an unfortunate case of ZILF’s standard library deviating from Infocom’s documented practices. Meretzky’s guide recommended giving people SEARCHBIT, but ZILF’s library doesn’t use SEARCHBIT. I believe TRANSBIT serves the same purpose of making their possessions accessible.
Similarly, ACTORBIT is what’s used in Zork, but ZILF’s library uses PERSONBIT instead. In this case, at least it does line up with Meretzky’s guide.
Historically, Infocom didn’t have a “standard library” for most of its existence. New games were made by copying the entire source code of older games, and features were occasionally ported between them inconsistently, with functions and flags renamed to suit the tastes of whoever worked on them (Sherlock was especially egregious, renaming just about everything). When it came time to write a standard library for ZILF, there was no one source of truth to base it on, and we ended up combining a few things from different eras, with some inferences about how they should work together.
To replace a standard library message, first find the message you want to change in libmsg-defaults.zil, where they’re organized by category and name. In this case, it’s EXAMINE PLAYER:
<DEFAULT-LIBRARY-MESSAGES EXAMINE
(PLAYER "You look like you're up for an adventure.")
(OPENABLE CT .OBJ " is " IFELSE .OPEN? "open" "closed" ".")
(DEFAULT "You see nothing special about " T .OBJ ".")>
Then, somewhere in your code after the <INSERT-FILE "parser">, use REPLACE-LIBRARY-MESSAGES with the same category and name:
<REPLACE-LIBRARY-MESSAGES EXAMINE
(PLAYER "That's difficult unless your eyes are prehensile.")>
The new definition is written in the same syntax you’d use with TELL, so it can use any of the existing TELL tokens, or you can define your own tokens if you need more complex logic to print the message. If the original message contained variable references like .OBJ, the new one must use the same names for them.
TRYTAKEBIT serves to stop the parser from implicitly taking something when the player uses it with a verb that requires it to be held. In other words, it dares the player to try taking it themselves. It’s used liberally in Zork, but it’s less necessary in ZILF, where the parser will only try to implicitly take things that have TAKEBIT in the first place.
I’ll forever be grateful to SeedComp! and Mathbrush for teaching me this early. Writing Red Door Yellow Door was the first time I really had to deal with NPCs in a parser game, and they were to be present and participating in decision-making the whole time! I couldn’t let them be static because as things got weird and dangerous any reasonable person would say “hey, we’re the ones doing this to ourselves. Let’s just stop astral projecting.” I even figured out how to make one of them opt out of the situation entirely, depending on dialogue and other choices the player made.
To be fair, not everything is needed. I write, I suspect, many more custom responses than is average in Inform, almost never relying on the standard built-in response set. The responses for the five senses, taking things, kissing things, and climbing things are all excellent ways to characterize how a PC interacts with nearly everything in their environment, and a lot of things give ample opportunity outside of that. I’ll also be sure to include looking behind/under things (even without extensions like Underside to make it possible to actually find anything there), thinking about things, and a couple other reasonable but non-standard actions for added flavor and to reward exploration. Will every or even any player see all of it? No! But most of them will see some of it, and it gives me space to explore and develop the character for the parts that all of them will see.
Experienced a motivational barrier. My artist cheered me up and started making a concept drawing for my game. My, oh my, now I absolutely have to finish that game. It was fun to have a break and put all the puzzle pieces on the table and let her pick and choose what to include in her artwork .
There’s definitely a point in many projects where things don’t work right (like, say, you get locked out of your kitchen), you can see just enough of the shape of the game to also see its myriad holes, bugs drag you down from every side, and your mental calculation of (time to deadline) - (time to implement your vision) = (some large negative number).
Finding those moments of joy pushed me through a lot: seeing the blank parts of the canvas and being excited about what I was going to produce to fill them in. A sense of obligation for the massive gift everyone was giving me by letting me compete was another.
But so many projects don’t have that, to the point where just seeing the acronym ‘WIP’ feels wistful. The way this competition forces you through and past moments that would otherwise block you with walls of discouragement is yet another gift: you get to see where your resilience could lie, outside the confines of this stadium.
So it’s been really fun to see our competitors find their resilience. Go chefs!
Genuinely you’ve had one of the worst things (in a coding sense) happen to you during the competition… You can get through this!! Even if the game is what you would consider unfinished, just remember that you literally learnt the language during the competition. I’ve had nearly 4 years of experience. That I would consider a win any day.
It is 1:20pm. I have now properly implemented the NPCs (not what you think, I just made them not move around in one timeline because I couldn’t be bothered to implement their movement, lol; they are now fully wandering), by recommendation from my testers. Also, made the game a lot easier (i.e. playable) with the creation of a little gadget which I still need to add the screenreader version for. I’m afraid I may have to put that off for a post-comp release, because it’s going to take a long time.
<OBJECT MAPPER
(LOC PLAYER)
(DESC "ship scanner")
(SYNONYM MAPPER SCANNER)
(ADJECTIVE SHIP)
(FLAGS WORNBIT)
(ACTION MAPPER-F)>
<ROUTINE MAPPER-F ()
<COND (<VERB? EXAMINE READ>
<TELL "This is your ship scanner, which you wear
around your wrist. It tracks the entire ship, and you can use
it by activating a SCAN. It's a lifesaver, especially when
tracking your passengers: once you caught someone trying to
get into the storage room. (Not that you blame them: ">
<COND (<FSET? ,STORAGE ,TOUCHBIT>
<TELL "you just entered it yourself,">)
(T
<TELL "in fact, you're trying to get in yourself.
Whatever's in that safe is worth a lot, so you intend to 'borrow' it;">)>
<TELL " but it's still not legal...)" CR>)
(<VERB? UNWEAR DROP>
<TELL "This thing has served you well
across the years: you wouldn't get rid of it now!" CR>)>>
<SYNTAX SCAN = V-SCAN>
<SYNTAX SCAN OBJECT = V-SSCAN PRE-SSCAN>
<SYNONYM SCAN MAP>
This code creates an index of all rooms, and an index of all WAM objects.
I kept running into limitations with the number of properties I could add to objects (and borogove did not allow me to choose version 4 for some reason), so I moved everything into tables. But for that I need to be able to look them up.
I originally was iterating through all objects to find the one with a given index, but creating empty index tables and filling them up at game start turned out to be faster.
It was also more foolproof, because manually updating a list of rooms turned out to be a pain in the backside. Also, creating a static list of objects didn’t work (probably due to their dynamic nature? creating a list of rooms did work…)
It was a simple matter of forgetting to put a <RETURN> within a <REPEAT> loop to stop iterating… Took me a while to find that one.
Also, some objects were mysteriously not showing up in my internal test routine… because I forgot to put a closing " somewhere and the compiler did not give a peep . So everything defined after that went into the Great Black Hole.
.
. So everything defined after that went into the Great Black Hole.