I7: Understanding through tables(?)
Perry The Cynic
Color is a kind of value. 15/15/15 specifies a color with parts R,
G, B.
Table of Colors
Color Name Color Value
white 15/15/15
black 0/0/0
blue 0/0/15
orange 15/8/8
[and so on]
The idea, of course, is that I can calculate with Color values for
blending, overlaying, etc. and still use the nice human-readable names
in text.
Turning a Color into pleasing text is not hard:
To say the natural name of (c - a color):
if c is a color value listed in the table of colors, say the color
name entry;
[do approximations, or as a last resort...]
otherwise say "[c]".
The approximation code here can produce names like "a very light
chartreuse" (chartreuse with extra white component), and such. Pretty
nice, particularly when you add alpha ("a watery, dark shade of
crimson" = darker than natural crimson, with partial transparency).
But how about the other direction - understanding color names? I'd
love to write a "To understand" rule (the obverse of "To say"), but
that doesn't seem available. That leaves me with something like this:
Color name is a kind of value. The color names are defined by the
Table of Colors.
But now I've got two value types, and no way to mediate between them.
I'd like to say something like
Understand "[color name]" as "<the color value of it> [tint]"
but I have no clue how to say that in I7. Section 16.13 explains how
to understand a value, but shows no way to actually involve a
computation of any kind.
I could turn this around and assign color names (rather than values)
to things, using the values only for computation as needed. But then
things could only have named colors, no in-between ones (no "light
chartreuse"), and I'd be forced to fill the color space with names for
all (reasonable) colors, which might be rather memory-intensive, no?
(The 15/15/15 space has 4096 possible colors.)
Any advice?
bal...@excite.com
I think you will need a color name value for every color you want to
parse, otherwise you would have to write a specialized parser
especially for your color names (probably in I6). You could use
adjectives to modify color values to darker and ligher shades.
Here's a possible solution using the 'after reading a command' rule:
"Paintshop" by Banbury
TestRoom is a room.
Color is a kind of value. 15/15/15 specifies a color with parts R, G,
B.
Color name is a kind of value. The color names are defined by the
Table of Colors.
Table of Colors
Color Name Color Value Color Text
white 15/15/15 "15/15/15"
black 0/0/0 "0/0/0"
blue 0/0/15 "0/0/15"
orange 15/8/8 "15/8/8"
To say the natural name of (c - a color):
if c is a color value listed in the table of colors, say the color
name entry;
otherwise say "[c]".
The box is in the TestRoom. The box has a color. The color of the box
is 15/15/15.
Rule for printing the name of the box:
let c be the color of the box;
say "[the natural name of c] box".
Coloring is an action applying to one thing and one color. Understand
"paint [something] [color]" as coloring.
Instead of coloring the box:
change the color of the box to color understood;
say "You paint the box [the natural name of color understood]."
After reading a command:
if the player's command includes "[color name]" begin;
repeat through the Table of Colors begin;
let s1 be the color name entry;
let s2 be the color text entry;
if the color name understood is s1 then replace the matched text
with s2;
end repeat;
end if.
Emily Short
> I am trying to model colors in some detail. Here's the sketch:
> I could turn this around and assign color names (rather than values)
> to things, using the values only for computation as needed. But then
> things could only have named colors, no in-between ones (no "light
> chartreuse"), and I'd be forced to fill the color space with names for
> all (reasonable) colors, which might be rather memory-intensive, no?
> (The 15/15/15 space has 4096 possible colors.)
This sounds a bit like what I did in the liquid-mixture example
("Noisy Cricket").
My method was to create separate properties for the main name and any
modifying adjectives -- so for instance you might have here a main
color which could be chartreuse, crimson, etc., and a secondary
adjective that could be light, very light, dark, and so on. Then I did
the calculations to assign these properties to objects whenever the
objects changed, and let Inform handle the understanding.
Does that seem workable? If not, I may not be understanding fully what
you want to do.
Perry The Cynic
> On Mar 6, 12:34 am, "Perry The Cynic" <perry.cy...@gmail.com> wrote:
>
> > I am trying to model colors in some detail. Here's the sketch:
> ...
> > I could turn this around and assign color names (rather than values)
> > to things, using the values only for computation as needed. But then
> > things could only have named colors, no in-between ones (no "light
> > chartreuse"), and I'd be forced to fill the color space with names for
> > all (reasonable) colors, which might be rather memory-intensive, no?
> > (The 15/15/15 space has 4096 possible colors.)
>
> This sounds a bit like what I did in the liquid-mixture example
> ("Noisy Cricket").
I remember that one, yes.
> My method was to create separate properties for the main name and any
> modifying adjectives -- so for instance you might have here a main
> color which could be chartreuse, crimson, etc., and a secondary
> adjective that could be light, very light, dark, and so on. Then I did
> the calculations to assign these properties to objects whenever the
> objects changed, and let Inform handle the understanding.
>
> Does that seem workable? If not, I may not be understanding fully what
> you want to do.
It seems perfectly workable for any one particular application. But
part of my purpose is to explore what can and cannot be done in I7. I
am trying to create a "concept of color" in the form of an extension
that can be applied to different things in different circumstances.
Sort of an abstract color concept, rather than an application of color
to a particular kind of thing. I'm still in that state where I'm
reaching for all the building blocks of the language and wondering
which one I have to turn upside down to get what I want. (It certainly
hadn't occurred to me to use an After reading activity to rewrite the
input, as has already been suggested.)
I want to achieve a degree of separation between the objective nature
of a color and its presentation to the player. That is, I want the
colored things to operate in terms of RGBA color coordinates, and the
subjective presentation (including modifiers such as light and watery
and greenish) to be a function of the circumstances (ambient light,
color blind player, etc.) so that the objective operations (mixing,
projecting, lighting) are independent of these modifiers and don't
have to change with the nature and circumstances of the observer. So
I'm trying to cram all of the objective nature of a color into a
single value type, with all the modifiers and ancilliary descriptors
part of the presentation (To say ...) and parsing (that's where I'm
baffled).
I realize I'm over-engineering this. If the general verdict is "you
just don't do this kind of thing in I7," I'll back off. But it seemed
a reasonable thing to at least try.
[There is a deeper question lurking here: whether I7 actually believes
in separating an objective world model from a subjective observation
model, as simulations tend to do; or whether the ethos of IF calls for
wholesale creation of only a subjective world with no independent
objective foundation. But that's a different post. A long one. :-)]
Cheers
-- perry
Emily Short
> > Does that seem workable? If not, I may not be understanding fully what
> > you want to do.
>
> It seems perfectly workable for any one particular application. But
> part of my purpose is to explore what can and cannot be done in I7. I
> am trying to create a "concept of color" in the form of an extension
> that can be applied to different things in different circumstances.
> Sort of an abstract color concept, rather than an application of color
> to a particular kind of thing. I'm still in that state where I'm
> reaching for all the building blocks of the language and wondering
> which one I have to turn upside down to get what I want. (It certainly
> hadn't occurred to me to use an After reading activity to rewrite the
> input, as has already been suggested.)
What I'm suggesting is essentially that you add some rules (separate
from your rules for managing the 15/15/15-style stuff) that would
determine what color terminology applies to the things in scope, and
put labels on them accordingly. If you're writing an extension, you
could define your properties in a table, and allow the author of the
game to extend the table to add more color-names of his own, for
instance; you could also let the author write and/or overwrite the
rules that subjectively assign color names to objects. Those rules
could also vary depending on the player perceptions you want to
support at the moment. I'm not sure this need undermine the
objectivity of the model, since you're still preserving the objective
data you've had all along; you're just also associating the subjective
terminology with the objects from moment to moment, rather than
locating it all in routines for printing and parsing.
Another way of handling understanding-with-calculations is to write
"Understand "cerulean" as a thing when the item described... [insert
routine here]." But this is likely to be very crunchy -- tedious to
write and slow at runtime -- if you want to handle a large number of
possible color names.
And for what you're describing -- converting a bit of text into a
numerical descriptor in different ways at different times depending on
the player's current state of perception -- I think I agree that
"after reading..." might also be a reasonable time to intervene.
Still, I prefer the method of assigning descriptive properties to
objects (even if these properties correspond to transient/subjective
features) because this means that it's easier to guarantee that the
saying and understanding aspects of the system are in sync.
> I realize I'm over-engineering this. If the general verdict is "you
> just don't do this kind of thing in I7,"
No no: I wouldn't say that. On the contrary, I tend to find I7
friendlier for this kind of task than I6.
> [There is a deeper question lurking here: whether I7 actually believes
> in separating an objective world model from a subjective observation
> model, as simulations tend to do; or whether the ethos of IF calls for
> wholesale creation of only a subjective world with no independent
> objective foundation. But that's a different post. A long one. :-)]
I7 has no opinion on this. And I'm not sure what Graham would say.
I -- speaking personally, and not as some kind of oracular voice of
the system -- would come down somewhere in the middle: I tend to think
one should model exactly as much information as is going to be
interesting once presented subjectively to the player. But this can
mean having a more-objective model underlying the representation, if
we're going to shift perspectives during the course of the narrative,
or if we're going to perform calculations on the objective model that
the player will be able to observe in the long term. For instance: the
player might only be able to observe on a given turn that it is sunny,
cloudy, raining, or snowing, but we might have an underlying model
that keeps track of weather trends over time and ensured that we
didn't go from snowing to sunshine too quickly or frequently; and this
behavior of the model would be evident to the player over multiple
turns, even if from moment to moment he could not see the numbers and
equations controlling the weather.
I also think that it is sometimes easiest, for IF purposes, to
represent information within the model in the form of words, since
both the input and the output will also be verbal. But there are lots
of exceptions, and your color-mixing model seems like a fine example.
JDC
>
> And for what you're describing -- converting a bit of text into a
> numerical descriptor in different ways at different times depending on
> the player's current state of perception -- I think I agree that
> "after reading..." might also be a reasonable time to intervene.
>
> Still, I prefer the method of assigning descriptive properties to
> objects (even if these properties correspond to transient/subjective
> features) because this means that it's easier to guarantee that the
> saying and understanding aspects of the system are in sync.
One place where you would need something like "after reading a
command" is if you want to understand the colors independently of any
objects, e.g.
> paint the walls cerulean blue
I've thought about this a bit and can't come up with a better solution
(a few slight modifications to what was posted, but nothing
significantly better). It seems that having a way of creating GPRs in
Inform 7 would be the only really effective way to handle this sort of
thing.
-JDC
Ryusui
pigments, wouldn't it make more sense to use a subtractive system like
CMYK? RGB applies to light, not paint: mixing a spectrum of colors
might result in a 15/15/15, or close to it, which would be white in an
RGB model but black in CMYK (or real life, for that matter).
Perry The Cynic
The matter is actually rather complicated, and I made a conscious
choice not to get bogged down in the technicalities. CMY is a good
representation for modeling overpaint (putting one layer of pigment
over another, already dry layer). Mixing (blending) is a different
operation altogether (both RGB and CMY can do that), and lighting
calls for RGB. Technically I should convert between RGB and CMY spaces
as needed, adjusting for the gamuts of the actual pigments and media
involved, and using the IEC spaces to model perceptional (eye/brain)
characteristics. (Oh, and *painters* use a different set of primary
colors altogether, in apparent defiance of physics.)
To the extent that you're pointing out that things aren't as simple as
just making all colors RGBA tuples, you are, of course, quite correct.
Cheers
-- perry
Perry The Cynic
> Table of Colors
> Color Name Color Value Color Text
> white 15/15/15 "15/15/15"
>
> if the player's command includes "[color name]" begin;
> repeat through the Table of Colors begin;
> let s1 be the color name entry;
> let s2 be the color text entry;
> if the color name understood is s1 then replace the matched text
> with s2;
> end repeat;
> end if.
I understand that "replace the matched text" requires text, but is
there really no way to generate text in I7 at all? It seems weird that
I have to make two different columns in my color table just so I get a
text and a value version of the color names. I dimly remember I6
having a "say to string" function (instruction? whatever). Is there
really nothing in I7 to turn a symbol (atom, name, whatever) into
text?
Thanks
-- perry
JDC
> I understand that "replace the matched text" requires text, but is
> there really no way to generate text in I7 at all? It seems weird that
> I have to make two different columns in my color table just so I get a
> text and a value version of the color names. I dimly remember I6
> having a "say to string" function (instruction? whatever). Is there
> really nothing in I7 to turn a symbol (atom, name, whatever) into
> text?
There is; here you have to be a bit tricky because you areputting the
text into a snippet and not just printing it to the screen. The
following is a slight modification that pmits the text entries (and
also gives some idea of how you could intercept things like "light
blue", etc.). And I couldn't explain to you why exactly a global
variable (cv) works here when a local variable doesn't, but that seems
to be the case:
<code>
"Paintshop" by Banbury
TestRoom is a room.
Color is a kind of value. 15/15/15 specifies a color with parts R, G
(without leading zeros), B (without leading zeros).
Color name is a kind of value. The color names are defined by the
Table of Colors.
Table of Colors
Color Name Color Value
white 15/15/15
black 0/0/0
blue 0/0/15
orange 15/8/8
To say the natural name of (c - a color):
if c is a color value listed in the table of colors, say the
color name entry;
otherwise say "[c]".
The box is in the TestRoom. The box has a color. The color of the box
is 15/15/15.
Rule for printing the name of the box:
let c be the color of the box;
say "[the natural name of c] box".
Coloring is an action applying to one thing and one color. Understand
"paint [something] [color]" as coloring.
Instead of coloring the box:
change the color of the box to color understood;
say "You paint the box [the natural name of color
understood]."
cv is a color variable.
After reading a command:
if the player's command includes "light [color name]" begin;
say "(light color)";
if the color name understood is a color name listed in the Table of
colors begin;
change cv to the color value entry;
let rv be the R part of cv; let gv be the G part of cv; let bv be
the B part of cv;
if rv < 15, increase rv by 1; if gv < 15, increase gv by 1; if bv <
15, increase bv by 1;
change cv to the color with R part rv G part gv B part bv;
replace the matched text with "[cv]";
end if;
end if;
if the player's command includes "[color name]" begin;
if the color name understood is a color name listed
in the Table of colors begin;
change cv to the color value entry;
replace the matched text with "[cv]";
end if;
end if.
Test me with "paint box light blue / paint it black".
</code>
-JDC
Perry The Cynic
> On Mar 7, 8:51 pm, "Perry The Cynic" <perry.cy...@gmail.com> wrote:
> text into a snippet and not just printing it to the screen. The
> also gives some idea of how you could intercept things like "light
> blue", etc.). And I couldn't explain to you why exactly a global
> variable (cv) works here when a local variable doesn't, but that seems
It makes a perverse kind of sense, now that you point it out. It seems
that text in I7 is indeed entirely static - all text is literally made
at compilation time. But at some point at runtime, brackets are
substituted-for to generate the actually-used text, and thus "[cv]" in
your sample turns into "whatever cv is when said." Local variables
only live until their phrase finishes, but the substitution of "[cv]"
happens after that; the replace phrase only splices "[cv]" (literally)
into the stream-of-snippets that is the player's command, and
substitution happens after all "after reading" rules have completed.
What a glorious mess. Thank you for pointing it out. I didn't really
understand how "[foo]" really works in I7. I probably still don't, but
I'm getting closer. :-)
Cheers
-- perry
JDC
Ah, yes, I knew that :). I started teaching myself a bit of Scheme
over the weekend, and got my bindings confused...
-JDC
Andrew Plotkin
> On Mar 7, 6:44 pm, "JDC" <j...@psu.edu> wrote:
> > On Mar 7, 8:51 pm, "Perry The Cynic" <perry.cy...@gmail.com> wrote:
> > There is; here you have to be a bit tricky because you are putting the
> > text into a snippet and not just printing it to the screen. The
> > following is a slight modification that permits the text entries (and
> > also gives some idea of how you could intercept things like "light
> > blue", etc.). And I couldn't explain to you why exactly a global
> > variable (cv) works here when a local variable doesn't, but that seems
> > to be the case [...]
>
> It makes a perverse kind of sense, now that you point it out. It seems
> that text in I7 is indeed entirely static - all text is literally made
> at compilation time. But at some point at runtime, brackets are
> substituted-for to generate the actually-used text, and thus "[cv]" in
> your sample turns into "whatever cv is when said." Local variables
> only live until their phrase finishes, but the substitution of "[cv]"
> happens after that; the replace phrase only splices "[cv]" (literally)
> into the stream-of-snippets that is the player's command, and
> substitution happens after all "after reading" rules have completed.
That is correct.
If you look under the covers, you'll see that "[cv]" actually compiles
as a function, which prints the global variable cv. Saying the
"string" calls the function. Functions and strings can be interchanged
(fairly) freely at the I6 level.
(And "...[cv]..." would compile as a function which printed the static
text "...", followed by cv, followed by "..." again.)
It is, indeed, a mess. But it works startlingly well, considering that
the "natural" way to think about IF is in terms of Perl-style powerful
string manipulation.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're an American.
Perry The Cynic
> It is, indeed, a mess. But it works startlingly well, considering that
> the "natural" way to think about IF is in terms of Perl-style powerful
> string manipulation.
And that's probably the core of my problem, right now. Being quite new
to (the writing of) IF, I think of it in simulation terms, with a self-
running world model filtered by observers. (In other words, I think of
my IF programs in terms of *meanings*, with the text being their
outflow, rather than the primary thing.) Which, I'm rapidly coming to
understand, is not how many (most?) IF authors see it at all.
Fascinating.
-- perry
Andrew Plotkin
I don't think this discussion demonstrates that. You were asking about
text, so we've been talking about text. The question of what programs
are primarily made of is another topic. I don't think of the text as
the primary structure.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation,
it's for one reason: they don't feel like it. Not because you're patriotic.
Richard Bos
> It is, indeed, a mess. But it works startlingly well, considering that
> the "natural" way to think about IF is in terms of Perl-style powerful
> string manipulation.
Might I say that I'd prefer Icon-style? Perl is... urgh. Tentacles all
the way down to the[1] core implementation.
Richard
[1] The definiteness of this article is bad enough as it is.
Hector Rodriguez
of got sidetracked a bit. The question pertains to how I7 can be used
to represent both subjective knowledge and objective facts. The
example of color is interesting because the subjective experience of
it need not match the physical facts. The same applies to time, and so
many other issues. Is there a general approach that folks have found
useful in tackling the difference between objective features and
subjective qualities? I mean a way of representing what a character
knows, believes, feels, etc..
Michael Martin
Not really I7-specific, but I often keep a set of variables around
based on
what the character knows or has experienced. This is then (in I7)
used
in clauses like [if the hero got brainwashed in episode 2] or whatnot
to
give different room and object descriptions, or action replies. That
way
the PC's internal monologue changes based on his or her emotional
state.
I haven't actually used it, but Eric Eve's "Epistemology" extension
for
I7 may make talking about such things easier.
--Michael
Hector Rodriguez
>
> I haven't actually used it, but Eric Eve's "Epistemology" extension
> for
> I7 may make talking about such things easier.
>
is very nice, but mainly focuses on representing what the player has
seen, is familiar with, etc. It does this by adding properties like: a
thing can be seen or unseen (familiar or unfamiliar, etc.). I wonder
whether this approach can be effectively extended to deal with the
epistemology of NPCs.
Michael Martin
> Thanks, Michael. I've just looked at the epistemology extension, which
> is very nice, but mainly focuses on representing what the player has
> seen, is familiar with, etc. It does this by adding properties like: a
> thing can be seen or unseen (familiar or unfamiliar, etc.). I wonder
> whether this approach can be effectively extended to deal with the
> epistemology of NPCs.
I handle that in my work in progress in a kind of clunky way. I have
a new kind of value, "fact", and then define facts that vary and set
or test them as needed. Since each NPC has their own set of facts, I
don't really bother with relations -- if I had a pool of facts that a
bunch of NPCs could know or not know, then I'd have the knowledge
relation relating one person to multiple facts, and I would need a
fact to be a kind of object instead of a kind of value. As it is,
code like this works:
---
A fact is a kind of value. The facts are known and unknown.
The PC's authority is a fact that varies. The PC's authority is
unknown.
After showing the badge to the witness: now the PC's authority is
known.
Instead of asking the witness about "incident", say "'What can you
tell me about the crime?' you ask.
[if the PC's authority is unknown]She seems skeptical. 'Why should I
talk to you?'[otherwise]She smiles nervously. 'Not a lot. S-S-S-
shall I record a statement or something?'[end if]"
---
Hope this helps.
--Michael