Glk styles: hello again
Andrew Plotkin
Which is to say, time to dig back into this. I admit I still don't
have a brilliant solution in hand, but I can answer the posts that
were left hanging last month.
Here, vaporware <jmc...@gmail.com> wrote:
> On Dec 8, 11:33 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > Jesse:
> >
> > > However, I wouldn't want to sacrifice one person's possible for
> > > another person's pleasant. I get the impression that restricting
> > > games to a finite number of predefined styles was an attempt to make
> > > changing styles pleasant for the player, at the cost of making
> > > certain style changes impossible for the author.
> >
> > Well, yes. And no. The old Glk model for preferences was that the
> > interpreter would show you all eleven styles to customize. Obviously
> > that setup is only possible with a finite number. If the game can
> > raise the limit arbitrarily, sooner or later we'd have a game with
> > hundreds or thousands -- as frequently mentioned last week. Is that
> > dialog impossible to manage or merely very very unpleasant? It's bad
> > enough, anyhow.
>
> Well, in practice, the sort of game that needed thousands of styles
> could easily offer a better interface for customization.
That "easily" conceals a bog of assumptions... if the interpreter is
constructing a preference dialog for the stylesheet, then thousands of
rows is a problem that the game cannot bypass.
> Parametrized styles could be a great solution, though, and I look
> forward to seeing the plan for those.
Yeah, that's what I'm thinking about.
> > In the end, though, my job is declaring some things to be impossible.
> > Aaron wrote a big blog post last week in which he frowned on
> > "legislating from the compiler". Well, it's going to happen. If I fail
> > to write legislation, somebody else will, or else we'll be stuck with
> > the legislation I wrote *last* time. There is no outcome in which
> > every possibility remains possible for everybody.
>
> I'm more concerned about what the system makes possible for authors
> than for players, for the reason I gave above: a cooperative *author*
> can make things possible for the player even without the system's
> help, but even with a cooperative *player*, the author is still
> limited to what the system lets him do.
I see symmetry there nonetheless. Even with a cooperative author, the
player is still limited to what the system lets him do.
The asymmetry, I suppose to be precise, is that the player's work
comes (temporally) after the author's, so there is no notion of the
player giving the author options in a direct causal sense.
Nonetheless, the opportunities run both ways in the design.
Here, John G. Wood <ra...@elvwood.org> wrote:
> Andrew Plotkin wrote:
> > Do people hate CSS? I don't *like* CSS -- I don't imagine many people
> > do -- but I hate the pre-CSS HTML world a lot more. I am usually
> > guilty of assuming that everybody is just like me.
>
> I have similar feelings about CSS. It's sort of like democracy: the
> worst form of style management except for all the rest. I think the
> pros (including familiarity and compatibility) outweigh the cons.
Glad to hear one positive opinion... :)
> > Color does have some unique problems, like the light-or-dark-
> > background conundrum. [...] I'm going to use muted tones --
> > Meaning #660000, #000088 on a light background, or #FF8888, #9999FF
> > on a dark background!
>
> I feel that supporting this level of response to the player's /
> interpreter's choices is close to essential. Since you're not allowing
> the game to query the interpreter preferences there would have to be
> some way of marking style alternates - by saying, for example, "use
> this CSS file for a dark background, use this other one for a light
> background and as the default".
The CSS @-rule syntax could be used to cover this -- @dark and @light
rules, accepted or rejected according to the dominant background
color. On the other hand, this would require extra work to support in
a Javascript/HTML terp.
My vague alternative notion is to support colors in HSL format, or
maybe just *compute* them in HSL format, so that a rule can specify
"lightness" in a way that applies to all colors... then #FF0000 with a
high lightness would work on black, and with a low lightness would
work on white. But it's hard to explain that to the traditional web
designer (or anyone who's used CSS at all) -- they want to just give
everything a color and be done.
Grr. This is hard. But I agree it's very important, enough so to be
worth a special case if there's no other way out.
Here, Ron Newcomb <psc...@yahoo.com> wrote:
> On Dec 8, 11:33 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > I guess I shouldn't go on with that argument without splitting out the
> > two basic design questions: (1) where does style information come
> > from: a separate stylesheet, or I7 declarations in the source code?
>
> Separate stylesheet, but, I7 declarations instruct Inform to *create*
> that separate stylesheet.
Certainly an option, but I worry that I7 would be a poorer CSS
description language than CSS is. (A logical worry, I hope you agree!)
It would have to be able to mimic everything that CSS can do.
Maybe it should just fall back to a big string, interpreted as-is --
much as the <style> block lets you splat CSS into an HTML file as-is:
[I7 code:]
The stylesheet is "
.bold {
font-size: 16px;
};
".
> > I would love to put semantic paragraphs and
> > line-by-line lists into the document model, but that's just too far
> > away from what I7 (or I6) does. We're stuck with line breaks the way
> > they are.
>
> Just as a color style can be flicked on & off and a font-weight style
> can be flicked on & off, how about a run-paragraph-on "style" that can
> be flicked on & off?
Okay, I grant it's *possible*, but it's a giant bear-trap of an issue
that I don't see any reason to tackle. :) If you don't like the way I7
does line breaks, you should be talking to Graham, not me. (If that
turns into a discussion of semantic line and paragraph markup, great --
but not here.)
> > David Fletcher
> > > A complicated example is the one Ron Newcomb suggested, where the
> > > author wants to use a colour which is halfway between the user's two
> > > preferred colours for normal text and input text.
> >
> > Yep, that's another tough one.
>
> Call it another example of parameterized styles, where the two
> parameters are each of type "style" rather than of type "color" or
> "number" or "weight". Does that make it easier?
Ah... maybe. I like the idea (Greg Ewing mentions it farther down) of
doing parameters *entirely* by linear combinations of styles. (Perhaps
with attribute masks, so you could say "color is 30% of the way from
style A to style B, but ignore the attributes of A and B other than
color.") That covers this case nicely.
> > Someone asked: "Can the game query the interpreter preferences?" That
> > is, should this game-vs-player preference conflict be managed *by the
> > game code*, after sucking in preference info. I'm going to go out on a
> > limb and say "No."
>
> For conflict, ok, I'll agree. But the above color-halfway-between
> isn't an author/player *conflict*.
It's still easier if information flows one way. I'd rather design a
system for specifying styles, than design a system for *letting the
author design a system* to specify styles.
> I think your larger question is, how do we allow a player to override
> *computed* styles?
>
> (Is it enough just to override the inputs???)
I think it is enough. Having "big tag" and "small tag" styles, and
interpolating linearly between them, is pretty clean for the author
and pretty understandable for the player (who can then customize just
those two). A full-spectrum rainbow can be specified with just six
vertices, and that's an extreme case.
Here, Ron Newcomb <psc...@yahoo.com> wrote:
> > Call it another example of parameterized styles, where the two
> > parameters are each of type "style" rather than of type "color" or
> > "number" or "weight".
>
> Mr. Voice-in-my-head says, "If a style only took as a parameter one
> other style, isn't that just called 'inheritance'? So a style that
> takes two or more styles as parameters using multiple inheritance?"
>
> ...which CSS kinda-sorta allows anyway:
>
> http://dorward.me.uk/www/css/inheritance/
My November proposal used that inheritance trick, actually... But
obviously you can't extend that into parametrized styles using pure
CSS. The terp is going to have to get involved. (I'm okay with that,
given that parametrized styles are an extra feature that most games
won't need.)
Here, Aaron A. Reed <aar...@gmail.com> wrote:
> On Dec 8, 11:33 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > Along this line, Aaron said:
> >
> > > Imagine in Blue Lacuna I let the user select a color for the three
> > > types of highlighted keywords, the standard text, and the parser error
> > > message.
> >
> > ...then went on to the idea of an in-game color picker. That
> > immediately gave me a migraine -- because color-picking, like window-
> > resizing and line-wrapping, belongs at the interpreter level, not the
> > game level. (Shouldn't people be able to select a color for *every*
> > style in *every* game? If they want? Using their machine's standard
> > color-selection widget?)
> >
> > My proposal went some distance in that direction. That's the whole
> > point of *having* named styles, declared by the game author, in a
> > terp-parsable section of the stylesheet. It lets the interpreter pop
> > up a nice preference pane which lists those styles and lets you tweak
> > their appearance.
>
> I guess what I was trying to avoid, by doing the end-run around
> interpreter control of styles in Blue Lacuna, was an instruction
> message like the following:
>
> "Welcome! In this game some words look like this. Did that word look
> different? If not, well, you'll need to figure out how to change it in
> your interpreter program.
This is several orders of overthinking the problem. Just don't do it.
> The point is that letting people deal with the game's custom styles on
> the interpreter level was a) inconsistent from terp to terp and
> platform to platform, and thus hard to explain, b) required learning a
> second program (the terp), not just Blue Lacuna, and c) was not even a
> consistently available or functional option on many interpreters. So
> my response was basically "Well, this is broken: I'll just give them a
> menu."
I am trying to set up a system in which the *default* behavior is more
predictable. (E.g.: since custom styles will be defined by the game,
rather than being general "#1 and #2" labels, the interpreter isn't
likely to have some mad idea of how they should look. Which is what I
gather your Blue Lacuna experience derived from.)
But if the system is broken, the game can't fix it.
(Oh, I *could* set it up full of trap doors so that the game could
come in and work around interpreter bugs -- or interpreter choices --
or player choices. I'm not going to, mostly because I recognize that
the trap doors would *become* the system in about six months, and why
should I waste my time on the rest of it?)
> Seen from another angle: the interpreter has no way of knowing what
> the custom styles signify in my particular story, and thus can't be
> expected to present a context-aware interface to the player for
> changing them.
I'm a little more optimistic. The stylesheet approach gives the
interpreter at least the notion that there are styles called (e.g.)
"Computer_Prose", "Researcher_Comment", and "Console_Data" to be
customized; that's fairly significant already. (Adding a line of
human-readable metadata to each style is within reason.)
In any case, I'm still presuming that *most people won't choose to
customize styles*, so the possible opacity of the preference interface
is not a huge issue. Players who are in the habit of tweaking their
display will get a feel for the system.
Here, Ben Cressey <bcre...@gmail.com> wrote:
>
> I really like the idea of the static style system, but I think its
> success would be heavily predicated on the rise of I7 extensions that
> offered predefined sets of styles: either as a packaged theme or just
> covering the basic demand for colored text. I envision a distinct
> syntax for each type of extension; for simple effects, the user might
> write "print X in red text" to set the relevant style. For the more
> complete themes, they would instead write "print X as a medium header"
> and allow the theme to use its prepackaged setting.
The idea of putting stylesheets in extensions is certainly tempting
(and a good argument for having an I7 notation for them!)
> In an environment like that, where most authors would end up using
> stylesheets that they did not create, a method to tweak individual
> values would be extremely useful, if not indispensable.
Sure. But I'm not very worried about resolving the conflicts between a
game and an extension, because I know the author can resolve that to
his own satisfaction. The rules for that can be worked out later.
(I also foresee *players* downloading packaged themes -- this got
mentioned last month a little.)
Here, Ron Newcomb <psc...@yahoo.com> wrote:
> On Dec 9, 1:53 pm, "Aaron A. Reed" <aar...@gmail.com> wrote:
> >
> > Seen from another angle: the interpreter has no way of knowing what
> > the custom styles signify in my particular story, and thus can't be
> > expected to present a context-aware interface to the player for
> > changing them. I'm not sure it's possible to keep the process of
> > selecting sensible styles something that happens entirely at the
> > interpreter level.
>
> This seems to be a point in favor of allowing styles to be named
> (optionally please!), but other than that, I think it odd to call out
> to the player "and you can customize these colors". Of course they
> can customize colors. They can also customize fonts, font sizes,
> margins, etc. as well, just by virtue of using an interpreter. I don't
> see why it's worth the shout-out. 90% of the players will trust you to
> choose decent defaults anyway.
Right.
> What your example *does* cry out for is asking the interpreter if it
> supports color or if it supports color but the user has it disabled.
Agreed.
Here, Gregory Ewing <greg....@canterbury.ac.nz> wrote:
> A couple of suggestions concerned with avoiding
> combinatorial explosions of styles:
>
> 1) Using more than one style at a time. If I have
> an Emphasised style set to bold, and a Keyword style
> set to blue, I should be able to display output using
> both styles together and get bold blue text.
Possible. CSS works this way, obviously. I find the idea of
non-combining styles simpler, and it makes implementation easier --
but that preference has gone way down my prioritity list since 1998,
and I'll pitch it if there's good reason.
> 2) Linear combinations of styles. This is for handling
> things like continuous colour gradations. For example,
> I could define two styles called Cold and Hot and
> display a temperature of 70 (on a scale from 0 to 100)
> using 0.3 * Cold + 0.7 * Hot.
I like this a whole lot.
(Then some joker will invoke Metafont to let you specify
0.25*serif + 0.75*sansserif...)
Here, Ben Cressey <bcre...@gmail.com> wrote:
> > The analogy with editing an .ini file on a DOS system is both reasonable
> > and revealing. Legacy systems that hark back to the 1970s are not a good
> > thing. They were tolerable in the early '90s, certainly. Today, no.
>
> Gargoyle uses an .ini file to set user preferences. Is it
> unfriendly? I suppose. It gets the job done, though, and I think the
> users that gravitate toward Gargoyle are for the most part comfortable
> with that sort of thing.
I am willing to let a given interpreter's preference UI be an argument
between the interpreter author and his players.
> However, in this case I think it's useful to have a barrier toward
> customization. It promotes feedback from the user to the developer
> if the default settings - fonts, styles, all the rest - drift away
> from what the majority of users want.
I am not enthusiastic about this attitude -- obviously, I am investing
a lot of effort in the idea of customization. But if there is such a
thing as a player majority concensus, then Gargoyle can live in it. If
there isn't, then you have a problem regardless of what I think. :)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
vaporware
What I meant was that a game that needs thousands of styles is almost
certainly choosing between them at runtime according to some
algorithm, and it can let the player tweak that algorithm in-game
instead of using the interpreter's preference dialog.
> > Parametrized styles could be a great solution, though, and I look
> > forward to seeing the plan for those.
>
> Yeah, that's what I'm thinking about.
>
> > > In the end, though, my job is declaring some things to be impossible.
> > > Aaron wrote a big blog post last week in which he frowned on
> > > "legislating from the compiler". Well, it's going to happen. If I fail
> > > to write legislation, somebody else will, or else we'll be stuck with
> > > the legislation I wrote *last* time. There is no outcome in which
> > > every possibility remains possible for everybody.
>
> > I'm more concerned about what the system makes possible for authors
> > than for players, for the reason I gave above: a cooperative *author*
> > can make things possible for the player even without the system's
> > help, but even with a cooperative *player*, the author is still
> > limited to what the system lets him do.
>
> I see symmetry there nonetheless. Even with a cooperative author, the
> player is still limited to what the system lets him do.
I don't think that's true. The author can make options available to
the player that the system cannot, because the author knows more about
how the game works.
For instance, even if the system has no means to let a player say "I
don't want colors, show me the same information in some appropriate
alternate form", a game can just ask the player about his color
preference and use some other method to show the same emphasis.
The player may still be limited to the options that the game provides:
maybe he wants to replace red text with capitalization, and the game
only offers to replace it with asterisks. But that's at least
something the author can fix by building in more options. When the
*author* hits a limitation, no one but the spec designer can fix it.
vw
ChicagoDave
> > > Do people hate CSS? I don't *like* CSS -- I don't imagine many people
> > > do -- but I hate the pre-CSS HTML world a lot more. I am usually
> > > guilty of assuming that everybody is just like me.
It just occurred to me that I _do_ hate CSS. Since playing around with
the non-standard XAML from Microsoft, I believe CSS is crap and should
be abandoned with all haste. XAML actually works exactly as you'd
expect in all cases. Margins, padding, placement, everything just does
what you'd naturally expect from a layout markup language. And you can
do it in XML or in code.
I'm not necessarily suggsting you look at XAML...just saying..there
are better things than CSS.
David C.
www.textfyre.com
Ron Newcomb
> [I7 code:]
> The stylesheet is "
> .bold {
> font-size: 16px;
> };
> ".
Somebody's gonna try to stick indexed text or substitutions in there.
And whine when they can't. :)
> > Just as a color style can be flicked on & off and a font-weight style
> > can be flicked on & off, how about a run-paragraph-on "style" that can
> > be flicked on & off?
>
> Okay, I grant it's *possible*, but it's a giant bear-trap of an issue
> that I don't see any reason to tackle. :) If you don't like the way I7
> does line breaks, you should be talking to Graham, not me.
Fair enough, but, the line break that occurs when the player hits
ENTER after typing a command isn't under Inform's control. Can we at
least have a little tag to turn off that automatic echo of the ENTER
key? I ask so I can weave commands into the middle of paragraphs, per
my earlier example.
> > > > A complicated example is the one Ron Newcomb suggested, where the
> > > > author wants to use a colour which is halfway between the user's two
> > > > preferred colours for normal text and input text.
> > Call it another example of parameterized styles, where the two
> > parameters are each of type "style" rather than of type "color" or
> > "number" or "weight". Does that make it easier?
> Ah... maybe. I like the idea (Greg Ewing mentions it farther down) of
> doing parameters *entirely* by linear combinations of styles. (Perhaps
> with attribute masks, so you could say "color is 30% of the way from
> style A to style B, but ignore the attributes of A and B other than
> color.") That covers this case nicely.
The earlier "green-to-red danger level" example asks that the % of the
interpolation is set by in-game variables at run-time. Likewise the
NPC mood example in which red/green/blue signifies amounts of anger/
confusion/depression. Just making that clear so we're all on the same
page.
> > > Someone asked: "Can the game query the interpreter preferences?"
I now realize that a new game-created style inheriting from the
interpreter-set styles essentially *is* a way of querying them. So if
we have run-time linear interpolation between static styles, then
that's three-quarters of the functionality that explicit queries would
provide anyway. Yes? If so, I feel secure that that function could
be dropped from the spec as you (Andrew) preferred.
*Except* for that bit about Blue Lacuna:
> > What your example *does* cry out for is asking the interpreter if it
> > supports color, or, if it supports color but the user has it disabled.
Speaking of Blue Lacuna and what's the context of style #17b in the
Preferences dialog:
> The stylesheet approach gives the
> interpreter at least the notion that there are styles called (e.g.)
> "Computer_Prose", "Researcher_Comment", and "Console_Data" to be
> customized; that's fairly significant already. (Adding a line of
> human-readable metadata to each style is within reason.)
I think that human-readable metadata (that presumably only appears in
the 'terps Preferences dialog or whatchamacallit) is a very good
idea.
-Ron
Ben Cressey
> interpreter at least the notion that there are styles called (e.g.)
> "Computer_Prose", "Researcher_Comment", and "Console_Data" to be
> customized; that's fairly significant already. (Adding a line of
> human-readable metadata to each style is within reason.)
I'm not sure I see the significance of these example styles. The
library can't really do anything with those labels except kick them up
to the user via a preferences dialog for customization. Unless they
are inherited from a common, universal parent, but then the
significance is in the relationship rather than in the name.
> > What your example *does* cry out for is asking the interpreter if it
> > supports color or if it supports color but the user has it disabled.
>
> Agreed.
Following from the principle that color should not receive
preferential treatment, does this also mean that there will be a way
to interrogate the interpreter about the status of the other style
properties?
> > 2) Linear combinations of styles. This is for handling
> > things like continuous colour gradations. For example,
> > I could define two styles called Cold and Hot and
> > display a temperature of 70 (on a scale from 0 to 100)
> > using 0.3 * Cold + 0.7 * Hot.
>
> I like this a whole lot.
For implementation, it seems like the calculated value should be
interpolated from the range of values between two styles. I.e. X% of
[style 1] should imply (100 - X%) of [style 2]. Otherwise a
temperature of (1.0 * Cold + 1.0 * Hot) would be possible and that
strikes me as meaningless, at least in terms of a color gradient.
What is the benefit of combining styles like this, rather than
allowing the game to calculate its own color value and apply it to a
named style at runtime? That would be more flexible and I don't see
that the outcome is much different. Either way you have a predefined
style with a dynamic value.
It could be more useful for something like fonts, where you might want
a gradual progression in size between the smallest and largest. But
that could be accomplished by specifying fonts in a relative unit like
ems and letting the library sort it out.
> > However, in this case I think it's useful to have a barrier toward
> > customization. It promotes feedback from the user to the developer
> > if the default settings - fonts, styles, all the rest - drift away
> > from what the majority of users want.
>
> I am not enthusiastic about this attitude -- obviously, I am investing
> a lot of effort in the idea of customization. But if there is such a
> thing as a player majority concensus, then Gargoyle can live in it. If
> there isn't, then you have a problem regardless of what I think. :)
Well, it's only a problem if everyone hates the default settings and
nobody tells me. I have to believe that there's a sense of shared
aesthetics among Gargoyle users. Otherwise I don't see why anyone
would use it on platforms where other options are available. Working
from that assumption, if someone has a better set of defaults or even
just ideal settings for a particular game, I want to hear about it.
Chances are that others in the community will appreciate those
changes.
My long term vision is to move toward a more feature-filled launcher,
with a game browser that makes it easy to apply different custom
styles. That could mean themes, or bundled alternatives to the
defaults, or some form of community-contributed settings. Obviously,
making games easier to customize would facilitate all of these goals.
Absent a better launcher infrastructure, though, all it does is add a
second configuration format to support, as I am not willing to expend
significant development effort to create a GUI editor for the existing
one.
In the short term, we have ini files. Admittedly, they suck from a
user experience perspective. However, once customized, they are easy
to pass around, to copy between platforms, and to email to developers.
In essence, they are easy to share, and since sharing is something I'd
like to promote, I choose to see this as an upside.
Ron Newcomb
> Following from the principle that color should not receive
> preferential treatment, does this also mean that there will be a way
> to interrogate the interpreter about the status of the other style
> properties?
Or even to what extent they are supported. It would be nice to know
if the 'terp is a 4-color, 16-color, 256-color, or gajillion-color
'terp. Blue Lacuna would likely be happy on a 4-color, but Everybody
Dies needs at least a 16-color.
And what if the 'terp doesn't support, say, bold, but has a reasonable
alternative, like all caps. When asked "do you support.." it should
probably answer to-what-extent, not just a simple yes/no.
> For implementation, it seems like the calculated value should be
> interpolated from the range of values between two styles. I.e. X% of
> [style 1] should imply (100 - X%) of [style 2]. Otherwise a
> temperature of (1.0 * Cold + 1.0 * Hot) would be possible and that
> strikes me as meaningless, at least in terms of a color gradient.
The NPC mood example has 3 axis of color it's blending, so that
wouldn't work in the general case.
> What is the benefit of combining styles like this, rather than
> allowing the game to calculate its own color value and apply it to a
> named style at runtime? That would be more flexible and I don't see
> that the outcome is much different. Either way you have a predefined
> style with a dynamic value.
Good point. How about rather than constantly shuttling changing values
at run-time, the stylesheet instead specifies the address of the
variable holding the value? The 'terp can see all of the game's RAM
anyway, for @save and @undo and the like.
(Of course, I believe that means the authoring tool would *have* to
generate the CSS, as only it knows what the address of the variable
will be.)
But it seems like a good way to keep the CSS "static", meaning,
without requiring any sort of API for run-time modifications.
> In the short term, we have ini files. Admittedly, they suck from a
> user experience perspective.
Er, a user-friendly GUI preferences pane can read/write .ini files. I
believe Windows 3.1 did that as a matter of course.
-R
Ben Cressey
> believe Windows 3.1 did that as a matter of course.
It's certainly not impossible, just tedious, especially with three
different native window APIs to contend with. Color pickers, font
browsers, form fields, and tooltips would have to be implemented for
each.
The file format is almost irrelevant, except that in its current
incarnation it's so easy to edit that it's hard to muster the energy
to tackle the above. I have in mind a move to a more structured format
like JSON or XML, which would be harder to interact with in a text
editor, necessitating a more gentle interface.
Right now the problem with the ini files is that they can be almost
anywhere, and within the file the same setting may be defined many
times. Although there's a deterministic way of deciding which file and
which setting takes precedence, it's anything but obvious to the
player. Complicating matters still further, authors can bundle an .ini
file along with their games. Most of the ones I've seen adjust only
the parameters they want to tweak, but some copy the default ini file
and leave all the other values in place. This effectively overrides
the user's defaults with whatever happened to be in that file.
The upshot is that it's quite a mess and at some point, I'm going to
have to cut the knot and break compatibility. I expect I won't do that
until I have a new file format and a new GUI preferences pane, both
better suited to the CSS style model being discussed, as well as a way
to convert the old format to the new one.
Ben Cressey
> if the 'terp is a 4-color, 16-color, 256-color, or gajillion-color
> 'terp. Blue Lacuna would likely be happy on a 4-color, but Everybody
> Dies needs at least a 16-color.
Glk colors are 24 bit values, so if a library claims color support
then the answer is "millions."
> And what if the 'terp doesn't support, say, bold, but has a reasonable
> alternative, like all caps. When asked "do you support.." it should
> probably answer to-what-extent, not just a simple yes/no.
This could also be implemented by the game: query the terp about all
style properties, figure out which ones it does support, then decide
which predefined style to use based on those answers.
Having the library propose alternatives means that somehow it has to
ask the user to approve those alternatives, in addition to the styles
they may have customized. Just because they don't have "small caps" as
a default somewhere doesn't mean they object to it in principle.
> The NPC mood example has 3 axis of color it's blending, so that
> wouldn't work in the general case.
Right, which to my mind is an argument for letting the game
interpolate between however many styles it likes according to the
whims of the author, and presenting the interpreter with a final
property value to update dynamically.
> Good point. How about rather than constantly shuttling changing values
> at run-time, the stylesheet instead specifies the address of the
> variable holding the value? The 'terp can see all of the game's RAM
> anyway, for @save and @undo and the like.
Glk has a concept of "rocks" which could be adapted here. Windows,
files, and sound channels have rocks. It doesn't seem to subvert the
model too much to give styles a rock also. They are sort of a channel
that you fill with a given type of data, in this case formatted text.
When the style is placed in the static stylesheet, it could have a
rock value in addition to its friendly name value.
Then to modify a given style, you could make successive calls to
glk_style_iterate(), which would return the style object and its rock
value. Iterate through the objects until you find the rock value
you're after, then call glk_style_update() and pass it the style
object, along with the parameter you are trying to change.
The extension responsible for creating your stylesheet would just have
to associate a unique rock value with your friendly style name, and
the library would know to use that value when it initialized the style
object.
> But it seems like a good way to keep the CSS "static", meaning,
> without requiring any sort of API for run-time modifications.
With Glulx, you either go through the output API or you don't go at
all. There's no direct memory access to anything that Glk abstracts.
@save, @restore, and @undo work by telling the interpreter to
manipulate the memory within the virtual machine. Glk doesn't get
involved, except to the extent that it supplies a file for saving or
restoring the VM stack.