Sunday, June 30, 2013

Container Theory Part II

Ok, so not long after writing that last post, I remembered one of the main reasons I have long associated "transparent" with "container".

In the example of a snowglobe, if we define it as a non-container, transparent object, it'll work fine with DoPutIn. A container, transparent object would need additional before routines to disallow it. This is part of the reason why yesterday's view of containers sounded appealing to me.

Still, that doesn't change the fact that DoLookIn demands that objects be containers. What's the point of a snowglobe that you can't look into? Anyhow, instead of trying to fix what is and isn't a container, I think I'm just going to fix DoLookIn's grammar.

I could try to do it on the grammar level, using Roodylib's "grammar helper" stuff to only allow containers and transparent items to work on the grammar pass, but I don't like forcing Roodylib users to use extensions like that so I'm probably just going to change DoLookIn's container check to an object token and add all necessary additional code to DoLookIn itself.

On the plus side, this should make coding windows (the glass kind) more intuitive to future authors. On the down side, maybe this change will have some ramifications down the road.

I mean, I could go back to my old container assumptions, but since I've already learned that others find other definitions more intuitive, I don't think that's the right path. I mean, the holy grail of an IF language is to make everything as intuitive as possible.


  1. I don't follow the example of the snowglobe and DoPutIn. I imagine that in a game with a snowglobe object, the default failure message would ordinarily be fine for trying to put things in the snowglobe.

    ....Or, that must be the point. The complication with making an object an open container is that the Hugo Library will want to allow putting things in it by default. So, if you had a snowglobe, and the snowglobe has a miniature snowman inside of it, you might want the snowman to be nested in inventory or other lists, but you definitely don't want the player to store miscellaneous objects in the snowglobe.

    1. Yeah, I was a little unclear since I felt like my description had to build up to the problem. Anyhow, this whole deal is pretty annoying because the existing code *mostly* works. It's just a few instances that annoy me, and I find that even in changing DoLookIn, I'm having to make little changes in other routines like CheckReach. This domino effect makes me wonder if it's even worth it, but ah well, I'm going to try putting it all together and then decide if it's worth putting into Roodylib.