a wall in every room? possible?

Hello,

I would like to prevent the following.

Now Inform already allows us to examine in a direction (examine east) but I am stuck as to how to give all internal rooms walls without specifiying something like…

the east wall of the living room is in the living room. the north wall of the living room is in the living room ....
and having an understand for every room and every wall…

understand "east wall" as the east wall of the living room

for each location- so the east wall is the living room one when we are in the living room.

You can say an inside room is a kind of room, but I am stuck as to then hang something like.

 every inside room has an east wall 

on it (this problems out. Im guessing as its trying to define lots of ‘east walls’?)

In the end I’d like players to be able to move furnature against walls, hang pictures etc and not be restricted as to which wall unless I want this (the east wall is a huge mirror/hang picture on east wall/ that would break the mirror)

An east wall is a kind of thing. An east wall is usually scenery. An east wall is in every inside room. 

Not an elegant solution, mind you; using this approach you’ll end up with four (or eight) undescribed walls in every inside room.

Would it then be possible to add a description to specific walls in certain rooms? And can you say "the description of an east wall is usually “This wall is unremarkable” or whatever? (Don’t have a PC with me right now, or I’d try it out myself).

Re: mostly useless… Yes, almost, but you don’t have to say ‘is usually’ because the trick is - there is only one ‘an east wall’. It’s just that it’s present in every room you tell it to be present in. You could say something like ‘an east wall is in the kitchen, the pantry and the dining room.’

Actually this solution seems very good to me.

EDIT: Oh hang on! I missed that maga said ‘scenery’, not backdrop. My following post and comments, and what I said to mostly useless, are actually about making ‘an east wall’ a backdrop. As an example:

'An east wall is a backdrop. An east wall is everywhere.'

As I read it, Paper Thing wants the game to acknowledge an object for each directioned wall in the majority of rooms, and that these can be referred to by name. Having installed one east wall backdrop in all relevant rooms, you can then differentiate amongst them by the player’s location. So to give different descriptions based on location, as an example:

Instead of examining east wall when location is the pantry: say "The food has made it yucky."

You can just give a default description to the master east wall backdrop object and then it’ll appear for all the rooms which don’t have instead exceptions without you doing anything else.

This setup should be good if the majority of the walls are not special, differing mostly only in description. And if there are some special walls that are sufficiently special you’d rather they were new objects, you can just make them new objects. The only catch is making sure any special walls are prioritised over the default wall on the same side of the room when the player says something like ‘examine east wall’. Perhaps the easiest way is to not put the default wall for a side in the room if there’s gonna be a special wall on that side.

There are a good number of alternatives along these lines but the basic idea of having master north, south, east, west wall backdrops, etc., and putting em all over the place, should be good.

  • Wade

Hi,

Many thanks for the replies. Can I just check whether this method creates an east wall for every room - so 20 rooms = 20 east walls =20 new objects - or a single east wall everywhere I tell it to be (a bit like a backdrop? Which I think is what severedhead is suggesting?)…

If we then nail a picture to one of the walls - will it appear on all of them or how does it work?

I’m just a bit worried about memory. For my small 5 room test 20 walls would not be a problem, but for the main project which has 30 rooms 120 new objects could break things - especially if I compile for z-machine. The manual mentions objects and memory in the 10.3 dispencers section.

Another question I have relates to the few (5 or 6) special walls I want. Can you say … 'in every inside room except the kitchen, lounge and bathroom. ?

Listing all the default ones will be a pain otherwise.

The “An east wall is a kind of thing” method will create 20 different east walls, one for every room.

Each east wall will be implemented as a separate object, so if you nail a picture to that wall it’ll stay on that wall – no worries about it showing up everywhere else.

Weeeellll, my guess is that if you’re writing a thirty-room project you’re going to wind up compiling to Glulx anyway, and then it shouldn’t be a problem. (Unless you’re doing funky stuff that requires looping over every object in play or many-many relations or something like that, in which case I think you might see a performance hit, though I’m not sure.)

If all you wanted to do was capture “Examine east wall” then you might be able to get away without defining explicit wall objects via something like this:

[code]A direction can be cardinal. North, south, east, and west are cardinal.

Understand “wall” as a direction when the item described is cardinal and the location is an inside room.[/code]

which winds up redirecting commands involving “wall” to the appropriate direction, so that you’d be able to change the response to “examine west” (the default is “You see nothing unexpected in that direction”) to something more appropriate. You’d also have to ensure that you get appropriate responses when you try to do things like “take east wall” (since the game thinks you’re trying to pick up a direction) and probably doing a lot of other fiddly stuff.

But IIRC you want to have a fair amount of physical interaction with the wall – putting things by or against or near the wall. And if you want that kind of interaction it’s probably better to model the wall as a thing instead of hacking around it.

I don’t think you can do this, at least not easily. But you could eliminate the ones you don’t want at the beginning of play:

An east wall is a kind of thing. An east wall is in every inside room. When play begins: now a random east wall in the kitchen is off-stage; now a random east wall in the living room is off-stage; [etc.]

One possible way:

[code]A room can be inside. A room can be east-free. Definition: a room is east-walled if it is inside and it is not east-free.

An east wall is a kind of scenery. An east wall is in every east-walled room.[/code]And so on for each relevant direction.

That doesn’t seem to work:

It looks like initial declarations like “An X is in every Y” will only work when X and Y are both unadorned kind names.

Also you can’t define “a kind of scenery,” I think, because scenery is itself not a kind (“An east wall is a kind of thing. An east wall is always scenery” would work), and I notice we’ve been talking about “inside” the whole time which gives a compilation error because it’s already the name of a direction or something.

UPDATE: But the adjective trick would make the “when play begins” solution work much more smoothly:

A room can be east-free. When play begins: now every east wall in an east-free room is off-stage.

This should work, I think.

Is not a kind, you meant to type. It’s a property of things. So, as you say, go with “An east wall is always scenery.”

Indeed; I’ve corrected it in the original post.

Many thanks for all the help.

I have hit an odd problem, which is I cant work out how to place items beside (etc) walls in the initial code

a trunk is beside the east wall of the hallway.  the trunk is an open enterable container. the trunk is openable.

is creating a new thing called ‘east wall of the hallway’ and placing the trunk beside this, rather than the ‘east wall’ of the hallway that has been created as Maga and Matt suggested. Similarly a new thing called east wall is created if Isay

a trunk is beside the east wall

Do I have to define the items and then silently try putting them by or is there another way?

I think folks will need to know which method you ultimately used to create your wall(s) from all that were discussed, before they can tackle your latest post :slight_smile:

Have you defined ‘beside’ in some way? I assume you have, because otherwise I’d expect Inform to be stopping you with a compilation error instead of creating an object called ‘east wall of the hallway’ and then carrying on. Being beside something is not a concept Inform understands by default. It knows ‘on top of’ because support is modeled. It knows ‘inside’ because containment is modeled. But ‘beside’ (being next to something - adjacency?) isn’t pre-programmed.

If you or some extension you’re using have defined ‘beside’ in some fashion, presumably one thing can be beside one other thing. The problem then becomes - how does Inform know you are talking about the east wall that is in the hallway and not one of your other 100 east walls? (And also - I don’t know what programming method you’ve used to get these walls going.) Using the word ‘of’ as you have (‘east wall of the hallway’) could potentially indicate to Inform that it should retrieve the value of the ‘east wall’ variable for the room ‘hallway’, which is clearly not what you meant. So it’s gone with the interpretation that ‘east wall of the hallway’ is one object with that name, and that’s likely not what you want either. Your problem if you’re going to stick specific things beside specific east walls is - these east walls would have to be distinguishable from one another by internal name. IE - they’d have to be uniquely named for code purposes, but all referable to by ‘east wall’ to the player. That’s a tedious thing to set up. Which, if I can plug my previous idea again… can be dodged by sticking one generic east wall backdrop across all the rooms where the wall just has to be there, but isn’t of special importance, and creating specific, uniquely named east walls for the special case rooms.

Re: modeling besideness, it’s worth considering if this is essential to the game. For instance, unless it’s significant that you could do something like push a crate up against all the different walls of the room, Inform doesn’t really need to know where the crate is within the room at a programming level. Authors would typically just put in its description, ‘The crate is against the east wall,’ to achieve the effect.

So in your example, my gut would be to just put the trunk in the hallway, and describe it as being ‘against the east wall’. If it can be moved (maybe once), then change the description when it’s moved. If the if-thens of changing its description become too complex to deal with depending on what you allow the player to do with it, well then that may be the sign you need to program a ‘beside’ system. But I try to avoid developing under-utilised systems, just because developing any system tends to be a crapload of work.

  • Wade

Hmm as an addition to the above.

when play begins: try placing the trunk beside the table.
works when trunk and the table have been previously defined as being in the hallway.

but

try placing the trunk beside the east wall in the hallway

produces

Problem. You wrote ‘try placing the trunk beside the east wall in the hallway’ , but ‘placing the trunk beside the east wall in the hallway’ is too vague to describe a specific action.

and

try placing the trunk beside the east wall of the hallway

problems with

Problem. You wrote ‘try placing the trunk beside the east wall of the hallway’ , but ‘placing the trunk beside the east wall of the hallway’ is not an action I can try. This looks as if it might be because it contains something of the wrong kind. My best try involved seeing if ‘the east wall of the hallway’ could be an object, which might have made sense, but it turned out to be something unrecognised.

Yet if the player types

place the trunk beside the east wall.

the code works and they get
now the trunk is beside the east wall.

Okay, the problem here is that you’re assuming too much about what Inform understands. Let’s go through it piece by piece.

Let’s assume that you’ve created an object with kind ‘east wall’ and put it in the hallway:

try placing the trunk beside the east wall in the hallway

The code above fails because there’s no such thing as ‘the east wall in the hallway’. When this code actually runs, there might be five east walls in the hallway, or none! Inform doesn’t know what other shenanigans you might be getting up to with east walls.

try placing the trunk beside the east wall of the hallway

The code above fails because ‘the east wall of the hallway’ is mixing up properties and kinds. ‘The X of Y’ is talking about a property, not a kind.

(Let’s say that Janeway has the kind ‘captain’. She can transport onto the bridge of the Defiant, but that doesn’t make her ‘the captain of the Defiant’. That’s a distinct property; it doesn’t really have anything to do with her location. You’d want to define a separate value for it - ‘A starship has a captain called commanding officer.’ Inform treats everything like captains and starships.)

But you can do it like this:

let N be a random east wall in the hallway; try placing the trunk beside N;
Even if you know that there’ll never be more than one east wall in any given room, Inform doesn’t; that’s why you need the ‘random’, even though it’s a random selection from a pool of one.

You could also do something like this:

[code]A room has an east wall called eastside.

concrete wall is an east wall in the hallway. concrete wall is the eastside of hallway.

(blah blah,)try placing the trunk beside the eastside of hallway;
[/code]

I think we can just go ahead and replace the documentation with that sentence.

Hi,

Firstly many thanks Maga for clearing the confusion up and also explaining why I keep seeing random everywhere in code when as you say we are picking a random thing from one.

There are no extensions in my code, and I have (with a lot of help from folks here) defined beside/against/next to etc

Im defining all this stuff so I have full flexibility when working on my main project, and won’t have to decend into a sea of if statements just to add a puzzle that involves a step ladder and a light bulb.

I also had no idea it would be this complex when I started, so perhaps a sea of if statements would have been easier. Still I’m learning

So what I have so far is a way of associating objects to each other (beside etc) and a way of putting them about a room (against walls etc) which allows the player to move them at will. You can put the standard lamp beside the sofa when the sofa is against the east wall, only to find that the lamp’s lead is too short to plug into the power socket on the west wall. This will work in any room in any building - no ifs at all. (OK loads of ifs in the rules but no specific ones in the rooms).

The down side is that I have had to write a load of code to do this and I really didn’t expect to have to produce so much. Oh well.