[IF Comp] Why Glulx?
Kevin Bracey
Given that you were coding in Inform, what motivated you to target Glulx
rather than the Z-machine?
a) Dynamic memory restrictions
b) Total memory restrictions
c) 32-bit variables
d) Some other capability that Glulx has over the Z-machine
e) Preferring the glk I/O model to the Z-machine's
f) Better glulx/glk support than V6 support on your platform
g) Wanting to push Glulx support forward
h) Other
I am of course asking this from the point of view of someone using a
platform that has a state-of-the-art Z-machine, but no glulx interpreter :)
Kevin
-----
OKB -- not okblacke
>Here's an open question to the authors of this year's Glulx entries.
>
>Given that you were coding in Inform, what motivated you to target Glulx
>rather than the Z-machine?
>
> a) Dynamic memory restrictions
> b) Total memory restrictions
> c) 32-bit variables
> d) Some other capability that Glulx has over the Z-machine
> e) Preferring the glk I/O model to the Z-machine's
> f) Better glulx/glk support than V6 support on your platform
> g) Wanting to push Glulx support forward
> h) Other
For "an apple from nowhere": d, e, and g (although d and e in this case
might go together -- I'm not sure if text styling really falls under I/O).
For "Stick it to the man": b, d, e, and g.
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Kevin Bracey
news:20011122130015...@mb-md.aol.com...
> "Kevin Bracey" wrote:
> >Given that you were coding in Inform, what motivated you to target Glulx
> >rather than the Z-machine?
> >
> > a) Dynamic memory restrictions
> > b) Total memory restrictions
> > c) 32-bit variables
> > d) Some other capability that Glulx has over the Z-machine
> > e) Preferring the glk I/O model to the Z-machine's
> > f) Better glulx/glk support than V6 support on your platform
> > g) Wanting to push Glulx support forward
> > h) Other
>
> For "an apple from nowhere": d, e, and g (although d and e in this
case
> might go together -- I'm not sure if text styling really falls under I/O).
>
> For "Stick it to the man": b, d, e, and g.
You did go a bit overboard on the styling, didn't you? Blimey. It reminds me
a little of the mid-90's when everyone discovered Netscape's <BLINK> tag...
On the memory front, presumably the limit you would have hit would be
Inform's artifical 320K limit on V6 - SITTM is only 360K. I'm knocking up a
compiler patch that will lift Inform's V6/V7 memory limit up to 512K.
Kevin
-----
M. D. Krauss
"Kevin Bracey" <ke...@bracey-griffith.freeserve.co.uk> wrote:
> "OKB -- not okblacke" <bren...@aol.comRemove> wrote in message
> news:20011122130015...@mb-md.aol.com...
[snip]
> > For "an apple from nowhere": d, e, and g (although d and e in this
> case
> > might go together -- I'm not sure if text styling really falls under I/O).
> >
> > For "Stick it to the man": b, d, e, and g.
>
> You did go a bit overboard on the styling, didn't you? Blimey. It reminds me
> a little of the mid-90's when everyone discovered Netscape's <BLINK> tag...
>
Reminds me of the 80's when everyone discovered
the ANSI blink code.
-M
(Yes!
We had "style" in email before HTML!
We even had animations!
Can't do THAT with HTML...)
OKB -- not okblacke
>You did go a bit overboard on the styling, didn't you? Blimey. It reminds me
>a little of the mid-90's when everyone discovered Netscape's <BLINK> tag...
<BLINK>I hope you can read HTML usenet posts!</BLINK> :-) Overboard? I
guess that's a matter of opinion.
>On the memory front, presumably the limit you would have hit would be
>Inform's artifical 320K limit on V6 - SITTM is only 360K. I'm knocking up a
>compiler patch that will lift Inform's V6/V7 memory limit up to 512K.
I wasn't considering V6, since I knew (and still know) nothing about how
to use it. It's probable that SITTM would have fit into Z8 (or possibly even
Z5), but that would have meant no menu window, no text styling, etc. Also, I
wasn't sure when I started how large it was going to be.
ems...@mindspring.com
a, g. But the reason I want to push Glulx support is that I want more
people to be able to play the future games I anticipate also releasing
in this format.
ES
> -----
Adam Thornton
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>Here's an open question to the authors of this year's Glulx entries.
>
>Given that you were coding in Inform, what motivated you to target Glulx
>rather than the Z-machine?
>
> a) Dynamic memory restrictions
No. SMTUC would have fit comfortably in a .z5.
> b) Total memory restrictions
No. See above.
> c) 32-bit variables
Not helpful.
> d) Some other capability that Glulx has over the Z-machine
Yep. Sound and image support, good multi-window support. Yes, v6 does
this too, but...
> e) Preferring the glk I/O model to the Z-machine's
This is one reason for d).
> f) Better glulx/glk support than V6 support on your platform
And this is the other, since I use Linux preferentially.
> g) Wanting to push Glulx support forward
This, kind of. I see Glulx as more useful in the long term than v6, and
I need a full-featured Linux terp.
> h) Other
Doe had already written a nice library to make using Glulx easier.
Adam
Jaap van der Velde
I am a bit critical on the use of Glulx and I think Adam's
critique shows why:
On Mon, 26 Nov 2001 15:46:22 +0000 (UTC), ad...@fsf.net (Adam
Thornton) wrote:
> In article <9ticvu$qd7$1...@news5.svr.pol.co.uk>,
> Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
> > a) Dynamic memory restrictions
> No. SMTUC would have fit comfortably in a .z5.
> > b) Total memory restrictions
> No. See above.
> > c) 32-bit variables
> Not helpful.
Sofar, I agree. None of these are truly important issues,
except for maybe a few games, most of which can probably
be helped with bigger game-size (fixed with .z8). Which
leaves some Z-machine abuse that may or may not be helped
and I don't think that really explains or necessitates
either the development or use of Glulx. But there's more:
> > d) Some other capability that Glulx has over the Z-machine
> Yep. Sound and image support, good multi-window support. Yes,
> v6 does this too, but...
> > e) Preferring the glk I/O model to the Z-machine's
> This is one reason for d).
> > f) Better glulx/glk support than V6 support on your platform
> And this is the other, since I use Linux preferentially.
So, it all boils down to v6 not being very well supported
and the use of sounds and images as the primary reason to
use either Glulx or .z6? Both multi-media and multi-window
support don't sound very necessary to me right now.
(although I do admit I have some cool ideas on an IC,
an interactive comic, but I sofar think Flash is the way
to go on that one, but let's not get side-tracked)
You see, my problem is that right now the only reasons to
use Glulx aren't very good ones. So I'm curious to any other
reasons the authors have for starting work on it in the
first place. And where do they propose to take it in the
near and foreseeable future?
> > g) Wanting to push Glulx support forward
Which is the only valid reason left, then. Although I still
think Glulx would eventually evolve into something used for
IF that definitely is -not- a text adventure, but a multi-
media experience. Especially since it does not appear to
substantially improve on the parser or other language-
aspects of the z-machine. (or am I wrong?)
> This, kind of. I see Glulx as more useful in the long term
> than v6, and I need a full-featured Linux terp.
Well, I'm not up to date on the IF-cans and -cannots on
Linux, so I'll remain silent there.
But to clearly state my most important question on the
Glulx matter: What does Glulx have to offer the author of
a 'nice and clean' text-adventure with no need for fancy
fonts, images, sounds or any other multi-media experience?
(just as most 'regular' authors of traditional fiction have
no need for these devices)
Grtz,
JAAP.
Andrew Plotkin
> I am a bit critical on the use of Glulx and I think Adam's
> critique shows why:
> On Mon, 26 Nov 2001 15:46:22 +0000 (UTC), ad...@fsf.net (Adam
> Thornton) wrote:
>> In article <9ticvu$qd7$1...@news5.svr.pol.co.uk>,
>> Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>> > a) Dynamic memory restrictions
>> No. SMTUC would have fit comfortably in a .z5.
>> > b) Total memory restrictions
>> No. See above.
>> > c) 32-bit variables
>> Not helpful.
> Sofar, I agree. None of these are truly important issues,
> except for maybe a few games, most of which can probably
> be helped with bigger game-size (fixed with .z8).
I would point out that Emily is *not* the first person ever to find
the Z-machine inadequate.
We have a long history of people -- not everybody, but still a fair
number of people -- running into Z-machine limits on global variables,
properties, attributes, and RAM (which must include property data,
array data, and the dictionary). None of those are helped by switching
to Z8.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Magnus Olsson
>think Glulx would eventually evolve into something used for
>IF that definitely is -not- a text adventure, but a multi-
>media experience. Especially since it does not appear to
>substantially improve on the parser or other language-
>aspects of the z-machine. (or am I wrong?)
I think you're slightly confused about what Glulx really
is, or, rather, that you're talking about the current
combination of Bi-platform Inform compiler/library and
Glk.
Glulx itself is just a virtual machine (glulxe) and its
machine language. It's sufficiently general to be used
for anything you can think of.
>But to clearly state my most important question on the
>Glulx matter: What does Glulx have to offer the author of
>a 'nice and clean' text-adventure with no need for fancy
>fonts, images, sounds or any other multi-media experience?
Basically, if you don't want that "fancy" stuff, you can think of
Glulx as an alternative to the Z-machine that offers more memory,
32-bit arithmetic, a larger number of function parameters and possibly
some other things as well.
So as long as your game isn't too large and your code isn't
too complex, you can just as well compile to Z-code. That will
give you a greater choice of interpreters today; I expect that
will change in the future.
What I expect is going to happen among authors of "nice and
clean" text adventures is that some of them will write so
large or complex games that they can't fit them within the
Z-machine. In such a case, moving to Glulx is *really simple*.
If you *are* going to use even slightly fancy stuff, such
as menues that are placed at the bottom of the screen rather
than at the top, or different sizes of text, or both bold
and italic text in the same game, then you can use Glulx
but not the Z-machine.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Kevin Bracey
m...@df.lth.se (Magnus Olsson) wrote:
> If you *are* going to use even slightly fancy stuff, such
> as menues that are placed at the bottom of the screen rather
> than at the top, or different sizes of text, or both bold
> and italic text in the same game, then you can use Glulx
> but not the Z-machine.
Oh, complete rubbish. Why do people keep saying things like that? You can do
any of that in V6, except change the font size. And I'm not terribly
convinced of the aesthetic benefits of changing font size. How many books do
you see that don't stick to a single typeface?
The Z-machine even goes beyond Glulx/glk in a number of areas:
1) Overlaying text on pictures
2) More flexible textual layout - I can't see any way of replicating
something as simple as "box" in glk
3) Support for more than just Latin-1
4) The ability to flow text around irregularly shaped images
5) Native menu support
Just because your Z-code interpreter's ropey isn't any reason to start making
claims like that about the Z-machine as a whole.
In fact, as far as display is concerned, the only thing I can think of that
glk can do that V6 can't is changing font size. Admittedly a lot of things
are easier with glk than with raw V6, but then that's what V6Lib's for.
Getting non-primary text colours is tricky, but possible.
Sorry, I'll attempt to calm down now. I've just got this chip on my shoulder
from creating Zip 2000 with state-of-the-art V6 support three years ago, and
since then no-one else on any other platform has managed to get V6 support
functioning well enough for anyone to actually use it. Even Moments Out Of
Time is woefully crude (in the UI department) compared to what Infocom did
with V6.
It doesn't help that the standard Inform library doesn't handle V6 properly,
and that the compiler restricts V6 to 320K. However, I'm fixing all these
problems and submitting them to Roger Firth's patch page.
--
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 518566
645 Newmarket Road Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pace.co.uk/
Magnus Olsson
Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9tujun$94l$2...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
>> If you *are* going to use even slightly fancy stuff, such
>> as menues that are placed at the bottom of the screen rather
>> than at the top, or different sizes of text, or both bold
>> and italic text in the same game, then you can use Glulx
>> but not the Z-machine.
>
>Oh, complete rubbish. Why do people keep saying things like that?
In this case, because I simply forgot z6. I must also say that I'm not
very sure of what you can and can't do in z6, except that its concept
of a window is different from that of Glk (which is used by Glulx
Inform).
>You can do
>any of that in V6, except change the font size. And I'm not terribly
>convinced of the aesthetic benefits of changing font size. How many books do
>you see that don't stick to a single typeface?
That's a false analogy - books aren't designed to be read on-screen.
Anyway, the only use I can see for a larger font size in "pure" text
IF (not even ASCII graphics allowed :-) ) is for headlines and stuff
like that.
>The Z-machine even goes beyond Glulx/glk in a number of areas:
>
> 1) Overlaying text on pictures
> 2) More flexible textual layout - I can't see any way of replicating
> something as simple as "box" in glk
> 3) Support for more than just Latin-1
> 4) The ability to flow text around irregularly shaped images
> 5) Native menu support
...of which only 3) is relevant for what we were discussing, viz.
"pure" text IF.
>Sorry, I'll attempt to calm down now.
Yes, you seem a bit excited :-).
>I've just got this chip on my shoulder
>from creating Zip 2000 with state-of-the-art V6 support three years ago, and
>since then no-one else on any other platform has managed to get V6 support
>functioning well enough for anyone to actually use it.
This is indeed sad, but...
...it's easy to say "look at all these wonderful things you can do
with V6". Has anybody actually expressed regret at not being
able to do these things in other systems? I'm not being sarcastic,
I'm just wondering if we really need to invest a lot of time in getting
V6 to work properly when nobody seems to want to use it. Yes, yes,
I know; let me reformulate: would many peopel want to use V6 if there
were more interpreters available? Why, or why not?
Jason C. Penney
> In article <31d0f6df4...@kbracey.cam.pace.co.uk>,
> Kevin Bracey <kevin....@pace.co.uk> wrote:
>>The Z-machine even goes beyond Glulx/glk in a number of areas:
>>
>> 1) Overlaying text on pictures
>> 2) More flexible textual layout - I can't see any way of replicating
>> something as simple as "box" in glk
>> 3) Support for more than just Latin-1
>> 4) The ability to flow text around irregularly shaped images
>> 5) Native menu support
> ...of which only 3) is relevant for what we were discussing, viz.
> "pure" text IF.
While I guess it's outside the boundaries of "pure" IF, V6 "box"
support was one of the most requested features in early V6Lib releases.
Would using interesting text layout (like flowing text around images
that weren't there) be outside "pure" IF?
>>I've just got this chip on my shoulder
>>from creating Zip 2000 with state-of-the-art V6 support three years ago, and
>>since then no-one else on any other platform has managed to get V6 support
>>functioning well enough for anyone to actually use it.
> ...it's easy to say "look at all these wonderful things you can do
> with V6". Has anybody actually expressed regret at not being
> able to do these things in other systems? I'm not being sarcastic,
> I'm just wondering if we really need to invest a lot of time in getting
> V6 to work properly when nobody seems to want to use it. Yes, yes,
> I know; let me reformulate: would many peopel want to use V6 if there
> were more interpreters available? Why, or why not?
I would say more people would, yes, since I have over the past few
years worked with about 10 different people on V6 games. Some of them
got disgusted with the lack of support and went to Glk, or standard
z-machine, and some of them just gave up the whole idea. To me the
latter is upsetting because those works may never be seen now.
Jay
--
Jason C Penney (jpenney [AT] jczorkmid.net) Xarton Dragon -=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor
Magnus Olsson
Jason C. Penney <jpe...@jczorkmid.SPAMOFF.net> wrote:
>Magnus Olsson <m...@df.lth.se> wrote:
>> In article <31d0f6df4...@kbracey.cam.pace.co.uk>,
>> Kevin Bracey <kevin....@pace.co.uk> wrote:
>
>>>The Z-machine even goes beyond Glulx/glk in a number of areas:
>>>
>>> 1) Overlaying text on pictures
>>> 2) More flexible textual layout - I can't see any way of replicating
>>> something as simple as "box" in glk
>>> 3) Support for more than just Latin-1
>>> 4) The ability to flow text around irregularly shaped images
>>> 5) Native menu support
>
>> ...of which only 3) is relevant for what we were discussing, viz.
>> "pure" text IF.
>
>While I guess it's outside the boundaries of "pure" IF, V6 "box"
>support was one of the most requested features in early V6Lib releases.
>Would using interesting text layout (like flowing text around images
>that weren't there) be outside "pure" IF?
The distinction is more than a little bit silly, but I was writing
within the context of the original question:
[paraphrased from memory] "What will Glulx offer me over Z-code
if I'm not interested in doing any 'fancy' stuff".
Personalyl, I think that even "pure" text adventures can use things
like fonts, colours, and, indeed, boxes to great advantage.
>>would many peopel want to use V6 if there
>> were more interpreters available? Why, or why not?
>
>I would say more people would, yes, since I have over the past few
>years worked with about 10 different people on V6 games. Some of them
>got disgusted with the lack of support and went to Glk, or standard
>z-machine, and some of them just gave up the whole idea.
Oh. I didn't know that.
To continue to play Devil's advocate (or, perhaps, Glk's advocate),
were these projects started before other graphics-capable systems
were available?
Jason C. Penney
> In article <gULM7.113$zX1.3...@typhoon.ne.mediaone.net>,
> Jason C. Penney <jpe...@jczorkmid.SPAMOFF.net> wrote:
>>>would many peopel want to use V6 if there
>>> were more interpreters available? Why, or why not?
>>
>>I would say more people would, yes, since I have over the past few
>>years worked with about 10 different people on V6 games. Some of them
>>got disgusted with the lack of support and went to Glk, or standard
>>z-machine, and some of them just gave up the whole idea.
> Oh. I didn't know that.
> To continue to play Devil's advocate (or, perhaps, Glk's advocate),
> were these projects started before other graphics-capable systems
> were available?
Well, if I'm remembering my history correctly:
Dec 97 - Glk proposal was released.
Jan 98 - first public V6Lib and manual were released
Apr 98 - HTML TADS was released.
HTML TADS was the most impressive since it was announced, and released
with a fully capable terp right away. Glk and V6 were both uncertain.
Most of the interest in V6Lib came between mid 1998-1999. (Not to say
it's died out completely... Jon "My Angel" Ingold's NovelLib release
has full V6Lib support).
Kevin Bracey
"Jason C. Penney" <jpe...@jczorkmid.SPAMOFF.net> wrote:
> Magnus Olsson <m...@df.lth.se> wrote:
> > In article <31d0f6df4...@kbracey.cam.pace.co.uk>,
> > Kevin Bracey <kevin....@pace.co.uk> wrote:
>
> >>The Z-machine even goes beyond Glulx/glk in a number of areas:
> >>
> >> 1) Overlaying text on pictures
> >> 2) More flexible textual layout - I can't see any way of replicating
> >> something as simple as "box" in glk
> >> 3) Support for more than just Latin-1
> >> 4) The ability to flow text around irregularly shaped images
> >> 5) Native menu support
>
> > ...of which only 3) is relevant for what we were discussing, viz.
> > "pure" text IF.
If you're talking about pure text IF, then none of glk's fancy features are
required at all - just compile for V5/V8; it's only memory limits that are an
issue then. You explicitly said that the Z-machine being unable to do any
sort of fancy effects, which is patently false.
>
> While I guess it's outside the boundaries of "pure" IF, V6 "box"
> support was one of the most requested features in early V6Lib releases.
> Would using interesting text layout (like flowing text around images
> that weren't there) be outside "pure" IF?
Does it do box now? I've just coded it up myself for an Inform patch this
morning. I've been following a vanila Z-code model for these patches, rather
than the class-based architecture of V6Lib.
> > ...it's easy to say "look at all these wonderful things you can do
> > with V6". Has anybody actually expressed regret at not being
> > able to do these things in other systems? I'm not being sarcastic,
> > I'm just wondering if we really need to invest a lot of time in getting
> > V6 to work properly when nobody seems to want to use it. Yes, yes,
> > I know; let me reformulate: would many peopel want to use V6 if there
> > were more interpreters available? Why, or why not?
That's the point, isn't it - people are obviously wanting to do these things
and they're turning to Glulx to do them. I'm just standing up for the older
existing standard, and saying that it shouldn't be dismissed so readily,
especially by people making false claims about missing features.
>
> I would say more people would, yes, since I have over the past few
> years worked with about 10 different people on V6 games. Some of them
> got disgusted with the lack of support and went to Glk, or standard
> z-machine, and some of them just gave up the whole idea. To me the
> latter is upsetting because those works may never be seen now.
So what should I be concentrating my effort on? What's missing? How can we
make it easier? The two main problems are lack of decent V6 interpreters on
some platforms, and maybe insufficient abstraction. What are the best V6
interpreters on each platform, and how far do they go? I'll start the list:
Platform Terp Standard Versions Blorb PNG JPEG AIFF MOD SONG
----------------------------------------------------------------------------
RISC OS Zip 2000 1.0, no omissions 12345678 Yes Yes Yes Yes Yes Yes
http://www.bracey-griffith.freeserve.co.uk/Zip2000/
Please add your top terps...
As for abstraction, what about implementing the glk API in V6? Would that
help? I'm pretty certain that that's quite possible, with near total
functionality.
Magnus Olsson
Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <gULM7.113$zX1.3...@typhoon.ne.mediaone.net>
> "Jason C. Penney" <jpe...@jczorkmid.SPAMOFF.net> wrote:
>
>> Magnus Olsson <m...@df.lth.se> wrote:
>> >>The Z-machine even goes beyond Glulx/glk in a number of areas:
>> >>
>> >> 1) Overlaying text on pictures
>> >> 2) More flexible textual layout - I can't see any way of replicating
>> >> something as simple as "box" in glk
>> >> 3) Support for more than just Latin-1
>> >> 4) The ability to flow text around irregularly shaped images
>> >> 5) Native menu support
>> > ...of which only 3) is relevant for what we were discussing, viz.
>> > "pure" text IF.
>
>If you're talking about pure text IF, then none of glk's fancy features are
>required at all - just compile for V5/V8; it's only memory limits that are an
>issue then.
This is getting more than a little bit silly, since it's just a matter
of defining "pure text IF" and "fancy features". But let me try,
since I'm feeling a bit pedantic:
If by "pure text IF" we mean a game that uses only text in its output,
but may use different fonts, font sizes, italic/bold, and colours, then
only 3) above is relevant, and Glk has *a few* more features than the
v5/v8 Z machine.
But I'm not sure why anybody would be such a purist as to refuse to
use any "fancy" features - even a "pure" text game could benefit from
the "fancy" features.
And Glulx offers more than more memory: it also offers 32-bit
arithmetic and relaxes most of those irritating limitations of the
Z-machine, all of which could be of interest to all IF authors.
>You explicitly said that the Z-machine being unable to do any
>sort of fancy effects, which is patently false.
As I've already explained, I was talking about V5/V8 and simply forgot
V6, which is of course wrong.
Mea culpa. Bad, *bad* Magnus. Now, can we go on, please?
Kevin Bracey
m...@df.lth.se (Magnus Olsson) wrote:
> But I'm not sure why anybody would be such a purist as to refuse to
> use any "fancy" features - even a "pure" text game could benefit from
> the "fancy" features.
Maybe, but don't forget the portability expense. Is it really so important
to have your background a particular shade of blue with such and such a point
size of chapter headings that you rule out all but three platforms? I'm sure
the number of platforms Glulx works on will gradually increase, but I doubt
it will ever reach the number of the Z-machine. And no-one's made a Glulx
interpreter for my platform yet :(
>
> And Glulx offers more than more memory: it also offers 32-bit
> arithmetic and relaxes most of those irritating limitations of the
> Z-machine, all of which could be of interest to all IF authors.
Indeed, but of less interest to IF _players_. In a sense what I'm trying to
do here is ask people not to forget the portability of the Z-machine, and
dispel oft-repeated misconceptions about its capabilities.
Just as everyone here jumps on people who say "why not use Java", I'm jumping
on people who say "why not use Glulx". Glulx is lovely, and provides a number
of things the Z-machine cannot, but ask yourself - do you really need it?
Magnus Olsson
Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9u0dib$lrp$1...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
>> But I'm not sure why anybody would be such a purist as to refuse to
>> use any "fancy" features - even a "pure" text game could benefit from
>> the "fancy" features.
>
>Maybe, but don't forget the portability expense. Is it really so important
>to have your background a particular shade of blue with such and such a point
>size of chapter headings that you rule out all but three platforms? I'm sure
>the number of platforms Glulx works on will gradually increase, but I doubt
>it will ever reach the number of the Z-machine. And no-one's made a Glulx
>interpreter for my platform yet :(
On the other hand, how many platforms have full implementations of
the V6 Z-machine? One, if I understand things correctly.
>> And Glulx offers more than more memory: it also offers 32-bit
>> arithmetic and relaxes most of those irritating limitations of the
>> Z-machine, all of which could be of interest to all IF authors.
>
>Indeed, but of less interest to IF _players_.
Well, yes, if the lack of those features just means a minor inconvenience
for the author. But if the inconvenience is such that the game doesn't
get written...
>Just as everyone here jumps on people who say "why not use Java", I'm jumping
>on people who say "why not use Glulx". Glulx is lovely, and provides a number
>of things the Z-machine cannot, but ask yourself - do you really need it?
My agenda is definitely not to persuade people to choose Glulx
over Z-code, but to dispel certain misconceptions about it, just as
ou are combatting misconceptions about Z6.
Matthew Russotto
>In article <092a16e04...@kbracey.cam.pace.co.uk>,
>Kevin Bracey <kevin....@pace.co.uk> wrote:
>>In message <9u0dib$lrp$1...@news.lth.se>
>> m...@df.lth.se (Magnus Olsson) wrote:
>>
>>> But I'm not sure why anybody would be such a purist as to refuse to
>>> use any "fancy" features - even a "pure" text game could benefit from
>>> the "fancy" features.
>>
>>Maybe, but don't forget the portability expense. Is it really so important
>>to have your background a particular shade of blue with such and such a point
>>size of chapter headings that you rule out all but three platforms? I'm sure
>>the number of platforms Glulx works on will gradually increase, but I doubt
>>it will ever reach the number of the Z-machine. And no-one's made a Glulx
>>interpreter for my platform yet :(
>
>On the other hand, how many platforms have full implementations of
>the V6 Z-machine? One, if I understand things correctly.
Five. Of course, you'll have to encode your files in Infocom format
to use the other four. (Apple IIgs, Mac, Amiga, PC)
Though I admit I'm starting to get motivated to put some Blorb support
into the V6 Zip Infinity and release it on an experimental basis.
Just starting, though.
--
Matthew T. Russotto russ...@pond.com
=====
Get Caught Reading, Go To Jail!
A message from the Association of American Publishers
Free Dmitry Sklyarov! DMCA delenda est!
http://www.freedmitry.org
Kent Tessman
"Jason C. Penney" <jpe...@jczorkmid.SPAMOFF.net> wrote:
Jason C. Penney
> Aug 97 - Hugo v2.4 released
I'm a horrible person. I always say I won't forget Hugo next
time... and I almost always do. Hugo, like TADS was anounced and
released with fully capable terps right away.
sigh...
Jay
--
Andrew Plotkin
> And no-one's made a Glulx interpreter for my platform yet :(
The no-frills library will work. The curses library should work,
unless your platform lacks a curses library, which I don't think is
true.
If you want to play a multimedia game and not miss out on the graphics
and sound, that will take more work. I can't help you with it. I only
have MacOS and Linux around here.
> Just as everyone here jumps on people who say "why not use Java",
> I'm jumping on people who say "why not use Glulx". Glulx is lovely,
> and provides a number of things the Z-machine cannot, but ask
> yourself - do you really need it?
I have always said that if the capabilities of the V8 Z-machine are
good enough for your game, you have no reason to switch that game to
Glulx.
Kevin Bracey
news:u07pmco...@corp.supernews.com...
> >the V6 Z-machine? One, if I understand things correctly.
>
> Five. Of course, you'll have to encode your files in Infocom format
> to use the other four. (Apple IIgs, Mac, Amiga, PC)
I am half-seriously considering writing a Blorb->MG1 converter, tragically.
Stop me before it's too late.
There is a minor gotcha, in that the interpreters for those platforms are of
course commercial products, so you'd have to pay for them. But in the
absence of any freeware alternative...
I was lead to believe by the Z-Spec that Frotz did V6. What's missing?
What about V6 on handhelds? V6, even with graphics, should be possible on
many current handhelds, especially considering that Infocom made do with
320x200 displays. And even without graphics, reasonable fallbacks should be
possible. Anyone looking at this? Or Glulx on handhelds?
> Though I admit I'm starting to get motivated to put some Blorb support
> into the V6 Zip Infinity and release it on an experimental basis.
> Just starting, though.
Feel free to rip as much code as you like out of Zip 2000, or to contact me
with any queries.
Kevin
-----
OKB -- not okblacke
>The Z-machine even goes beyond Glulx/glk in a number of areas:
>
> 1) Overlaying text on pictures
> 2) More flexible textual layout - I can't see any way of replicating
> something as simple as "box" in glk
> 3) Support for more than just Latin-1
> 4) The ability to flow text around irregularly shaped images
> 5) Native menu support
This is true, but these have associated sacrifices, most notably loss of
scrollback capability and the requirement that everything be positioned
explicitly. Now, admittedly I dream of the ability to do non-rectangular
windows in Glk, but the advantage of the Glk system is that the windows are
linked to their content.
Kevin Bracey
"OKB -- not okblacke" <bren...@aol.comRemove> wrote in message
> Kevin Bracey kevin....@pace.co.uk wrote:
> >The Z-machine even goes beyond Glulx/glk in a number of areas:
>
of
> scrollback capability and the requirement that everything be positioned
> explicitly. Now, admittedly I dream of the ability to do non-rectangular
> windows in Glk, but the advantage of the Glk system is that the windows
are
> linked to their content.
That is very true, and it's something of a performance and memory hit for
Zip 2000 when doing V6, as it suddenly needs a graphical backing store.
I'm sure scrollback of a sort can be done by using pulling text out like you
would when transcripting, and pressing a hot key to switch to scrollback
mode. I'm sure I've seen that done even on non-V6 terps. Not attempted it
myself though.
I'm still pretty convinced that I can implement the glk API in V6. That
might make
authors' lives easier on the manual positioning front.
Kevin
-----
Kevin Bracey
news:9u0v31$bje$1...@news.panix.com...
> Kevin Bracey <kevin....@pace.co.uk> wrote:
> > And no-one's made a Glulx interpreter for my platform yet :(
>
> The no-frills library will work. The curses library should work,
> unless your platform lacks a curses library, which I don't think is
> true.
I've just about gotten cheapglk working, apart from the file handling. I've
only found one curses library, and it dates back to 1993, and in turn relies
on all sorts of crusty other libraries. I'll ask around.
>
> If you want to play a multimedia game and not miss out on the graphics
> and sound, that will take more work. I can't help you with it. I only
> have MacOS and Linux around here.
Well, yes. Either of the above would be light-years away from Zip 2000, and
I'm not really relishing the thought of doing all that UI work again from
scratch. Maybe one day when a convincing enough Glulx game comes along... I
did do a bit of work starting off on the VM portions of "Glx 2000", but it
never got very far.
Kevin
-----
Adam Thornton
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>"Andrew Plotkin" <erky...@eblong.com> wrote in message
>news:9u0v31$bje$1...@news.panix.com...
>> Kevin Bracey <kevin....@pace.co.uk> wrote:
>> > And no-one's made a Glulx interpreter for my platform yet :(
>> The no-frills library will work. The curses library should work,
>> unless your platform lacks a curses library, which I don't think is
>> true.
>I've just about gotten cheapglk working, apart from the file handling. I've
>only found one curses library, and it dates back to 1993, and in turn relies
>on all sorts of crusty other libraries. I'll ask around.
I'm sorry, but I missed it: which platform?
Adam
David Fillmore
okblacke) wrote:
>Kevin Bracey kevin....@pace.co.uk wrote:
>>The Z-machine even goes beyond Glulx/glk in a number of areas:
>>
>> 1) Overlaying text on pictures
>> 2) More flexible textual layout - I can't see any way of replicating
>> something as simple as "box" in glk
>> 3) Support for more than just Latin-1
>> 4) The ability to flow text around irregularly shaped images
>> 5) Native menu support
>
> This is true, but these have associated sacrifices, most notably loss of
>scrollback capability and the requirement that everything be positioned
>explicitly. Now, admittedly I dream of the ability to do non-rectangular
>windows in Glk, but the advantage of the Glk system is that the windows are
>linked to their content.
Assuming you consider that an advantage.
--
Fillmore
Jaap van der Velde
> > Especially since it does not appear to
> > substantially improve on the parser or other language-
> > aspects of the z-machine. (or am I wrong?)
> I think you're slightly confused about what Glulx really
> is, or, rather, that you're talking about the current
> combination of Bi-platform Inform compiler/library and
> Glk.
Well, not as much confused as in the dark maybe. First of
all, I have to admit I did not know Glulx had such a long
history. Furthermore, the argument that people appear to
think they need it (put up by someone else) as they appear
to be using it, only goes sofar but I can't possible refute
it.
> Glulx itself is just a virtual machine (glulxe) and its
> machine language. It's sufficiently general to be used
> for anything you can think of.
Well, I guess, but the main reason for my asking "Why?"
was my wondering about yet another 'new' system. I think
IF would be really helped by a few authoring systems
kicking the bucket and more people jumping on the right
bandwagon. If Inform/z-machine is essentially dead (as
in not going to change to allow for larger or more complex
games), I think it would be wise to slowly abandon it. But
I'd hate to have to look back in five years and conclude
we should have staid put.
> Basically, if you don't want that "fancy" stuff, you can think of
> Glulx as an alternative to the Z-machine that offers more memory,
> 32-bit arithmetic, a larger number of function parameters and possibly
> some other things as well.
Well, as you can guess, I'd rather think of it as a
definitive replacement instead of an alternative. I think
IF has been 'blessed' with *enough* alternatives. It's time
to eliminate some of the alternatives in my opinion. Have
a single system that says "pick me!" to new authors and
that is truly convincing to the entire community. This
includes offering some sort of friendly IDE in the long
run to authors that don't want to be programmers.
> So as long as your game isn't too large and your code isn't
> too complex, you can just as well compile to Z-code. That will
> give you a greater choice of interpreters today; I expect that
> will change in the future.
Point is: if everything Z-code has to offer is covered by
Glulx as well, what possible reason could any author of
IF have to pick Z? Sure there are more interpreters out
there but is a 5-minute download really going to stop
anyone? And if Glulx takes almost all z games, why not
recompile (nearly) all of them and offer them as Glulxe-
playable games as well. This will convince every reader
without an interpreter to select Glulxe as his prefered
download instead of some Frotz. No offense intended, I
really enjoy WinFrotz. And of course, I would like to
see a Glulxe for my Palm, but that's a whole 'nother
story.
> What I expect is going to happen among authors of "nice and
> clean" text adventures is that some of them will write so
> large or complex games that they can't fit them within the
> Z-machine. In such a case, moving to Glulx is *really simple*.
Bottom line: I'd like to be able to just ignore the forest
of interpreters and stick with one, preferably the most
popular. Both for my PC and my handheld. And I think I
speak for the larger part of the community in saying that.
Nice and clean to me also means 'easy to run', besides just
being a 'regular' text adventure or work of IF.
Grtz,
JAAP.
Gunther Schmidl
> Glulx as well, what possible reason could any author of
> IF have to pick Z?
Glulx can't do Z6. Furthermore, I don't like the way the Glulx interpreters
look and it's IMHO a pain in the ass to do Glulx windowing code.
So I'm all against abolishing the Z-machine, thank you very much.
-- Gunther
Alan Trewartha
> What are the best V6 interpreters on each platform, and how far do they
> go? I'll start the list:
>
> Platform Terp Standard Versions Blorb PNG JPEG AIFF MOD SONG
> ----------------------------------------------------------------------------
> RISC OS Zip 2000 1.0, no omissions 12345678 Yes Yes Yes Yes Yes Yes
GO KEVIN!!
There that's my raif contribution for the next couple of months. we should
have a riscos anthem or something just to rally the troops.
i'm watching you all. very well done i must say.
Alan
Andrew Plotkin
> [...] and I'm not really relishing the thought of doing all that UI
> work again from scratch.
Now that sounds very similar to a thought I was having around, oh,
1996 or 1997, as I was ripping the UI out of MaxZip for MaxTADS and
rewriting it for, what was it, the third or fourth time. :-)
dgr...@cs.csuabk.edu
> I was lead to believe by the Z-Spec that Frotz did V6. What's missing?
Frotz does indeed do V6. Under DOS and Windows, graphical V6 works fine.
Unix Frotz will do nongraphical V6 fine and draw outlines where graphics
should be. Xfrotz handles graphical V6 acceptably, but since it's based
on straight 2.32 Frotz, it's rather dated. Full V6 support in Unix Frotz
is still experimental.
--
David Griffith
dgr...@cs.csubak.edu
Magnus Olsson
>think they need it (put up by someone else) as they appear
>to be using it, only goes sofar but I can't possible refute
>it.
Well, how could it possibly be refuted?
"Why are you using Glulx?"
"Because I think I need it."
"No, you don't think you need it."
"How can you know what I think?"
:-)
>> Glulx itself is just a virtual machine (glulxe) and its
>> machine language. It's sufficiently general to be used
>> for anything you can think of.
>
>Well, I guess, but the main reason for my asking "Why?"
>was my wondering about yet another 'new' system. I think
>IF would be really helped by a few authoring systems
>kicking the bucket and more people jumping on the right
>bandwagon.
I may seem like I'm nitpicking, but I really don't think Glulx,
or even Glulx Inform, should be referred to as a new authoring
system. When people are talking about "Switching from Inform to
Glulx" they make it sound like it's a really big step, which it
isn't.
An analogy: Switching from Inform/Z-code to Inform/Glulx is not like
switching from C++ to Java, it's more like changing UI libraries under
C++.
>If Inform/z-machine is essentially dead (as
>in not going to change to allow for larger or more complex
>games), I think it would be wise to slowly abandon it.
People whose games require features not supported by the Z machine
will *have* to abandon it (unless the plans for a V9 Z machine
are set into motion). I can't really see why people who don't need
such features should abandon it, as long as Graham and the interpreter
writers support it.
I think th edefinition of "dead" for a software system shouldn't be
when it's stopped growing, it should be when it's no longer being
maintained.
>> Basically, if you don't want that "fancy" stuff, you can think of
>> Glulx as an alternative to the Z-machine that offers more memory,
>> 32-bit arithmetic, a larger number of function parameters and possibly
>> some other things as well.
>
>Well, as you can guess, I'd rather think of it as a
>definitive replacement instead of an alternative.
But why would we need to replace the Z-machine for the uses where
it's sufficient? Remember that if we truly *wanted* to replace
the Z-machine with Glulxe everywhere, we'd have to recompile all old
Inform games to Glulx as well. And, as has been pointed out, for
V6 games that's not even possible.
>I think
>IF has been 'blessed' with *enough* alternatives. It's time
>to eliminate some of the alternatives in my opinion.
And just how do you propose to do that?
>Have
>a single system that says "pick me!" to new authors and
>that is truly convincing to the entire community.
Bleargh. I suppose you want just one make of car on sale, and
one brand of toothpaste?
>Point is: if everything Z-code has to offer is covered by
>Glulx as well, what possible reason could any author of
>IF have to pick Z? Sure there are more interpreters out
>there but is a 5-minute download really going to stop
>anyone?
If there simply isn't a Glulxe port to your system, it damn
well is going to stop you.
>And if Glulx takes almost all z games, why not
>recompile (nearly) all of them and offer them as Glulxe-
>playable games as well.
To begin with, you'll need access to the source. Then you need
bi-platform versions of all previous versions of both the compiler and
the library (beccuase there are enough incompatibility that old source
won't work with the current versions).
Kevin Bracey
news:3c04f9f4...@news.student.utwente.nl...
> On 26 Nov 2001 23:41:11 GMT, m...@df.lth.se (Magnus Olsson) wrote:
>
> Point is: if everything Z-code has to offer is covered by
> Glulx as well, what possible reason could any author of
> IF have to pick Z? Sure there are more interpreters out
> there but is a 5-minute download really going to stop
> anyone?
Something tells me you're a PC/Mac/Linux user. No other platform has a Glulx
interpreter yet, let alone a decent one. Now, if everyone pulled their
finger out and wrote a Glulx interpreter for every platform that currently
has a Z-machine, we'd be laughing. Maybe one day. And then, interestingly,
Glulx would lose one of its advantages for authors - at present there's near
total uniformity in the interpreters that people use; they don't have to
worry too much at the moment about screen size issues etc.
And Glulx cannot do everything the Z-machine can do. There's no way
Infocom's 4 V6 games could be rendered faithfully in Glulx, and Glulx is for
some reason limited to Latin1 support only. Even relatively simple things
like menu systems that use proportional fonts are totally beyond it. Some of
these restrictions will probably be lifted by later versions, others are
fundamental parts of deliberate compromises in its design, albeit taken with
good reason.
> And if Glulx takes almost all z games, why not
> recompile (nearly) all of them and offer them as Glulxe-
> playable games as well. This will convince every reader
> without an interpreter to select Glulxe as his prefered
> download instead of some Frotz. No offense intended, I
> really enjoy WinFrotz. And of course, I would like to
> see a Glulxe for my Palm, but that's a whole 'nother
> story.
I see exactly where you're coming from. But until someone writes a complete
Z-machine in Glulx, that isn't going to happen. Now, the more people that
use Glulx the more pressure there will be for people to write Glulx
interpreters, but I can't help but feel that there aren't enough active
programmers in the community to cover all the platforms that people are
currently using, so users will be left terpless.
So on the one hand you'll have the convenience of only running one terp, but
other people will be left totally unable to play the games. That seems a bit
skewed to me. I am strongly in favour of using the Z-machine if at all
possible.
> Bottom line: I'd like to be able to just ignore the forest
> of interpreters and stick with one, preferably the most
> popular. Both for my PC and my handheld. And I think I
> speak for the larger part of the community in saying that.
> Nice and clean to me also means 'easy to run', besides just
> being a 'regular' text adventure or work of IF.
We have tolerated too much variance in the capabilities of Z-code
interpreters; people have been coding around terp bugs for too long, and
possibly not lobbying the maintainers of the broken ones enough. There is a
very clear standard saying what the interpreters should be doing, so in
theory (hah) there should be no portability problems in the Z-machine. That
there are just reflects how widely ported the Z-machine is. As soon as Glulx
comes anywhere near the number of platforms, it will have just the same
problems.
Kevin
-----
Magnus Olsson
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>"Jaap van der Velde" <ve...@bigfoot.com> wrote in message
>news:3c04f9f4...@news.student.utwente.nl...
>> On 26 Nov 2001 23:41:11 GMT, m...@df.lth.se (Magnus Olsson) wrote:
>>
>> Point is: if everything Z-code has to offer is covered by
>> Glulx as well, what possible reason could any author of
>> IF have to pick Z?
For the record: Jaap wrote that, not I. (Yes, you can count
the number of >'s and reach that conclusion, but still...)
>We have tolerated too much variance in the capabilities of Z-code
>interpreters; people have been coding around terp bugs for too long, and
>possibly not lobbying the maintainers of the broken ones enough.
Also, before the standard document existed, terps were designed by
reverse-engineering Infocom games. It's no wonder different reverse
engineers reached different conclusions, or made mistakes.
>As soon as Glulx
>comes anywhere near the number of platforms, it will have just the same
>problems.
I think the problems will not be with the glulx VM, since (unlike
for the Z-machine) there is a reference implementation (glulxe).
The problems will be with Glk.
Magnus Olsson
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>interpreter yet, let alone a decent one.
Shouldn't it be possible to compile glulxe and CheapGlk on most
systems with a standard C compiler? Or at least on Posix compliant
systems?
Of course, the resulting interpreter may not meet your definition
of "decent". :-)
>And Glulx cannot do everything the Z-machine can do. There's no way
>Infocom's 4 V6 games could be rendered faithfully in Glulx, and Glulx is for
>some reason limited to Latin1 support only.
Multiple character sets shouldn't bee too difficult, should it? Zarf?
>Even relatively simple things
>like menu systems that use proportional fonts are totally beyond it.
I'm afraid you've lost me there - care to explain?
>Some of
>these restrictions will probably be lifted by later versions, others are
>fundamental parts of deliberate compromises in its design, albeit taken with
>good reason.
The fundamental difference that I can think of is the inability to
mix graphics and text, like for example putting a graphical border around
the text window or to let text float around an image. And these can
be quite a killer factor if you want, say, a game window that
looks like an illuminated manuscript, with initials and miniatures and
borders, or one that looks like the archaeologist's diary in "Beetmonger".
Kevin Bracey
m...@df.lth.se (Magnus Olsson) wrote:
> Shouldn't it be possible to compile glulxe and CheapGlk on most
> systems with a standard C compiler? Or at least on Posix compliant
> systems?
Yes, I've managed cheapglk, except I haven't sorted out its file handling.
I bet a lot of Glk programs won't like RISC OS' filenaming system though.
>
> Of course, the resulting interpreter may not meet your definition
> of "decent". :-)
Exactly. :)
>
> >Even relatively simple things
> >like menu systems that use proportional fonts are totally beyond it.
>
> I'm afraid you've lost me there - care to explain?
You cannot move the cursor in a text window, so you cannot provide the
capability to do Menus.h / AltMenu.h type functionality unless you use a
character grid window, which limits you to an ugly fixed space font. Now,
that's the same limitation that V5 has, but V6 lifted that restriction. Look
at Zork Zero's hints, for example, or Journey's bottom of screen menus.
Of course, this was a deliberate design decision for Glk, because as soon as
you can position the cursor in a non-character grid window, you need a
graphical backing store.
>
> >Some of
> >these restrictions will probably be lifted by later versions, others are
> >fundamental parts of deliberate compromises in its design, albeit taken with
> >good reason.
>
> The fundamental difference that I can think of is the inability to
> mix graphics and text, like for example putting a graphical border around
> the text window or to let text float around an image. And these can
> be quite a killer factor if you want, say, a game window that
> looks like an illuminated manuscript, with initials and miniatures and
> borders, or one that looks like the archaeologist's diary in "Beetmonger".
The Encyclopedia Frobozzica did that in Zork Zero. Lots of the subgames
did as well (see
http://www.bracey-griffith.freeserve.co.uk/Zip2000/DFanucci.png ), but they
could also have been done by breaking the background picture into lots of
subparts and using lots of windows, if absolutely necessary (as long as
window borders are invisible). Again, a graphical backing store is required.
The simplest way to extent Glulx to handle it would be to allow text to be
drawn in graphics windows. But that would not be a minor extension, and as
soon as people start extending Glulx, the compatiblity problems begin...
The only catch in V6 is that text is printed on a solid background colour, so
you can't overlay pleasantly on a textured background. A few of us V6 gurus
are quietly working behind the scenes on a minor standard extension which
would allow that.
M. D. Krauss
Kevin Bracey <kevin....@pace.co.uk> wrote:
> In message <9u290l$5sj$4...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
> > Shouldn't it be possible to compile glulxe and CheapGlk on most
> > systems with a standard C compiler? Or at least on Posix compliant
> > systems?
>
> Yes, I've managed cheapglk, except I haven't sorted out its file handling.
> I bet a lot of Glk programs won't like RISC OS' filenaming system though.
Huh? The more you talk about RISC OS the more intrigued I get. Just what
is it's filenaming system?
[Snip]
> The only catch in V6 is that text is printed on a solid background colour, so
> you can't overlay pleasantly on a textured background. A few of us V6 gurus
> are quietly working behind the scenes on a minor standard extension which
> would allow that.
Cool... That would be really snazzy.
You know, though, after all this discussion on z6 and Glulx and the quirks
of design involved in bringing essentially more dynamic display
capabilities and multimedia to IF, the more I think that HTML-TADS has the
right approach. I haven't used TADS so I'm not sure how it works, but HTML
and CSS combined already accomplish just about everything that everyone
wants for IF, and good open-source code is available for every major
platform for handling it correctly. So why bother re-inventing the wheel?
For platforms that don't want to go to the extent of a full HTML/CSS
system, those standards are designed very carefully so that anything that
is unimplemented will not seriously damage the presentation, which solves
another major pitfall involved here.
Couldn't an authoring system use the Gecko rendering engine (I'm not sure
how many platforms Gecko is available on?) for it's i/o? And if Gecko
isn't available on your platform of choice, a more primitive engine will
do -- the standard would be W3C HTML/CSS, not any particular
implementation.
I'm just brainstorming there, and I've been up since 11am yesterday, and
it's 9am now here. So if I've said anything stupid all apologies in
advance!
-M
(*YAWN*)
--
To email me convert my address to something resembling reason
Magnus Olsson
M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
>You know, though, after all this discussion on z6 and Glulx and the quirks
>of design involved in bringing essentially more dynamic display
>capabilities and multimedia to IF, the more I think that HTML-TADS has the
>right approach.
While I have only programmed in vanilla TADS, and never in HTML TADS,
I can at least say that I'm extremely impressed by the visual
appearance of some HTML TADS games; even if you discount such things
as screen resolution, I think they look just as good as the best V6
games. I don't know, though, how good HTML TADS is for doing things
like menus where you move around a highlight with the cursor keys.
Glulx games, on the other hand, tend to have a rather blocky
appearance, since Glk forces text and graphics into different windows.
Matthew Russotto
M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
>
>of design involved in bringing essentially more dynamic display
>capabilities and multimedia to IF, the more I think that HTML-TADS has the
>right approach. I haven't used TADS so I'm not sure how it works, but HTML
>and CSS combined already accomplish just about everything that everyone
>wants for IF, and good open-source code is available for every major
>platform for handling it correctly. So why bother re-inventing the wheel?
CSS is an abomination. Also I'm unaware of any good open-source code for
it, particularly on the Mac.
OKB -- not okblacke
>I may seem like I'm nitpicking, but I really don't think Glulx,
>or even Glulx Inform, should be referred to as a new authoring
>system. When people are talking about "Switching from Inform to
>Glulx" they make it sound like it's a really big step, which it
>isn't.
Yes. This confusion seems to be at the root of many misunderstandings.
>>Have
>>a single system that says "pick me!" to new authors and
>>that is truly convincing to the entire community.
>
>Bleargh. I suppose you want just one make of car on sale, and
>one brand of toothpaste?
Next we'll owe our souls to the company store. :-)
OKB -- not okblacke
>Now, if everyone pulled their
>finger out and wrote a Glulx interpreter for every platform that currently
>has a Z-machine, we'd be laughing. Maybe one day. And then, interestingly,
>Glulx would lose one of its advantages for authors - at present there's near
>total uniformity in the interpreters that people use; they don't have to
>worry too much at the moment about screen size issues etc.
I think it's just the opposite. I personally have only used 2 Glulx
terps, but my understanding is that there is an IMMENSE variation in capability
from one platfrom to another. Some terps support sound, graphics, multiple
windows, mouse input, text styling, and the kitchen sink. Some apparently do
not support anything but a single window with plain, unvarnished text in it.
Now, some of these differences arise from the platform's Glk library rather
than the interpreter itself, but if, as you say, we look at it from an author's
perspective (and believe me, I do), there are untold differences between
various implementations.
>Even relatively simple things
>like menu systems that use proportional fonts are totally beyond it. Some of
>these restrictions will probably be lifted by later versions, others are
>fundamental parts of deliberate compromises in its design, albeit taken with
>good reason.
This isn't true, unless you're talking about some particular kind of menu
(and even then it probably isn't true). "Stick it to the man" uses a menu with
a proportional font (or at least, the menu is set up for a proportional font --
the interpreter may allow the player to set his font of choice, which may be
fixed-width).
OKB -- not okblacke
>The fundamental difference that I can think of is the inability to
>mix graphics and text, like for example putting a graphical border around
>the text window or to let text float around an image. And these can
>be quite a killer factor if you want, say, a game window that
>looks like an illuminated manuscript, with initials and miniatures and
>borders, or one that looks like the archaeologist's diary in "Beetmonger".
Well, it is possible to have images "inline" with text in a text buffer
window (e.g., the main story window), although I can't say how this might be
dealt with on various terps.
Kevin Bracey
M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
> Huh? The more you talk about RISC OS the more intrigued I get. Just what
> is it's filenaming system?
"." as the directory separator, case-insensitive filenames, no file
extensions. Files have an auxiliary filetype internally represented as a
12-bit number (a bit like the Mac). Many older disc formats only support
10-character leafnames.
A canonical path name might look like:
ATAFS::KBracey.$.Infocom.Games.ZorkZero
Where ATAFS: specifies the filing system, :KBracey specifies the drive, $
specifies the root directory. As with most systems, you can give partial
filenames like ":KBracey.Infocom", "$.Foo", "^.Blorb.Spec", "RAM:$.Blah".
There are lots of neat tricks like path variables being built into the basic
filing system API, so you can ask for things like:
Font:Trinity.Medium
where Font$Path is a system variable giving a comma-separated list of
directories to search.
Usually the approach to ported programs is to quietly swap "/" and "." before
calling the underlying system ("/" is legal in a filename).
In development environments, the compilers etc silently map "fred.h" to
"h.fred" so you put all your sources in a "c" directory, abject files in an
"o" directory, etc.
> I haven't used TADS so I'm not sure how it works, but HTML
> and CSS combined already accomplish just about everything that everyone
> wants for IF, and good open-source code is available for every major
> platform for handling it correctly. So why bother re-inventing the wheel?
Isn't HTML-TADS model basically the same as Glulx's? Does it actually allow
full arbitrary cursor movement? I'm something of an Inform bigot, so I'm not
that familiar with TADS. I did do a basic character mode port of the standard
runtime to RISC OS a while back though.
> Couldn't an authoring system use the Gecko rendering engine (I'm not sure
> how many platforms Gecko is available on?) for it's i/o? And if Gecko
> isn't available on your platform of choice, a more primitive engine will
> do -- the standard would be W3C HTML/CSS, not any particular
> implementation.
Well, I think it was rather Zarf's idea that Glk be a portable I/O system for
IF authoring systems. Only glulx is using it at the moment though. When I
have time I'm going to have a go at implementing the glk API in V6 Z-code, so
authors could use that API in the Z-machine too.
Andrew Plotkin
> The fundamental difference that I can think of is the inability to
> mix graphics and text, like for example putting a graphical border around
> the text window or to let text float around an image. And these can
> be quite a killer factor if you want, say, a game window that
> looks like an illuminated manuscript, with initials and miniatures and
> borders, or one that looks like the archaeologist's diary in "Beetmonger".
Hang on, I added the ability for text to flow around (square) images.
You can do Z0-style manuscript capitals/miniatures.
You can put borders around a window with other windows. The
inter-window borders do show up -- that's something I'm thinking
about.
Adam Thornton
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>total uniformity in the interpreters that people use; they don't have to
>worry too much at the moment about screen size issues etc.
I have but one word for you:
Ha.
Adam
Magnus Olsson
Kevin Bracey <kevin....@pace.co.uk> wrote:
>Well, I think it was rather Zarf's idea that Glk be a portable I/O system for
>IF authoring systems. Only glulx is using it at the moment though.
Glulx is (currently) the only system where Glk is callable directly
from the VM. But Glk is used by several interpreters for other systems
(hiding it from the VM) - Nitfol springs to mind, and there are Glk-
based Alan and Hugo interpreters as well. And there's also Zarf's
C port of Dungeon, that calls Glk directly from C.
>When I
>have time I'm going to have a go at implementing the glk API in V6 Z-code, so
>authors could use that API in the Z-machine too.
Sounds like a lot of work for a very small gain to me.
Magnus Olsson
Andrew Plotkin <erky...@eblong.com> wrote:
>Magnus Olsson <m...@df.lth.se> wrote:
>
>> The fundamental difference that I can think of is the inability to
>> mix graphics and text, like for example putting a graphical border around
>> the text window or to let text float around an image. And these can
>> be quite a killer factor if you want, say, a game window that
>> looks like an illuminated manuscript, with initials and miniatures and
>> borders, or one that looks like the archaeologist's diary in "Beetmonger".
>
>Hang on, I added the ability for text to flow around (square) images.
>You can do Z0-style manuscript capitals/miniatures.
>
Great! I've managed to miss that - sorry.
Andrew Plotkin
> In message <9u290l$5sj$4...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>> Shouldn't it be possible to compile glulxe and CheapGlk on most
>> systems with a standard C compiler? Or at least on Posix compliant
>> systems?
> Yes, I've managed cheapglk, except I haven't sorted out its file handling.
> I bet a lot of Glk programs won't like RISC OS' filenaming system though.
Glk programs don't get much of a say in file naming. The library deals
with that. That was a design restriction I put in, for this precise
reason -- RiscOS was one of the cases I wanted to be compatible with.
(There's the fileref_create_by_name call, but the spec is really clear
that the Glk program should stick to 8-character filenames without
punctuation -- so that the library can add suffixes, or not, as
appropriate.)
Sheesh, people complain when I try to be OS-neutral, and they complain
when I don't. :-)
Kevin Bracey
m...@df.lth.se (Magnus Olsson) wrote:
> > When I have time I'm going to have a go at implementing the glk API in V6
> > Z-code, so authors could use that API in the Z-machine too.
>
> Sounds like a lot of work for a very small gain to me.
A lot of people's main complaint about V6 is that it's too complicated,
whereas they seem quite happy driving Glk. So providing the Glk API in the
Z-machine would be one way of placating those people. Indeed, simple things
like big drop caps (a la Zork Zero) are a lot easier to ask for in Glk then
they are to code in V6.
It shouldn't be that hard, as the interpreter's doing most of the work. All I
have to do is map Glk concepts onto V6 concepts. Sort of Nitfol in reverse.
I think it's got more chance of being usable than trying an attempt to map
Glk onto V6, because of the helpful simplifying rules of Glk, and the
ultimately free-form graphical nature of V6.
Magnus Olsson
Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9u31kp$c3p$1...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
>> > When I have time I'm going to have a go at implementing the glk API in V6
>> > Z-code, so authors could use that API in the Z-machine too.
>>
>> Sounds like a lot of work for a very small gain to me.
>
>A lot of people's main complaint about V6 is that it's too complicated,
>whereas they seem quite happy driving Glk. So providing the Glk API in the
>Z-machine would be one way of placating those people. Indeed, simple things
>like big drop caps (a la Zork Zero) are a lot easier to ask for in Glk then
>they are to code in V6.
Yes, but what I meant by the gain being small is that if you're using
the Glk API, then you can't use the V6 features that aren't in Glk,
right? Or are you planning some sort of "extended Glk"?
Lewis Raszewski
>
> "Matthew Russotto" <russ...@wanda.pond.com> wrote in message
> news:u07pmco...@corp.supernews.com...
> > In article <9u0nrd$oih$1...@news.lth.se>, Magnus Olsson <m...@df.lth.se>
> wrote:
> > >On the other hand, how many platforms have full implementations of
> > >the V6 Z-machine? One, if I understand things correctly.
> >
> > Five. Of course, you'll have to encode your files in Infocom format
> > to use the other four. (Apple IIgs, Mac, Amiga, PC)
>
> I am half-seriously considering writing a Blorb->MG1 converter, tragically.
> Stop me before it's too late.
>
> There is a minor gotcha, in that the interpreters for those platforms are of
> course commercial products, so you'd have to pay for them. But in the
> absence of any freeware alternative...
>
> I was lead to believe by the Z-Spec that Frotz did V6. What's missing?
>
> many current handhelds, especially considering that Infocom made do with
> 320x200 displays. And even without graphics, reasonable fallbacks should be
> possible. Anyone looking at this? Or Glulx on handhelds?
>
> > Though I admit I'm starting to get motivated to put some Blorb support
> > into the V6 Zip Infinity and release it on an experimental basis.
> > Just starting, though.
>
> Feel free to rip as much code as you like out of Zip 2000, or to contact me
> with any queries.
Frotz supports not blorb. Linux frotz also fails to support sound or
graphics of any kind (afaik)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"This is the noise that keeps me awake; my head explodes and my body
aches."
-- Garbage, Push It
Lewis Raszewski
> Well, I guess, but the main reason for my asking "Why?"
> was my wondering about yet another 'new' system. I think
> IF would be really helped by a few authoring systems
> kicking the bucket and more people jumping on the right
> bandwagon. If Inform/z-machine is essentially dead (as
> in not going to change to allow for larger or more complex
> games), I think it would be wise to slowly abandon it. But
> I'd hate to have to look back in five years and conclude
> we should have staid put.
>
Why? Games aren't getting bigger. z8 will still accomodate games far
larger than have every been written for it. At a guess, I'd suspect that
there have been something like six games *ever* which patently could not
be shoehorned into the z-machine.
Glulx does not run on handhelds, and probably will not for the near
future. Glulx barely runs on DOS, and will not run on the wacky 8-bits
that float around here.
> Well, as you can guess, I'd rather think of it as a
> definitive replacement instead of an alternative. I think
> IF has been 'blessed' with *enough* alternatives. It's time
> to eliminate some of the alternatives in my opinion. Have
> a single system that says "pick me!" to new authors and
> that is truly convincing to the entire community. This
> includes offering some sort of friendly IDE in the long
> run to authors that don't want to be programmers.
>
I'm still, I gather, the only person who finds it ironic that everyone
wants a graphical tool for writing text games.
> Point is: if everything Z-code has to offer is covered by
> Glulx as well, what possible reason could any author of
> IF have to pick Z? Sure there are more interpreters out
> there but is a 5-minute download really going to stop
> anyone? And if Glulx takes almost all z games, why not
> recompile (nearly) all of them and offer them as Glulxe-
> playable games as well. This will convince every reader
> without an interpreter to select Glulxe as his prefered
> download instead of some Frotz. No offense intended, I
> really enjoy WinFrotz. And of course, I would like to
> see a Glulxe for my Palm, but that's a whole 'nother
> story.
>
Glulx game files are larger than equivalent Z-code. The interpreter runs
more slowly. THe screen model is substantially more complex.
I could go on.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"'Till now, I always got by on my own -- I never really cared until I
met
you." -- Heart, Alone
Kevin Bracey
Andrew Plotkin <erky...@eblong.com> wrote:
> Kevin Bracey <kevin....@pace.co.uk> wrote:
>
> > Yes, I've managed cheapglk, except I haven't sorted out its file
> > handling. I bet a lot of Glk programs won't like RISC OS' filenaming
> > system though.
>
> Glk programs don't get much of a say in file naming. The library deals
> with that. That was a design restriction I put in, for this precise
> reason -- RiscOS was one of the cases I wanted to be compatible with.
It's appreciated :)
> (There's the fileref_create_by_name call, but the spec is really clear
> that the Glk program should stick to 8-character filenames without
> punctuation -- so that the library can add suffixes, or not, as
> appropriate.)
>
> Sheesh, people complain when I try to be OS-neutral, and they complain
> when I don't. :-)
Oh, Glk's fine. It's authors that are going to be the problem. I've got a big
design decision to make - do I treat filenames as RISC OS ones and pass them
straight through, which was your intent, or do I do a Unix->RISC OS type
mapping in case some muppet has put an extension or directory separator in?
I'd rather do the former, but I can't help but feel that it'll break in
practice. I suppose as long as the spec is clear, which I think it is, RISC
OS users would be justified on jumping on any authors who do anything silly.
Lewis Raszewski
> >I think
> >IF has been 'blessed' with *enough* alternatives. It's time
> >to eliminate some of the alternatives in my opinion.
>
> And just how do you propose to do that?
>
Dear Mr. President,
There are too many authoring systems nowadays. Please eliminate three.
I am not a kook.
Signed,
Abe Simpson
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
Squirrel -- It's the other gray meat.
Lewis Raszewski
>
> On Wed, 28 Nov 2001 12:15:43 GMT
> Kevin Bracey <kevin....@pace.co.uk> wrote:
>
> > In message <9u290l$5sj$4...@news.lth.se>
> > m...@df.lth.se (Magnus Olsson) wrote:
> >
> > > Shouldn't it be possible to compile glulxe and CheapGlk on most
> > > systems with a standard C compiler? Or at least on Posix compliant
> > > systems?
> >
> > Yes, I've managed cheapglk, except I haven't sorted out its file handling.
> > I bet a lot of Glk programs won't like RISC OS' filenaming system though.
>
> Huh? The more you talk about RISC OS the more intrigued I get. Just what
> is it's filenaming system?
>
Ever noticed that the standard inform library files don't have .h's at
the ends of their names?
RISC OS doesn't let you put a period in a file name. I think it uses it
as the directory separator.
> You know, though, after all this discussion on z6 and Glulx and the quirks
> of design involved in bringing essentially more dynamic display
> capabilities and multimedia to IF, the more I think that HTML-TADS has the
> right approach. I haven't used TADS so I'm not sure how it works, but HTML
> and CSS combined already accomplish just about everything that everyone
> wants for IF, and good open-source code is available for every major
> platform for handling it correctly. So why bother re-inventing the wheel?
>
I'm not entirely convinced. Aside from the fact that there would almost
certainly be no console mode version of such an interpreter, the
web-formatting languages are, by and large, designed for static
documents. There's a basic uneasiness with using that sort of thing in a
system where text is beign printed at any time from various places. It
would take an insane amout of checking to prevent disrupting the screen
model by sending a HTML code at the wrong time.
Also, I think there's somethign fundamentally "not quite right" about
confabulating formatting information and printed text (in a game. In a
static doument, it makes more sense).
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"The color of the sky, as far as I can see, is cold gray." -- 10,000
Maniacs,
Like the Weather
Magnus Olsson
Lewis Raszewski <rras...@hotmail.com> wrote:
>Why? Games aren't getting bigger. z8 will still accomodate games far
>larger than have every been written for it.
I don't think that's true. I recall seeing games that strained z8's
capacity to the limit - perhaps some of Andy Phillips' games?
Anyway, z8 games can only be slightly less than twice as large as
z5 games, and considering the number of games that had to be compiled
to z8 becuase they didn't fit in z5, I don't think it's too much of
an extrapolation to think that there'll be games that don't fit in
it.
Or do you know of any revolutionary new ways of writing smaller
games with the current Inform compiler?
>Glulx does not run on handhelds, and probably will not for the near
>future. Glulx barely runs on DOS, and will not run on the wacky 8-bits
>that float around here.
Just for the record, the game I'm currently working on will probably
be released in both Glulx and Z-code versions, the latter lacking
some (non-essential) features of the former.
Kevin Bracey
news:9u358e$d08$1...@news.lth.se...
> In article <fb9992e04...@kbracey.cam.pace.co.uk>,
> Kevin Bracey <kevin....@pace.co.uk> wrote:
> >A lot of people's main complaint about V6 is that it's too complicated,
> >whereas they seem quite happy driving Glk. So providing the Glk API in
the
> >Z-machine would be one way of placating those people. Indeed, simple
things
> >like big drop caps (a la Zork Zero) are a lot easier to ask for in Glk
then
> >they are to code in V6.
>
> Yes, but what I meant by the gain being small is that if you're using
> the Glk API, then you can't use the V6 features that aren't in Glk,
> right?
Yes. But there seem to be quite a lot of people who are quite happy with
just using Glk.
> Or are you planning some sort of "extended Glk"?
Nah. If they want to do anything beyond Glk, then they're still free to
access the Z-machine directly.
Kevin
-----
Lewis Raszewski
>
> Magnus Olsson <m...@df.lth.se> wrote:
>
> > The fundamental difference that I can think of is the inability to
> > mix graphics and text, like for example putting a graphical border around
> > the text window or to let text float around an image. And these can
> > be quite a killer factor if you want, say, a game window that
> > looks like an illuminated manuscript, with initials and miniatures and
> > borders, or one that looks like the archaeologist's diary in "Beetmonger".
>
> Hang on, I added the ability for text to flow around (square) images.
> You can do Z0-style manuscript capitals/miniatures.
>
> You can put borders around a window with other windows. The
> inter-window borders do show up -- that's something I'm thinking
> about.
Which reminds me. CUrrently, whether or not the boundaries of a glk
window are visible is completely at the discression of the glk
implementation, currently. (GlkDOS doesn't show them unless explicitly
told to, WinGlk shows them unless explicitly told not to, etc).
Since one's interface might be designed such as to look substantially
better or worse depending on this (for instance, a purely text, but
multi-windowed UI, say, a remake of Suspended where every robot had its
own minitature window, as opposed to, say, Balances for GWindows), it
would be awfully nice if there was, say, a hint available, by which a
particular game might inform GLK of what it thinks about visible window
boundaries.
Just a thought.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"Zaphod Beeblebrox! Over here!"
"No, Zaphod Beeblebrox over _here_!" -- Douglas Adams, The Hitch-hiker's
Guide
to the Galaxy, episode 7
Lewis Raszewski
>
> In message <9u31kp$c3p$1...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
> > > When I have time I'm going to have a go at implementing the glk API in V6
> > > Z-code, so authors could use that API in the Z-machine too.
> >
> > Sounds like a lot of work for a very small gain to me.
>
> A lot of people's main complaint about V6 is that it's too complicated,
> whereas they seem quite happy driving Glk. So providing the Glk API in the
> Z-machine would be one way of placating those people. Indeed, simple things
> like big drop caps (a la Zork Zero) are a lot easier to ask for in Glk then
> they are to code in V6.
>
> It shouldn't be that hard, as the interpreter's doing most of the work. All I
> have to do is map Glk concepts onto V6 concepts. Sort of Nitfol in reverse.
>
> I think it's got more chance of being usable than trying an attempt to map
> Glk onto V6, because of the helpful simplifying rules of Glk, and the
> ultimately free-form graphical nature of V6.
>
Now, I find this really amazing, myself. I've always found Glk much
harder to work in than v6. Most of the reason I wrote GWindows was that
I couldn't get my mind around controlling the display.
---
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"I'll start with who, what, where, and when, followed by whither,
whether,
wherefore and whence, and follow that up with a big side-order of 'why'"
--
Douglas Adams, The Hitch-Hiker's Guide to the Galaxy, episode 11
Andrew Plotkin
> Andrew Plotkin wrote:
>> You can put borders around a window with other windows. The
>> inter-window borders do show up -- that's something I'm thinking
>> about.
> Which reminds me. CUrrently, whether or not the boundaries of a glk
> window are visible is completely at the discression of the glk
> implementation, currently. (GlkDOS doesn't show them unless explicitly
> told to, WinGlk shows them unless explicitly told not to, etc).
> Since one's interface might be designed such as to look substantially
> better or worse depending on this (for instance, a purely text, but
> multi-windowed UI, say, a remake of Suspended where every robot had its
> own minitature window, as opposed to, say, Balances for GWindows), it
> would be awfully nice if there was, say, a hint available, by which a
> particular game might inform GLK of what it thinks about visible window
> boundaries.
That's pretty much what I was thinking.
Andrew Plotkin
> In message <9u31ns$45m$2...@news.panix.com>
> Andrew Plotkin <erky...@eblong.com> wrote:
>> Kevin Bracey <kevin....@pace.co.uk> wrote:
>>
>> > Yes, I've managed cheapglk, except I haven't sorted out its file
>> > handling. I bet a lot of Glk programs won't like RISC OS' filenaming
>> > system though.
>>
>> Glk programs don't get much of a say in file naming. The library deals
>> with that. That was a design restriction I put in, for this precise
>> reason -- RiscOS was one of the cases I wanted to be compatible with.
> It's appreciated :)
>> (There's the fileref_create_by_name call, but the spec is really clear
>> that the Glk program should stick to 8-character filenames without
>> punctuation -- so that the library can add suffixes, or not, as
>> appropriate.)
> Oh, Glk's fine. It's authors that are going to be the problem. I've got a big
> design decision to make - do I treat filenames as RISC OS ones and pass them
> straight through, which was your intent, or do I do a Unix->RISC OS type
> mapping in case some muppet has put an extension or directory separator in?
In my Mac and Unix libraries, I cheerfully rip out or change directory
separator characters. If the game tries to write a file called "a/b",
the Unix user will have to live with it actually winding up as "a-b".
If I wrote a library for Windows, I would (equally cheerfully) rip off
any suffixes and put on a correct one.
Kevin Bracey
> In article <3C052586...@hotmail.com>,
> Or do you know of any revolutionary new ways of writing smaller
> games with the current Inform compiler?
Me me me me me! Yes, I know several ways to reduce the code and string area
(but by tweaking the compiler). Each of which only by 1% or less, but
they'll all add up. One of them is already up on the Inform patch page.
Another is to optimise the alphabet (as well as the abbreviations); that
will almost certainly need another of my patches to make it work. Other
optimisations that I haven't got ready yet are peepholing the code output,
short-circuiting branches and high string tail matching.
Unfortunately, it's often the low memory area that's the bugger.
Kevin
-----
Kevin Bracey
news:3C052FCE...@hotmail.com...
> Also, I think there's somethign fundamentally "not quite right" about
> confabulating formatting information and printed text (in a game. In a
> static doument, it makes more sense).
Ahem. Aren't you the author of "znsi.h", an Inform library that let the
author put formatting information in strings? Are you now repenting?
Kevin
-----
OKB -- not okblacke
>Games aren't getting bigger. z8 will still accomodate games far
>larger than have every been written for it. At a guess, I'd suspect that
>there have been something like six games *ever* which patently could not
>be shoehorned into the z-machine.
From what I've heard around here, this isn't the case. Moreover, I
personally have no desire to shoehorn anything into the Z-machine. Why scrimp
and save on global variables and double up objects and arrays and whatnot when
you can just use Glulx and not have to worry about it? Plus, if you target
your game for the Z-machine and then find out much later that it won't fit, you
have to backtrack over all your work and economize everywhere -- or backtrack
over all your work and convert to Glulx (which is much easier, but still not as
easy as if you'd just targeted Glulx from the outset).
Joe Mason
Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9u31kp$c3p$1...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
>> > When I have time I'm going to have a go at implementing the glk API in V6
>> > Z-code, so authors could use that API in the Z-machine too.
>>
>> Sounds like a lot of work for a very small gain to me.
>
>A lot of people's main complaint about V6 is that it's too complicated,
>whereas they seem quite happy driving Glk. So providing the Glk API in the
>Z-machine would be one way of placating those people. Indeed, simple things
>like big drop caps (a la Zork Zero) are a lot easier to ask for in Glk then
>they are to code in V6.
I thought the problem with V6 wasn't that it was too complicated for the game
author, but for the terp author. A lot of the restrictions in Glk that people
dislike are there, as I understand it, because Zarf wanted to make it easy to
port so that lots of Glk terps would be made really fast.
Joe
Andrew Plotkin
> I thought the problem with V6 wasn't that it was too complicated for the game
> author, but for the terp author. A lot of the restrictions in Glk that people
> dislike are there, as I understand it, because Zarf wanted to make it easy to
> port so that lots of Glk terps would be made really fast.
Note how well it worked. :-)
That's not the whole story, though -- I wanted to push flexibility
over to the library side of the line, so that each library could fit
in well with its host OS. (Visually, coding-wise, etc.)
Matthew Russotto
Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
>
>I thought the problem with V6 wasn't that it was too complicated for the game
>author, but for the terp author. A lot of the restrictions in Glk that people
>dislike are there, as I understand it, because Zarf wanted to make it easy to
>port so that lots of Glk terps would be made really fast.
There were several problems, historically, implementing V6
1) Incompletely specified. The way V6 works has been known for far
less time than V1-V5. This problem is largely solved.
2) Infocom file formats -- these were something of a pain to work
with, and no tools exist (AFAIK) for creating them. This problem is
presumably solved with Blorb.
3) Scrollback. The V6 screen model is inherently difficult to
reconcile with scrollback.
4) Mr. Chicken, meet Mr. Egg. But now there's at least one major new V6
game (moments), so even this should be solved
5) Totally different screen model. This makes it difficult to
modify an interpreter which does V1-5,8 with V6.
--
Matthew T. Russotto russ...@pond.com
=====
Get Caught Reading, Go To Jail!
A message from the Association of American Publishers
Free Dmitry Sklyarov! DMCA delenda est!
http://www.freedmitry.org
Kevin Bracey
news:9u3jk3$5kp$1...@watserv3.uwaterloo.ca...
>
> I thought the problem with V6 wasn't that it was too complicated for the
game
> author, but for the terp author.
Glk+glulx would be a lot easier from scratch, but if you have a working
Z-machine, bolting V6 onto it isn't hard. The big step is switching to a
totally graphical backing store if you don't have one already. Other than
that, it's pretty straightforward.
The last non-V6 Zip 2000 was released on 27th November 1995, and the first
full V6 version was released on 13th December 1995, which might give you
some idea of complexity. Admittedly, that was MG1 only and still a little
buggy, but on the other hand it was done without the help from Standard 1.0,
which was written with the experience gained from Frotz and Zip 2000.
Kevin
-----
Lewis Raszewski
>
> In article <3C052586...@hotmail.com>,
> Lewis Raszewski <rras...@hotmail.com> wrote:
> >Why? Games aren't getting bigger. z8 will still accomodate games far
> >larger than have every been written for it.
>
> I don't think that's true. I recall seeing games that strained z8's
> capacity to the limit - perhaps some of Andy Phillips' games?
>
> Anyway, z8 games can only be slightly less than twice as large as
> z5 games, and considering the number of games that had to be compiled
> to z8 becuase they didn't fit in z5, I don't think it's too much of
> an extrapolation to think that there'll be games that don't fit in
> it.
>
> Or do you know of any revolutionary new ways of writing smaller
> games with the current Inform compiler?
>
Let us say that I know how to make over three megabytes of source code
compile into a z8 file.
I do not mean to imply that it is easy, or even "worth the trouble" to
shoehorn a large game into z8. What I do mean is that people have not
begin to stretch the limits of z8 nearly so much as infocom stretched
the limits of z3 before abandoning it. Most people run into the wall due
to non-compact coding practicies, and immediately give up.
Also, very few of these "my game's way too large for Z-code" have yet
materialized.
---
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"And is it true, that devils end up like you? Something safe for the
picture-frame?" -- Tori Amos, She's your Cocaine
Lewis Raszewski
(I wrote znsi purely for use with Gemstone. I figured that so long as I
was abusing the z machine, I might as well get my money's worth.)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"If you can't beat your computer at chess, you can always try
kickboxing." --
Dr. Keith Gallagher
Joe Mason
Matthew Russotto <russ...@wanda.pond.com> wrote:
>3) Scrollback. The V6 screen model is inherently difficult to
>reconcile with scrollback.
That's evil. Scrollback is yor frend. IMHO, making scrollback difficult is
something that should be considered a major problem in an IF screen model.
>5) Totally different screen model. This makes it difficult to
>modify an interpreter which does V1-5,8 with V6.
V1-5,8 don't really have much of a screen model, though, do they? One
window on top, one on the bottom. Glk, I'll point out, is pretty much a
direct superset of the V5 model, except for boxquotes which are a complete
hack in V5 and handled differently in Glk.
Joe
Andrew Plotkin
> In article <u0anqp1...@corp.supernews.com>,
> Matthew Russotto <russ...@wanda.pond.com> wrote:
>>5) Totally different screen model. This makes it difficult to
>>modify an interpreter which does V1-5,8 with V6.
> V1-5,8 don't really have much of a screen model, though, do they? One
> window on top, one on the bottom.
There's a lot more in the screen model than that -- and, as you point
out, it's a Glk-like model.
The behavior of the status window (grid-based, buffered in the terp)
and the behavior of the story window (stream-based, changes only at
the end) make a pretty strong set of promises. Infocom's terps made
use of that full range, too -- the Mac V3/5 terps used proportional
fonts in a scrollable, resizeable window.
(Box quotes, of course, were the notable failure of those promises.
And I seem to recall that _Trinity_ on the Mac lost its scrollback
ability -- although I might be misremembering the whole scrollback
issue, it's been a while and I'm not in front of a Mac.)
Jaap van der Velde
<rras...@hotmail.com> wrote:
> Jaap van der Velde wrote:
>
> > If Inform/z-machine is essentially dead (as
> > in not going to change to allow for larger or more complex
> > games), I think it would be wise to slowly abandon it.
>
> Why? Games aren't getting bigger. z8 will still accomodate games far
> larger than have every been written for it.
Don't get me wrong, I don't think I'll need much more than Inform
without Glulx in that respect, but I get the distinct impression,
a lot of other people do.
> Glulx does not run on handhelds, and probably will not for the near
> future. Glulx barely runs on DOS, and will not run on the wacky 8-bits
> that float around here.
Well, that's a shame then.
> > Well, as you can guess, I'd rather think of it as a
> > definitive replacement instead of an alternative. I think
> > IF has been 'blessed' with *enough* alternatives. It's time
> > to eliminate some of the alternatives in my opinion. Have
> > a single system that says "pick me!" to new authors and
> > that is truly convincing to the entire community. This
> > includes offering some sort of friendly IDE in the long
> > run to authors that don't want to be programmers.
>
> I'm still, I gather, the only person who finds it ironic that
> everyone wants a graphical tool for writing text games.
I don't think everyone does and besides, that's besides the
point. :) My whole point is everyone would be helped with a
single terp environment, with one or more development
environments ('integrated' or otherwise) all compiling to
the same game format. Wether you like to hack it out with
your favourite incomprehensible text-editor or just want
to click words together doesn't really matter. Besides,
think of Delphi or the like, which proves offering an IDE
does not preclude traditional coding. I realise developing
graphical applications is very different from writing IF,
but you get the idea.
The amount of effort going into all of these systems is both
staggering, praise-worthy and a deplorable waste. I say waste
because the community would be much better off with a single
system slowly being developed to ultimate greatness than with
a 20-year terp/platform-comp, which is how the current
situation strikes me.
> > And of course, I would like to see a Glulxe for my Palm,
> > but that's a whole 'nother story.
>
> Glulx game files are larger than equivalent Z-code. The interpreter
> runs more slowly. THe screen model is substantially more complex.
> I could go on.
Which drives you Glulx can never replace Inform point home,
although I am curious to the opinion of the authors...
Grtz,
JAAP.
---------------------------------------------------------------------------
"Anyone who considers arithmatical methods of producing random digits is,
of course, in a state of sin."
-- John Von Neumann
Jaap van der Velde
> "Why are you using Glulx?"
> "Because I think I need it."
> "No, you don't think you need it."
> "How can you know what I think?"
> :-)
*grin*
> I may seem like I'm nitpicking, but I really don't think Glulx,
> or even Glulx Inform, should be referred to as a new authoring
> system. When people are talking about "Switching from Inform to
> Glulx" they make it sound like it's a really big step, which it
> isn't.
Well, I did get that in a way, but still, using Glulx makes
your code useless to an Inform without Glulx compiler, so
it's a pretty big step for me as a writer to take, as it
renders my game useless for a lot of terps.
But I don't think you're nitpicking, I think it's a matter
of perspective. From the perspective of a Glulx user, you
are absolutely right. But from the prespective of a writer
who just wants to pick the best combination of power and
ease of development on the one hand and wide audience on the
other, choosing Glulx is a biggy.
> >If Inform/z-machine is essentially dead (as
> >in not going to change to allow for larger or more complex
> >games), I think it would be wise to slowly abandon it.
>
> People whose games require features not supported by the Z machine
> will *have* to abandon it (unless the plans for a V9 Z machine
> are set into motion). I can't really see why people who don't need
> such features should abandon it, as long as Graham and the interpreter
> writers support it.
They may abandon it if another platform can offer them the same
and enable them to reach a broader audience.
> I think th edefinition of "dead" for a software system shouldn't be
> when it's stopped growing, it should be when it's no longer being
> maintained.
True, in a way. I personally tend to agree, but the community
seems to be asking for more than just z-machine. And I was just
thinking in the line of my argument for a single terp and
preferably a single language.
> >Well, as you can guess, I'd rather think of it as a
> >definitive replacement instead of an alternative.
> But why would we need to replace the Z-machine for the uses where
> it's sufficient?
I think I've made my point on that now. But just for the sake
of clarity: to keep things simple. (and I am thinking more of
games to come than games of the past, important as they may be)
> Remember that if we truly *wanted* to replace
> the Z-machine with Glulxe everywhere, we'd have to recompile all old
> Inform games to Glulx as well. And, as has been pointed out, for
> V6 games that's not even possible.
I wasn't aware of that, but I really think it's too bad. I had
rather high hopes for Glulx as an alternative, but with a few
of the arguments of several writers in this thread take together,
it's hard to keep them up.
> >I think
> >IF has been 'blessed' with *enough* alternatives. It's time
> >to eliminate some of the alternatives in my opinion.
> And just how do you propose to do that?
<sweats, pulls collar and looks for easy way off soapbox>
But seriously, I don't propose anything, to be frank. It's
just that I've been a programmer myself for a few years now
(professionally that is) and I know what amounts of work
have to have gone into the terps and platforms that are out
there. And I can't help but think it a waste to develop all
these systems in paralel, instead of cooperating to make a
single system the better one.
> >Have a single system that says "pick me!" to new authors and
> >that is truly convincing to the entire community.
> Bleargh. I suppose you want just one make of car on sale, and
> one brand of toothpaste?
No I don't, but I don't think 20 brands of rocketship engines
are going to help NASA reach Mars or 20 standards in measurements
of nuts and bolts will do international industry a lot of good.
Point is, a good intermediate standard is needed. A format in
which games can be distributed and run on a variety of terps and
written on a variety of platforms. More like HTML is to the web.
Or like Linux is to UNIX-like OS-es (conveniently ignoring
Windows there)
I realise I just changed my opinion slightly. Instead of a
single terp and single platform, maybe we would be helped by
a single game-format, but the idea remains the same.
> If there simply isn't a Glulxe port to your system, it damn
> well is going to stop you.
Can't argue with that, but that all depends on the efforts of
developers out there and the intentions of the developers of
Glulx and Glulxe. Or another system all together, because to
me, the discussion is not about Glulx in particular.
> >And if Glulx takes almost all z games, why not
> >recompile (nearly) all of them and offer them as Glulxe-
> >playable games as well.
> To begin with, you'll need access to the source. Then you need
> bi-platform versions of all previous versions of both the compiler and
> the library (beccuase there are enough incompatibility that old source
> won't work with the current versions).
True, but are there that many games out there that are
source orphans? (that's another discussion, but still)
Jaap van der Velde
<ke...@bracey-griffith.freeserve.co.uk> wrote:
> "Jaap van der Velde" <ve...@bigfoot.com> wrote in message
> news:3c04f9f4...@news.student.utwente.nl...
> > On 26 Nov 2001 23:41:11 GMT, m...@df.lth.se (Magnus Olsson) wrote:
> >
> > Point is: if everything Z-code has to offer is covered by
> > Glulx as well, what possible reason could any author of
> > IF have to pick Z? Sure there are more interpreters out
> > there but is a 5-minute download really going to stop
> > anyone?
>
> Something tells me you're a PC/Mac/Linux user.
Guilty.
> And Glulx cannot do everything the Z-machine can do. [snip] Some of
> these restrictions will probably be lifted by later versions, others
> are fundamental parts of deliberate compromises in its design, albeit
> taken with good reason.
I was unaware of that, but I do wonder how many old game
recompilations would be precluded by those restrictions. And
also wether Glulx offers sufficient alternatives.
> I see exactly where you're coming from. But until someone writes a complete
> Z-machine in Glulx, that isn't going to happen. Now, the more people that
> use Glulx the more pressure there will be for people to write Glulx
> interpreters, but I can't help but feel that there aren't enough active
> programmers in the community to cover all the platforms that people are
> currently using, so users will be left terpless.
This may be so, but there are dozens of programmers out there
working on their own little terps, Basic systems, Java IF, etc.
etc. etc., so it's not the potential that's failing, but the
organisation, it seems.
> So on the one hand you'll have the convenience of only running one terp, but
> other people will be left totally unable to play the games. That seems a bit
> skewed to me. I am strongly in favour of using the Z-machine if at all
> possible.
Personally, I'm very much in favor of the Z-machine as well,
but if there's a way to augment it in such a way that it also
appeals to wishes of other programmers, or to replace it with
an alternative that takes Z-code, I'm all for it.
> We have tolerated too much variance in the capabilities of Z-code
> interpreters; people have been coding around terp bugs for too long, and
> possibly not lobbying the maintainers of the broken ones enough. There is a
> very clear standard saying what the interpreters should be doing, so in
> theory (hah) there should be no portability problems in the Z-machine. That
> there are just reflects how widely ported the Z-machine is. As soon as Glulx
> comes anywhere near the number of platforms, it will have just the same
> problems.
Maybe so. I do admit, there's a lot of ways you can go, both with
a terp or a platform. The sad thing is though, that great systems
and libraries developed for particular games can't be combined
into a better system unless they're in a single or compatible
language.
Jaap van der Velde
<gsch...@xxx.gmx.at> wrote:
> > Point is: if everything Z-code has to offer is covered by
> > Glulx as well, what possible reason could any author of
> > IF have to pick Z?
> look and it's IMHO a pain in the ass to do Glulx windowing code.
Well, that's a matter of opinion as you've stated yourself.
Nonetheless, Glulx is alive and kicking and able to change,
where Inform is only changing marginally. Mind you, I'm no
expert on Z6, but I imagine Glulx gives you some
possibilities Z6 can't give you and vice versa.
> So I'm all against abolishing the Z-machine, thank you very much.
I'm not proposing to do that, of course. Just wondering what
is keeping everyone from doing so.
David Thornley
Jason C. Penney <jpe...@jczorkmid.SPAMOFF.net> wrote:
>Kent Tessman <ke...@remove-to-reply.generalcoffee.com> wrote:
>> Aug 97 - Hugo v2.4 released
>
>I'm a horrible person. I always say I won't forget Hugo next
>time... and I almost always do. Hugo, like TADS was anounced and
>released with fully capable terps right away.
>
Not on the Mac. The wxWindows terp on the Mac is relatively new
and has rough edges, but is the first one I've seen do actual
pictures.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David Thornley
Lewis Raszewski <rras...@hotmail.com> wrote:
>I do not mean to imply that it is easy, or even "worth the trouble" to
>shoehorn a large game into z8. What I do mean is that people have not
>begin to stretch the limits of z8 nearly so much as infocom stretched
>the limits of z3 before abandoning it. Most people run into the wall due
>to non-compact coding practicies, and immediately give up.
>
well, ok, if I had a dollar for every time, I'd buy myself a new
laptop.
Writing a large game is already a good bit of work, and I don't
see any reason why it should be made even more difficult than it
is already. Nor do I see why people who are better at writing
the game text than the game code should be made to have to dig
into a list of tweaks to try.
Fundamentally, there is better uses for most game author's time
than byte-squeezing.
>Also, very few of these "my game's way too large for Z-code" have yet
>materialized.
>
How many do you want? Most games aren't that large, but if somebody's
going to want to write a really big one, why not let them? IIRC
"Dangerous Curves" was pushing the limits.
Magnus Olsson
Jaap van der Velde <ve...@bigfoot.com> wrote:
>On Wed, 28 Nov 2001 08:32:04 -0000, "Kevin Bracey"
><ke...@bracey-griffith.freeserve.co.uk> wrote:
>>Now, the more people that
>> use Glulx the more pressure there will be for people to write Glulx
>> interpreters, but I can't help but feel that there aren't enough active
>> programmers in the community to cover all the platforms that people are
>> currently using, so users will be left terpless.
>
>This may be so, but there are dozens of programmers out there
>working on their own little terps, Basic systems, Java IF, etc.
>etc. etc., so it's not the potential that's failing, but the
>organisation, it seems.
Organization? What organization? :-)
I think that it's the motivation that's been lacking. And I'm
optimistic that now that interesting Glulx games have started to
appear, some of the terplesss unfortunates out there will feel
motivated to start porting.
>Maybe so. I do admit, there's a lot of ways you can go, both with
>a terp or a platform. The sad thing is though, that great systems
>and libraries developed for particular games can't be combined
>into a better system unless they're in a single or compatible
>language.
Well, those great systems and libraries will probably never be ported
to a single language. An Inform class library will in all probability
build on the Inform Library, so porting it to TADS is undoable until
the entire Inform Library is ported to TADS. And even if *that*
would happen, it would still be incompatible with the TADS Library.
Magnus Olsson
>> I may seem like I'm nitpicking, but I really don't think Glulx,
>> or even Glulx Inform, should be referred to as a new authoring
>> system. When people are talking about "Switching from Inform to
>> Glulx" they make it sound like it's a really big step, which it
>> isn't.
>
>Well, I did get that in a way, but still, using Glulx makes
>your code useless to an Inform without Glulx compiler, so
>it's a pretty big step for me as a writer to take, as it
>renders my game useless for a lot of terps.
I'd say it's the other way round: for me as a writer, switching from
Z-code to Glulx is just a matter of typing "informbp -G" rather than
"informbp" (as long as I'm not writing graphical games in V6 Z-code,
in which case it's a very big step indeed). It's a big step for the
players who find that they'll suddenly need a new terp.
>But I don't think you're nitpicking, I think it's a matter
>of perspective. From the perspective of a Glulx user, you
>are absolutely right. But from the prespective of a writer
>who just wants to pick the best combination of power and
>ease of development on the one hand and wide audience on the
>other, choosing Glulx is a biggy.
Depends on your definition of "system".
I'd like to offer the following definitions:
Glulx and Z-code are different *platforms*.
Inform is the same *development system* regardless of whether
you compile to Z-code or Glulx.
>> People whose games require features not supported by the Z machine
>> will *have* to abandon it (unless the plans for a V9 Z machine
>> are set into motion). I can't really see why people who don't need
>> such features should abandon it, as long as Graham and the interpreter
>> writers support it.
>
>They may abandon it if another platform can offer them the same
>and enable them to reach a broader audience.
That's a big "if", because you can hardly get a broader audience
than that of the Z-machine (which is simply the most widely ported
IF platform today).
>> But why would we need to replace the Z-machine for the uses where
>> it's sufficient?
>
>I think I've made my point on that now. But just for the sake
>of clarity: to keep things simple. (and I am thinking more of
>games to come than games of the past, important as they may be)
This is a bit like the old argument of whether English needs a
big spelling reform: it would make things easier for everybody
as long as you're confining yourself to texts written after the
spelling reform, but it would make the entire cultural heritage
almost inaccessible.
In the IF world, the old games *are* important. If nothing else,
people will want to continue playing the Infocom classics, which
means keeping Z-code interpreters around.
>> >Have a single system that says "pick me!" to new authors and
>> >that is truly convincing to the entire community.
>> Bleargh. I suppose you want just one make of car on sale, and
>> one brand of toothpaste?
>
>No I don't, but I don't think 20 brands of rocketship engines
>are going to help NASA reach Mars or 20 standards in measurements
>of nuts and bolts will do international industry a lot of good.
Standards are good. And, yes, there's an awful lot of reinvention
of the wheel going on in the IF world. But I think that the IF
world is in such a state of flux that it's almost impossible to
agree on a common standard today.
In a way, it would be very convenient if we could make all computers
in the world run Linux. The same distribution of Linux, of course,
with the same applications installed. *And* the same settings.
Would it be a better world? I don't think so. We need alternatives;
standardizing things too far leads to stagnation and rigidity.
BTW I think your statement is true for standards of measurement
(except that it's tremendously expensive to replace all American bolt
sizes with metric ones). But I'm not so sure about the 20 rocket
engines. Even the communists running the Soviet military program
realized that it was a good idea to have different design bureaus
making competing fighter aircraft.
So I think it's a sign of health that we have different, competing
IF systems.
Lewis Raszewski
>
> <ke...@bracey-griffith.freeserve.co.uk> wrote:
>
> > "Jaap van der Velde" <ve...@bigfoot.com> wrote in message
> > news:3c04f9f4...@news.student.utwente.nl...
> > > On 26 Nov 2001 23:41:11 GMT, m...@df.lth.se (Magnus Olsson) wrote:
> > >
> > > Point is: if everything Z-code has to offer is covered by
> > > Glulx as well, what possible reason could any author of
> > > IF have to pick Z? Sure there are more interpreters out
> > > there but is a 5-minute download really going to stop
> > > anyone?
> >
> > Something tells me you're a PC/Mac/Linux user.
>
> Guilty.
>
> > And Glulx cannot do everything the Z-machine can do. [snip] Some of
> > these restrictions will probably be lifted by later versions, others
> > are fundamental parts of deliberate compromises in its design, albeit
> > taken with good reason.
>
> I was unaware of that, but I do wonder how many old game
> recompilations would be precluded by those restrictions. And
> also wether Glulx offers sufficient alternatives.
>
amount of work. Almost anything which uses nontrivial text formatting
would require a nontrivial amount of work. Anythign which was released
before the current version of the library would require a nontrivial
amount of work. Anythign which was released before the current compiler
version wo0uld require a *substantial* amount of work (inform 5 source
is not completely compatable wiht inform 6, and programming paradigms
have shifted quite a bit.)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"You wear nothing, but you wear it so well." -- Dave Matthews, Crash
into Me
Jaap van der Velde
> > Well, I did get that in a way, but still, using Glulx makes
> > your code useless to an Inform without Glulx compiler, so
> > it's a pretty big step for me as a writer to take, as it
> > renders my game useless for a lot of terps.
> I'd say it's the other way round: for me as a writer, switching from
> Z-code to Glulx is just a matter of typing "informbp -G" rather than
> "informbp" (as long as I'm not writing graphical games in V6 Z-code,
> in which case it's a very big step indeed). It's a big step for the
> players who find that they'll suddenly need a new terp.
I've started a reply to that point twice and discarded it both
times before I finally decided to disagree after all... Sure,
the actual effort I have to put into it as a writer is just
copying another library and passing an extra switch to my
compiler. But I am also making the choice for the alternative
terp for all my readers.
I know I cannot be the only player out there just playing Inform
games, just as there are bound to be players who exclusively
play TADS or whatever terp they prefer. Why do I do that? Beats
the hell out of me. I guess part of my just wants to ignore
the other platforms because people playing on them will never
see my own work of fiction if and when I finish it. Another
reason may be simple habit, maybe I am wrong in thinking
players don't mind to download a new terp with a game. The
first time I played games on another terp than Inform was
during the recent Comp and this was only because it was all
so nicely packaged in a single installer.
Point is, a good author writing in TADS will very likely never
reach me unless he gets rave reviews and a poor author writing
in Inform will probably end up on my harddrive if he publishes
in the right place. So to me, the author is selecting his
audience by picking a platform.
> > [snip] But from the prespective of a writer
> > who just wants to pick the best combination of power and
> > ease of development on the one hand and wide audience on the
> > other, choosing Glulx is a biggy.
>
> Depends on your definition of "system".
> I'd like to offer the following definitions:
> Glulx and Z-code are different *platforms*.
> Inform is the same *development system* regardless of whether
> you compile to Z-code or Glulx.
Your definitions make sense in a way. But a platform is 'a formal
scheme of principles' and a system has a more general definition
of being 'an orderly combination or arrangement, as of parts or
elements, into a whole'. So I'm not quite sure I'd agree on the
terminology. But I see the difference you are hinting at. I am
wondering: are you trying to point something out other than the
point you made by saying 'to the writer, switching from Z-code to
Glulx is just a matter of typing "informbp -G"'?
In plain English: "What are you trying to show or prove with the
division in systems and platforms?"
(not on the offensive here, just genuine interest about your
thoughts)
> > They may abandon it if another platform can offer them the same
> > and enable them to reach a broader audience.
>
> That's a big "if", because you can hardly get a broader audience
> than that of the Z-machine (which is simply the most widely ported
> IF platform today).
I realise that. But then why start something like Glulx, introducing
yet another platform or at least the need for yet a new generation of
terps? It's a bit like moving from C to C++ or Windows 3.11 to 95 to
me. (so I'm a Wintel user, sue me! At least my handheld runs Palm OS
and I pay for all my software... ;P ) And after making the move,
saying: look its just a matter of telling your compiler to use a +cpp
switch or not. That argument just doesn't stand up to close scrutiny,
because by adding Glulx specific code, you render your code useless
to the standard Inform compiler, right?
> > > But why would we need to replace the Z-machine for the uses where
> > > it's sufficient?
> > I think I've made my point on that now. But just for the sake
> > of clarity: to keep things simple. (and I am thinking more of
> > games to come than games of the past, important as they may be)
> This is a bit like the old argument of whether English needs a
> big spelling reform: it would make things easier for everybody
> as long as you're confining yourself to texts written after the
> spelling reform, but it would make the entire cultural heritage
> almost inaccessible.
This is true for human processors (your brain and mine) but hardly
for computers. Only in time (say a decade or so) would OSes start
to appear that would no longer support the old terps and make it
hard or impossible to play the old fiction. By then, you'd probably
have some silly 1Ghz Pc-emulator running on your system to run an
old terp and people would be working on translating all the really
good stuff. (we still read Shakespeare and Milton, right?)
> Standards are good. And, yes, there's an awful lot of reinvention
> of the wheel going on in the IF world. But I think that the IF
> world is in such a state of flux that it's almost impossible to
> agree on a common standard today.
Well, I wonder. What would you say is a typical example of
conflicting demands on the part of IF-authors? The only one
I can think of that really matters is the use of multi-media
vs. plain text, as multi-media won't run on handhelds, mobile
phones or wrist watches for the next, oh, two or three years.
But most other wishes aren't all that conflicting, are they?
> In a way, it would be very convenient if we could make all computers
> in the world run Linux. The same distribution of Linux, of course,
> with the same applications installed. *And* the same settings.
> Would it be a better world? I don't think so. We need alternatives;
> standardizing things too far leads to stagnation and rigidity.
I agree, so we get Suse, RedHat, Debian and who knows what
distributions. But they're all Linux and in the bigger picture,
there all UNIXy. All those systems have C at their core and that's
what really unites them. So it's not as simple as you make it seem.
I realise there's a host of compatibility problems there, but at
least there's a common language.
> So I think it's a sign of health that we have different, competing
> IF systems.
I think it would be healthy to have different, competing development
environments, different, competing terps, different competing
libraries, but a single intermediate format or language that ties
them all together. I realise Inform is that in a way for Glulx and
basic inform, but the trouble is, Glulx isn't written in Inform
itself.
You'd need a whole new platform, supporting both Informese and Glulx,
but I realise that's probably just a Utopian scheme. As many others
already pointed out, many pieces of IF use and exploit the
peculiarities of particular libraries, versions and terps and may
never be succesfully translated to some better defined underlying
language...
It's a shame though.
Grtz,
JAAP.
---------------------------------------------------------------------------
"When in danger or in doubt, run in circles, scream and shout."
-- Robert A. Heinlein
Marnie Parker
>From: "Kevin Bracey" ke...@bracey-griffith.freeserve.co.uk
>Date: 11/22/2001 12:14 AM Pacific Standard Time
>Message-id:
>Here's an open question to the authors of this year's Glulx entries.
>
>Given that you were coding in Inform, what motivated you to target Glulx
>rather than the Z-machine?
>
> a) Dynamic memory restrictions
> b) Total memory restrictions
> c) 32-bit variables
> d) Some other capability that Glulx has over the Z-machine
> e) Preferring the glk I/O model to the Z-machine's
> f) Better glulx/glk support than V6 support on your platform
> g) Wanting to push Glulx support forward
> h) Other
d.) Graphics! Graphics! Graphics! Oh, and sound too, of course..
g.) Very much so.
Doe :-)
doea...@aol.com
IF http://members.aol.com/doepage/intfict.htm
(An Iffy Theory | Glulx/Glk for Duncies | unglklib | Inform Primer)
IF Art Gallery http://members.aol.com/iffyart/
IF Review Conspiracy http://www.plover.net/~textfire/conspiracy/
M. D. Krauss
russ...@wanda.pond.com (Matthew Russotto) wrote:
> In article <20011128090058.0bd2...@home-nospam.com-nospam>,
> M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
> >
> >You know, though, after all this discussion on z6 and Glulx and the quirks
> >of design involved in bringing essentially more dynamic display
> >capabilities and multimedia to IF, the more I think that HTML-TADS has the
> >right approach. I haven't used TADS so I'm not sure how it works, but HTML
> >and CSS combined already accomplish just about everything that everyone
> >wants for IF, and good open-source code is available for every major
> >platform for handling it correctly. So why bother re-inventing the wheel?
>
> CSS is an abomination. Also I'm unaware of any good open-source code for
> it, particularly on the Mac.
No. It's not. I've heard people say that before, and while I do feel there were some mistakes made in it, the concept is excellent and the execution is reasonable. What makes you say this? Have you actually studied it? I'm not being Socratic here, I really am very curious since I haven't been able to figure out what it is that makes some people so upset about CSS.
As to open-source implementations on the Mac (or any of many other platforms) see Mozilla / Gecko (as mentioned) at www.mozilla.org.
--
To email me convert my address to something resembling reason
Lewis Raszewski
>
> >Subject: [IF Comp] Why Glulx?
> >From: "Kevin Bracey" ke...@bracey-griffith.freeserve.co.uk
> >Date: 11/22/2001 12:14 AM Pacific Standard Time
> >Message-id:
>
> >Here's an open question to the authors of this year's Glulx entries.
> >
> >Given that you were coding in Inform, what motivated you to target Glulx
> >rather than the Z-machine?
> >
> > a) Dynamic memory restrictions
> > b) Total memory restrictions
> > c) 32-bit variables
> > d) Some other capability that Glulx has over the Z-machine
> > e) Preferring the glk I/O model to the Z-machine's
> > f) Better glulx/glk support than V6 support on your platform
> > g) Wanting to push Glulx support forward
> > h) Other
>
> d.) Graphics! Graphics! Graphics! Oh, and sound too, of course..
>
I think I'm going to cry now.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"Hold on. Hold on to yourself, because this if going to hurt like
hell." --
Sarah McLachlan, Hold On
M. D. Krauss
Lewis Raszewski <rras...@hotmail.com> wrote:
> "M. D. Krauss" wrote:
> >
> > On Wed, 28 Nov 2001 12:15:43 GMT
> > Kevin Bracey <kevin....@pace.co.uk> wrote:
> >
> > > In message <9u290l$5sj$4...@news.lth.se>
> > > m...@df.lth.se (Magnus Olsson) wrote:
> > >
> > > > Shouldn't it be possible to compile glulxe and CheapGlk on most
> > > > systems with a standard C compiler? Or at least on Posix compliant
> > > > systems?
> > >
> > > Yes, I've managed cheapglk, except I haven't sorted out its file
handling.
> > > I bet a lot of Glk programs won't like RISC OS' filenaming system
though.
> >
> > Huh? The more you talk about RISC OS the more intrigued I get. Just
what
> > is it's filenaming system?
> >
> Ever downloaded inform?
>
> Ever noticed that the standard inform library files don't have .h's at
> the ends of their names?
>
> RISC OS doesn't let you put a period in a file name. I think it uses it
> as the directory separator.
>
> > You know, though, after all this discussion on z6 and Glulx and the
quirks
> > of design involved in bringing essentially more dynamic display
> > capabilities and multimedia to IF, the more I think that HTML-TADS has
the
> > right approach. I haven't used TADS so I'm not sure how it works, but
HTML
> > and CSS combined already accomplish just about everything that
everyone
> > wants for IF, and good open-source code is available for every major
> > platform for handling it correctly. So why bother re-inventing the
wheel?
> >
>
> I'm not entirely convinced. Aside from the fact that there would almost
> certainly be no console mode version of such an interpreter, the
> web-formatting languages are, by and large, designed for static
> documents. There's a basic uneasiness with using that sort of thing in a
> system where text is beign printed at any time from various places. It
> would take an insane amout of checking to prevent disrupting the screen
> model by sending a HTML code at the wrong time.
Nope, no trouble with console mode. Ever hear of Lynx? It's just the most
well known of several console-mode web browsers which are completely
standard compliant. Web standards are not only designed to be independant
of graphics and windows, but in fact completely independant of i/o
conventions. A properly designed web page will work just as well for a
completely blind reader using an audio browser or a braile browser as for
you and me with our pretty graphics. (Note that many existing web pages
are not properly designed. Unfortunately.)
Now your issue with static documents... that's a little tougher. Please
note I'm Still just brainstorming, and running on even less sleep then my
earlier post, and might not make much sense here. I think there are two
possible tacts to solving that..
The first is to let the HTML flow dynamically, so to speak. There's really
nothing to prevent this.. it could be done much the way Javascript is used
to modify a web document "live". Only, of course, I am NOT suggesting
using Javascript.. after all, there's already a programming environment
involved. Functions could easily be provided to create and modify HTML
structures, add to them, etc.
The second approach would actually be to use static pages. This would be
somewhat easier to do... I mean, the rendering engine from a browser could
just about be dropped cleanly in to place in the terp... but the drawback
is it wouldn't be quite as cool. There's no reason, though, that static
pages dynamically generated need to in any way seem static. In this model,
ever command typed by the player would presumably generate a new page.
Note: This would be (somewhat) easier to implement, but it would be harder
to use from the game authors perspective, harder on CPU time, and
generally worse form the audiences perspective. I really think the other
approach is much better.
> Also, I think there's somethign fundamentally "not quite right" about
> confabulating formatting information and printed text (in a game. In a
> static doument, it makes more sense).
Clearly, you haven't studied up on recent web standards. The whole point
of CSS is to seperate style (formatting information) from content and
structure.
Also, it would not be necessary to actually even write in HTML/CSS --
simple convenience functions could be provided in a library to generate
the style sheets and markup from more conventional things.
Oh, and also still, don't forget that using the caret (^) to insert
newlines, the spacebar to shove text over on the screen, and such.. that's
all "confabulating formatting information and printed text". Using
HTML/CSS would actually allow one to much more cleanly seperate style from
content then current practices.
People who've used HTML TADS? Comments?
-M
>
> --
> L. Ross Raszewski
> The Johns Hopkins University
> Wyman Park 407
>
> "The color of the sky, as far as I can see, is cold gray." -- 10,000
> Maniacs,
> Like the Weather
Daniel Barkalow
> Why? Games aren't getting bigger. z8 will still accomodate games far
> larger than have every been written for it. At a guess, I'd suspect that
> there have been something like six games *ever* which patently could not
> be shoehorned into the z-machine.
It's very possible that, while games might not grow to much more (since
people like to finish games occasionally, even if only to go on to the
next one in a series), the library (or alternative libraries) may grow
past what will leave room for a reasonable game.
Having library code for NPCs to wander around a bit, exploring (with
library support for NPC knowledge, perhaps) and doing sensible actions
that don't mess with the game state too much, will probably pretty quickly
run the game over z8 size. If you have conversational NPCs with
substantially more things they can say than will appear in a particular
run, it wouldn't be hard to need Glulx's size.
The standard library is quite large and complicated, with abilities beyond
what Infocom's could do. As authors push off to the library more and more
work, with the goals of making different puzzle solutions work and of
writing less code for a given game, the library will grow yet more, and
will presumably fill up more space by itself. Consider
(NPC.knows_location(book) && NPC.knows_path(book.location)); that's a lot
of information to store for each NPC, but it would be so handy...
Out of curiousity, is Glulx sufficiently powerful to be a target for TADS
compilation? How about for compiling programs from other systems? As far
as I can tell, the advantages of most other systems are in the development
tools and the library abilities, plus having fewer size limits than z8.
-Iabervon
*This .sig unintentionally changed*
Magnus Olsson
>> > Well, I did get that in a way, but still, using Glulx makes
>> > your code useless to an Inform without Glulx compiler, so
>> > it's a pretty big step for me as a writer to take, as it
>> > renders my game useless for a lot of terps.
>> I'd say it's the other way round: for me as a writer, switching from
>> Z-code to Glulx is just a matter of typing "informbp -G" rather than
>> "informbp" (as long as I'm not writing graphical games in V6 Z-code,
>> in which case it's a very big step indeed). It's a big step for the
>> players who find that they'll suddenly need a new terp.
>
>I've started a reply to that point twice and discarded it both
>times before I finally decided to disagree after all... Sure,
>the actual effort I have to put into it as a writer is just
>copying another library and passing an extra switch to my
>compiler. But I am also making the choice for the alternative
>terp for all my readers.
OK, I see. There are really three perspectives from which to look
at the problem, then:
1) The perspective of the writer who is concerned about producing
a game.
2) That of the writer who is concerned about reaching the largest
possible audience.
3) That of the audience.
1) and 2) are of course not exclusive, but at least I tend to jump
between them rather than considering them both at once.
>I know I cannot be the only player out there just playing Inform
>games, just as there are bound to be players who exclusively
>play TADS or whatever terp they prefer. Why do I do that? Beats
>the hell out of me. I guess part of my just wants to ignore
>the other platforms because people playing on them will never
>see my own work of fiction if and when I finish it.
Well, to me that makes about as much sense as somebody who only reads
books with green covers. You're missing out on a lot of interesting
stuff. Since you're a PC user, it's not as if there were a lot of
effort involved.
>Another
>reason may be simple habit, maybe I am wrong in thinking
>players don't mind to download a new terp with a game.
If the terp is only going to be useful for that particular
game, I guess people may be reluctant to download and install
it. But that's not the case for the TADS runtime, for instance.
>Point is, a good author writing in TADS will very likely never
>reach me unless he gets rave reviews and a poor author writing
>in Inform will probably end up on my harddrive if he publishes
>in the right place.
Well, that's your loss.
>So to me, the author is selecting his
>audience by picking a platform.
Yes. While I think you are pretty extreme in this regard, you're
not alone, if only because some people play on machines where only
one or two terps are available (like handhelds).
>> Depends on your definition of "system".
>> I'd like to offer the following definitions:
>> Glulx and Z-code are different *platforms*.
>> Inform is the same *development system* regardless of whether
>> you compile to Z-code or Glulx.
>
>Your definitions make sense in a way. But a platform is 'a formal
>scheme of principles' and a system has a more general definition
>of being 'an orderly combination or arrangement, as of parts or
>elements, into a whole'.
Are those some kind of standard definitions or something?
At least the word "system" is used very loosely when talking
about computers; you've listed the basic meaning above but
it can be applied to just about anything, it seems.
And I must confess to never having heard of a computing platform
being defined as a "formal scheme of principles". But maybe that's
just a lack in my education.
>So I'm not quite sure I'd agree on the
>terminology.
Please note that I wrote "development systems", not just "systems".
It's the common usage as I experience it - a compiler, a langauge,
a set of tools.
As for "platforms" - I'm not entirely satisfied with that term either.
I can't say "virtual machine" because it's more than the VM -
the Glulx "platform", for example, is the Glulx VM *plus* the Glk
I/O System. Suggest a better term if you like.
>But I see the difference you are hinting at. I am
>wondering: are you trying to point something out other than the
>point you made by saying 'to the writer, switching from Z-code to
>Glulx is just a matter of typing "informbp -G"'?
>
>In plain English: "What are you trying to show or prove with the
>division in systems and platforms?"
I'm trying to avoid confusion by clearing up the terminology. We are
discussing two different kinds of distinctions here: on one hand, that
between, say, writing *in* Inform and writing in TADS; on the other,
that between writing *for* the Z-machine and writing for Glulxe.
Because I see a lot of confusion being propagated because people
loosely use the term "system" about everything, thus giving the
false impression that Glulx is a "system" on the same level
as Inform.
>> > They may abandon it if another platform can offer them the same
>> > and enable them to reach a broader audience.
>>
>> That's a big "if", because you can hardly get a broader audience
>> than that of the Z-machine (which is simply the most widely ported
>> IF platform today).
>
>I realise that. But then why start something like Glulx, introducing
>yet another platform or at least the need for yet a new generation of
>terps?
I think the reason for starting Glulx has been made abundantly clear
here and in Zarf's posts elsewhere: because the Z machine isn't
sufficient.
But if your question is "why start using Glulx when I don't want
to do anything the Z-machine can't handle" then the answer is
that there's no reason to.
>It's a bit like moving from C to C++ or Windows 3.11 to 95 to
>me.
Now you're falling victim to the same confusion that I'm trying
to stamp out: Moving from Z-code to Glulx is *nothing at all* like
moving from C to C++. It *is* like moving from Win 3.11 to NT and
simultenously upgrading your computer from a 386 to an Alpha
(yes, I know, Win NT isn't available for the Alpha anymore, but
consider for the sake of argument that it is).
In other words, you're still programming in the same language, but
you have a different API and a different underlying assembly language.
>And after making the move,
>saying: look its just a matter of telling your compiler to use a +cpp
>switch or not. That argument just doesn't stand up to close scrutiny,
>because by adding Glulx specific code, you render your code useless
>to the standard Inform compiler, right?
As long as you're not doing anything advanced with Glk - and we're
still in the context of text-only games, right - the differences
are not likely to be more than a few tens of lines, which are placed
in ifdef's.
>This is true for human processors (your brain and mine) but hardly
>for computers. Only in time (say a decade or so) would OSes start
>to appear that would no longer support the old terps and make it
>hard or impossible to play the old fiction.
I don't think so - backwards compatitibility is a big issue nowadays
and most terps don't require anything more than an ANSI C compiler,
and a Posix compliant API. (We're still talking *text* games). I think
OS's will continue to provide these services for many years to come.
>> Standards are good. And, yes, there's an awful lot of reinvention
>> of the wheel going on in the IF world. But I think that the IF
>> world is in such a state of flux that it's almost impossible to
>> agree on a common standard today.
>
>Well, I wonder. What would you say is a typical example of
>conflicting demands on the part of IF-authors?
Have you really been paying attention to the thread you're posting
in? If so, you can't have missed the discussion of whether the
Glk screen model (supported by Glulx) or the V6 screen model
(supported by some Z-code interpreters) is the best one.
To build a case just out of this single issue: Your hypothetical
one-size-fits-all VM must be able to accomodate both these screen
models. That's certainly not impossible (it could for example have
an underlying, more powerful, API, like that of Java, and implement
both Glk and V6 in that) but it would make the VM rather a heavy
beast.
And that brings us back to the reason Zarf designed a new VM (Glulx)
instead of writing an Inform-to-JVM compiler: People want a
*lightweight* VM so they can play IF on handhelds and other small
computers. The JVM is considered far too big. Even Glulx is consider
too big by some people. SO I don't think you can write a sufficiently
powerful VM to be able to satisfy all the writers' demands, and still
make it small enough to fit the players' demands of portability.
(this is today's situation, of course. Things change. In ten years
we may all be using 1 THz Pentium XXIII handhelds, in which case this
discussion will be moot).
>But most other wishes aren't all that conflicting, are they?
You haven't been following this group very closely, have you?
>> In a way, it would be very convenient if we could make all computers
>> in the world run Linux. The same distribution of Linux, of course,
>> with the same applications installed. *And* the same settings.
>> Would it be a better world? I don't think so. We need alternatives;
>> standardizing things too far leads to stagnation and rigidity.
>
>I agree, so we get Suse, RedHat, Debian and who knows what
>distributions. But they're all Linux and in the bigger picture,
>there all UNIXy.
You're missing my point completely. I don't *want* a world where
every computer runs Linux.
>All those systems have C at their core and that's
>what really unites them.
That's simply not true. Windows NT also has C at its core -
does that make it the same thing as Linux? And I've used Unix-like
OS's written in Pascal.
(What unites Linux and all varius Unixes and a lot of other OS's
is a common API, a set of common tools, and a common philosophy.)
>I think it would be healthy to have different, competing development
>environments, different, competing terps, different competing
>libraries, but a single intermediate format or language that ties
>them all together.
I think the single intermediate format is a good idea, *if* it's
powerful enough to enable people to do all that they want to do - but
then it will probably not be practical (because it will be too large
and heavyweight for, say, handhelds).
>I realise Inform is that in a way for Glulx and
>basic inform, but the trouble is, Glulx isn't written in Inform
>itself.
To begin with, you're making the mistake I referred to above:
putting Glulx and "Basic Inform" on the same footing. For the
umpteenth time: Glulx is a VM, Inform is a high-level language.
And what on earth would you gain by writing Glulx in Inform?
Now, an Inform compiler in Glulx, *that* would be interesting.
And useful, once Glulxe gets more widely ported. Perhaps that's
what you're thinking of.
Magnus Olsson
for the main point to be visible anymore. So let me summarize
the part that's perhaps of most interest to Inform programmers:
Suppose you're using Inform to write your games.
Question 1: Should you switch from producing Z-code to producing Glulx?
Answer: Unless your game doesn't fit in the Z-machine (the compiler
will tell you when it doesn't) or you want to use multiple windows,
graphics or sounds, or if you need 32-bit arithmetic, there is really
no reason to.
Question 2: Do I have to switch to Glulx if I want to use multiple
windows, graphics or sounds?
Answer: Not necessarily - you can do sounds in "ordinary" (V5/V8)
Z-code, and even if you want windos and graphics, V6 Z-code may be an
equally good or even better choice (depending on what you want to do,
of course). But note that V6 Z-code is far less widely supported
than V5 or V8, so you'll lose much of the portability.
Question 3: Will the switch be difficult?
Answer: No. As long as you're doing only basic text stuff, your code
will be almost identical. Doing graphics, sounds, windows etc is more
difficult - but that's true regardless of whether you're using
Glulx or V6 Z-code. What will be *really* difficult is switching
a graphic game from V6 Z-code to Glulx.
Question 3: Will the switch have any other consequences that I ought
to know about?
Answer: Yes: at least at the moment, Glulx is supported by fewer
computers than Z-code. So you'll lost portability.
Summary: Unless you can't do what you want to do in V8 Z-code,
switching to Glulx will not be to your advantage. Unless, of course,
you want to make a statement, like "Glulx ought to be implemented
on more computers."
Jaap van der Velde
> OK, I see. There are really three perspectives from which to look
> at the problem, then:
> 1) The perspective of the writer who is concerned about producing
> a game.
> 2) That of the writer who is concerned about reaching the largest
> possible audience.
> 3) That of the audience.
I agree.
> 1) and 2) are of course not exclusive, but at least I tend to jump
> between them rather than considering them both at once.
True, I agree.
> >I know I cannot be the only player out there just playing Inform
> >games, just as there are bound to be players who exclusively
> >play TADS or whatever terp they prefer. Why do I do that? Beats
> >the hell out of me. I guess part of my just wants to ignore
> >the other platforms because people playing on them will never
> >see my own work of fiction if and when I finish it.
> Well, to me that makes about as much sense as somebody who only reads
> books with green covers. You're missing out on a lot of interesting
> stuff. Since you're a PC user, it's not as if there were a lot of
> effort involved.
I look at it like this: I'm Dutch and most English writers of
some import are translated into Dutch, but some aren't. If
some Dutch person decides not to read a book as it is only
published in English, even though pretty much all Dutch people
below a certain age limit are able to read English, I'd
understand. Even though there isn't a lot of effort involved,
they'd rather read a (possibly worse) book in Dutch than the
English title.
Yes I'm missing out and to me it's not a lot of effort, but
still I see people using only 1 terp... I'm not saying it's
a good idea or that I know why, but I'm just saying it's not
something hypothetical or something that'll go away.
> If the terp is only going to be useful for that particular
> game, I guess people may be reluctant to download and install
> it. But that's not the case for the TADS runtime, for instance.
True.
> >Point is, a good author writing in TADS will very likely never
> >reach me unless he gets rave reviews and a poor author writing
> >in Inform will probably end up on my harddrive if he publishes
> >in the right place.
> Well, that's your loss.
True, but it's the author's loss as well, per view 2.
> Yes. While I think you are pretty extreme in this regard, you're
> not alone, if only because some people play on machines where only
> one or two terps are available (like handhelds).
Or, like me, like to play a game on handheld -and- PC. I don't like
to play two games at a time, so I like to play the same games on
my handheld as I play on my PC. I don't view the handheld as very
convenient, but more as an option to play on the road.
> >Your definitions make sense in a way. But a platform is 'a formal
> >scheme of principles' and a system has a more general definition
> >of being 'an orderly combination or arrangement, as of parts or
> >elements, into a whole'.
>
> Are those some kind of standard definitions or something?
They're dictionary definitions. Not that that means a lot, but
it does give you a valid indication of what most people will think
when they hear those words being used.
> At least the word "system" is used very loosely when talking
> about computers; you've listed the basic meaning above but
> it can be applied to just about anything, it seems.
True. That's exactly the problem I have with your use of the
word in your definition. But like I said, you've made the
distinction clear.
> And I must confess to never having heard of a computing platform
> being defined as a "formal scheme of principles". But maybe that's
> just a lack in my education.
I'd think 'platform' would generally mean a (set of) tool(s) or an
environment. Using this 'platform' you can create some system
supported by this platform. Like the Delphi platform vs. the Visual
C platform. Or the Windows platform vs. the Linux platform. Or a
C++ application on an Oracle or SQL Server platform. Something like
that.
> As for "platforms" - I'm not entirely satisfied with that term either.
> I can't say "virtual machine" because it's more than the VM -
> the Glulx "platform", for example, is the Glulx VM *plus* the Glk
> I/O System. Suggest a better term if you like.
No real need I think. I guess we are veering off a bit :)
> I'm trying to avoid confusion by clearing up the terminology. We are
> discussing two different kinds of distinctions here: on one hand, that
> between, say, writing *in* Inform and writing in TADS; on the other,
> that between writing *for* the Z-machine and writing for Glulxe.
True. I'd say writing in some platform and for some platform. Compare:
I can use either the Delphi platform or the Visual C platform to
develop a database application for either the SQL Server platform or
the Oracle platform. A combination of choices defines my chosen
platform, for instance the Delphi + Oracle platform. Platform is a
pretty flexible word too...
'source platform' and 'target platform' sound fine to me. ('platform'
being preferable to 'system', since all *Frotz systems would fall
under the z-machine target platform.)
> Because I see a lot of confusion being propagated because people
> loosely use the term "system" about everything, thus giving the
> false impression that Glulx is a "system" on the same level
> as Inform.
I see. Rest assured, I'm no longer under that impression. But it is
a little hard to explain to a non-programmer or a novice.
> I think the reason for starting Glulx has been made abundantly clear
> here and in Zarf's posts elsewhere: because the Z machine isn't
> sufficient.
And because it couldn't be extended in a more compatible way, I guess.
> Now you're falling victim to the same confusion that I'm trying
> to stamp out: Moving from Z-code to Glulx is *nothing at all* like
> moving from C to C++.
Why? C++ compilers can compile C source, C compilers can't compile
C++ source. Glulx (compilers+lib) can compile (pure) Inform source,
Inform compilers can't compile Glulx source. Right?
> As long as you're not doing anything advanced with Glk - and we're
> still in the context of text-only games, right - the differences
> are not likely to be more than a few tens of lines, which are placed
> in ifdef's.
But if that is so, you're essentially saying that those lines are
'useless' unless they're there to replace some Inform oddity.
> I don't think so - backwards compatitibility is a big issue nowadays
> and most terps don't require anything more than an ANSI C compiler,
> and a Posix compliant API. (We're still talking *text* games). I think
> OS's will continue to provide these services for many years to come.
Well, in that case, there's no point to your point at all. *confused*
I guess you'll have to read the message I replied too. Never mind,
not that important.
> >But most other wishes aren't all that conflicting, are they?
> You haven't been following this group very closely, have you?
I have, but most 'conflicts' seem to be along the lines of "I don't
like this or that, so I'll pick another platform alltogether".
Basically everyone wants a few windows, some control over text
and not too much hassle to get it all done. A lot of memory thrown
into the deal and all options being just that and not just more
problems to solve and everybody's happy.
> You're missing my point completely. I don't *want* a world where
> every computer runs Linux.
Nor do I. I'm just saying that meeting somewhere in the middle for
compatibility is a good thing and not instant death for competition.
> (What unites Linux and all varius Unixes and a lot of other OS's
> is a common API, a set of common tools, and a common philosophy.)
You're right, but my point wasn't on C, it was on the fact that
they're united in a way, all meeting in the middle.
> I think the single intermediate format is a good idea, *if* it's
> powerful enough to enable people to do all that they want to do - but
> then it will probably not be practical (because it will be too large
> and heavyweight for, say, handhelds).
I simply don't know about that last bit, writing IF just doesn't
seem like that much of a heavy-weight task to me as, say, developing
Windows applications. And even there languages are getting closer
together all the time.
> To begin with, you're making the mistake I referred to above:
> putting Glulx and "Basic Inform" on the same footing. For the
> umpteenth time: Glulx is a VM, Inform is a high-level language.
Look, this is getting irritating. Do you really assume I'm not
reading what you are writing here. I REALISE THAT. I'm not making
that mistake. Try and read whatever I write with that in mind and
try and find an interpretation of my words as if I'm not a complete
moron unable to grasp what you are saying.
I there is no such interpretation, I'm not writing very clearly
and I'll be glad to explain myself. Don't get me wrong, I'm not
picking a fight here. But you've been telling me that same thing
every post and I got it the first time.
> And what on earth would you gain by writing Glulx in Inform?
Being able to compile everthing on a single (set of) compiler(s)
[platform], to a single (set of) terp(s) [platform].
> Now, an Inform compiler in Glulx, *that* would be interesting.
> And useful, once Glulxe gets more widely ported. Perhaps that's
> what you're thinking of.
To me, it sounds like the same thing. Except for the fact that
the first option Glulx in Inform (however impossible that may
be) would only result in a really heavy system for computers that
can take it and the second option would result in a light system
being compiled to a platform that is not supportable on handhelds.
Grtz,
JAAP.
---------------------------------------------------------------------------
Your Horoscope:
You are easily influenced by what you read, and have the ability to
relate vague sentences to your own mundane existence.
Jason C. Penney
> Marnie Parker wrote:
>> >Given that you were coding in Inform, what motivated you to target Glulx
>> >rather than the Z-machine?
>> >
>> > a) Dynamic memory restrictions
>> > b) Total memory restrictions
>> > c) 32-bit variables
>> > d) Some other capability that Glulx has over the Z-machine
>> > e) Preferring the glk I/O model to the Z-machine's
>> > f) Better glulx/glk support than V6 support on your platform
>> > g) Wanting to push Glulx support forward
>> > h) Other
>> d.) Graphics! Graphics! Graphics! Oh, and sound too, of course..
> I think I'm going to cry now.
Wanna split a box of tissues?
--
Jason C Penney (jpenney [AT] jczorkmid.net) Xarton Dragon -=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor
Magnus Olsson
>> Now you're falling victim to the same confusion that I'm trying
>> to stamp out: Moving from Z-code to Glulx is *nothing at all* like
>> moving from C to C++.
>
>Why? C++ compilers can compile C source, C compilers can't compile
>C++ source. Glulx (compilers+lib) can compile (pure) Inform source,
>Inform compilers can't compile Glulx source. Right?
Depends on what you mean.
The language is Inform in both cases. As long as you aren't
using inline assembly language (which you'll only need for
doing the advanced stuff we're ignoring) there's no difference
between source that compiles to Z-code and source that compiles
to Glulx code. The difference is that you have a different API;
system calls, if you like, that exist when you're compiling to Glulx
but not when you're compiling to Z-code.
The best analogy is comparing a C program for Unix with one
for some other OS: under Unix, you can call Unix system functions
directly from C, but you can't do that under an OS where the system
calls don't exist (if they aren't emulated by a library).
C++, on the other hand, is a totally different language from C.
It happens to contain C as a subset, but it's much larger and
more advanced.
So the C/C++ analogy is false because there is no such thing
as a separate "Glulx Inform" language - it's the same language,
but with a different library. And this is the normal definition
of computer language - C doesn't turn into another language because
you add, say, the X11 library and get access to the X API, regardless
of the fact that a program that uses X11 won't be linkable on a
Windows box.
>> As long as you're not doing anything advanced with Glk - and we're
>> still in the context of text-only games, right - the differences
>> are not likely to be more than a few tens of lines, which are placed
>> in ifdef's.
>
>But if that is so, you're essentially saying that those lines are
>'useless' unless they're there to replace some Inform oddity.
They are useless if you are certain that you'll never compile the
source to Z-code. But your question was about going back to Z-code
if you decide that Glulx isn't your thing.
It's quite analogous to the countless C programs with things like
#ifdef MSDOS
do something the Microsoft way...
#else
do something the Unix way...
#endif
and the good news is that the lines between #ifdef and #endif
are likely to be few and far between.
>> >But most other wishes aren't all that conflicting, are they?
>> You haven't been following this group very closely, have you?
>
>I have, but most 'conflicts' seem to be along the lines of "I don't
>like this or that, so I'll pick another platform alltogether".
>Basically everyone wants a few windows, some control over text
>and not too much hassle to get it all done. A lot of memory thrown
>into the deal and all options being just that and not just more
>problems to solve and everybody's happy.
Now I don't udnerstand you at all. In what way are wishes that cause
people to choose different platforms not conflicting? My point
was precisely that people have conflicting ideas of what a system
should do, and that so far they haven't been able to agree on
a single system to fulfil all wishes.
Throwing a lot of memory into the deal is not going to make people
happy. People here are very economic with memory.
>> I think the single intermediate format is a good idea, *if* it's
>> powerful enough to enable people to do all that they want to do - but
>> then it will probably not be practical (because it will be too large
>> and heavyweight for, say, handhelds).
>
>I simply don't know about that last bit, writing IF just doesn't
>seem like that much of a heavy-weight task to me as, say, developing
>Windows applications.
It's a heavyweight task for, say, a small handheld (and we're not
talking about the new WinCE models; we're talking Palm III and
Psions).
>And even there languages are getting closer
>together all the time.
At the price of *enormous* bloat and resource hogging. How much
RAM and CPU power does a typical Windows machine require today?
Tomorrow?
>> To begin with, you're making the mistake I referred to above:
>> putting Glulx and "Basic Inform" on the same footing. For the
>> umpteenth time: Glulx is a VM, Inform is a high-level language.
>
>Look, this is getting irritating. Do you really assume I'm not
>reading what you are writing here. I REALISE THAT. I'm not making
>that mistake. Try and read whatever I write with that in mind and
>try and find an interpretation of my words as if I'm not a complete
>moron unable to grasp what you are saying.
I'm sorry, but when I make every effort possible to tell you that
"Glulx Inform" and "Basic Inform" aren't different languages, but are
the same language compiled to different VM/API combinations, and you
continue to refer to them as different languages (as your C/C++
analogy), I can't get help but getting the impression that you haven't
really understood what I'm writing.
I'm not implying that you're a moron. And I honestly don't know
whether you've read everything in the thread - I do assume that
you've read what you're replying to, I'm sorry if I made a different
impression - but when I ask if you've read everything it's because
I really can't know if you've perhaps missed what other people
(whom you're not replying to) have written.
>But you've been telling me that same thing
>every post and I got it the first time.
I really don't know how to put this in a way that can't be taken
as an insult, but *from what you're writing* I get the distinct
impression that you haven't got it; that you still don't really
understand the difference between Inform/Glulx and Inform/Z-code,
or why I don't think it's a good idea to try to replace all
the various VMs with a single system. (You don't have to agree
with me on the last point; but we keep talking past each other).
This may of course be my fault. Perhaps I'm so indoctrinated
in the ways of the IF programming that I can't explain it to
an outsider, or perhaps I'm so full of it that I can't understand
any opinions but my own, or perhaps I'm the moron.
But since this is degenerating to name-calling and accusations,
and since I can't see tht discussion will lead to any fruitful
results whatsoever, I see no point in continuing this thread.
Hope this helped in *some* way, and have a nice day.
Lucian P. Smith
: In article <3c08af47...@news.student.utwente.nl>,
: Jaap van der Velde <ve...@bigfoot.com> wrote:
:>I know I cannot be the only player out there just playing Inform
:>games, just as there are bound to be players who exclusively
:>play TADS or whatever terp they prefer. Why do I do that? Beats
:>the hell out of me. I guess part of my just wants to ignore
:>the other platforms because people playing on them will never
:>see my own work of fiction if and when I finish it.
: Well, to me that makes about as much sense as somebody who only reads
: books with green covers. You're missing out on a lot of interesting
: stuff. Since you're a PC user, it's not as if there were a lot of
: effort involved.
This is actually an interesting point to me, because after I finally
figured out how to play .z5 games way back when, it was at least another
year if not two or three before I finally decided to try out a TADS game.
And this was back ('95ish) when there weren't nearly the sheer number of
games out that there are now.
I think there are a variety of reasons for this. One, which we've been
discussing here, is the interpreter issue. For a newbie (at least, for
*this* newbie), getting an interpreter up and running was a significant
accomplishment. I think it was two or three months between first hearing
about 'Curses' and finally getting it up and running on a PC. I had
worked enough, now I wanted to play some games.
After that, I didn't really trust non-Inform games. I had played bits of
Curses, wanted more, and when I looked for 'em, I stuck with other z-code
games. Christminster, MST3K, Weather, Jigsaw, and Spiritwrak soon found
their way to my computer. This was plenty to occupy me for a good long
time--the second reason I didn't try any TADS games.
When I finally *did* try a few TADS games (I think it was for the '96
comp), it took me a while to warm up to them. There were two major
reasons for this, I think--the way they looked on my screen was just
different than I was used to (what with a different interpreter and all),
and the library and error messages were different, so I had to re-learn
how to play IF. My previous experience had taught me to recognize when I
had his an unimplemented path, and I knew to turn away and try something
else. A new library meant that I didn't necessarily know right away
whether I was getting a default response to trying something or a
possibly-clued response to trying something that would push me in the
right direction. I think I also just liked the tone and tenor of Graham's
writing over MJR's.
Eventually, of course, I got to know both systems well, and today I make
decisions about what game to play entirely independent of whether the
game's in Inform or TADS or Hugo (and though I do make certain assumptions
about what a game is likely to be like in other systems, I think those
assumptions are pretty well justified ;-)
Anyway, one perspective...
-Lucian
Magnus Olsson
Lucian P. Smith <lps...@rice.edu> wrote:
>Magnus Olsson <m...@df.lth.se> wrote in <9u7nr1$gs4$1...@news.lth.se>:
>: In article <3c08af47...@news.student.utwente.nl>,
>: Jaap van der Velde <ve...@bigfoot.com> wrote:
>
>:>I know I cannot be the only player out there just playing Inform
>:>games, just as there are bound to be players who exclusively
>:>play TADS or whatever terp they prefer. Why do I do that? Beats
>:>the hell out of me. I guess part of my just wants to ignore
>:>the other platforms because people playing on them will never
>:>see my own work of fiction if and when I finish it.
>
>: Well, to me that makes about as much sense as somebody who only reads
>: books with green covers. You're missing out on a lot of interesting
>: stuff. Since you're a PC user, it's not as if there were a lot of
>: effort involved.
>
>This is actually an interesting point to me, because after I finally
>figured out how to play .z5 games way back when, it was at least another
>year if not two or three before I finally decided to try out a TADS game.
(Interesting tale snipped)
I think I should qualify what I wrote:
What I found a bit strange about Jaap's statement was not really that
he doesn't play anything but Inform games, but his reason for doing so.
He later gave another reason: that he wants to play the games on
a handheld as well as on his PC, which is eminently reasonable.
And, for the record, I think it's perfectly understandable if Jane Doe
only plays Z-code games because that was the first interpreter she
downloaded and there are so many good Z-code games around that she'd
never had the time to download anything else.
Matthew Russotto
M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
>On Wed, 28 Nov 2001 15:38:09 -0000
>russ...@wanda.pond.com (Matthew Russotto) wrote:
>
>> In article <20011128090058.0bd2...@home-nospam.com-nospam>,
>> M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
>> >
>> >You know, though, after all this discussion on z6 and Glulx and the quirks
>> >of design involved in bringing essentially more dynamic display
>> >capabilities and multimedia to IF, the more I think that HTML-TADS has the
>> >right approach. I haven't used TADS so I'm not sure how it works, but HTML
>> >and CSS combined already accomplish just about everything that everyone
>> >wants for IF, and good open-source code is available for every major
>> >platform for handling it correctly. So why bother re-inventing the wheel?
>>
>> CSS is an abomination. Also I'm unaware of any good open-source code for
>> it, particularly on the Mac.
>
>No. It's not. I've heard people say that before, and while I do feel
>there were some mistakes made in it, the concept is excellent and the
>execution is reasonable. What makes you say this? Have you actually
>studied it? I'm not being Socratic here, I really am very curious
>since I haven't been able to figure out what it is that makes some
>people so upset about CSS.
CSS mostly separates style and content for the user. But not for the
implementor. Anything which does anything useful with CSS must have
much data about HTML, particularly including which CSS selectors go
with which tags, and the defaults for each tag. Further, CSS is so
powerful that parsing HTML without the CSS information is largely
futile -- CSS can completely redefine the behavior of a tag.
--
Matthew T. Russotto russ...@pond.com
=====
Get Caught Reading, Go To Jail!
A message from the Association of American Publishers
Free Dmitry Sklyarov! DMCA delenda est!
http://www.freedmitry.org
Paul O'Brian
> Marnie Parker wrote:
> >
> > >From: "Kevin Bracey" ke...@bracey-griffith.freeserve.co.uk
> > >
> > > a) Dynamic memory restrictions
> > > b) Total memory restrictions
> > > c) 32-bit variables
> > > d) Some other capability that Glulx has over the Z-machine
> > > e) Preferring the glk I/O model to the Z-machine's
> > > f) Better glulx/glk support than V6 support on your platform
> > > g) Wanting to push Glulx support forward
> > > h) Other
> >
> > d.) Graphics! Graphics! Graphics! Oh, and sound too, of course..
>
> I think I'm going to cry now.
I see your point. So maybe you (and the others in this thread) could help
me with a dilemma I'm having. This will probably be a bit rambling, since
I'm still forming my thoughts on this topic.
I want to include graphics (for sound effects, and maybe a title screen or
something) in the next episode of Earth And Sky. I want to start
developing the game next month. I'll be writing it in Inform, so I have
the choice of using z6 or glulx. I don't know either one, so I'm facing a
learning curve either way.
Right now, it seems to me that the obvious choice is Glulx, because the
graphics I want to use are simple enough to implement in Glk, and Glulxe
seems to be finished, at least in my OS (Windows). Terp support for v6
seems not to be finished -- again, at least not for my OS. I like the look
of the glulx games I've seen, whereas I found the one non-Infocom z6 game
I've played to be, well, a pain in the neck, with most every terp
complaining about it or vice versa. Since Moments didn't have graphics, I
can't say I've seen a z6 graphical game, at least not one produced in the
last 10 years. The graphical Infocom games I've seen just don't look that
great, by today's standards anyway.
In addition, I agree with Joe Mason about scrollback. I use it all the
time, and would be substantially annoyed if it were absent -- I think of
it as right up there with SCRIPT and UNDO.
Now, I'll be the first to admit that I'm not a bang-up programmer. I
doubt I could achieve the level of coding sophistication that Moments
sustains. I can, however, wrap my mind around the idea of Glk calls. I'm
totally ignorant of what z6 requires to include graphics, as it never
really seemed worth investigating to me. I don't mean to step on anyone's
toes here -- I guess I'm just sort of a proof-of-concept guy. When I saw
the graphics in this comp's various glulx games, I thought: I like the way
those look. I haven't seen a v6 game that made me say that.
On the other hand, based on a quick look at Gull, I'm still not sure
whether glulx will do what I want, which is to place graphics at
particular points in a text stream, as in:
With a loud [BLAM! graphic], the gun goes off.
Will z6 do this? Will glulx? Yes, yes, I know I should find out for
myself, and I plan to, but since the debate seems to be happening now,
maybe those of you who are contributing to this thread wouldn't mind
contributing your expertise to me as well.
So what should I do? Would z6 really be a better choice, a more practical
one? Will *either* one work for what I want? I don't particularly care
about advancing an agenda or putting pressure on terp authors -- I just
want to use what works, now. If anything.
--
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
Add your own brick to the wall of SPAG -- write a review! The deadline
for the annual competition issue is December 5, 2001.
Andrew Plotkin
> In article <3c0a8457...@news.student.utwente.nl>,
> Jaap van der Velde <ve...@bigfoot.com> wrote:
>>On 30 Nov 2001 10:42:41 GMT, m...@df.lth.se (Magnus Olsson) wrote:
>>> Now you're falling victim to the same confusion that I'm trying
>>> to stamp out: Moving from Z-code to Glulx is *nothing at all* like
>>> moving from C to C++.
>>
>>Why? C++ compilers can compile C source, C compilers can't compile
>>C++ source. Glulx (compilers+lib) can compile (pure) Inform source,
>>Inform compilers can't compile Glulx source. Right?
> Depends on what you mean.
> The language is Inform in both cases. As long as you aren't
> using inline assembly language (which you'll only need for
> doing the advanced stuff we're ignoring) there's no difference
> between source that compiles to Z-code and source that compiles
> to Glulx code.
To give a specific example: Advent.inf (Graham's Original Adventure
port) is what you might call "pure" Inform. It has no Z-machine
assembly at all. It compiles straight to Z-code or Glulx, without any
code changes at all.
Most Inform games are *mostly* "pure" Inform, but have a little bit of
assembly -- a customized status-line routine, maybe a "wait for
keystroke" routine.
If you plan to write a graphics-heavy game, like _Carma_, then Z6 and
Glulx versions will indeed look very different (in their source code).