I7 : Glulx Text Effects, Better Ways to Word It (in Source Text)
Jeff Nyman
as to why I'm asking it.
Here's the context: In looking at some notes from a class about how
"easy" it was to apply Glulx styles, it becomes really obvious that
what people want is something simple like this:
now the text color is dark red;
now the text color is black;
now the text style is italic and dark red;
and so forth. Or something like that anyway; sort of, you know,
natural language-ish. (Wonder where they got that idea?) And, ideally,
they shouldn't have to worry about whether this is "Glulx" or "Z-
machine" since that's an implementation detail that the bulk of users
shouldn't have to care about.
What people really don't like is having to do things like this:
======================================
Table of Common Color Values (continued)
glulx color value assigned number
g-red 16711680
g-dark-red 11141120
Table of User Styles (continued)
style name justification obliquity indentation first-line
indentation boldness fixed width relative size glulx color
special-style-1 left-justified italic-obliquity 0 0 regular-
weight proportional-font 0 g-red
special-style-2 left-justified no-obliquity 0 0 regular-weight
proportional-font 0 g-dark-red
======================================
And then say things like:
say "[first custom style]"
which doesn't even obviously match any text in those tables. (After
all, why wouldn't it be "first special style" -- at least that would
provide some mapping.) At the very least, they'd like to say something
like:
say "[dark red]some text[black]".
So here's the question: has anyone found an effective way to actually
apply styles that would make them a little more palatable to use and/
or type in for Glulx in particular? I'm probably going to start
working on something but I didn't want to re-invent any wheels here.
- Jeff
Peter Pears
Someone better than I will soon come along to explain it better than
I'm about to, but I can summarize the situation from my layman-ish
point of view.
Basically, in the zMachine you can sort of change colours in font and
background at will. Not in Glulx, because it doesn't work quite like
that. Glulx has several "layouts", as it were - a layout for the
status line, a layout for the main screen, a layout for "bold", and
whatnot. It uses this layout system exclusively, so that in order to
change a color you need to use a layout - say, "the layout of the
green colour".
That is basically why a zMachine-like <say "[dark red]some text
[black]"> in unlikely to ever work.
You're very likely to use the custom styles for your purpose. That's
what they're their for. But you're limited to 2 custom styles. You
also use a style if you want to, say, center/right-align some text.
It seemed to be an old debate when I stumbled across it, and that was
quite a few months ago - the layout limitations (in the form of
"custom styles") in what was supposed to be the Limitation-Free Z-
Machine (Glulx). As far as I know, things remain the way they are.
Does that clarify? Ah well, if it doesn't someone else will fill in
the blanks and correct my mistakes.
Jeff Nyman
Thanks for the reply.
And, yeah, I roughly know the context of why the z-machine and Glulx
implementations are different. But I'm in the process of trying to
introduce writing textual IF to a larger audience base, one that
doesn't (necessarily) want to understand all of the implementation
details. The way Glulx styles are now utilized in Inform 7 is clearly
a cumbersome approach to many people who get lulled by Inform 7's
surrounding syntax.
So basically what would be nice to do is have a "wrapper" of sorts
around that mess I quoted in my first post -- with the various tables
-- such that someone could say something like this in source:
say "The sign says [dark red][italic]DANGER!!![roman][black] and
looks like it means it."
You can almost do that now -- and you certainly can do that with the
[italic] / [roman] part. You can even change that to [i] and [/i]
although you have to use strange constructions like this:
To say i -- beginning say_i -- running on: (- style underline; -).
To say /i -- ending say_i -- running on: (- style roman; -).
(Yeah, in Inform when you say italic you apparently mean underline.)
But people often want to do colors in a lot of places, particularly
with games or stories where children of various ages will be writing
them. So when you start having to explain these tables and custom
styles -- well, people just start to wonder why a system devoted ot
text has so much "clunkiness" when it comes to formatting that text.
(Again, keep in mind my audience here: they're generally less tolerant
of constructs that people here may treat as necessary implementations
due to legacy concerns.)
So I'm in a situation now where I want to construct some "wrapper"
that I can present to people that makes all this a lot easier, which
it arguably should be. I just wanted to make sure that this wasn't
work that was either already done or in progress by someone (or
perhaps planned as part of the next Inform release).
- Jeff
vaporware
The fundamental problem is that Glk styles have to be set up before
the window is created, and there are only a limited number of them.
When you use the "[italic]" tag, you're choosing a predefined style
that's been set up for italics. The game could theoretically start
building a new style when you use the "[dark red]" tag, but you
wouldn't be able to use it until you closed and reopened the window.
That's why styles have to be set up in a table: there's a rule that
runs before the game window opens and registers the styles with Glk.
I don't think there's a way to make it nearly as convenient as on the
Z-machine without changing either Glk or I7.
Changing Glk to support Z-machine-style color changes would be, well,
pretty awesome. I hacked that feature into Gargoyle, so I know the
implementation changes aren't a very big deal. But even if the spec
were changed, it'd take a long time for all the interpreters to catch
up.
Changing I7 would only be a workaround, but it could be handy. The
compiler could notice all the style tags you use, anywhere in the
game, and basically build the style table for you. If you have some
text that's dark red and italic, it would create a style that's dark
red and italic. You'd still be limited to a small number of
combinations, though.
vw
Erik Temple
> You can almost do that now -- and you certainly can do that with the
> [italic] / [roman] part. You can even change that to [i] and [/i]
> although you have to use strange constructions like this:
> To say i -- beginning say_i -- running on: (- style underline; -).
> To say /i -- ending say_i -- running on: (- style roman; -).
Strange constructions aren't necessary to make aliases for these built in
things. Just do:
To say i:
say "[italic type]";
To say /i:
say "[roman type]";
As far as the rest goes, what vaporware said. There are some avenues for
simplifying things. You could predefine some template styles (e.g.,
colored text), let the user declare the appropriate color with an
appropriate variable, then slot the appropriate values into the table
before the main window is opened. The problem, as vaporware noted, is that
even if the user is saved from the ugliness of the table, the limitation
of only 2 custom styles still exists. You don't want the end user to
declare more styles than will actually affect output, for obvious reasons.
If you'd like to save authors from having to use the color definition
table (which is quite awkward), I've put together an extension to the
table that includes all of the standard HTML colors. I plan to release it
is an extension once the extensions library is functioning again, but I've
pasted the table below if it might be of use to you.
--Erik
Version 1/090823 of HTML Color Names for Glulx Text Effects (for Glulx
only) by Erik Temple begins here.
[This extension needs to be included after Glulx Text Effects. It does not
itself include Glulx Text Effects because of issues having to do with the
order of extension inclusion (affects table continuation and amendment).
It is currently set up to require Flexible Windows.]
Use authorial modesty.
[The colors that are commented out are defined in either Glulx Text
Effects or Flexible Windows.]
Table of Common Color Values (continued)
glulx color value assigned number
g-AliceBlue 15792383
g-AntiqueWhite 16444375
g-Aqua 65535
g-Aquamarine 8388564
g-Azure 15794175
g-Beige 16119260
g-Bisque 16770244
[g-Black 0]
g-BlanchedAlmond 16772045
[g-Blue 255]
g-BlueViolet 9055202
[g-Brown 10824234]
g-BurlyWood 14596231
g-CadetBlue 6266528
g-Chartreuse 8388352
g-Chocolate 13789470
g-Coral 16744272
[g-CornflowerBlue 6591981]
g-Cornsilk 16775388
[g-Crimson 14423100]
g-Cyan 65535
g-DarkBlue 139
g-DarkCyan 35723
g-DarkGoldenRod 12092939
g-DarkGray 11119017
[g-DarkGreen 25600]
g-DarkKhaki 12433259
g-DarkMagenta 9109643
g-DarkOliveGreen 5597999
[g-DarkOrange 16747520]
g-DarkOrchid 10040012
g-DarkRed 9109504
g-DarkSalmon 15308410
g-DarkSeaGreen 9419919
g-DarkSlateBlue 4734347
g-DarkSlateGray 3100495
g-DarkTurquoise 52945
[g-DarkViolet 9699539]
[g-DeepPink 16716947]
g-DeepSkyBlue 49151
g-DimGray 6908265
g-DodgerBlue 2003199
g-FireBrick 11674146
g-FloralWhite 16775920
g-ForestGreen 2263842
g-Fuchsia 16711935
g-Gainsboro 14474460
g-GhostWhite 16316671
[g-Gold 16766720]
g-GoldenRod 14329120
g-Gray 8421504
[g-Green 32768]
g-GreenYellow 11403055
g-HoneyDew 15794160
g-HotPink 16738740
g-IndianRed 13458524
[g-Indigo 4915330]
g-Ivory 16777200
[g-Khaki 15787660]
[g-Lavender 15132410]
g-LavenderBlush 16773365
g-LawnGreen 8190976
g-LemonChiffon 16775885
g-LightBlue 11393254
g-LightCoral 15761536
g-LightCyan 14745599
g-LightGoldenRodYellow 16448210
g-LightGrey 13882323
g-LightGreen 9498256
g-LightPink 16758465
g-LightSalmon 16752762
g-LightSeaGreen 2142890
g-LightSkyBlue 8900346
g-LightSlateGray 7833753
g-LightSteelBlue 11584734
g-LightYellow 16777184
[g-Lime 65280]
g-LimeGreen 3329330
g-Linen 16445670
g-Magenta 16711935
[g-Maroon 8388608]
g-MediumAquaMarine 6737322
[g-MediumBlue 205]
g-MediumOrchid 12211667
g-MediumPurple 9662680
g-MediumSeaGreen 3978097
[g-MediumSlateBlue 8087790]
g-MediumSpringGreen 64154
g-MediumTurquoise 4772300
g-MediumVioletRed 13047173
[g-MidnightBlue 1644912]
g-MintCream 16121850
g-MistyRose 16770273
g-Moccasin 16770229
g-NavajoWhite 16768685
[g-Navy 128]
g-OldLace 16643558
g-Olive 8421376
g-OliveDrab 7048739
g-Orange 16753920
[g-OrangeRed 16729344]
g-Orchid 14315734
g-PaleGoldenRod 15657130
g-PaleGreen 10025880
g-PaleTurquoise 11529966
g-PaleVioletRed 14184595
g-PapayaWhip 16773077
g-PeachPuff 16767673
g-Peru 13468991
[g-Pink 16761035]
g-Plum 14524637
g-PowderBlue 11591910
g-Purple 8388736
[g-Red 16711680]
g-RosyBrown 12357519
g-RoyalBlue 4286945
g-SaddleBrown 9127187
g-Salmon 16416882
g-SandyBrown 16032864
g-SeaGreen 3050327
g-SeaShell 16774638
g-Sienna 10506797
[g-Silver 12632256]
g-SkyBlue 8900331
g-SlateBlue 6970061
g-SlateGray 7372944
g-Snow 16775930
g-SpringGreen 65407
[g-SteelBlue 4620980]
g-Tan 13808780
g-Teal 32896
g-Thistle 14204888
g-Tomato 16737095
g-Turquoise 4251856
g-Violet 15631086
g-Wheat 16113331
[g-White 16777215]
g-WhiteSmoke 16119285
[g-Yellow 16776960]
g-YellowGreen 10145074
[The colors in this table amendment are defined in Flexible Windows but
differ in their definition.]
Table of Common Color Values (amended)
glulx color value assigned number
g-Brown 10824234
g-Khaki 15787660
HTML Color Names for Glulx Text Effects ends here.
Jeff Nyman
On Nov 22, 6:59 pm, "Erik Temple" <ek.tem...@gmail.com> wrote:
> Strange constructions aren't necessary to make aliases for these built in
> things. Just do:
You are entirely correct. I don't know why I didn't do that anyway. I
saw the lines that I originally quoted in the manual for achieving
HTML-like structures and I just went with those.
As far as the HTML Color Names, I can give that a shot and play around
with it. Thanks for providing it.
In general, I think a lot of it really does have to do with the fact
that tables are such a mess in the IDE (at least on Windows), what
with the width of screen real-estate and the way tabs are handled. The
Table of Common Color Values isn't that bad, but the Table of User
Styles looks horrendous. Teaching that aspect of styling in a class is
tricky at best, usually just telling people to accept it and forget
it. (As a side-note, tables are probably one of the main elements that
people have not liked about Inform, at least in terms of my classes.
But I really do think that a lot of this has to with how they appear
in the IDE. If you think about it, they're really just like an
imaginary Excel grid or HTML table and people are, by and large, used
to those. But Inform doesn't capitalize on the familiarity and put it
to use, which is where I think the disconnect comes in.)
Going to vaporware's original point: since Glulx styling is not as
convenient as the Z-machine styling and given that I doubt Glk/Glulx
was designed on purpose to be more *inconvenient*, I'm wondering if it
does make sense to actually design something that will be useful for
people of varying technical levels -- meaning, consider the user base
and design to that to the extent possible. Even if this required
changes to Glk or Inform 7 -- would that be a better thing to do
sooner rather than later? As far as interpreter support, all you
*really* need are three canonical ones for the three main operating
systems, I suppose: Win, Mac, Linux. Those can be used as reference
configurations, such that any interpreter builds off that base and
then can add whatever frills it wants.
- Jeff
David Kinder
> Going to vaporware's original point: since Glulx styling is not as
> convenient as the Z-machine styling and given that I doubt Glk/Glulx
> was designed on purpose to be more *inconvenient*, I'm wondering if it
> does make sense to actually design something that will be useful for
> people of varying technical levels -- meaning, consider the user base
> and design to that to the extent possible. Even if this required
> changes to Glk or Inform 7 -- would that be a better thing to do
> sooner rather than later?
It would be good to come up with a better solution than the current
situation. Andrew has talked before about allowing something like a CSS
model for styles. However, it would be technically pretty straightforward to
have a simpler change to Glk that would allow Inform 7 to provide more
"Z-code like" colour changes: either Glk could allow a lot more user defined
styles, or it could have a call added that updated the styles for new text
without changing the display properties of anything currently on screen.
David
George Oliver
> In general, I think a lot of it really does have to do with the fact
> that tables are such a mess in the IDE (at least on Windows), what
> with the width of screen real-estate and the way tabs are handled. The
> Table of Common Color Values isn't that bad, but the Table of User
> Styles looks horrendous. Teaching that aspect of styling in a class is
> tricky at best, usually just telling people to accept it and forget
> it. (As a side-note, tables are probably one of the main elements that
> people have not liked about Inform, at least in terms of my classes.
> But I really do think that a lot of this has to with how they appear
> in the IDE.
Just as a sidenote, I want to add that I feel the same way about how
tables appear in the IDE, but there is an IMO good short-term
workaround for this that you might want to explore -- in fact it might
be a good general solution for a reason I'll get to in a moment.
If you edit the index.html file in the Inform 7/Documentation
directory, you can add whatever 3rd party links you want to the IDE
docs. I've started using this to link to an html spreadsheet; you
could set this up as an online or offline thing conceivably though
currently I use it online. This gives you a surprisingly nice
interface for writing out tables, then it's a simple copy and paste
into the code pane. Of course you could do the same thing with an
external spreadsheet program but I find this to be even more
convenient.
To generalize, people could write whatever 3rd party tools they wanted
as web pages and link them to the IDE, like how people write
extensions now to mod people's code. I got started doing this with
Juhana Leinonen's thing creater script and it actually works quite
nicely.
On topic, I fully support a more friendly approach to styles. :)
ChicagoDave
> In general, I think a lot of it really does have to do with the fact
> that tables are such a mess in the IDE (at least on Windows), what
> with the width of screen real-estate and the way tabs are handled. The
> Table of Common Color Values isn't that bad, but the Table of User
> Styles looks horrendous.
I think I mentioned this to Graham back in the early phases of Inform
7 IDE development. Different portions of code could use helper user
interface controls. So even though the plain text screen is the
primary editor, it should be possible to click a tab labeled "Tables"
and this would give you grid view access to every table in your source
code. The IDE developer would be responsible for parsing every table
in and out of the grid controls, but this is trivial.
The harder part is creating a grid control that works in an Inform 7
friend way. So it should understand column titles, types in row 1,
empty cells, etc. Still, this should not be difficult for any of the
IDE developers, outside of adding time to a hobbyist endeavor of
course.
David C.
www.textfyre.com
Andrew Plotkin
I have not gone in this direction because I worry that it would
conflict with the "right", that is, CSS-like model in the future.
I expect we will be supporting *less* dynamic typography in the
future, because it will be controlled by a stylesheet in the Blorb
package. Including backwards compatibility for a "simpler" proposal is
asking for pain.
I'm almost starting to think that the right point of view (for color
only, not other aspects of typography) is that I7 does not support
colored text. The historical existence of colored text in the
Z-machine (not cross-platform -- I never saw it on my Apple 2) is not
an argument for color being an important element of modern IF.
And once you move on to fonts, line spacing, and indentation, the
"[begin red text]" model stops looking nearly so cozy.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
ChicagoDave
> I'm almost starting to think that the right point of view (for color
> only, not other aspects of typography) is that I7 does not support
> colored text. The historical existence of colored text in the
> Z-machine (not cross-platform -- I never saw it on my Apple 2) is not
> an argument for color being an important element of modern IF.
I think an external stylesheet is the way to go. Not sure what the
syntax would be, but it would probably have to have some prefix
notation, like [class:header]Secret Letter[/class]. Of course then we
get into what styles can do....can they format paragraphs? can they
embed images? This is all doable if you have interpreters that
translate to CSS/HTML or XAML or MXML or some other markup system. Not
trivial, but doable.
David C.
www.textfyre.com
Jeff Nyman
> I'm almost starting to think that the right point of view (for color
> only, not other aspects of typography) is that I7 does not support
> colored text. The historical existence of colored text in the
> Z-machine (not cross-platform -- I never saw it on my Apple 2) is not
> an argument for color being an important element of modern IF.
On your last assertion there: according to whom, though? Meaning, who
is the arbiter of what is or isn't an important element of modern IF?
Is this being backed up with actually checking with what textual IF
authors might like to have available?
I can tell you that in just about every class I've given -- and most
definitely in every class that involved younger children -- the idea
of being able to color text elements was considered a very important
element. I'm not throwing this out just to be contrary; I'm genuinely
curious. What people saw ten or twenty years ago is not the same that
people necessarily expect to see now. Maybe that's not what you're
saying here, but from a user perspective the end result would be the
same.
- Jeff
Andrew Plotkin
> On Nov 23, 10:59�am, Andrew Plotkin <erkyr...@eblong.com> wrote:
>
> > I'm almost starting to think that the right point of view (for color
> > only, not other aspects of typography) is that I7 does not support
> > colored text. The historical existence of colored text in the
> > Z-machine (not cross-platform -- I never saw it on my Apple 2) is not
> > an argument for color being an important element of modern IF.
>
> On your last assertion there: according to whom, though? Meaning, who
> is the arbiter of what is or isn't an important element of modern
> IF?
Me. And the squirrel in my pocket.
The slightly more serious answer is, "me the player". Players have
opinions about text colors too, and if you're going to study this
stuff, you have to include the white-on-black/black-on-white
preferences of players as well as the fruit-salad preferences of
writers. And then come to some solution that doesn't ignore either.
> I can tell you that in just about every class I've given -- and most
> definitely in every class that involved younger children -- the idea
> of being able to color text elements was considered a very important
> element.
Is that also true in (non-interactive) creative writing classes?
Erik Temple
FWIW, I agree with Zarf here, at least as far as my personal preferences
go (big caveat--see below). For hundreds of years, a handful of techniques
(size, bold & italics, indentation, changing fonts) have served to
indicate changes in the status of text. Color just isn't needed to do the
job these techniques do, and as readers these are all we really need.
(Glulx does all of these, but the issues you've raised about ease of use
also apply to at least some of these, as do issues with variability in
interpreters' presentation). Basically, I don't want to see a melange of
colors in the text just because it is possible, and it often distracts us
from the older, more transparent techniques.
However, over the last 15 years or so, a model of colored text has become
key to the way people experience text, i.e. hyperlinking. I think Blue
Lacuna's color-coded, hyperlinked keywords show that color-coded links is
probably something we *do* want to be able to keep doing. So, while I
don't want to see more gratuitous color in IF from an aesthetic
standpoint, I think that at least the limited use of color now available
in Glulx is appropriate and desirable, in order to produce texts that
reproduce the major model of textual presentation we interact with every
day (the internet). There are other presentational uses of color that
arguably useful as well; I'm thinking principally of Bronze's compass,
with red used to mark unvisited rooms. But this is really a case of text
being used to imitate a graphic--the compass rose--and so perhaps this is
really an argument for more use of images in IF.
--Erik
Jeff Nyman
> The slightly more serious answer is, "me the player". Players have
> opinions about text colors too, and if you're going to study this
> stuff, you have to include the white-on-black/black-on-white
> preferences of players as well as the fruit-salad preferences of
> writers.
Yup, I've done that (talking with players as well as authors) to a
certain extent. (The "certain extent" is that the authoring
experiments were actually tested out on various subsets of people. All
these authoring experiments were useless if we didn't actually try
them out on a base of users.) The problem is you can't just ask a
subset of players: "Do you want color?" They may say 'yes' or 'no'
without any real thought behind it. What matters is showing them what
difference color may (or may not) make. So in the case of encouraging
children to write stories, colors were enjoyed by both authors and
players. In the case of of just adults, many of them wanted to color
parser specific messages to the player (like "I don't recognize that
verb" or whatever). They also wanted "helper" or "tutorial" prompts to
appear in different colors.
Sometimes people wanted to use colors to indicate "internal thoughts"
of the PC, as opposed to using something like italics, which was found
to be harder to read. One of my participants wanted to use different
colors for the "warring personalities" of a given protagonist and, in
fact, that coloring was critical to "getting" what was going on.
(Which I understand was also the case with the recent "Rover's Day
Out" although I may have heard that wrong.)
- Jeff
ChicagoDave
> FWIW, I agree with Zarf here, at least as far as my personal preferences
I think this misses the point entirely...our personal preferences
aside, we should _enable_ the same functionality that we have in other
publishing environments. Allow the author/game designer the full set
of options to do what they will. They may come up with something that
never ocurred to any of us here. So we should implement styles that
allow font family, style, color, and weight and not worry about its
abuses.
David C.
www.textfyre.com
David Kinder
> In general, I think a lot of it really does have to do with the fact
> that tables are such a mess in the IDE (at least on Windows), what
> with the width of screen real-estate and the way tabs are handled. The
> Table of Common Color Values isn't that bad, but the Table of User
> Styles looks horrendous. Teaching that aspect of styling in a class is
> tricky at best, usually just telling people to accept it and forget
> it. (As a side-note, tables are probably one of the main elements that
> people have not liked about Inform, at least in terms of my classes.
> But I really do think that a lot of this has to with how they appear
> in the IDE. If you think about it, they're really just like an
> imaginary Excel grid or HTML table and people are, by and large, used
> to those. But Inform doesn't capitalize on the familiarity and put it
> to use, which is where I think the disconnect comes in.)
Inform 7 on OSX now has "elastic" tab-stops, that expand to the width of the
widest element, which may be enough to address this. At some point Inform 7
on Windows will get this feature too.
For an explanation and example, see
http://nickgravgaard.com/elastictabstops/
David
vaporware
*spit take*
Whaaaa--?
First, Photopia is still modern IF, is it not? I would hate to see a
typography model that made it unimplementable.
Second, who says Glk is only good for modern IF anyway? Multiple Z-
machine interpreters use it simply as a cross-platform text windowing
library. IMO, it has always been a shame that these interpreters
couldn't actually implement all the Z-machine features because of
limitations in Glk -- which is why I hacked them into Gargoyle, with
the unfortunate result that Demona is tied to a single Glk library on
a single platform.
> And once you move on to fonts, line spacing, and indentation, the
> "[begin red text]" model stops looking nearly so cozy.
Well, I don't know about that. HTML got along fine with separate tags
for such things until people remembered that they were supposed to be
separating semantic meaning from presentation. But is that really an
important distinction for Glk to enforce? There are no bots indexing
the output of IF games, and as far as I know there are no interpreters
doing the kind of drastic reformatting to games that some browsers do
to web pages.
In any case, a well-designed new style model would solve this and
other problems. If you're modeling it after CSS, why not include CSS's
ability to apply styles to individual elements on the fly without
predefining them in a style sheet? If that's not acceptable, then
allowing a large number of custom styles that could be hinted without
reopening the window would also work.
vw
Andrew Plotkin
> On Nov 23, 8:59�am, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > Here, David Kinder <da...@david.david> wrote:
> >
> >
> > I'm almost starting to think that the right point of view (for color
> > only, not other aspects of typography) is that I7 does not support
> > colored text. The historical existence of colored text in the
> > Z-machine (not cross-platform -- I never saw it on my Apple 2) is not
> > an argument for color being an important element of modern IF.
>
> *spit take*
<napkin>
> Whaaaa--?
>
> First, Photopia is still modern IF, is it not?
And what else?
If Z-code interpreters had not supported color quite as well in 1998,
Photopia wouldn't have been possible in the form that we see. Adam
would have done something else. It's one game, not an argument for
color being important to the field.
> Second, who says Glk is only good for modern IF anyway?
I decided early in building Glk/Glulx that legacy Z-code concerns
should be subordinate to future growth concerns. (Not "ignored", but
"subordinate".) We now have a history of hundreds of Z-code games
since Photopia, of which 99% don't care about color and can therefore
be handled by a Glk Z-code interpreter. This tells me that my decision
was correct.
> In any case, a well-designed new style model would solve this and
> other problems.
I agree. I'll get back to you next week.
vaporware
> I decided early in building Glk/Glulx that legacy Z-code concerns
> should be subordinate to future growth concerns. (Not "ignored", but
> "subordinate".)
Well, perhaps I'm missing something, but it seems to me the legacy Z-
code concerns *have* been ignored, and the more important growth has
not happened. That is, Glk has grown since its inception, but not in a
way that would have been blocked by including the remaining Z-machine
features (colors, terminating characters, and that goofy retroactive
input buffer thing).
It's true that the missing features are rarely used, and I suppose
implementing the Z-machine wasn't the point of Glk anyway. But it's
frustrating that after all this time, Glulx+Glk still doesn't provide
a proper superset of the Z-machine's features. Glk has become a
framework for other interpreters to use: for instance, the new version
of Twisty (Z-code for Android) uses Glk so that the slow Java core can
be replaced with the C core from an existing terp, but of course that
means it's unable to play some Infocom games as they were originally
designed.
vw
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>I'm almost starting to think that the right point of view (for color
>only, not other aspects of typography) is that I7 does not support
>colored text. The historical existence of colored text in the
>Z-machine (not cross-platform -- I never saw it on my Apple 2) is not
>an argument for color being an important element of modern IF.
Photopia cries!
Adam
Peter Pears
My personal preferences cry out "Don't take it away! We might need
it!", because I'm that sort of person. My personal preferences also
tend towards inclusion of Multimedia in IF, but that's another can of
worms altogether. But putting preferences aside, I'm fully and
completely with Dave on this one.
Roger
One one hand, I agree with Andrew. I personally prefer Gargoyle for
IF, which to my knowledge handles nothing but grey-text-on-white-
background (except for "-more-" which shows up green), bold, italic,
and fixed-width characters. (If I am wrong, please let me know.) It
looks the best to me and I get a little annoyed when a game even HAS
color, because it forces me to switch to Frotz or something,
On the second hand, I do think that colors have a niche and useful
application in some games. Phototopia did some cool stuff with colors.
I firmly believe, though, that Phototopia's effects are achieveable
via text alone.
On the third hand, I agree with your sentiments that an author should
be able to create what he chooses and how he chooses. Yes, keeping
one's audience in mind is important. But giving an author the freedom
to write as he pleases is never a bad thing.
And on the fourth hand, I'm kind of concerned that I seem to now have
two extra hands.
Roger
Nice! My current project has tables with upwards of 20, sometimes 30
columns. I'm finding it hard to even LOOK at it Inform 7 at this
point. What I'd personally like is the ability to select a delimiter.
"Tab" could be the default, or you could switch to semicolons (or both
could be interpreted as a column delimiter - allowing users to simply
switch will break current extensions). It might make things less messy
for really large tables.
What I'm currently doing is creating and editing my tables in Excel
and then literally copying them into Inform 7. I can't look at them in
Inform with the current setup.
jeremy...@gmail.com
> And what else?
>
> If Z-code interpreters had not supported color quite as well in 1998,
> Photopia wouldn't have been possible in the form that we see. Adam
> would have done something else. It's one game, not an argument for
> color being important to the field.
The winner of this year's comp (Rover's Day Out) used colored text.
The winner of last year's comp (Violet) used colored text. The most
experienced programmer in this year's comp (Snowquest) used colored
text. The most ambitious release of the past year (Blue Lacuna) used
colored text.
Blue Lacuna's efforts to be player friendly were hindered by not being
able to use more different colors, because it had this part where the
player could choose how they would want the different keywords to
display, but it only cycled through a couple of colors and I suspect
looked rather clumsy to anyone who didn't know that Aaron was working
up against a limitation.
--Jeremy
Andrew Plotkin
>
> > And what else?
> >
> > If Z-code interpreters had not supported color quite as well in 1998,
> > Photopia wouldn't have been possible in the form that we see. Adam
> > would have done something else. It's one game, not an argument for
> > color being important to the field.
>
> The winner of this year's comp (Rover's Day Out) used colored text.
> The winner of last year's comp (Violet) used colored text. The most
> experienced programmer in this year's comp (Snowquest) used colored
> text. The most ambitious release of the past year (Blue Lacuna) used
> colored text.
Point taken.
I am, as I said, going to include color in any new style model. When I
said "maybe consider I7 to not support color", I was thinking "at the
moment", and from Jeff's perspective of students wanting a simple
color tag that works blindly across the two VMs. We don't have that
now, and I don't expect to move in that direction.
Ron Newcomb
I would "simply" prefer tables not be word-wrapped. But how to not
word-wrap a table when everything else is, I dunno. My issue isn't so
much headings & entries not lining up -- which elastic tabs fix but
I've always fixed manually anyway by sticking in extra tabs in a row
-- but the width of the table when one places text or stored actions
into it.
Aaron A. Reed
> > I can tell you that in just about every class I've given -- and most
> > definitely in every class that involved younger children -- the idea
> > of being able to color text elements was considered a very important
> > element.
>
> Is that also true in (non-interactive) creative writing classes?
I can't speak to that, but I'm pretty sure if we went another
direction with this analogy, and asked a room full of software
designers if they wanted the ability to affect the color of their
program's output, or would prefer monochrome, every hand would go up.
--Aaron
Aaron A. Reed
>
> And what else?
Well, to speak to something I'm familiar with, Blue Lacuna uses color
in a way people seem to have found interesting and useful.
I've been speaking about Blue Lacuna quite a bit recently in college
classes and at a digital arts conference a few weekends ago. Whenever
I explain that the color-coded keywords are "blue, green, and bold,"
people always ask me why the third one isn't a color, too. I have to
explain that it's for "technical reasons," which tends to be an
unimpressive moment in the presentation.
> If Z-code interpreters had not supported color quite as well in 1998,
> Photopia wouldn't have been possible in the form that we see. Adam
> would have done something else. It's one game, not an argument for
> color being important to the field.
Again, to speak to something I'm familiar with, I can attest that
there's at least one color-based game idea I ended up abandoning
because of the lack of color support. Perhaps all the monochrome fans
are thinking "good riddance" to this, but we'll never know whether
that would have turned out to be an interesting game or not.
I think the argument that "we haven't seen games with color support so
we don't need color support" is fairly circular.
--Aaron
Andrew Plotkin
I'm sure that writers would also prefer to be *able* to use color in
books, in case they ever want or need to. But that wasn't the
question.
Aaron A. Reed
I've bumped into this problem too. The elastic tab stops are a huge
improvement in table usability, but as soon as things have to wrap to
the next line, usability drops drastically again. A way to keep tables
from wrapping and have a horizontal scroll bar would address this
nicely, though yeah, this might create insurmountable difficulties
when integrated into already wrapped text...
--Aaron
Erik Temple
A horizontal scroller combined with tables liberated from word-wrap is the
best idea yet for this (there was a fairly long thread a few months ago
that hashed out a lot of this UI stuff.)
--Erik
Andrew Plotkin
> On Tue, 24 Nov 2009 15:55:55 -0600, Aaron A. Reed <aar...@gmail.com> wrote:
>
> > On Nov 24, 10:03 am, Ron Newcomb <psc...@yahoo.com> wrote:
> >
> >> I would "simply" prefer tables not be word-wrapped. But how to not
> >> word-wrap a table when everything else is, I dunno. My issue isn't so
> >> much headings & entries not lining up -- which elastic tabs fix but
> >> I've always fixed manually anyway by sticking in extra tabs in a row
> >> -- but the width of the table when one places text or stored actions
> >> into it.
> >
> > I've bumped into this problem too. The elastic tab stops are a huge
> > improvement in table usability, but as soon as things have to wrap to
> > the next line, usability drops drastically again. A way to keep tables
> > from wrapping and have a horizontal scroll bar would address this
> > nicely, though yeah, this might create insurmountable difficulties
> > when integrated into already wrapped text...
>
> best idea yet for this (there was a fairly long thread a few months ago
> that hashed out a lot of this UI stuff.)
Is that going to help when you try to put a paragraph of text
into a table entry? It sounds no less painful.
My dream is still an alternative table notation, with one line per
entry rather than one tab per entry.
ChicagoDave
> I would "simply" prefer tables not be word-wrapped. But how to not
> word-wrap a table when everything else is, I dunno. My issue isn't so
> much headings & entries not lining up -- which elastic tabs fix but
> I've always fixed manually anyway by sticking in extra tabs in a row
> -- but the width of the table when one places text or stored actions
> into it.
As I've said before, I think some elements of IF programming,
regardless of platform, need different UI controls. The bulk of Inform
7 is fine in one big blob of a text file, but this table business is
ripe for re-imagining.
If I were to address this from a UI perspective, I would have embedded
grid controls in place of textual tables. Another way to handle it is
to replace all text tables with a button or link that when clicked
opens a grid control with the data reset in grid form.
There's simply no reason to maintain one big blob of text as far as
I'm concerned. Even in word processors you can embed a grid with
sizable columns and rows. Since we've decided to build an IDE that
does a lot of really cool things, why not add onto it with more
sanity?
David C.
www.textfyre.com
Erik Temple
Thanks, Dave. This is my new favorite idea (or set of ideas and
criticisms). Sorry, Aaron... (Zarf, I've not yet used tables for
paragraphs of text. It does sound terrible, except maybe in a text grid,
as Dave suggests.)
--Erik
Jim Aikin
>
> I've bumped into this problem too. The elastic tab stops are a huge
> improvement in table usability, but as soon as things have to wrap to
> the next line, usability drops drastically again.
Agreed. I'm using Eric Eve's Adaptive Hints extension in my WIP, and hit
exactly this problem. If the first hint in a table happens to be several
lines long, the elastic tab stops make a mess in the Source pane.
Tables are great as a basic way of formatting data in IF -- much
friendlier than trying to wrestle with lists of lists. But the author's
UI, with respect to both the display of the table in the IDE and the
commands used to access data in the table, could use some refinement, in
my opinion.
--JA
Erik Temple
I guess I'd better respond to this, since this creative snipping of my
post seems to have convinced a few people that I was calling for colored
text support to be removed from Glulx. (A rather odd assumption, seeing as
I was the guy who, just a couple of posts upthread, had taken the time to
put together a table of the standard HTML colors in I7-friendly format.)
For the record--if there's anyone who cares--these are the points I
actually made:
(1) In general, we don't need colored text to communicate within the
simple design-space of an IF window and there have been poor uses of color
in the past. (I nearly quit playing Photopia when I encountered the red
text on Mars.)
(2) So much for my personal preferences. There are uses of colored text
that are quite appropriate and useful and that work to communicate in ways
that are by now well established in everyone's daily experience. Aaron's
use of color-coded hyperlinked text in Blue Lacuna is the best example.
My intention was to discourage stuff I don't like while affirming that
color has a role to play in IF. I never interpreted Zarf as saying he
wanted to suck all of the color out of Glulx (I thought he was going to
Walden Pond or someplace to make it easier, in fact ;), so it never
occurred to me that we were engaged in a debate over the future of the
medium. Hell, all I've ever done--so far--in IF is release multimedia
tools, so I definitely don't want to see the *capacity* for kaleidoscopic
output go away... I just want Jeff to reconsider whether working hard to
make colored text easier was really worth his time.
--Erik
Gregory Ewing
> Nice! My current project has tables with upwards of 20, sometimes 30
> columns. I'm finding it hard to even LOOK at it Inform 7 at this
> point.
Maybe I7 should have an option to accept source
in HTML format. Then the IDE could have an HTML
editor built into it, and you'd be able to have
tables that really look like tables.
HTML could be useful in other ways, too. E.g.
section, chapter, etc. headings could be specified
using various levels of HTML heading tags.
And maybe bulleted lists could be used for
block structure in the code.
--
Greg
Gregory Ewing
> Is that going to help when you try to put a paragraph of text
> into a table entry?
That's another thing that HTML would solve...
--
Greg
vaporware
And instead of "if a random chance of 1 in 2 succeeds", you could just
use the <blink> tag.
vw
Roger
I'm waiting for the DirectX 11 plugin for Glulx, personally.
ChicagoDave
>
> I'm waiting for the DirectX 11 plugin for Glulx, personally.- Hide quoted text -
You already have it. It's called FyreVM. Take whatever channel data
you create and do something in DirectX accordingly. I really should
put some sort of FyreVM abuse app together.
David C.
www.textfyre.com
vaporware
Finally, IF Quake the way it was meant to be seen!
vw
Jim Aikin
In IF, the writer is also the book designer and the publisher. So a more
appropriate analogy might be, "Do book publishers prefer to have
complete control over the color, size, and font of the text used in
their books?"
I think the answer is unquestionably, "Yes." No publisher would
willingly give up that ability. Nor should they be asked to.
Likewise IF authors. The author, as publisher, should have complete
control over the presentation of the work. The idea that the user of the
interpreter should have any say in the matter is a throwback to the 1980s.
As in a video game, the author should be _able_ to give the player some
degree of control, if that seems appropriate. It's like being able to
design your avatar or something in a video game. Some games will let you
do that (if the game designers want to let you), and some won't. And
some players will refuse to play a game unless they can design their
avatar or whatever the current buzzword/feature is. (I don't play video
games. I have no idea.) That's okay too.
But in any case, it's up to the designer to design and implement a
system of presentation that's appropriate for the game. Control must
always reside with the artist.
--JA
mwigdahl
That would be good for long table definitions. But as far as the
problems when you try to include long paragraphs of text in a table
(whether there are lots of columns or not), is it not possible to
replace the text with a token coupled with a "To say" statement to
keep things nice and compact? That's what I've done, and it seems to
work fine.
Matt
usenet-...@happyjack.org
Whenever I start up a new game and it overrides my interpreter's colors,
I quit. There are enough games out there that I don't need to bother
with one that decides my choices aren't good enough. Honestly, why
would I want to strain my eyes reading white on black, for example, when
I don't have to? This also why I have a minitool set up in my browser
to change a page to black on white; just because garish colors are
available doesn't mean they should be used.
Of course an author should have the *right* to do what he wants, but
that doesn't mean it's a good idea. I think, as an example, Photopia
does it right: at the outset, it asks if you want color. If so, great;
you get the "fuller" experience. Otherwise it still runs fine, and
there are no nasty color surprises.
The author can desire anything he pleases, but for me, interactive
fiction is the text. I don't care much about how you want it to look; I
mean, are you planning on also telling me what font I have to use?
Write good text and let me view it how I want to. If the game is good,
presentation is of little consequence, and if the game is bad, I won't
like it no matter how nice it is made to look.
C.
Jeff Nyman
> Of course an author should have the *right* to do what he wants, but
> that doesn't mean it's a good idea. I think, as an example, Photopia
> does it right: at the outset, it asks if you want color. If so, great;
> you get the "fuller" experience. Otherwise it still runs fine, and
> there are no nasty color surprises.
For what it's worth, I would agree. I don't necessarily think color
should be *necessary* in order to complete a given game, anymore than
I think a certain type of paper should be *necessary* to read a book.
All of this really just speaks to having options: both for the player/
reader and the author. In my experience, there's rarely a good
argument made for limiting people's options either way.
- Jeff
Andrew Plotkin
>
> Whenever I start up a new game and it overrides my interpreter's colors,
> I quit.
Spatterlight has a preference for "colors and styles" -- that is,
allow game colors and styles to override the app default stylesheet.
You can turn it off. This is what it's for.
Regardless of what the VM spec says, interpreters are going to provide
these sorts of options -- and they should. IF authors will never have
complete control over the player's display, any more than web page
authors do. That's never been in question.
(Really I'd like "colors" and "styles" to be separate preferences,
just because color is such a flashpoint for many people. I have the
same reaction to green-on-black text, for example. But this is a
detail.)
Eliuk Blau
> I think this misses the point entirely...our personal preferences
> aside, we should _enable_ the same functionality that we have in other
> publishing environments. Allow the author/game designer the full set
> of options to do what they will. They may come up with something that
> never ocurred to any of us here. So we should implement styles that
> allow font family, style, color, and weight and not worry about its
> abuses.
>
> David C.www.textfyre.com
I fully agree.
Eliuk.
Roger
wrote:
> > And what else?
>
> > If Z-code interpreters had not supported color quite as well in 1998,
> > Photopia wouldn't have been possible in the form that we see. Adam
> > would have done something else. It's one game, not an argument for
> > color being important to the field.
>
> The winner of last year's comp (Violet) used colored text. The most
> experienced programmer in this year's comp (Snowquest) used colored
> text. The most ambitious release of the past year (Blue Lacuna) used
> colored text.
>
> Blue Lacuna's efforts to be player friendly were hindered by not being
> able to use more different colors, because it had this part where the
> player could choose how they would want the different keywords to
> display, but it only cycled through a couple of colors and I suspect
> looked rather clumsy to anyone who didn't know that Aaron was working
> up against a limitation.
>
> --Jeremy
Violet had colored text? I didn't even know. I personally think IF
looks awesome in Gargoyle. I go so far as to design specifically with
the Gargoyle aesthetic in mind. Which means no color.
Peter Pears
on the making of, say, Zork Zero, Beyond Zork, Shogun, Arthur,
Gateway, Gateway II, Eric the Unready, Time Quest, Carma, Six
Stories...
Honestly, I sometimes think the position I see here against all things
that stray from the "standard book format" is way too radical,
unforgiving, and ultimately severely limiting.
Great to see that people at least agree that the authors should have
the choice, and so should the players.
Roger
I hope I'm not giving the impression that I think color is a bad
thing. I personally think the author should have the most control over
the presentation of his work - more than the player - but that options
for both are a good thing. Color isn't necessarily important to me, as
a player, but it's still good to have that option.
Adam Thornton
<usenet-...@happyjack.org> wrote:
>are you planning on also telling me what font I have to use?
>Write good text and let me view it how I want to. If the game is good,
>presentation is of little consequence
S. John Ross cries!
Adam
Adam Thornton
Jeff Nyman <jeff...@gmail.com> wrote:
[...]
>- Jeff
Oh, hey! Good to see you made it back safely!
Adam
Jim Aikin
>>
>> Likewise IF authors. The author, as publisher, should have complete
>> control over the presentation of the work. The idea that the user of the
>> interpreter should have any say in the matter is a throwback to the 1980s.
>
> Whenever I start up a new game and it overrides my interpreter's colors,
> I quit. There are enough games out there that I don't need to bother
> with one that decides my choices aren't good enough. Honestly, why
> would I want to strain my eyes reading white on black, for example, when
> I don't have to?
You're certainly free to do as you please. But it's entirely possible
that by using this criterion for filtering which games you'll play,
you're going to miss some good games.
> The author can desire anything he pleases, but for me, interactive
> fiction is the text. I don't care much about how you want it to look; I
> mean, are you planning on also telling me what font I have to use?
In general, it's true that the game IS text, in exactly the same way
that a novel IS text. "Great Expectations" would still be "Great
Expectations" no matter what typeface were used.
That said, there are plenty of examples in conventional fiction of text
effects. I'm thinking, for instance, of the mouse's tale in Alice in
Wonderland. There are text effects in Tristram Shandy, a very strange
novel that was published in 1760 and is still in print. Any number of
science fiction books rely on font changes to introduce alien viewpoints
-- as does "Rover's Day Out." Are you saying that you would insist on
playing "Rover's Day Out" in plain text? What would you hope to gain by
insisting on that?
Nonfiction books on computer programming quite conventionally use at
least three different typefaces, in order to set off different types of
material. The choice of typeface conveys important information. Do you
refuse to read books that rely on typeface changes to convey
information? Or do you simply accept the fact that the book designer
knows what she's doing?
Are you trying to make a case that such effects are always irrelevant?
They may be irrelevant to YOU, but all that proves is that from time to
time you're going to miss out on stuff that may be interesting.
I reiterate: Because virtually all IF is self-published, the author is
also the publisher and book designer, and therefore has (or ought to
have, if the technology supported it) primary responsibility for the
type design.
Good book designers produce readable books; bad ones produce books that
are difficult to read. But very, very few of them would ever dare use
single-spaced 11-point Courier throughout a book. If that's your
preference, you're in a very small minority.
--JA