Working on my first game. The starting room is, diegetically, a platform inside of a closet. In my code, it’s a bespoke room inside of the closet room, and to step off the platform, they have to exit the platform room.
In my story, I want the player to start out with a simple restraint on them that keeps them on the platform, preventing them from leaving until they remove it. It’s akin to a roller coaster safety harness sort of thing, and removing it should be as simple as typing “remove harness”. This interaction is solely for the benefit of the flavor of the story.
What are some methods I could use to go about this?
Make the restraint into another room inside the platform room. Make removing the restrainst instead generate some prose and then ‘now the player is’ to the correct room.
I’m tired enough I’m seeing double, so writing code is probably ill-advised right now. But, I’ll write some example I7 code in the morning assuming someone doesn’t either beat me to it, or list one of half a dozen more elegant solutions to your problem.
Don’t even bother matryoshka-ing the rooms. Duplicate your platform room and don’t connect it to anything, no exits. Same descriptions, etc. Rewire the n/s/e/w etc to custom “you’re restrained” failure messages. Start the player in the cut off room. Then, taking off the restraint simply transports you to the pair of rooms you’ve already made.
No worries, we are all at different places. I’ve learned quite a bit but many here could run circles around me, others could run circles around them.
The neat thing about Inform 7 is it is very versatile. For everything you might want to do, there might be 10 radically different ways of doing it. Some pragmatic, some stunningly brilliant, some breathtakingly stupid and unnecessarily and hilariously labor-intensive. The beauty is that, from the player’s perspective, the effect is all the same, despite however many miles of duct tape you have holding things together behind the scenes.
Oftentimes, getting better at Inform isn’t as much about learning about how to implement new things as it is about learning how to do things you already know how to do, but several orders of magnitude less dumb.
Like I said, I’ll provide my spaghetti code in the AM if no else does it better in the meantime.
instead of exiting when the location is platform and the harness is closed, say “The harness keeps you from getting up.”
NB “remove” has the player take off something they’re wearing, but I probably wouldn’t implement the harness as something wearable, just an openable closed object that’s maybe part of whatever scenery object is representing the platform. So you’d want to redirect that input.
Personally I’d also implement the platform as an enterable supporter rather than a separate room since that’ll make it easier for the player to see stuff in the closet proper while they’re restrained without having to mess with scope.
Dim Closet is a room. "A mysterious closet. How did you get here? And how do you know it's a closet??[paragraph break][if the player is on the platform and the restraints are secured]You are lying here, strapped to a platform by some formidable restraints. How are you ever going to get off??[otherwise if the player is on the platform]You sit on the platform, looking victoriously over the defeated straps.[otherwise]You look exultantly over the platform in the center of the room, its restraints hanging impotently over the edges.[end if][paragraph break]A sliding door[if the sliding door is closed], closed[otherwise]open[end if], is on the north wall."
A platform is here. It is an enterable supporter. The description is "It's a table with some straps attached, which are [if the restraints are secured]currently restraining you[otherwise]hanging weakly over the edges of the table[end if]." Understand "table" as the platform.
Instead of getting off the platform when the restraints are secured:
say "The restraints hold you down rather tightly."
Some restraints are a part of the platform. They can be secured or released. They are secured. The description is "[if the restraints are secured]Some rather formidable-looking straps with large metal hasps all over. They look hopeless.[otherwise]They hang loosely over the edges of the table." Understand "hasp/hasps/restraint/strap/straps", "metal" as the restraints.
Instead of taking, opening, taking off, pulling, pushing or turning the restraints when the restraints are secured:
say "You look around desperately, all over the restraints. There is a strap or an unbreakable hasp wherever you look. Just as you are about to give up, you see one metal connector near your hand, with a button marked [']RELEASE[']. You barely touch it, and suddenly all of the hasps click and the restraints jump up off of your body, flying over the sides of the table. You are released.";
now the restraints are released.
Instead of wearing the restraints when the restraints are released:
say "You can't see how to put them back on; but why would you want to do that??"
The player is on the platform.
A sliding door is north of Dim Closet. It is a door and scenery. It is closed. It is not lockable. The description is....
I know that some of what I used here is somewhat advanced, but you may find it useful.
If the restraint really is just for flavor, I wouldn’t do anything too involved with it.
before getting off the platform:
say "You remove your restraining collar, then step down from the platform.".
report getting off the platform:
rule succeeds.
If the player wishes to take it off manually, that can be accounted for:
instead of taking off or opening the restraining collar:
try getting off the platform.
If the player isn’t going to be returning here or doing more involved things with the restraints, you may just want to print some text and send them on their way.
If you’d like to further constrain the player, you could make a list of permitted actions.
taking off is possible while restrained.
opening is possible while restrained.
getting off is possible while restrained.
examining is possible while restrained.
looking is possible while restrained.
smelling is possible while restrained.
listening is possible while restrained.
Note that “possible while restrained” isn’t an Inform 7 built-in thing. I’m just making a property that will be easy to read. This allows me to make a rule like
instead of doing something when the player is on the platform:
if the current action is possible while restrained:
continue the action;
otherwise:
say "You'll have to get rid of this collar first."
This rule will permit actions I’ve characterized as “possible while restrained” to continue while stopping everything else.
I’m going to plug what I always plug, which is… FAKE IT. You don’t need to have the player be on a real enterable supporter, because when you use Inform supporters and containers and doors and such, you have to anticipate whatever weird baked-in behavior those things have. If you fake it, you control everything about it.
Lab is a room. "A lab with a platform in the center. The kitchen is north. [if player is platformed]You're on the platform.".
Someone can be platformed. Someone is usually not platformed.
The player is platformed.
A platform is here. It is scenery. The description is "A wooden platform.".
The description of the player is "As good-looking as ever. [if player is platformed]You are on the platform, restrained by a mysterious force field.".
A hat is here. The description is "Wow, is this a cool hat.".
Check taking the hat:
if the player is platformed:
say "You can't. The force field prevents you.";
stop the action.
Kitchen is a room. It is north of Lab.
Check going north from lab:
if the player is platformed:
say "You can't. The force field prevents you.";
stop the action.
The player carries the bell. The description of the bell is "A silver bell.".
Understand the command "ring" as something new. Understand "ring [something]" as ringing. Ringing is an action applying to one visible thing.
Carry out ringing something:
if the noun is the bell:
say "[if player is platformed]You ring the bell and the force field disappears![otherwise]You ring the bell.";
now player is not platformed;
otherwise:
say "You can't ring that!".
Fwiw, I’m pretty sure my no exit second room teleport option would have still technically worked (from the player’s POV) in the same way that Doc Brown’s Rube Goldberg-esque inventions manage to keep his dog fed when he could have simply asked Marty to feed him (Back to the Future reference). As far as Einstein the dog is concerned though, there’s still food in the bowl either way.
That said, I strongly recommend any of these other much better solutions. You shouldn’t need my more convoluted code anymore after receiving a few much better examples.
Seconded! The idea that you can use special rooms as “different states of play” instead of only physical rooms can be very powerful. I think people forget that a room doesn’t have to be a logical physical space in every instance.
I did this once in a test for an enormous dining room table. I just made one enterable chair (masquerading as all the multiple chairs so the player wouldn’t fuss with which chair) that invisibly transported the player to another room called “Sitting at the Table” where I could have different rules and restrictions and separate “dining” versions of characters and conversations and accessible items without having to check if the player was seated or not. That way when “seated” the player only had access to their place-setting and not the candelabras and everyone else’s “food” that was described. I also used a backdrop with an attached supporter in both the seated and normal rooms so specific things could exist in both locations “on the table” based on what I wanted to be accessible from outside the table and inside the “seated” version of the room - say if the player set their bag on the table and then sat down they could still “reach” it.
This would also work for a situation like a computer at a desk. When the player sits down they’re actually in a different special room where the author can use tricks like the screen being a supporter so you can have icons listed as “on the screen” and interactable. You could even physically model folders as containers on the screen that the player can open and close and move icons into if you wanted to simulate all that. You would just need a rule so when the player gets up, all the “cyber” objects get returned to the computer since they shouldn’t be physical - and possibly restrict physical object use while sitting “at the computer”.
I’ve never made an argument, here or anywhere, for simulation, so I hope I don’t seem to be doing that here, but it is very possible to spend more time inventing your own systems than it is to use those that already exist.
You could–someone probably has–make a game entirely of “instead” rules where the player never leaves the starting room. Instead, that room is renamed and its description is replaced. Nothing is ever taken, or moved, etc. This would all work from a player perspective, but it would be more work for the author. There would be no internal logic; every action would be a point solution.
The “is it worth it?” question regarding faking it vs. using established systems might only become answerable over the course of writing a large game. Or else after looking at one’s body of work in total.
Anyway, I’ve faked lots of things, but I don’t know how to say objectively when faking it (or using the standard rules) is the best idea. There’s value in learning some of Inform 7’s internal systems, if only to be able to tell when they aren’t worth the trouble.
Oh, agreed. This case seems like such a fleeting moment that it’s far easier to simulate it. Generally, containers are really useful and worth the trouble, but enterable containers? Headache, especially for such a brief thing.
They’re great for effects. For example, you could set up a “Monitoring Room” with screens showing views of different rooms. If the player wants to >OBSERVE HALLWAY you could temporarily transport them into an invisible closed transparent container in the actual room so they can examine things in the room (and potentially see what NPCs are doing) but not touch anything.
Probably already solved, but I would make the restraints a closed, transparent, enterable container. Then the library will handle most of the interactions for you automatically: it’ll require you to get out of the restraints before you interact with anything else in the room, and try to do that automatically, if it can.
i’ll definitely keep “keeping it in the same room” in my back pocket for later projects but in this case i think it makes sense for my purposes for the platform to be its own room. the idea is that on waking, the player and the ‘narrative’ are focused on the platform and therefore it takes up the room description. while the closet is mentioned in my preamble text that fires on starting the game, it’s not brought into focus until it’s relevant, e.g. the player is free to move about. partly, i’m just trying to maintain focus, and partly, i’m trying to make sure that while exiting the platform requires some level of interaction, it’s not a confusing process due to visible details in the greater closet (for example, i don’t want the player to think that they have to initiate a bond-esque solution involving grabbing things from the closet to get free)
real quick, when the room title prints, it also outputs in non bold text “(in the docking latches)”. How do I make it not do this? also, when the player exits the container, the room lists the container as one of its contents, how do i prevent that?
