I know I'm not alone in feeling that whatever I describe in a room, must be made into an object in case the player wants to look at it. I'm looking at you, Xan.

Some of you may say so we should - that's the responsibility of a good game designer, but what if we could allow for this 'scenery' without having to create it as an object?

My compromise (and I don't claim this is some great hack that no one's ever thought of before) is to go into the libraries, search for UnresolvedObject and change I Can't see that to Nothing out of the ordinary.

Now I accept that with this method, if someone were to type look at shark while inside a living room, they would get Nothing out of the ordinary, suggesting there is a shark in the living room. But I think there is far more chance of a player wanting to look at a piece of scenery which does exist, than them typing Look at [random word here] just for the hell of it.

With this method, you can be as elaborate with your descriptions as you please, knowing that every minute detail you describe can be effectively 'looked at' or e(x)amined.

One minor flaw with this, maybe, is that an important object which gives vital clues, would get this default response if the player typed it incorrectly or called it something slightly different to the names you've given it, effectively meaning they'd disregard it as insignificant.

A bigger flaw is that now the player can type "examine fnurglewitz", or any random string of characters not once mentioned in the room description, and they'll still get the "nothing out of the ordinary" response. At which point the illusion is shattered.

For this reason, Inform 6 has a way to let you specify "unimportant" nouns. (Pretty sure other authoring systems do as well, but I can't remember which now.) But Alan 3 for example doesn't, so what I did there was to create one "catch-all" object per room, that responds to all those extra nouns and has no description or any other interaction set, so players will soon figure out it's just a boring prop.

A bigger flaw is that now the player can type "examine fnurglewitz", or any random string of characters not once mentioned in the room description, and they'll still get the "nothing out of the ordinary" response. At which point the illusion is shattered.

You clearly didn't read my whole post. I covered this. And in any case, my game features lots of fnurglewitzs as scenery so it's not a problem if they type that.

And yet another flaw is that use [scenery object] also gets this response. As does take [scenery object], and I suspect, anytime a default verb is used for an object which is scenery/doesn't exist.

A better way to do this, if anyone's remotely interested, is to bring up the library list, search for the lookat command and add Nothing out of the ordinary. in the Unresolved object text field.

Felix wrote:

A bigger flaw is that now the player can type "examine fnurglewitz", or any random string of characters not once mentioned in the room description, and they'll still get the "nothing out of the ordinary" response. At which point the illusion is shattered.

But the player already broke the illusion by typing fnurglewitz. If you assume good faith from the player, it works fine. And I find "the fnurglewitz is nothing out of the ordinary" - when you were deliberately goading the parser - much less jarring than "The floor isn't there" when you were playing along nicely.

I played an old Level 9 game, Knight Orc, recently, which compromises on the compromise by saying "That's probably just scenery." In my own games I use "Nothing special." (Which is technically true of the fnurglewitz too.)

Implementing as many objects as you can is good practice of course, but there'll always be some that slip through the net.

there's scripting that can handle all of this very well, but it's more advanced coding stuff...

Thanks, robin, I'm glad others can see my reasoning. I had Detectiveland recommended to me by a fellow member - thetruespin if memory serves - and it really is a cut above.

Hege, my brain doesn't do advanced. You should know that by now :)

I suppose it depends on how much you use it. If you want to use it as a safety net to catch things you miss, then fine. If you use it to avoid providing your player with a rich experience, then I'm not so keen on it. An important question would be, "Is this providing a better experience for the user, or is it just making it easier for me as the game author?" If it's the former, as it avoids the player seeing "I can't see that" when I goof up, then great! If it's the latter and it actually makes for a worse experience for the user (in terms of being able to explore the world you're creating) just so I don't have to bother implementing things, then it has no appeal for me. It's not even a question of the loss of illusion. For me, being able to examine objects mentioned is not about just preserving the game illusion (over "I can't see that" for something mentioned). It's about having a world with more than one dimension (where that one "dimension" is just the bits needed to complete the game).

Another question to ponder as you design your games is whether the destination is more important than the journey. Sometimes it's all an author can do to be able to create enough content just to get a player from point A to point B. But the truly enjoyable games are the ones (for me) that make the journey a delight as well, with things to explore along the way, even if it's just having really cool things to look at.

On the other side, providing default responses can help the player identify what's important and what isn't. Something with a default response tells the player "don't worry about this". (Some even use "That's not important right now" as a default response, which has its own philosophical issues.)

So, in the end, it all comes down to what kind of game you want to make and what your design choices are. The tip you offer is one that's good for people to know (as long as it's not abused - ok, I couldn't avoid the last minute bias :) ).

Sorry for such a late response, Jay.

I understand the points you're making, but I'm in agreement with robin that constantly being told I can't see something (that has just been mentioned in the room's description) is far more irritating than seeing an obvious default response.

And then as game designers we have to ask where we stop? How much of the scenery we describe in a richly detailed room do we make into objects just in case the player wants to examine them? Do we make the curtains an object? The walls? Ceiling? Windows? What if we say there's a layer of dust lying on every surface - do we then have to make a dust object?

In my opinion, suggesting that an item a player wants to examine is indeed present, though not important, would enrich my experience as a player, even if it does mean that a player could effectively examine a rumfellerhogalight (or other nonsensical/non-existent object)

It's also worth noting, just in case I didn't make it clear, that my idea is really only there to cater for those who try to examine things that any seasoned TA would know didn't matter. If a room has an item that a player may naturally want to look at, I make it into a object and give it its own description and, when required, functionality.

you could always do the best of both... have default responses to let the person playing know what's going on, but you can have/give multiple random default responses so it's not the same default message every time, and to make them even less boring, be creative with them, be funny, maybe also give a hint or tell about various features or some background info, etc etc etc, be creative ...

A better way to do this, if anyone's remotely interested, is to bring up the library list, search for the lookat command and add Nothing out of the ordinary. in the Unresolved object text field.

The Unresolved object text field is a string attribute but with little changes you could add an unresolved object script. So you could add a string list to every room containing all of the "scenery objects" of this room and within the unresolved object script you could check these sceneries and output your own template

The rule of thumb I've read for how deep to define objects is three, if that helps. In other words, a seasoned TA player (to use your phrase!) would expect that you would have objects defined that deep.

1. Any objects mentioned in the room description have descriptions.
2. Any objects mentioned in the descriptions for those objects would have descriptions.
3. And once more for any objects mentioned in those descriptions.

I'm not 100% positive if the third level is 3) or if the the initial room mention counts as one. But the point is, it's not just all objects in the initial description that need descriptions themselves, but any objects then mentioned in (minimally) those descriptions.

In my reading of the int fic forums, that's the expected behavior by people who play a lot of TA. It's up to you how much you wish to follow that!

That doesn't mean there isn't plenty of debate and room for opinions. Here's a link I just found with IF discussions in general:

http://www.ifwiki.org/index.php/Past_raif_topics:_IF_Theory:_part_1

If you search for "descr" on that page, you can find a number of discussion threads about descriptions. And I haven't even read them all myself (or many perhaps).

Well that's certainly worth scouring through when I have the time.

As for your three rule system, I suppose it depends on individuals' definition of 'object'. Are the floor, ceiling and walls objects? Are the panes of glass in a window, described as 'a small window with four panes of glass, objects? Like I say, depending on the individuals' definition of object, expectations could get very silly indeed.

Pertex, I'm not sure I understand your post, and how your method would differ from creating objects that would naturally want to be examined and letting my custom default response take care of the scenery?

It's really easy: every noun in your game should have a description. This would be optimum but is not really achievable.

I have created a demo for my idea here : https://gist.github.com/Pertex/82bb79cc37e983e50e88b63681e7a28a

I imported the UnresolvedCommand function and the lookat command and changed it a bit (you will find the changes). So now you only need the string attribute "sceneryobjects" in your rooms with a list of all words which should be handled like scenery objects. If the player looks at one of this "objects" it prints one of the answers from the dictionary game.lookanswers

This is just a fast written demo and you can't edit the lookat command in the Quest editor any more.

"Are the floor, ceiling and walls objects? Are the panes of glass in a window, described as 'a small window with four panes of glass, objects? "

Generally, yes. If you give the words to the player, then the player will use the words. If you say there are four panes of glass, then you have explicitly called out the panes of glass, and the player will want to explore them, since you as the author felt they were interesting enough to mention. I know as a player, that would indicate something to me, and so I would try to examine them. And I don't consider that unreasonable. Whether you decide to actually author a description for something you yourself mention depends on whether you want to run the risk of disappointing the player.

I don't know if when you refer to walls, floor and ceiling if you mean something the player implicitly knows or something you have mentioned in your description. I would think that if you haven't mentioned them, then the player should not expect much from them. If you have explicitly mentioned them in your description, then it's not unreasonable for the player to want to explore them further and expect the author to have implemented that obvious exploration.

One thing you may notice if you read through some of those articles is a recurring point by some which is that if something isn't important enough to have a description, then perhaps it shouldn't be in the room description to begin with. That can be a bit harsh, but it has some validity as a thought (not necessarily a dictate). It might end up, then, that room descriptions would be considered too bare without something to flesh them out, at which point it becomes, yes, you do want to flesh them out. So then flesh them out!

(It's quite possible that this discussion will reach no conclusion as I feel we're approaching it from different points of view. Assuming I can speak to my interpretation of your viewpoint, you're coming at it from an authorial point of view whereas I'm looking at if from the player's point of view. They're both valid viewpoints, but they can conflict if it comes down to the finite time an author has vs the infinite world a player would love to have. Obviously, an author can't implement everything, but it does pay to consider what a player will expect in terms of basic things like nouns mentioned in a room description being further defined. Yes, it can be a pain, but that's part of the job of creating IF/TA if you want to create something that others will consider well crafted. Others in some of those threads have mentioned parallel ideas in other languages to what you have mentioned. The response is generally (to the extent I have grok'ed it all) that it's ok as a safeguard, but not necessarily as a design principle, especially when it comes to things mentioned in a main room description.)

Well I've learned a fair bit in this thread alone, relating to an author vs player viewpoint. What I can take from this, is that a compromise between the game's descriptions and what in that room the player should be able to examine, must be met.

I'd also agree your 'rule of thumb' which states that as an author, if you don't want your player examining certain objects, don't mention them, is a good one, but it's by no means ideal. "A fully-furnished living room" doesn't mention ANY objects, but wouldn't a player find it odd to get a response of "I can't see that." if they tried 'x couch' ?

I think all I was ever saying when I started this thread, is that "I can't see that." is perhaps not the best default response to have been used, as it only ever works and makes sense when a player tries to examine an object that explicitly doesn't exist.

Pertex, I'm just about to load that game up to see what's going on. Thank you.

Pertex, just tried your game and immediately found problems - not by way of errors, but logic.

In the very first room, for which the description is:

You are standing in an wonderful forest, old trees are standing along a dark path, squirrels are hunting butterflies and a near well spots water on mushrooms.

I'm told I can see neither the trees nor the mushrooms.

This is exactly what my custom 'unresolved' response avoids.

Here's my approach (and I'm not sure how this works in Quest, as I haven't used it).

There are a few all-purpose scenery objects to catch unmentioned but presumably present things like sky, ceiling, floor, and so on. In Inform it's possible to make an object (called a backdrop) that is present in multiple locations, or in every location, so you only have to make these objects once.

If an object is mentioned in the room description, or in a description of another object, there should be some sort of non-generic response for examining it. If an object is important, it gets its own description. If it's mentioned, but not important in its own right, it can become a synonym for the thing it's part of. For instance:

>look
You're in a cramped garden shed. A broken wheelbarrow lies in one corner.

>x wheelbarrow
This wheelbarrow has seen better days. The wheel has come completely off.

>x wheel
This wheelbarrow has seen better days. The wheel has come completely off.

By making "wheel" a synonym for "wheelbarrow," you get a non-generic response for examining the wheel, but you don't have to write a separate description for it. And it also acts as a subtle hint to players that the wheel is not something they need to interact with separately.

But this only gives the same response because Quest sees x wheel as the same thing as x wheelbarrow, in exactly the same way it would see go li as the same thing as go living room

In fact, in your example, you wouldn't need to give wheelbarrow the synonym of wheel to get this response.

If you use a different example and say:

>look
You're in a cramped garden shed. There's an old box here with an ornate latch.

>x box
It's a small box, about the size of a jewellery box, and features an ornate latch.

>x latch
It's a small box, about the size of a jewellery box, and features an ornate latch.

In other words making latch a synonym of box won't work.

"I'd also agree your 'rule of thumb' which states that as an author, if you don't want your player examining certain objects, don't mention them, is a good one, but it's by no means ideal. "A fully-furnished living room" doesn't mention ANY objects, but wouldn't a player find it odd to get a response of "I can't see that." if they tried 'x couch' ?"

I definitely agree with you that "I can't see that." is not a good default response, for all the reasons you've stated and more! ("That" implies that the game has understood and is replying to the content of what you said. But if you type nonsense like "x tywqksdmn", then "I can't see that" is a nonsense response, because the game is acting as if it knew what you were talking about when it's actually gibberish. A human being would reply, "What the heck are you talking about?" But it can only do so much.)

Another thing I'll mention just since I've read it (but I have a hard time agreeing completely, though I can see the wisdom at times) is avoiding being a slave to realism. Sometimes authors will completely populate a room with items just because they would be there in real life even though they have absolutely no function in the game. It is a fine line to walk, between having enough detail to make it interesting (and "realistic") without having to add every single detail the real world would have. A parallel example for me is how the Enterprise seems completely real in Star Trek even though we never see a toilet, presumably because they play no part in the stories. We can assume they're there, but there's no loss of realism if we don't actually see them. :)

there's probably better designs, but here's something you can do, an example:

<command name="response_command">
  <pattern>response #text#</pattern>
  <script>
    if (Contains (game.pov.parent, text)) {
      object_variable = GetObject (text)
      if (HasAttribute (object_variable, "look")) {
        if (TypeOf (object_variable, "look") = "string") {
          msg (object_variable.look)
        } else if (TypeOf (object_variable, "look") = "script") {
          invoke (object_variable.look)
        }
      } else if (HasAttribute (object_variable, "description")) {
        if (TypeOf (object_variable, "description") = "string") {
          msg (object_variable.description)
        } else if (TypeOf (object_variable, "description") = "script") {
          invoke (object_variable.description)
        }
      } else {
        msg (StringListItem (response_object.default_response_stringlist_attribute, GetRandomInt (0, ListCount (response_object.default_response_stringlist_attribute) - 1)))
      }
    } else if (HasAttribute (game.pov.parent, response_stringdictionary_attribute)) {
      if (DictionaryContains (game.pov.parent, response_stringdictionary_attribute, text)) {
        msg (StringDictionaryItem (game.pov.parent.response_stringdictionary_attribute, text))
      } else {
        msg (StringListItem (response_object.default_response_stringlist_attribute, GetRandomInt (0, ListCount (response_object.default_response_stringlist_attribute) - 1)))
      }
    } else {
      boolean_variable = true
      foreach (object_placeholder_variable, GetDirectChildren (game.pov.parent)) {
        if (HasAttribute (object_placeholder_variable, response_stringdictionary_attribute)) {
          if (DictionaryContains (object_placeholder_variable, response_stringdictionary_attribute, text)) {
            boolean_variable = false
            msg (StringDictionaryItem (object_placeholder_variable.response_stringdictionary_attribute, text))
          }
        }
      }
      if (boolean_variable) {
        msg (StringListItem (response_object.default_response_stringlist_attribute, GetRandomInt (0, ListCount (response_object.default_response_stringlist_attribute) - 1)))
      }
    }
  </script>
</command>

<object name="response_object">
  <attr name="default_response_stringlist_attribute" type="list">
    <value>YOUR_CREATIVE_DEFAULT_RESPONSE_1</value>
    <value>YOUR_CREATIVE_DEFAULT_RESPONSE_2</value>
    // etc <values>
  </attr>
</object>

// your various Objects (if desired for them) would need a 'response_stringdictionary_attribute' Stringdictionary Attribute. I can try to explain how to set up and how they work and what they do, if you need help on using Dictionary Attributes. The various 'text' inputs would be your 'keys' for the Dictionary Attribute, and then you give them their responses as the 'values' for each of those 'keys'

// I can include code for handling the use of a Scriptdictionary Attribute as well, if interested

Thanks, hege. Without wanting to sound lazy and as though I want results without putting the work in, I was originally looking for way to simply have Quest handle objects in a more logical way.

I clearly haven't achieved that when you look at the thread and how many different opinions there are relating to what the response should be, what should and shouldn't be considered an object, what the author's responsibilities are, etc etc.

However, when you consider how laborious a task making these games is, I really don't want a method which requires me to do even more work on objects each time I create them, such as adding a Stringdictionary Attribute. If I could just make a one-off global command with the above and leave it at that, then maybe it would be worth implementing, but I'm really not prepared to start adding more scripts and conditions to each and every object I create.

this actually reduces the work greatly (assuming it works perfectly, lol), as this is really versatile. If you want, you can just add default responses to the 'response_object' Object's 'default_response_stringlist_attribute' Stringlist Attribute. Or, you can add terms (what someone would type in for the 'response #text#', our 'look/examine' custom 'response_command' Command) to the Room Object's 'response_stringdictionary_attribute' Stringdictionary Attribute, and add in the response for those terms, as well. Lastly, you can have your Objects within the Room Object have the same as the prior sentence. You can decide on how much detail (how many Objects and/or layer of Objects have info/details/descriptions/responses/default-repsonses to them). Also, I can add/adjust my code for also being able to do the same for the 'response_object' Object, having a Stringdictionary Attribute with terms and their responses, if you only want to deal with a single Object to handle all of the possible terms one playing the game might try or that you mention about as terms they can get more details (or a default response) about.

I'm told I can see neither the trees nor the mushrooms.
This is exactly what my custom 'unresolved' response avoids.

If you would check the code and would add 2 letters to the attribute everything would work fine. But you don't seem to be interested in the idea how to do it but to get the complete solution on a silver platter. Sorry, in that case I am out.

Fair enough, but perhaps if you'd made this clear in your post I'd have known. I'm not a mind-reader.

You shouldn't assume everyone knows and understands the inner workings of Quest to the extent you do.

I know I'm not alone in feeling that whatever I describe in a room, must be made into an object in case the player wants to look at it.

Unless I want someone to be able to pick something up and do stuff to it, I just use keywords for those sorts of objects. That way, there aren't a ton of objects in my room, but if they see something in a description, they can still look at it. Example is:

You are standing in a room. Red curtains hang on one window, a coffee table stands in a corner, and a ratty couch leans against the far wall.

in that I would use keywords for red, curtains, hang, window, coffee, corner, ratty, couch, wall. Because people might reasonably want to type look ratty look far look corner

But the only thing I want them to actually interact with is the table, so it's the only actual object in the room.

look table
You see a table
look at table
There's a letter on the table
get letter
you can't get it
look letter
It's addressed to ...

like that