Foxaroo project #1: TARDIS Adrift

Foxaroo project #1 - TARDIS Adrift

(Sounds like TADS Adrift, doesn’t it? :laughing: Pure co-incidence I assure you)

Hi all, I’m back from Canada and very keen to make progress on my 1st Inform 7 project, from which I hope to learn enough to then progress onto more sophisticated projects. My progress to date has been impossibly slow, I cite lack of time and lack of talent so I’m throwing myself at your mercy, or else this will never materialise (pun intended).

I’ve chosen the classic Doctor Who series for the theme.

The premise I’ve devised for my first project is that the player takes the role of a young time lord/lady not long out of the Gallifreyan Academy whose TARDIS suffers an in-flight disaster and makes planetfall in a completely inoperative state. The player is tasked with scavenging the components to restore his/her TARDIS to nominal function (Similar to Infocom’s The Hitchhiker’s Guide to the Galaxy by Douglas Adams where the player as Arthur Dent scavenges for various tools). This will not only involve searching, but also identifying ways to move the TARDIS by external means until the point where the player has re-enabled flight functionality. For example, the player departs their starting planet by scooping up the TARDIS with a sandminer and loading it onto a modified maglev track to propel it up to escape velocity.

I chose this theme for flexibility; no requirement for a linear narrative, and the structure of locations and puzzles can be moved around if needed. Interactive characters in the game will initially be very basic (a non-talking robot from the sandminer) until I learn how to establish rules for more sophisticated interactive characters. The player also has 12 “lives” in the form of regenerations, although there will be some hazards that do not allow regeneration, such as drifting off into space.

Now the first difficulty confronting me is one I’ve already asked about: the early puzzle requiring the player to break open the fire extinguisher cabinet. The player needs to use the sonic screwdriver to either cut (preferred) or bludgeon (alternative) the glass plate. The purpose of the puzzle is to ensure that the player has located the sonic screwdriver before he/she can exit the TARDIS, since the object will be indispensable throughout much of the game.

Matt W devised a code that enables the player to accomplish the breaking of the glass by the player

Instead of attacking the case glass: say "Crash!"; now the case glass is shattered; now the small metal case is open.
However I need to refine the command so that only the below can be accepted.

[b]CUT GLASS WITH {SONIC} SCREWDRIVER

BREAK GLASS WITH {SONIC} SCREWDRIVER

SMASH GLASS WITH {SONIC} SCREWDRIVER[/b]

(Rule fails without visible possession of the sonic screwdriver, and if attempted in an unlit room)

The problem being that Inform7 already has “break” in the group of synonyms for attack, including (but not limited to) “smash”, “hit”, “fight”, “torture”, “wreck”, “crack”, “destroy”, “murder”, “kill”, “punch” and “thump.” While I was searching the manual, I stumbled upon a paragraph somewhere that spoke of the need to tell Inform to forget or unlearn a verb so that it is no longer a synonym of something else. That sounds like what I need to do, but I neglected to bookmark the place where I read the syntax. :cry:

Yes, that’s how I read it at first, and was surprised to find it an Inform post. :slight_smile: (Btw, there’s a special section of the forum for Inform.)

Regarding your actual question, I’m not qualified to answer that (I’ve not yet done anything in Inform 7, except reading posts here), but the phrase “Understand … as something new” comes to mind. I don’t know if that’s right, but someone else with better knowledge will no doubt post soon.

You don’t need to remove the grammar for “break glass”. What you need to do is define a new action called attacking it with. Here’s a working example:

[code]
The Test Lab is a room.

The window is fixed in place in the Lab. The window can be broken. The window is not broken. The printed name of the window is “[if broken]broken [end if]window”.

Instead of attacking the window:
say “With your bare hands?”

The hammer is in the Lab.

Attacking it with is an action applying to two visible things and requiring light. Understand “attack [something] with [something]”, “break [something] with [something]”, “smash [something] with [something]” as attacking it with.

Check attacking it with:
say “That’s not a useful action.”

Instead of attacking the window with the hammer:
if the player does not carry the hammer:
try silently taking the hammer;
if the player carries the hammer:
say “(first picking up the hammer)[line break]”;
if the player carries the hammer:
say “Crash!”;
now the window is broken.

Test me with “break window / break window with hammer / look”.[/code]
Naturally, you’ll need to refine this further.

A point you may want to ponder is this: Doctor Who is subject to copyright law. You can certainly write a game using Doctor Who – nobody is going to come into your house and erase the files from your computer. But you won’t be able to upload the game to the Interactive Fiction Archive, which means that players will have a hard time finding it.

Total aside here but there’s tons of fanfic out there for Dr. Who and no one has had any trouble. Some franchises do give you trouble (Star Trek being one). But the Dr. Who fan fiction has been going strong for quite some time. The owners of the Dr. Who copyright have pretty much stuck to the idea that as long as you (1) aren’t claiming the intellectual property as your own and (2) you’re not making money from it, then you’re fine. Whether the Interactive Fiction Archive will or won’t upload it, I suppose, is a different issue. But it would be pretty silly to exclude it since, again, Dr. Who fan fiction of various types has been out there for a very long time with the explicit okay from the owners of the copyright with the above stated caveats. I also don’t think the owners would treat interactive fiction as too much different from the written fanfic.

This is just going to be a student project. Profit isn’t on my mind for this piece, and I probably wont be uploading it anyway unless asked to.

That’s what was suggested before, but I don’t want the commands for “Break” and “Attack” to be interchangeable. If at a later stage in the design I want the player to “Attack Dalek with rocket launcher” I don’t want the player becoming confused by finding that they can successfully enter “Break Dalek with rocket launcher.

That may well have been what I was reading earlier. I’ll take another look through the chapters on new rules.

I’d try something like this:

[code]Understand the command “break” as something new.

Breaking it with is an action applying to two things.
Understand “break [thing] with [thing]” as breaking it with.
Understand “cut [thing] with [thing]” as breaking it with.
Understand “smash [thing] with [thing]” as breaking it with.

Carry out breaking it with: [default messages for using the wrong combinations of things]
if the second noun is not the sonic screwdriver, say “You need to use [the sonic screwdriver] to break stuff.”;
else say “[The sonic screwdriver] fails to penetrate [the noun].”

Instead of breaking the glass with the sonic screwdriver:
if in darkness:
say “You can’t see what you’re doing.”;
stop the action;
if the case glass is shattered:
say “That’s already broken.”;
stop the action;
say “Crash!”;
now the case glass is shattered;
now the small metal case is open.[/code]

That should give you break/cut/smash and leave “attack” unaffected.

I wouldn’t actually worry about this. Most players won’t try “Break Dalek with rocket launcher,” and if they do it won’t be a problem if it results in them attacking the Dalek. The big problem is understanding too few synonyms, not too many.

I agree with Matt.
Inform’s Standard Rules contains lot of synonyms for verbs that would in actual life be synonymous only in specific contexts (i.e. for some actions both verbs can be naturally used but for many actions only one of them would be a natural choice): e.g. since “carry” and “hold” are understood as “take”, Inform let’s you HOLD INVENTORY or CARRY INVENTORY, and if you’re wearing something the command HOLD OFF will take it off; you can UNWRAP DOOR; you can PAY BANANA TO HUNGRY ORANGUTAN; you can COVER OFF a device; you can try to CLEAR WHEELBARROW TO OUT (meaning you try to push it outside); and if you can CUT THE GLASS WITH THE SONIC SCREWDRIVER, Inform will also let you PRUNE THE GLASS WITH SCREWDRIVER, SLICE THE GLASS WITH SCREWDRIVER and CHOP THE GLASS WITH SCREWDRIVER (since “slice”, “prune” and “chop” are all understood as “cut”).

It’s probably not worth the drudgery to replace them all with more fine-grained actions that only accept a natural choice of words, and I’m not sure if it’s even desirable.

Normally, I suppose, this is not a problem, since few players would try those commands, other than for the fun of it (I can’t remember ever trying to unwrap a door).
At least, I guess that’s true for native speakers of English. Foreigners like me—and I’m sure there are lots of other non-Anglophones playing IF in English—may well make wilder guesses at a verb, and in that case these way off synonyms might conceivably even be of some weird kind of help.

This, of course, is not to say that there can’t be reasons to fine-tune certain synonyms in a specific game. If there is any reason to think that BREAK DAREK would be a natural command for players to try in some other sense than that of attacking him, then you have a good reason for understanding “break” as something new.
Or if you’ve implemented to different actions that can be performed to different effects on the same kind of things, e.g. if you want players to be able either to open or to unwrap a door as two distinct actions with distinct effects on the door; then, of course, the verbs mustn’t remain synonymous.

Foxaroo, I see you’re in Sydney like me. Are you a DWCA member? (like me.) They might be interested to hear about your game at some point. Preferably a point when you know the game’s definitely gonna be completed :slight_smile:

That is PERFECT!!! I think you’ve covered every possible contingency, including the if-in-darkness rule. I’ve incorporated it into my project exactly as you’ve written it, and it worked immediately without any tweaking. I’ve tested the present/not present visible/not visible rules and they all worked as desired. Thanks Shammack! :smiley:

@ Matt w and Felix. I quote from the in-game commentary of the Valve software game Portal. “We try not to take the easy way out.” I recall some of the bugs in the commercial Infocom games, and some commands that worked despite peculiar grammar. None off the top of my head, but if I dig Zork out I’m sure I’ll remember.

Long as they’re not holding their breath for it :wink:

Like I mentioned above, I chose Dr Who as the theme for my 1st project due to the flexibility; go anywhere anytime in the universe and with few restrictions on the order of activities in the game. Eg: If I find that a puzzle on Skaro isn’t working out as planned I’ll switch to Zeos, Zolfa-Thura or Terra-Omega instead. Anything goes. Even the rooms inside the TARDIS don’t need to follow a pattern. I’ve moved Boot Cupboard 12 to be in a hallway opposite the player’s bedroom, whereas it started out aft of the console room.

For my 2nd project I aim to have a furry theme, and my ultimate goal is an Inform7 game based on The Goon Show which will be extremely challenging due to the surrealism - I’ll have to write custom code for nearly everything.

Aside: I used to be fairly active in the Doctor Who community when I was in high school and TAFE. I met Dudley Simpson (always liked his music) at Novacon '91, at which were also Katy Manning and Mark Strickson. In my (sadly-on-long-term-hiatus) web comic, my character’s companion “GG1” is based on K9 (he was a tin dog, she’s an iron horse; IE a robotic locomotive). These days, most depressingly, I have little to no spare time, being stuck in an especially demanding job. I’d very much like to continue my web comic, but Inform7 projects are something I might have more success with, as I can learn and design while on the go (even on the train to work) whereas my comic requires me to be at my drawing desk (not that I’m pretending to have any talent for drawing :cry:).

Maybe it SHOULD be called TADS ADRIFT!

Jim, where did you get this idea? It’s not true. There are several fanfic games on the Archive, include a handful of Dr Who ones.

And a worthy goal it is! I do look forward to that!

Bloodnok: Oooh! It’s gonna be Hell in the CPU! :wink:

Let me just finish Projects #1 and #2 first… My learning experiences. :slight_smile:

Working happily on the project and haven’t run into any obstacles as yet. Just had a question about streamlining a bit of code. The part highlighted with comment markers:

Instead of breaking the glass with the sonic screwdriver: if in darkness: say "It is too dark to see what you are doing."; stop the action; if the case glass is shattered: say "The [case glass] is already broken."; stop the action; if the player is not holding the sonic screwdriver:[ <-- T h i s] try silently taking the sonic screwdriver;[ <-- P a r t] say "(taking [the sonic screwdriver] first)";[ <-- H e r e] say line break; say "You power on [the sonic screwdriver] which emits its familiar high-pitched buzz. The glass front of the case is no match for the potent vibrations and quickly shatters into tiny fragments. You are now able to reach [the contents of the metal case] inside."; now the case glass is shattered; now the small metal case is open.
Each time the player goes to use a particular tool, whether it’s the sonic screwdriver, an etheric beam locator, laserson probe or lumricator core tracer, I intend to put in a check like the one above to ensure that the player is holding the noun in their hand(s). I was particularly fond of the way that the old Infocom adventures would do so, and explain in parenthesis that the picking up was being performed automatically (eliminating an all-too-obvious step for the player).

Rather than repeat those same three lines of code ad nauseum, is there a way to encode them in a general rule, or a definition?

2nd question, when you’re posting a bit of code in this forum, is there any way to highlight a section? I tried colouring and bold, but they didn’t work.

UPDATE: What shammack said. Duh. The last thing I say about “if the case is not empty” still probably makes sense.

Well, I don’t know what the best way to do this is, but you could try a kind of action, thus:

Breaking the case glass with the sonic screwdriver [when the case glass is not shattered when not in darkness] is handy action. Before handy action: if the second noun is not held: say "(taking [the second noun] first)[command clarification break]"; try silently taking the second noun; if the second noun is not held: stop the action.

The problem is that I can’t get Inform to recognize the commented-out code; apparently conditions in the definition of a kind of action don’t work? The documentation on kinds of action (7.15) is not super helpful. Which means that you’ll try taking the screwdriver even when the glass is already shattered. It might just be better to keep typing those lines.

Incidentally, the difference between “command clarification break” and “line break” is probably moot here – it apparently only manifests itself when the command takes you to another room and prints its description. More seriously, you need to print the “(taking the screwdriver first)” before the try-silently; otherwise the action will stop when the try-silently fails and you’ll never see the command clarification. (Put the screwdriver in the case and you’ll see what I mean.) --It looks like the code I wrote about “if the second noun is not held” may not be necessary, since if taking fails then the action stops, though you might want it in anyway, in case there’s a situation where the “taking” action can succeed without actually giving you the second noun. Also, you should probably add “[if the case is not empty]” before the “you are now able to reach sentence,” to rule out the possibility of saying “You can now reach nothing inside.”

Isn’t this behavior already built into the standard rules? From the manual section on “Implicitly taking something” (17.32):

So it may just be a matter of making your breaking it with action require a carried noun (which it probably should have done anyway). Try changing the definition of breaking it with to “Breaking it with is an action applying to one touchable thing and one carried thing.”

I’m not sure that’s quite right. I thought putting “carried” in action definitions was deprecated because it led to parsing problems.

If that doesn’t generate an automatic take, you could always make a rule to apply wherever it’s needed. I like to base my code on the Standard Library as much as possible. This is the can’t insert what’s not held rule:

Check an actor inserting something into (this is the can’t insert what’s not held rule): if the actor is carrying the noun, continue the action; if the actor is wearing the noun, continue the action; issue miscellaneous library message number 26 for the noun; silently try the actor taking the noun; if the actor is carrying the noun, continue the action; stop the action.

To modify that for the second noun, you could do this:

Check an actor breaking something with something (this is the second noun must be held rule): if the actor is carrying the noun, continue the action; if the actor is wearing the noun, continue the action; issue miscellaneous library message number 26 for the second noun; ["(first taking [the item described])[command clarification break]"] silently try the actor taking the second noun; if the actor is carrying the second noun, continue the action; stop the action.

And then you can put “abide by the second noun must be held rule” in any other Instead rules that need it, or just say “the second noun must be held rule is listed [somewhere in] the check [specific action] rulebook.”

I think it’s as easy as this:

Breaking it with is an action applying to one thing and one carried thing. Understand "break [something] with [something preferably held]" as breaking it with.

I just checked. “carried” does seem to generate an automatic take. I don’t remember where I heard it was deprecated - it’s used in several places in the Standard Rules, including for the second noun in “locking it with.”

“[something preferably held]” causes the parser to choose a held object over a not held object when there is ambiguity, but it doesn’t ever generate an automatic take.