On Scenery Objects

[tajmone]

I've noticed that the implementation of scenery objects is somewhat limited.
Here's the entire source module:

-- "scenery.i"

Every scenery IsA object
  Is
    Not searchable.
    Not takeable.
    Not pushable.
    Not touchable.

  Verb examine, take
    Does only
      "That's only scenery."
  End verb.
End every.

Honor xDesc Attribute

The main problem I see with scenery objects is that in order to produce some text when examining them you need to implement the Verb examine Does only on the specific instance, whereas it would be much easier to separate the examine verb definition above and tweak it to honor an xDesc attribute which is not an empty string (like we did for examine and elsewhere).

It makes sense to me that many scenery objects are usually intended to be examinable, since they are the to provide mood and atmosphere to the game.

Improve Default Message

Also, I'm not quite happy with the "That's only scenery." default response.

1. It should check if the object is plural ("These are...").
2. I'm not quite convinced that word "scenery" is appropriate here:
   • First of all, this terms is mostly known to IF veterans, and a first time player might be puzzled by it.
   • It kind of breaks the narrative illusion, as if remind us that we're in an artificial set, where plants are just fake plastic props, and horizons are just painted backdrops on some wood panel. There must be a better way to deliver the sense that it's not an important item for the game goals, without breaking the illusion of being in a "real narrative world".

I think the goal of the default message is to inform the player that he/she is dealing with an object that plays no significant role in the game (except maybe revealing some info or hinting in the right direction). So, trying to take it, push it, etc., should result in a response that makes it clear that it's not worth attempting further actions because the object has a merely scenic purpose (without being so explicit though).

• Any suggestions as to a good default reponse?

Blocked Attributes vs Verbs Overrides

For the same reasons mentioned above, I can't but notice that scenery objects are trying to prevent actions via attributes negations:

Every scenery IsA object
  Is
    Not searchable.
    Not takeable.
    Not pushable.
    Not touchable.

Although setting those attributes is probably a good practice, I still think that the best approach is overriding as many verbs as possible, to ensure the default (deterrent) response is shown, otherwise these attributes will prevent specific actions without clarifying that attempting other verbs is futile — which might lead to player frustration, especially if he/she is stuck in the game and is going for the "guess the verb" brute force solution to move in the adventure.

Since many verbs share similar syntaxes, it should be possible to override all library verbs with a limited number of verb overrides. The real problem might be that the negated attributes might be triggering CHECKs that will prevent the verbs execution, so overriding the verbs might not work, unless we set all those attribute to true, confiding that our custom DOES ONLY verbs on the class will prevail. Authors should still be able to override via custom DOES ONLY verbs on specific instances (if the need be).

@thoni56:

• do you foresee any problems with either of the above approaches?
• Do you advise one over the other?

Also, the attributes list needs to be checked for it might be incomplete — e.g. I'd add Not wearable, Not eatable, etc., even though these are unset by default, just to be on the safe side.

[thoni56]

I think that the "scenery" implementation is modeled after "That's just scenery." that you find in some games. Things that are there just for ... scenery, not playing any part in the game, not even as a prop. With it, you can go through your location descriptions and create scenery objects for all the nouns. In this way, the player doesn't get "I don't understand the word 'painting'" when the game has just said there was a painting there.

If you have long descriptive texts which mention many nouns, this needs to be as simple as remotely possible.

I feel there is a stylistic variance between "That is just scenery." (that you might want to keep) and a more "illusion preserving" response.

Maybe there is room for something slightly different. Perhaps a type of thing that is fairly easy to create and works as you would expect with descriptions and all necessary verbs.

I just wanted to comment on this, before proceeding.

Expanding on the scenery class to provide all that "protection" is probably a good idea. And, if done inside that class it should not present any further burden on the author. So I think this is a point of possible improvement.

Default Response

Perhaps just expand on the current to

Say The this. "is just part of the scenery."

That fixes issues with forms for the item as such. Still have the "is" though, but that's an easy extension of the suggestion provided that the author can indicate the plural-ness, which shouldn't be an issue:

The plants Isa scenery Is plural. End The plants.

But also, when it comes to "scenery" players might probably disregard any grammatical errors, so I'd say fixing that is only necessary for completeness and perfection ;-)

(Other languages might require other aspects to resolve this, I suppose.)

Blocked Attributes vs Verbs Overrides

It seems like overriding verbs is the safe route to go. Then the default response can be given in unconditional checks for all blocked verbs:

Verb take
    Check <default_response>
End.

Since checks are always run first starting with the most specialized, this will override any general checks, for objects e.g. And then we don't need the negated attributes.

You are probably writing more Alan code than me these days so, I might have missed something.

[thoni56]

First, I'm really sorry for working of memory here which obviously is leading us astray. So thank you for being the "concrete" part in these discussions!

Since I read your previous comment my mind has been wandering a lot around this without any clear conclusions.

I'm primarily deep-diving into the reasons for having the general-to-specific ordering of the checks.

Remember that the initial decision on ordering of verb execution was based on some experience from v2, but that only covered global verb definitions, verbs in the location and the object. But the decision for ordering of execution in v3, with classes and inheritance, was taken without much experience, in particular of writing larger, real, games using those features. It was really only based on logic and inference.

Radical, breaking, thoughts

I might be second-guessing myself too much based on this single example, but I'm considering how we could experiment with the execution order to learn more about what would be the best way.

To me (at this moment, the current "me") the ordering of check execution that I assumed in my proposal feels like the natural order. But I feel I need more anecdotal data, examples, where this would come into play, to do a good reasoning here.

I have also thought about controlling check order specifically, like you suggest. And I also feel that would be complex and stretching things bit too far. It would be acceptable if there was just a few cases where it would be required, not if it actually was the only way to get inherited checks to work the way you mostly wanted.

Analogy with constructors

An analogy would be how object oriented languages allow a constructor to invoke, or not, the "parents" constructor. The constructor is always run with the exact class being instantiated. (This would indicate "start with the most specific".)

The that constructor could invoke the constructor of the parent class at will. In my experience this is usually done before running class-specific code. (This would indicate "start with the more general".) But you might actually invoke it at any time, including last. (This would again be analogous to "start with the more specific".)

What do checks do?

We now have 2 examples of when the current order is an obstacle to "natural" needs. Or maybe 1.5 since StdLib and alan-i18n have the same problem with overriding verbs.

I have only two large-ish game sources on my hands both built on top of StdLib 1.0. Typically they have

ADD TO EVERY THING
  VERB attack
	CHECK target IS examinable
		ELSE 
			IF target IS NOT plural
				THEN "That's not"
				ELSE "Those are not"
			END IF.
			"something you can $v."
	AND target <> hero 
		ELSE "It doesn't make sense to $v yourself."
	AND target NOT IN hero
		ELSE "It doesn't make much sense to $v something you're holding."
	AND target NOT IN worn
		ELSE "It doesn't make sense to $v something you're wearing."
	AND CURRENT LOCATION IS lit
		ELSE "It is too dark to see."
	AND target IS reachable
		ELSE SAY THE target. 
			IF target IS NOT plural
				THEN "is"
				ELSE "are"
			END IF. 
			"too far away."

My imagination is not working well enough to figure out an example where I'd sub-class THING and implement a more specific check for "attack". But that is really what would be needed to research this line of thought thoroughly.

I guess the question is "what problems might there be with a more specific check triggering before a more general?"

The syntax guarantees that the instance is an instance of the correct class and the compiler ensures that all access to aspects of the parameter is legal given that it is of that class, so no crashes should occur.

So it is only "logical" problems that might occur, such as a very specific message is given when some more general aspect should have already been checked. I think this is the reasoning behind the current implementation.

Conclusion

None. Yet. I'm just letting you know where I'm in this at this point. Any contributions, examples, thoughts would be most welcome.

I will probably make a test with "inverted" check executions order just to see what it feels like and perhaps try to use that with one of the games.

[tajmone]

General 2 Specific

Remember that the initial decision on ordering of verb execution was based on some experience from v2, but that only covered global verb definitions, verbs in the location and the object. But the decision for ordering of execution in v3, with classes and inheritance, was taken without much experience, in particular of writing larger, real, games using those features. It was really only based on logic and inference.

I think that the original logic of applying CHECKs from the general to the specific still holds true, and its in line with the WHERE clauses, which are a good example of why and where class checking should be follow that pattern.

But it's also true that inheritance has brought into ALAN new possibilities, and along with them new challenges that can lead to complexity where authors can bump into practical limitations.

I have also thought about controlling check order specifically, like you suggest. And I also feel that would be complex and stretching things bit too far. It would be acceptable if there was just a few cases where it would be required, not if it actually was the only way to get inherited CHECKS to work the way you mostly wanted.

Verbs with Identical Syntaxes Not Allowed

My impression is that this type of problem tends to surface in large games, and more so in libraries and extensions. The question of how to enforce a radically different VERB response and/or behaviour (the former can be achieved via an unconditional CHECK, the latter requires a DOES ONLY) is primarily tied to the order of executions of VERB CHECKs, but not exclusively. We need to keep into account the way SYNTAXes work too — i.e. whether it's possible or not to define another VERB with same parameters but different ID — but doing so would result in the following compiler error:

334 W : Multiple syntaxes are defined with this structure (words and parameters).

E.g. if it was possible to define a take2 SYNTAX and VERB, with identical parameters to take, we could then add VERB take2 to the specific class or instance where we'd like to override the default CHECKs of take, since this would be an entirely different VERB where the CHECKs and verb bodies of take don't apply. But, as we've seen, this is not a viable option.

Obviously, if there was a CHECK BEFORE clause the solution would be very easy and intuitive, since this clause would be used as the exception to the rules, and only when there's a need for the specific to have a better hand on the generic.

Overriding Verbs on Locations

Having said this, it's not as if authors are left without solutions... It's always possible to exploit the natural generic to specific exec order, especially the fact that enclosing locations have precedence over any instances they contain (and their base classes to, all the way up to ENTITY).

So, a simple solution would be to reimplement the VERB on the location class. E.g.:

Add to every location
  Verb take
    Check obj <> fire
      else "Didn't your mum warn you not to play with fire?!"
  End verb.
End Add.

In this case, the take verb will bypass all the default CHECKs on object class, since the current location is always processed first.

Lack of Not IsA Limits

This works fine with specific instances, but if we were to bypass the CHECKs for a whole class (which indeed is our case with the scenery class), we stumble upon the limitations of CHECKs not supporting negative IsA expression — i.e. this won't work:

Add to every location
  Verb take
    Check obj not IsA scenery
      else "That's just part of the scenery."
  End verb.
End Add.

The topic of lack of IsA negation was recently discussed and added to the ALAN repository Issues as a feature request, but this is a practical example of what makes it problematic to handle this type of use case right now, with the current ALAN syntax.

As far as I know, there's currently not workaround to handle CHECKs overriding at the class level. Even using the solution proposed by @AnssiR66 in the StdLib (i.e. to create an all-encompassing location for overriding library defined verbs) doesn't fix the lack of IsA negation — as a matter of fact, all the messages overrides of the specialized StdLib classes are not working, due to this problem (they are there in the code, but the test suite showed that they are never displayed).

General Considerations

So, as you can see, this problem doesn't exist "in a vacuum", so to speak, but has to be viewed in the overall context of the tools available through the ALAN language. Implementing support for negative IsA expression (not IsA or IsA not) would already make this problem much easier to solve — whether the solution should be considered elegant or not is another matter.

So, what would be more elegant and "idiomatic"? having a CHECK BEFORE construct or overriding verbs on locations?

I fell that having BEFORE, AFTER and ONLY clauses for CHECK would feel natural, since these are already available for DOES — and again, these represent exceptions to the rule, and should only be used when the more conservative approach doesn't work.

Implement verbs on locations seems also a reasonable solution, albeit more "hackish" in nature and (possibly) harder to decipher for someone studying an adventure source (requires more abstraction to visualize). Still, it's a good solution, and authors should be aware that encompassing locations (instances or their classes) have execution precedence over their contained instances (when the generic to specific pattern applies). So, if we could use not IsA for class CHECKS, we probably be having this discussion anyway (apart from mentioning changes to the original library code, since these options didn't even exist at the time of its writing).

Analogy with constructors

An analogy would be how object oriented languages allow a constructor to invoke, or not, the "parents" constructor. The constructor is always run with the exact class being instantiated. (This would indicate "start with the most specific".)

That's a good analogy to bring into the conversation, and that's exactly the approach taken by many IF engines (e.g. Hugo, and I think also TADS).

Usually if a constructor (or any inherited method, really) is defined on the instance (or subclass) then that's executed in place of the constructor of its ancestor classes. And the instance/subclass can always invoke execution of the parent's constructor via super (or some similar keyword).

But I'm not sure how this model overlaps with how ALAN inheritance works for VERBs, especially for their CHECKs, since if I've understood correctly CHECKs inheritance simply executes all the CHECKs encountered along the generic-to-specific path (either that or it first scans them and piles them up somewhere before executing them in reverse order). Since CHECKs don't have their own ID, like methods, I don't see how a specific CHECK definition (in a class or instance) could replace another defined elsewhere.

Also, I'm not sure that adopting the OOP constructors model would make things easier for authors, since that would add more complexity. I think that the current inheritance system is easier to understand (despite its limitations) since its much more linear in nature — and the -xml option should produce a structural representation of the adventure which should be easy to read and understand (although the -xml option seems to no longer work right now).

[tajmone]

Converting Scenery to Attribute

@thoni56, after having though the issue through, I think that the best solution would be to convert the scenery class into an attribute. This is also what @AnssiR66 did in the StdLib 2, where in version 1 it was a class (as it had been in ALAN Lib all along); I believe that Anssi stumbled upon the same limitations and realized that it makes more sense to use an attribute instead.

With a scenery class we'd have to re-implement new CHECKs for every verb, on the class (which is what's failing to work); with an attribute, we'd have to add a CHECK to every VERB to prevent the action if the parameter is scenery — either way, it doesn't make a big difference in terms of work, not for us maintainers, nor for end users implementing custom verbs. The only possible downside is that every verb will have a longer series of CHECKs, whereas re-implementing the VERBs on the scenery class would have slightly cleaner, for it would happen all in the scenery module.

When you come to think about it, it doesn't make much sense to implement a whole class for scenery. It's not a specialization of a super class, it's actually the contrary, which is probably why it's giving so many problems.

So, if it's OK with you, I'd like to proceed with the English library, then apply the same changes to the Spanish and Italian libs too.

[thoni56]

Sure. Go ahead!

[tajmone]

Scenery Now an Attribute!

Done! in Foundation English v0.3.0 the scenery class was converted to an attribute. All verbs were adapted accordingly, and full coverage was provided in the test suite.

For the full details, see CHANGELOG and the Foundation Design document (local HTML).