Oh that’s way less convoluted than what I was thinking I had to do, thank you. I also didn’t realize that non-boolean properties could just be used as adjectives like that. So I’m guessing you can’t have multiple properties have the same value?
Follow-up question: what would be (other than using a bunch of if statements) a way to implement a more general color mixing system? I was trying to figure out if there was a way to create a more abstracted system for mixing colors (a very simple additive color system that works on two colors).
No, you can use the same kind of value for more than one property, but you’d have to name that property and you wouldn’t be able to use it as an adjective like above.
An animal has a color. [<- this creates a property with the same name, "color," as it's kind of value]
An animal has a color called favorite color. [<- this creates a second property using the same KOV]
The description of an animal is usually "[The noun] has fur of [color], but prefers [favorite color].".
Tom is a grey animal in the Lab. [creates an animal with grey as its color property]
The favorite color of Tom is brown.
let L be a list of colors;
repeat with the creature running through animals in the location:
add the color of the creature to L. [add "if absent" if you don't want repeats]
But as a general rule, I’ve found you seldom need actual lists (as in the data type) in I7, and it’s often more idiomatic to solve it a different way instead.
lab is a room.
color is a kind of value.
the colors are brown, red, orange, yellow, blue, green, indigo, violet.
a color has a relation of a color to a color called the mixmaster.
to (c1 - color) mixed with (c2 - color) is (c3 - color):
now the mixmaster of c1 relates c2 to c3;
now the mixmaster of c2 relates c1 to c3;
to decide what color is (c1 - color) mixed with (c2 - color):
if c2 relates to a color by the mixmaster of c1, decide on the color that c2 relates to by the mixmaster of c1;
when play begins:
red mixed with blue is violet;
say "red + blue = [red mixed with blue].";
say "blue + red = [blue mixed with red].";
say "orange + green = [orange mixed with green].";
produces
red + blue = violet.
blue + red = violet.
orange + green = brown.
Inspired by @zarf, I came up with this. Not perfect (the secondary colors dominate when mixed with any primary, for example) but you get the idea.
Lab is room.
A color is a kind of value.
white, blue, yellow, green, red, violet, orange, and brown are colors.
To decide what color is (c1 - a color) mixed with (c2 - a color):
(- (({c1}-1) | ({c2}-1) + 1); -).
When play begins:
repeat with first running through colors:
repeat with second running through colors:
say "[first] mixed with [second] is [first mixed with second].".
I tried to use relations at one point but couldn’t figure out how to make it work (still fairly new to this language and struggling through learning its various features).
@zarf’s bitwise idea feels like the most elegant solution here
This is perhaps the most convoluted use of relations I’ve ever seen. Even experienced Inform users generally don’t know that it’s possible! So don’t worry about that part.
Yeah, what Daniel said. My code would compile but not work in 9.3/6M62. To my knowledge, relations as properties don’t work at all before 10.1, and in 10.1’s two years now of existence, I don’t think I’ve seen anyone else use them.
Inform’s “Everything is an X”: relations and rules
[…]
For Inform, there are two big ideas: relations and rules.
I think it’s the case that something like my solution is actually “meant to” be the Inform-ish approach to a problem like this (or, at very least, that there’s a defensible argument for such).
Unfortunately, the docs are so opaque and omit so much detail you need to actually have a shot of knowing what’s possible and how to express that in code, that relations’ use tends toward the simplistic.
This is a valid way to do it, I guess it just feels… inelegant? Like, color mixing should be commutative (you shouldn’t have to account for both “red and blue” and “blue and red”). That said, a table approach would probably be the most flexible in terms of things like where one of these glowing chameleon things in my game is in its “off” cycle” but the other one is red (thus the room’s color would be a “dim red.”)
At a certain point one might as well just use RGB hex values to accomplish all of this, and maybe I’ll think about that as an extension idea one day when I’m more familiar with Inform 7.
This has the flexibility a rulebook offers, but counts on the author stating the rules with the colors in ascending order.
lab is a room.
color is a kind of value.
the colors are brown, red, orange, yellow, blue, green, indigo, violet.
color-mix is a list of colors that varies.
blending is a rulebook producing a color.
blending when color-mix is { red, blue }: rule succeeds with result violet.
last blending: rule succeeds with result brown.
to decide what color is (c1 - color) mixed with (c2 - color):
if c1 is c2, decide on c1;
truncate color-mix to 0 entries;
add c2 to color-mix;
if c1 < c2, add c1 at entry 1 in color-mix;
else add c1 to color-mix;
decide on the color produced by blending;
when play begins:
say "red + blue = [red mixed with blue].";
say "blue + red = [blue mixed with red].";
say "orange + green = [orange mixed with green].";
Hat tip to @OtisTDog, who showed me this trick when I was a noob.
