Players are awkward things, and for no reason at all they will try to interact with anything you mention, and indeed things you do not mention, in your rooms. It would be great if Quest had a way to catch this. For example, the player may decide to look at the wall or the sky, and it would be far better to have an appropriate response rather than to get an error message back.

Inform does this though what it calls "backdrops" (see here), and I would like to think about how something similar could be done in Quest.

These objects would all be visible, but not takeable, and they would all be common to many (but perhaps not all) rooms. Here are my thoughts:

There would seem to be potentially two mechanisms for handling these objects. The first is to use object types, and put the scenery object in a object type (so a room could have the "cave" type, which has a cave wall object. Unfortunately you cannot put objects into object types, so that is out.

The second is to have rooms inside regions (which are really just rooms). The scenery objects go into the regions, and the scope methods check for objects in the parent (or indeed any ancester) room if appropriate. So inside the "Object" object, you might have "inside region" and "outside region", and in "inside region" you have "cave region", and inside that you have "cave entrance". The player can only get to the "cave entrance" room, but could look at any object in "inside region", "cave region" and "cave entrance".


Given these objects are not reachable (at least, not takeable), not held, are scenery and are visible they should appear in these lists:

ScopeVisible
ScopeVisibleForRoom
ScopeVisibleNotHeld
ScopeVisibleNotHeldForRoom
ScopeVisibleNotReachable
ScopeVisibleNotReachableForRoom

As far as I can see, these all ultimately rely on the last, so it would only be that one that needs changing. I will have a go at making a new version of ScopeVisibleNotReachableForRoom, but first I thought I would see what others think.

It a good thing to start brainstorming about this problem!

There is already a way to do this. If you have an "outer region" room with an object and an "inner region" in it, you can set the attribute "transparent"=true to the "inner region" then you can examine the object in the "outer region" from the "inner region". But this messes up the room description and the take command . So I fear that only changing the visible scope is not enough. Perhaps this will mess up other thing like the container objects.

Perhaps Alex should tell us, what would be the best way to do it

I am wondering if a better way than using the object hierarchy would be to go via an attribute, say environment. If the object is not in this location, check the location in the environment attribute, then check the location is that object's environment attribute.

My thinking is that it is useful to use the object hierarchy to break up a large game. You can collapse all the other regions when you focus on just the current one (and I did this with Myothioan Falcon). However, there might be caves in each region, there might be outside in each region, so the regions do not correspond.

The downside is that it would take slightly more effort to set up for a author, and is not as intuitive, but I think the long term benefits would outweigh that, bearing in mind this is only of interest to "serious" authors (and possibly only me!).

There is another question: Do you only want to examine objects in the outer region or should it be possible to manipulate them (take, use,...)?

I was assuming you cannot take them. Are you thinking about a stick in a forest? I think if I was going to do that, I would still use the same system. You have your forest region, which contains a stick and a tree, so you can examine both. To be able to take the stick, I would put a special implementation of take on the stick so it spawns a clone in your inventory.

Having said that, that means they must be reachable, so the scoping is wrong. But if you have the stick as reachable, then take all will get you a stick. Hmm, maybe not so straightforward...

The other side is do you think players will expect to be able to "take stick" if they are in a forest, but no mention is made of sticks?

If you have several beach rooms you could use a bucket to take some water. But why only using scenery object? If you are in the forest, a tree could be shown in the "You can see" list.

You are in a forest.
You can see a tree.

That seems bit odd to me. You are in a forest, so of course there are trees. If this is unusual in some way, then sure:

You are in a forest.
You can see a gnarled oak tree with a power glyph carved in it.

But then it is not a ubiquitous oject, it is a specific object, so can be handled normally.



>fill bucket with water

How does Quest handle that command? Can it cope with the second object not being reachable (and allow te author to decide how it will be checked)? I woul guess so, but will have to check.

The Pixie wrote:That seems bit odd to me. You are in a forest, so of course there are trees.

Yes it may not work with a forest but when developing a gameengine you must think more global. What feature could be used by an user in any way. So here is an example where an object is used in several rooms:

You are in a spaceship.
You can see a cable which is attached to the metall ceiling.

The Pixie wrote:
>fill bucket with water

How does Quest handle that command? Can it cope with the second object not being reachable (and allow te author to decide how it will be checked)? I woul guess so, but will have to check.

Why should the second object be not reachable?

Yes it may not work with a forest but when developing a gameengine you must think more global. What feature could be used by an user in any way. So here is an example where an object is used in several rooms:

You are in a spaceship.
You can see a cable which is attached to the metall ceiling.

If it is listed explicitly like this (if you mean the cable), then I think it should be handled normally; an object inside this room. You take the cable in this room, it is then gone from this room, but is still present in the other rooms

Why should the second object be not reachable?

Only because that is how I am currently thinking of implementing ubiquious items - so their scope is "visible" but not "reachable". You would want to have it so the water could actually be reached (in the fill command perhaps: check the bucket is held, and the water is "VisibleNotReachable"; the water object never moves, but the status of the bucket changes).

Here is a first stab at this.



I set up the environment by creating a room "environment", and putting objects inside it representing each environment. Each room in the game can be linked to an environment object through the "enviro" attribute, and environment objects can link to each other in the same way.

If you pick up the cup and go w and w, you will be in a forest by a stream. This room is connected to e_forest_river (which has a water object), which is linked to e_forest (with a tree object), linked to e_outside (with a sky object). The player can look at any of these items.

You can fill the cup from the water here, showing the ability to interact with ubiquous items at least in some way.

Go e and you can look at the odd tree, overriding the normal tree for e_forest.

Go w and w, and the dance, and you change the sky for all outside rooms.

You can "listen" and "smell" in each room too.


I have not tested this well, it may well be that when the game gets more complicated things break, so I offer this for comment at this stage not for use (not yey ready to be s[lit off into a library). We discussed ealier how to handle picking up a stick in the forest, and I am still not sure of the best way to do that (eg, do you let the player pick up as many sticks as he wants?).

Nice! I think this could be the right way. But I would like to see the environment as a kind of object. You can define e_objects in an environment section (as you did it) and then you can drag & drop them to the real objects. So you don't need to work with attribs.

Not sure quite what you mean here. Are you talking about how it would appear in the GUI (i.e., behind the scenes you are setting attributes, but this is set by drag-and-drop)? If so, then yes, I agree, but that is beyond what I can do myself.

I've been looking over the code (nice recursive function! ), and it looks straightforward. But I was wondering if it could be generalized a bit (conceptually at first, coding later) to cover more cases.

It seems we want to be able to include objects that we can see but not reach, and also be able to share them in multiple places. In my own story, I was coming up with places where I wanted to be able to have such objects, but I don't know if they'd be considered "environment." For example:

1) You are on an elevator. When you get to the fourth floor, the doors open, and you can see the foyer. There are objects there (e.g. "look foyer"). If you exit the elevator at that point, you can reach the objects. However, when you're on the elevator, you can see but not reach them. But you'd like them to be the same objects, especially if they may come and go (so you don't have to duplicate everything).

2) You are in a kitchen and there is a window. Through the window you can see a sunflower plant. If you go outside, you want to see the same sunflower plant (but now be able to reach it).

3) You enter a fancy conservatory, with a broad clear skylight. Through it, you can see the sky, the sun, the twin moons of Calera, etc. That's environment, but you're not technically outside.

All of these seem to have a common thread - being able to see into another room or to a "place" that is outside or larger than the room you're in.

I don't have a definitive strategy for this yet, but I wanted to throw it out there in case either it works with what you have in mind or if what you have in mind could be expanded to cover that. (And just spurring ideas is fun. ) I am a newbie to Quest, so perhaps there are other ways to do what I'm talking about that aren't even related to this.

Update: another thought... it would be cool (to follow your example) that if you opened the window in the kitchen, you'd be able to smell the sunflower or the crisp afternoon air. But if the window were closed, you could not.

Good to have someone else looking at this!

Quest already has a look direction facility. I have not used it at all, but that is where I would want to handle looking from one room to another and seeing the objects there, it might even do that already.

For the conservatory, I would call that outside if it has the same features as outside (or have stuff that is really outside linked to e_really_outside, where you can feel the rain, which in turn is linked to e_outside, as is the conservatory, which has the sky object).

For the smell in the kitchen, probably best to just change the "smell" property on that room when the window opens and closes (if you like, do kitchen.smell = e_garden.smell when the window is opened).

Pixie,

I've been following this with some interest. I've done something similar for my own use which pertains to the lookat command using lists and dictionaries. Had the idea a while back. I'll post a demo if anyone is interested in looking at it.

You might not be aware that the inherited types "editor_room" and "editor_object" go away in published games. In fact, all "editor*" types disappear. When running a published game, any refrences to them, will produce an error running script message. Just FYI. Noticed you used a few DoesInherit calls used those types.

I had not realised that. Thanks for the warning.

Okay, this version does not check for editor_object or editor_room.

Also, it adds a new tab to rooms and objects so the various attributes can be set rather more easily.

This version now handles darkness and light-giving objects. Set an environment object to "Dark area", and all rooms linked to it will be dark. Set an object to "Object provides light" and when the attribute "turnedon" is True, you can see in the dark. Or set "seeinthedark" on the player (when it is daytime or has cast a nightvision spell or whatever), and the player can see.

Ah yes I am just trying to integrate dark/light into Q5.3

What does that mean? Will what you implement be compatible with this (or even based on this)? It would be useful to know so we can plan to accomodate that when 5.3 is released.

I started working on it last week so it's not compatible with your lib. I am not working with lighttypes, only normal attributes.