This isn’t part of a game I’m actually making - it’s just a simpler example of a problem I ran into.
An item for sale is a kind of thing. A price tag is a kind of thing. A price tag is part of every item for sale.
A flamingo is an item for sale. An antique desk is an item for sale. On the desk is a vase. The vase is an item for sale.
I think you can see the problem here. Since the desk is a supporter, it cannot also be an item for sale, but I obviously don’t want all items for sale (like a flamingo) to be supporters, neither do I want all supporters to be for sale. And a similar problem would arise if I wanted the vase to be a container, as it should be.
And what if I wanted to take this further:
An item for sale is a kind of thing. A price tag is a kind of thing. A price tag is part of every item for sale.
A Persian piece is a kind of thing. Understand "Persian" or "Iranian" as a Persian piece. Instead of buying a Persian piece, say "The Persian style doesn't appeal to you.".
A flamingo is an item for sale.
A rug and a statue are Persian pieces. The rug and the statue are items for sale.
Again, Persian piece and item for sale are incompatible. I could conceivably want a Persian vase for sale, meaning I’d need it to be a container, an item for sale and a Persian piece. Am I missing something obvious?
Yes, the lack of multiple inheritance can be a nuisance at times but since you’re just tracking simple properties you can just do:
[code]A thing can be for sale. A thing is usually not for sale.
A thing can be Persian. A thing is usually not Persian. Understand “persian” and “iranian” as a thing when the item described is Persian.
The antique desk is for sale. The rug is for sale and Persian.
Instead of buying a Persian thing, say “The Persian style doesn’t appeal to you.”[/code]
See chapter 4.6. in the manual.
Ah, thank you. I did suspect that that could be a solution but I happened to have got the syntax wrong. But what about “A price tag is part of every for sale thing.” That doesn’t work. Apparently ‘every’ can only be used with kinds. Is there a way to get around that?
As a purely aesthetic footnote … a game with 50 items for sale would quickly become tedious. At least, if I were the player I think I’d react that way. As an author, I’d be inclined instead to make the three things that are actually useful to the player into real for-sale items and subsume the rest of the merchandise under some sort of “You glance around briefly, and nothing catches your eye” message.
But that’s just my personal take on it. Other authors may disagree. (And maybe I’m just being lazy!) But if you limit the number of items for sale, creating a price tag for each shouldn’t be too big a burden.
–Jim Aikin
P.S.: Yeah, multiple inheritance. Dang. I don’t actually miss it much, but this is a good example…
You might not like my competition entry then!
But thanks for the comment. I thought, as well as adding realism, it means that the player genuinely has to think about what they do or don’t need; it also lends itself to multiple puzzle solutions and easter eggs.
I sort of like the multiple items for sale thing. I presume you only have a set amount of cash and can’t buy everything? Otherwise I’d just buy everything just in case I need it, which could be tedious. But it would be fun to know I could only afford three things, and to try and understand what they should be.
Then again I’ve also programmed some things which proved unpopular among some, such as unwinnable states.
I’d like that… if it was possible to make more money in some way. Perhaps in a rather tedious fashion that meant you couldn’t close off buying something important, but that would discourage you from trying to buy out the whole store.
Without that, you would be creating… an unwinnable state.
