Poll: Programming language or adventure scripting language?
Richard Bos
> In article <8parmg$j34$1...@oravannahka.helsinki.fi>,
> Joona I Palaste <pal...@cc.helsinki.fi> wrote:
>
> >Do you use a normal programming language (like C or Java) or a
> >specialised adventure scripting language (like TADS or ADRIFT)?
>
> Anyway, to get back to your question: I have written an adventure
> in a GP language (Turbo Pascal). I wouldn't dream of doing that again now
> that TADS and Inform are available.
I've even written one in GW Basic! The parser was a load of dog's
excrement, tough.
> >I myself
> >use normal ISO C, because that's more portable than the scripting
> >languages (at least if I distribute the game in source form), and it
> >gives me total control over the way the game works.
>
> Inform also gives you total control over the way the game works, since
> it's really a general-purpose language with some special features for
> IF.
In fact, people have been abusing Inform (and the ZMachine) for general
programming. For example, there's ZBefunge, ZReversi, and ZTetris.
There's even a (partial, I gather) Scheme interpreter written in Inform.
It isn't ideal for this, but it _can_ be done.
> >Does anyone else use normal programming languages for writing
> >adventures? Why? Why not?
>
> But, anyway, the three major reasons for using a specialized IF language:
>
> 1) The object code is portable, whereas your C adventure will have to be
> recompiled on every new machine it's ported to. And far from all
> computers have a C compiler (many people play IF on things like Palm
> Pilots).
I suspect that far, far more platforms have a C compiler available than
a ZMachine or, e.g., Hugo interpreter. In particular, I would be most
surprised if there turned out not to be a C compiler for the Palm Pilot
(and would suggest that someone make a buck out of that market, _now_).
Even things like Sinclair Spectrum computers had a C compiler.
Mainframes tend to have one. That's what C is for, after all. So this
argument doesn't hold water, IMO.
The other ones do, though, and IMO are sufficient not to try and write a
game in a general language unless I had other reasons to (for example,
it _is_ a good programming exercise, so if I wanted to practice my
Pascal, I could try and write a piece of IF in it).
> 3) You save a lot of typing, since the syntax of the specialized
> languages is customized to make it easy to write adventures. I have
> no hard data on this, though. Perhaps some of the people who've
> ported Dungeon and Advent from Fortran to TADS, Inform and Hugo might
> care to comment on this?
On a related note, Inform, and AFAICT most other IF languages as well,
are more-or-less object-oriented, and that is a way of programming
particularly well suited to IF, because most of the things you deal with
_are_ objects in a semantic as well as an abstract sense.
Richard
Iain Merrick
> Magnus Olsson wrote:
[...]
> > But, anyway, the three major reasons for using a specialized IF language:
> >
> > 1) The object code is portable, whereas your C adventure will have to be
> > recompiled on every new machine it's ported to. And far from all
> > computers have a C compiler (many people play IF on things like Palm
> > Pilots).
>
> I suspect that far, far more platforms have a C compiler available than
> a ZMachine or, e.g., Hugo interpreter. In particular, I would be most
> surprised if there turned out not to be a C compiler for the Palm Pilot
> (and would suggest that someone make a buck out of that market, _now_).
> Even things like Sinclair Spectrum computers had a C compiler.
This is probably true, but different computers most certainly _don't_
have the same I/O libraries. How are you going to print stuff on the
screen, and read command lines? Not even ANSI C stdio runs on every
platform -- I don't think the Palm SDK has a stdio library, for
instance. And stdio is a pretty poor least-common-denominator: what if I
want a status bar, styled text, menus, pictures, music, etc?
You could define some standard I/O system and port it to the machines
you're interested in, of course, but then you're back where you started.
If you go down that route, you might as well use glulx: the glulx
interpreter is pure C + a touch of ANSI + a platform-dependent Glk I/O
library.
Basically, writing an IF game in raw unexpurgated C is almost always
more trouble than it's worth. Unless you need it to be _fast_ -- but
that isn't usually an issue with IF.
Executive summary: write a program in ANSI C and test it on unix. I
*promise* you that it *will not* run on PalmOS without a lot of hacking.
--
Iain Merrick
i...@cs.york.ac.uk
Andrew Plotkin
> m...@pobox.com (Magnus Olsson) wrote:
>> But, anyway, the three major reasons for using a specialized IF language:
>>
>> 1) The object code is portable, whereas your C adventure will have to be
>> recompiled on every new machine it's ported to. And far from all
>> computers have a C compiler (many people play IF on things like Palm
>> Pilots).
> I suspect that far, far more platforms have a C compiler available than
> a ZMachine or, e.g., Hugo interpreter. In particular, I would be most
> surprised if there turned out not to be a C compiler for the Palm Pilot
> (and would suggest that someone make a buck out of that market,
> _now_).
There isn't.
Now I'll explain that.
First, the Palm is too small, slow, and awkward to compile large
programs on. (Yes, I know about PocketC. It doesn't count.) Therefore,
people write code on desktop machines and cross-compile.
The most popular development environment for this is CodeWarrior, as
far as I know, and Metrowerks *is* making a large pile of bucks on it.
Does that mean a C compiler is available for the Palm? Well, do you
want to pay for one? If I download a text adventure in the form of ISO
C source code, I'm *not* going to go out and invest in a commercial
compiler just to play it.
You can also get gcc which cross-compiles to Palm. That's free. So
that means that a C compiler is available for the Palm, right? Well,
do you want to find it, install it, and make it work? I might -- I
know my way around a Linux machine. But not many Palm owners do.
In fact, that's all beside the point. I won't even compile C source
for arbitrary text games for the *Macintosh*. It's just too much of a
hassle. You put together a build tree, push in the files, and what do
you get? A game with a crappy stdin/stdout interface.
If you're writing a text adventure in C, for all meaningful purposes,
*no C compiler is available for the Macintosh*. A compiler exists, but
it's not available -- it won't get used on your game. Unless you do
the work yourself. Or find a volunteer who likes you a lot.
To the best of my knowledge, the same is true of Windows.
But there *are* Z-machine interpreters available for Mac, Windows,
Palm, etc, etc. And players *will* go find them and use them on your
game, if you distribute your game as a Z-code file. This has been
demonstrated.
Ergo, Z-machine interpreters are more widely available than C
compilers -- in this context.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
John Elliott
>Even things like Sinclair Spectrum computers had a C compiler.
Even things like Sinclair Spectrum computers have a Z-Code interpreter.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
wo...@one.net
Hi Richard,
>I suspect that far, far more platforms have a C compiler available than
>a ZMachine or, e.g., Hugo interpreter. In particular, I would be most
>surprised if there turned out not to be a C compiler for the Palm Pilot
>(and would suggest that someone make a buck out of that market, _now_).
>Even things like Sinclair Spectrum computers had a C compiler.
>Mainframes tend to have one. That's what C is for, after all. So this
>argument doesn't hold water, IMO.
C isn't the only widespread language, Python has a score of platforms,
and is well suited to novice game authors as well as experienced
programmers. :)
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
David Thornley
Andrew Plotkin <erky...@eblong.com> wrote:
>Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
>> m...@pobox.com (Magnus Olsson) wrote:
>
>In fact, that's all beside the point. I won't even compile C source
>for arbitrary text games for the *Macintosh*. It's just too much of a
>hassle. You put together a build tree, push in the files, and what do
>you get? A game with a crappy stdin/stdout interface.
>
run using most of the capabilities of a teletype, you might make it
portable. If you do *anything* more complicated, it won't be
portable.
>If you're writing a text adventure in C, for all meaningful purposes,
>*no C compiler is available for the Macintosh*. A compiler exists, but
>it's not available -- it won't get used on your game. Unless you do
>the work yourself. Or find a volunteer who likes you a lot.
>
To be precise, there are two C compilers generally available for the Mac,
and they both require a significant investment.
Metrowerks Codewarrior is commercial, relatively easy to use, and costs
hundreds of dollars. It is well worth it for people who do serious
programming, but not to compile some random game.
Apple's Macintosh Programmer's Workshop is free, and requires a good
deal of time to effectively use a programming environment that is
literally like nothing I've ever worked with. It takes an investment
of time. I don't know whether it's worth it or not, but I wouldn't
hack at it to compile some random game.
>To the best of my knowledge, the same is true of Windows.
>
I think there are options available for Windows, at least if you don't
mind running it in a DOS window - and, remember, that's more than good
enough for all functionality you can portably supply. If running in
a DOS window seems like a bad idea, well, then the whole idea is
suspect.
>But there *are* Z-machine interpreters available for Mac, Windows,
>Palm, etc, etc. And players *will* go find them and use them on your
>game, if you distribute your game as a Z-code file. This has been
>demonstrated.
>
More to the point, most people interested in IF have already downloaded
a Z-code interpreter for their machine, and probably a TADS interpreter
also. I've also got Hugo and Alan available. I can compile and run a
C program, but if it's not set up for Codewarrior, and takes more than
a minimal amount of work to set up, I'm not going to bother without
some additional reason.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Jonadab the Unsightly One
> C isn't the only widespread language, Python has a score of platforms,
> and is well suited to novice game authors as well as experienced
> programmers. :)
A score of platforms is *nothing*. Python probably has at least
three or four times that many; Perl certainly does. But that's
still small compared to the number of platforms that have a
z-machine, much less something that can be called a C compiler.
(How useful and compatible those C compilers are is another
matter entirely; see Andrew Plotkin's post.)
Of course, the score of platforms that do have Python tend
to be the most common platforms, so the percentage of systems
that have a Python interpreter available is pretty good.
OTOH, Python is still sufficiently obscure that I wouldn't
want to distribute Python source code and expect people to
download and install an interpreter for it, unless the app
I'm distributing is a pretty big important app that would
see a lot of use. Perl I'd figure would be installed on
most Unixy systems, but I wouldn't expect a typical Windows
user or Mac user to install even that for the sake of
one app (again, unless it's a very significant app, like,
say, a really great newsreader).
--
Forward all spam to u...@ftc.gov
Richard Bos
> Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
> > m...@pobox.com (Magnus Olsson) wrote:
>
> >> But, anyway, the three major reasons for using a specialized IF language:
> >>
> >> 1) The object code is portable, whereas your C adventure will have to be
> >> recompiled on every new machine it's ported to. And far from all
> >> computers have a C compiler (many people play IF on things like Palm
> >> Pilots).
>
> > I suspect that far, far more platforms have a C compiler available than
> > a ZMachine or, e.g., Hugo interpreter. In particular, I would be most
> > surprised if there turned out not to be a C compiler for the Palm Pilot
> > (and would suggest that someone make a buck out of that market,
> > _now_).
>
> There isn't.
>
> Now I'll explain that.
>
> First, the Palm is too small, slow, and awkward to compile large
> programs on. (Yes, I know about PocketC. It doesn't count.) Therefore,
> people write code on desktop machines and cross-compile.
That's _on_. I said _for_. You only need to (cross-)compile once to get
an executable for your new platform.
> In fact, that's all beside the point. I won't even compile C source
> for arbitrary text games for the *Macintosh*. It's just too much of a
> hassle. You put together a build tree, push in the files, and what do
> you get? A game with a crappy stdin/stdout interface.
Sure. I never said there weren't any other disadvantages to using
straight ISO C for this. I just claimed that if you _do_ keep to ISO C,
your code is going to be more portable than if you use an IF language.
Whether this portability outweighs the disadvantages is a different
matter.
> If you're writing a text adventure in C, for all meaningful purposes,
> *no C compiler is available for the Macintosh*. A compiler exists, but
> it's not available -- it won't get used on your game. Unless you do
> the work yourself. Or find a volunteer who likes you a lot.
>
> To the best of my knowledge, the same is true of Windows.
Well, at least MS-DOS executables will run under Windows. And there's
always Cygwin.
> Ergo, Z-machine interpreters are more widely available than C
> compilers -- in this context.
Only if you take "this context" to be "for popular gaming platforms, and
in such a way that it exploits their bonnie bits". If you take "this
context" to be "all computers you could, perhaps, run your adventure
on", then I dunno if there's a ZMachine for the PDP-11, or a Cray, but
there are certainly C compilers for them.
Of course, you still should really program your game in a specialised
language. The extra possible platforms you could get by using C are
really not worth the hassle you have from using a lowest common
denominator; I never denied that. But you _could_ use C, and you would
get wider portability, in principle even if maybe not in practice.
And it is still a great programming exercise for a medium-level C
programmer <g>.
Richard
Magnus Olsson
Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
>Andrew Plotkin <erky...@eblong.com> wrote:
>
>> Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
>> > I suspect that far, far more platforms have a C compiler available than
>> > a ZMachine or, e.g., Hugo interpreter. In particular, I would be most
>> > surprised if there turned out not to be a C compiler for the Palm Pilot
(...)
>> There isn't.
>>
>> Now I'll explain that.
>>
>> First, the Palm is too small, slow, and awkward to compile large
>> programs on. (Yes, I know about PocketC. It doesn't count.) Therefore,
>> people write code on desktop machines and cross-compile.
>
>That's _on_. I said _for_. You only need to (cross-)compile once to get
>an executable for your new platform.
Yes, but consider this:
Suppose you have a new platform for which there is no IF at all
available in executable form. Suppose also that you, the owner of this
machine and presumptive IF player, don't have access to a compiler
and/or don't have the technical prowess to port and compile a program
(and don't say that no porting is necessary as long as you write in
ISO C - that's simply not true for all platforms).
Suppose also that there are twenty Z-code games and twenty C games
that you want to play.
For the Z-code games, you need to find someone who can port a Z-code
interpreter to your platform (or perhaps even write a new one). This
needs to be done exactly *once*. Then you can play not only the twenty
Z-code games, but any new Z-code games that are relased in the future
(unless Graham releases a new Z-code version, of course).
For the C games, you need to find someone to port and compile each
game. This must be repeated for each game - twenty times - and not
only that, it must be repeated for every new C game released in the
future.
Which is the most convenient?
And, of course, this also applies if you can do the porting and
compiling yourself.
As for there being machines that have a C compiler but not a Z-code
itnerpreter: either this is because nobody has wanted a Z-code
interpreter for that platform badly enough to port it, in which case
you just need to persuade somebody that *you* want it badly enough, or
it's because there are fundamental portability problems (e.g. the
machine doesn't use textual I/O at all). In the latter case, however,
porting an adventure written in C is also likely to be difficult.
>Sure. I never said there weren't any other disadvantages to using
>straight ISO C for this. I just claimed that if you _do_ keep to ISO C,
>your code is going to be more portable than if you use an IF language.
I think it's important to define "portable". Portable for whom? For a
person who wants to hack the code? In that case, ISO C is preferable,
not just because of the availability of compilers, but because the ISO
C lnaguage and libraries are standardized and very well documented,
which is not the case for IF languages.
If you mean "Portable for a person who wants to play the game", then
I'd say that Z-code is as portable as you can get. If you can't
compile and run a Z-code interpreter on your system, I really don't
think that you can compile and run the ISO C adventure either.
(Note: Z-code is standardized and extensively documented, though
without the blessing of ISO. This means that anybody interested in
running Z-code games can in theory write their own interpreter, even
if their machine has no compiler other than COBOL.)
To summarize:
If you're concerned about portability because you want as many people
as possible to be able to play your game, now and in the future,
choosing C over Z-code is not going to help you. In the short run, it
is probably counter-productive, even if all other things are equal,
unless you want to make sure yourself that executables for all the
umpteen platforms that support the Z-machine today. (The number of
players who use machines which have a C compiler but no Z-machine is
probalby negligible).
Of course, there are other valid reasons for writing in C, personal
preference being one of them.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Adam J. Thornton
Rather.
Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Matthew T. Russotto
}in such a way that it exploits their bonnie bits". If you take "this
}context" to be "all computers you could, perhaps, run your adventure
}on", then I dunno if there's a ZMachine for the PDP-11, or a Cray, but
}there are certainly C compilers for them.
Yes, there's a Z-machine for the PDP-11. That might have been the first
platform a Z-Machine was written for.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
mathew
> In article <8parmg$j34$1...@oravannahka.helsinki.fi>,
> Joona I Palaste <pal...@cc.helsinki.fi> wrote:
> >I myself
> >use normal ISO C, because that's more portable than the scripting
> >languages (at least if I distribute the game in source form), and it
> >gives me total control over the way the game works.
> But, anyway, the three major reasons for using a specialized IF language:
>
> 1) The object code is portable, whereas your C adventure will have to be
> recompiled on every new machine it's ported to. And far from all
> computers have a C compiler (many people play IF on things like Palm
> Pilots).
>
> an excellent object library and a good parser. No need to reinvent
> the wheel.
>
> 3) You save a lot of typing, since the syntax of the specialized
> languages is customized to make it easy to write adventures. I have
> no hard data on this, though. Perhaps some of the people who've
> ported Dungeon and Advent from Fortran to TADS, Inform and Hugo might
> care to comment on this?
I'd add another couple:
4) There are lots of things you can do with TADS or Inform that you
can't do in pure ISO C. Bold text, italics, cursor addressing,
sound, graphics...
5) You save a lot of porting work. Far from being more portable, ISO C
is actually less portable than specialized IF languages because of
I/O issues.
For instance, on systems like the Macintosh and Palm you have to worry
about how to put a windowing front-end on your ISO C, since there's no
command line. For the Mac you can get simple stdio-in-a-window
libraries, but your game will then be really ugly and painful to play
compared to all the ones written in (say) Inform. [ISO C file access
can also be problematic on the Mac unless you're really careful, because
the Mac doesn't have pathnames.]
Coding your C to *really* be portable is harder work than you think.
Much better to leverage all the work people have already done to put
native interfaces on all the IF virtual machine interpreters.
And even if I were writing an adventure in a general-purpose programming
language, I still wouldn't use C. In fact, C is about the worst
possible programming language for the choice, because it has terrible
string handling, poor type-checking, no object orientation, and no
automatic memory management.
mathew
--
No taxation without representation!
Carl Muckenhoupt
russ...@wanda.vf.pond.com (Matthew T. Russotto) wrote:
> Yes, there's a Z-machine for the PDP-11. That might have been the
first
> platform a Z-Machine was written for.
I had got the impression that the TRS-80 was the first. At any rate,
it was the first microcomputer that ran Zork, and the Z-machine was
invented specifically to port Zork to micros. (The "mainframe" version
of Zork, AKA Dungeon, was written in MDL or something.)
I wouldn't be at all surprised if they made a PDP-11 z-machine first as
part of the development process, though. After all, someone had to
actually write and test Z-code, and I imagine that as being more
comfortable on a "real computer".
Sent via Deja.com http://www.deja.com/
Before you buy.
Carl Muckenhoupt
in...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> Sure. I never said there weren't any other disadvantages to using
> straight ISO C for this. I just claimed that if you _do_ keep to ISO
C,
> your code is going to be more portable than if you use an IF language.
I don't know if this holds water.
Let me ask two questions:
1) Does there exist a pure ISO C implementation of the Z-machine?
2) Is there any machine for which there exists a Z-code interpreter but
no ISO C compiler (or cross-compiler)?
If the answer to question 1 is "yes", then Z-code is just as portable
as ISO C.
If the answer to both questions is "yes", then Z-code is *more*
portable than ISO C.
Unfortunately, I don't know the answer to either question. But if the
answer to question 1 is "yes", then someone around here probably knows
it. And I suspect that the answer to question 2 is "yes", on the
grounds that Infocom released their games on platforms such as the
Commodore Pet, the Osborne, and the Kaypro II. There may well have
been C compilers for all of these machines, but if so, they would have
predated the ISO standard by many years.
Mind you, it's just a small matter of programming to reverse a "no"
answer to question 1. Or, for that matter, a "yes" answer to question
2.
wo...@one.net
Hi Jonadab,
>A score of platforms is *nothing*. Python probably has at least
>three or four times that many; Perl certainly does. But that's
>still small compared to the number of platforms that have a
>z-machine, much less something that can be called a C compiler.
>(How useful and compatible those C compilers are is another
>matter entirely; see Andrew Plotkin's post.)
By platform I actually meant OS, not hardware. :) All the DOS/Windows
family, including CE and 2000, OS/2, Mac, BeOS, Psion, Amiga, Linux,
many Unixen, QNX, Palm (soon), VMS, VxWorks, and Acorn RISC OS.
>Of course, the score of platforms that do have Python tend
>to be the most common platforms, so the percentage of systems
>that have a Python interpreter available is pretty good.
I would hazard a guess that nearly 99% of all computers (aside from
the 8 bit generation) can run Python and the pyc's are *binary
compatible* across all of them. Even if not for some odd reason,
Python will automatically recreate the pyc's if you include the py
source files. I'd say that covers almost everybody... {chuckle}
>OTOH, Python is still sufficiently obscure that I wouldn't
>want to distribute Python source code and expect people to
>download and install an interpreter for it
Hmm. The Windows and Mac versions are no harder to install than any
other app for that OS. I can't speak for Linux but anyone running
Linux/Unix variants won't have any trouble downloading and installing
the interpreter. And www.python.org is a really simple link to
remember!
On top of which, they have to download a z-machine so there's little
practical difference.
Richard Bos
> In article <39bcf2ff....@news.worldonline.nl>,
> in...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>
> > Sure. I never said there weren't any other disadvantages to using
> > straight ISO C for this. I just claimed that if you _do_ keep to
> > ISO C, your code is going to be more portable than if you use an
> > IF language.
>
> I don't know if this holds water.
> Let me ask two questions:
> 1) Does there exist a pure ISO C implementation of the Z-machine?
Of course not. Consider timed input, font changes, status lines; the
ZMachine does more things, and does them more prettily, than an ISO C
implementation, and therefore _must_ be less portable.
For example, you can run an ISO C implementation over a teletype, if you
want to. You can't run a ZMachine on one.
Richard
Iain Merrick
> Andrew Plotkin wrote:
> [...]
> > Ergo, Z-machine interpreters are more widely available than C
> > compilers -- in this context.
>
> Only if you take "this context" to be "for popular gaming platforms, and
> in such a way that it exploits their bonnie bits". If you take "this
> context" to be "all computers you could, perhaps, run your adventure
> on", then I dunno if there's a ZMachine for the PDP-11, or a Cray, but
> there are certainly C compilers for them.
If you have a C compiler, you can compile a Z-code interpreter.
--
Iain Merrick
i...@cs.york.ac.uk
Iain Merrick
> Carl Muckenhoupt wrote:
> [...]
> > 1) Does there exist a pure ISO C implementation of the Z-machine?
>
> Of course not. Consider timed input, font changes, status lines; the
> ZMachine does more things, and does them more prettily, than an ISO C
> implementation, and therefore _must_ be less portable.
> For example, you can run an ISO C implementation over a teletype, if you
> want to. You can't run a ZMachine on one.
I believe there are special header bits which the interpreter can set to
indicate whether all these fancy features are available. So if you write
your game carefully, it should run okay on a no-frills terp with no
fancy features at all.
This scheme is pretty ad-hoc, though, so there might be some features
which are always assumed to work. (Note that Glulx uses Glk for its I/O,
which has a much cleaner 'Gestalt' mechanism, and which therefore _can_
be ported to basic stdio.)
(By the way, what exactly is the 'ISO C' people are talking about in
this thread? Is it the same as 'ANSI C', as described in the 2nd edition
K&R, or something slightly different?)
--
Iain Merrick
i...@cs.york.ac.uk
Carl Muckenhoupt
Iain Merrick <i...@spod-central.org> wrote:
> Richard Bos wrote:
>
> > Carl Muckenhoupt wrote:
> > [...]
> > > 1) Does there exist a pure ISO C implementation of the Z-machine?
> >
> > Of course not. Consider timed input, font changes, status lines; the
> > ZMachine does more things, and does them more prettily, than an ISO
C
> > implementation, and therefore _must_ be less portable.
> > For example, you can run an ISO C implementation over a teletype,
if you
> > want to. You can't run a ZMachine on one.
>
> I believe there are special header bits which the interpreter can set
to
> indicate whether all these fancy features are available. So if you
write
> your game carefully, it should run okay on a no-frills terp with no
> fancy features at all.
Case in point: the TRS-80 Model 1 had a monochrome display and didn't
have any sort of bold or italic text - in fact, even support for lower
case was an optional add-on. So the TRS-80 version of the Z-machine
simply didn't support alternate fonts. If it saw any font-changing
commands, it simply ignored them. Moreover, I'm pretty sure that there
were interpreters that didn't support a status line; I seem to recall
this being mentioned in the docs of some of the Infocom games. Unlike
the font issue, this is a case where the game would pretty much have to
be able to execute code conditionally depending on what it can
determine about the terp's capabilities.
> (By the way, what exactly is the 'ISO C' people are talking about in
> this thread? Is it the same as 'ANSI C', as described in the 2nd
edition
> K&R, or something slightly different?)
As far as I'm aware, it's just the same thing handled by a different
standards body.
Carl Muckenhoupt
of the Z-machine does effectively limit the portability of Z-code games
that have a crucial reliance on those features. For example, you
couldn't very well play Border Zone on a 'terp that doesn't support
timed input. So in fact, at best only *some* Z-code games are as
portable as ISO C, and there's no simple way to find out which ones.
Richard Bos
> (By the way, what exactly is the 'ISO C' people are talking about in
> this thread? Is it the same as 'ANSI C', as described in the 2nd edition
> K&R, or something slightly different?)
ISO is the parent organisation of ANSI; ANSI is the American National
Standards Institute, ISO is the International Standards Organisation.
ANSI wrote the first C standard; some time later, ISO adopted it. From
that time on, it was more correct to call it the ISO standard, because
ISO implies ANSI (usually), but ANSI does not necessarily imply ISO, and
because the scope of ISO is world-wide.
The new standard was written by an ISO committee (some of whose members
were also ANSI members, I gather). Amusingly, ANSI delayed ratification
of this standard on a technical matter, though only by a couple of
months.
K&R2 doesn't _exactly_ describe ANSI C, AFAIK, though it gets close. And
not everything in K&R2 is ANSI or ISO. If you want to know for certain,
you need to check the standard.
Richard
Iain Merrick
> Iain Merrick <i...@spod-central.org> wrote:
>
> > (By the way, what exactly is the 'ISO C' people are talking about in
> > this thread? Is it the same as 'ANSI C', as described in the 2nd edition
> > K&R, or something slightly different?)
>
> ISO is the parent organisation of ANSI; ANSI is the American National
> Standards Institute, ISO is the International Standards Organisation.
[...]
> K&R2 doesn't _exactly_ describe ANSI C, AFAIK, though it gets close. And
> not everything in K&R2 is ANSI or ISO. If you want to know for certain,
> you need to check the standard.
Ah, I see. Thanks for the info. (I think I'll still take the K&R
appendices as my baseline for 'standard C', though.)
--
Iain Merrick
i...@cs.york.ac.uk
Matthew T. Russotto
Carl Muckenhoupt <ca...@wurb.com> wrote:
}In article <acbv5.289$Uc.1...@monger.newsread.com>,
} russ...@wanda.vf.pond.com (Matthew T. Russotto) wrote:
}
}> Yes, there's a Z-machine for the PDP-11. That might have been the
}first
}> platform a Z-Machine was written for.
}
}I had got the impression that the TRS-80 was the first. At any rate,
}it was the first microcomputer that ran Zork, and the Z-machine was
}invented specifically to port Zork to micros. (The "mainframe" version
}of Zork, AKA Dungeon, was written in MDL or something.)
The Infocom fact sheet puts the first sale of a PDP-11 version a month
before the TRS-80 version. I think the only earlier one would be
something that ran on Infocom's development mainframe.
Christopher Currie
>
> > Ergo, Z-machine interpreters are more widely available than C
> > compilers -- in this context.
>
> Only if you take "this context" to be "for popular gaming platforms, and
> in such a way that it exploits their bonnie bits". If you take "this
> context" to be "all computers you could, perhaps, run your adventure
> on", then I dunno if there's a ZMachine for the PDP-11, or a Cray, but
> there are certainly C compilers for them.
Actually, since Inform and Frotz are both written in C, it is plausible
that one could have a ZMachine complier and interpreter for any machine
that has a C compiler.
But this whole discussion assumes that "ISO C" will solve the problems
of portability, which is not the case. A study of the Inform source will
demonstrate some of the challenges involved in writing portable C,
because it has been ported to a number of different platforms. Configure
scripts such as those generated by Autoconf can help, but "ISO C" is a
standard to which few compilers can successfully be held. Part of this
is due to the constant evolution of the standard (many compilers still
do not comply with the latest "C9X" standard), and partly because so
many parts of the standard are "implementation defined." (The primary
example of this in Inform is default signedness of "char", and the way
that various (bad) compilers deal with it.)
Inform, although billed as a portable language, is really only playable
on one platform (or two, if you count glulx). However, the z-machine is
trivial enough and documented enough that interpreters can and have been
written for a large selection of machines available. It should be a
matter of a couple day's work to track down and take care of the various
system dependancies so that most Z-machine games that don't use graphics
should be playable. (The proof is left as an exercise. ;-)
mathew
> Iain Merrick <i...@spod-central.org> wrote:
> > (By the way, what exactly is the 'ISO C' people are talking about in
> > this thread? Is it the same as 'ANSI C', as described in the 2nd edition
> > K&R, or something slightly different?)
>
> ISO is the parent organisation of ANSI; ANSI is the American National
> Standards Institute, ISO is the International Standards Organisation.
Actually, ISO is the International Organization for Standardization.
The name is carefully translated so that the initial letters do *not*
spell "ISO" in any language, so as not to show preference for any
particular language or country.
Larry Smith
> }Ok, I admit I have no idea if you're joking here or not. BUT: ISO is
> }"Internationale Standardisierungs-Organisation" in German.
>
> Officially, or is that just what everyone calls it?
Depends on whether you call it by name or by value...
--
.-. .-. .---. .---. .-..-. | "Bill Gates is just a monocle
| |__ / | \| |-< | |-< > / | and a Persian Cat away from
`----'`-^-'`-'`-'`-'`-' `-' | being one of the bad guys in a
My opinions only. | James Bond movie." -- D Miller
Gunther Schmidl
> Officially, or is that just what everyone calls it?
I just checked on the web, and it seems to be the official naming.
-- g.
Adam J. Thornton
Larry Smith <lsm...@redhat.com> wrote:
>"Matthew T. Russotto" wrote:
>> Officially, or is that just what everyone calls it?
This pun has become pretty Wirthless by now.
mathew
> > Actually, ISO is the International Organization for Standardization.
> > The name is carefully translated so that the initial letters do *not*
> > spell "ISO" in any language, so as not to show preference for any
> > particular language or country.
>
> "Internationale Standardisierungs-Organisation" in German.
Wouldn't that be IS, not ISO?
And no, I wasn't joking. It's really the International Organization for
Standardization.
Gunther Schmidl
> The name is carefully translated so that the initial letters do *not*
> spell "ISO" in any language, so as not to show preference for any
> particular language or country.
>
>
> mathew
Ok, I admit I have no idea if you're joking here or not. BUT: ISO is
"Internationale Standardisierungs-Organisation" in German.
-- g.
Matthew T. Russotto
Larry Smith
> In article <39BFC08C...@smith-house.org>,
> Larry Smith <lsm...@redhat.com> wrote:
> >"Matthew T. Russotto" wrote:
> >> Officially, or is that just what everyone calls it?
> >Depends on whether you call it by name or by value...
>
> This pun has become pretty Wirthless by now.
I guess I'll just have to accept a nickel less...
Jonadab the Unsightly One
> Let me ask two questions:
> 1) Does there exist a pure ISO C implementation of the Z-machine?
DumbFrotz. HTH.HAND.
> 2) Is there any machine for which there exists a Z-code interpreter but
> no ISO C compiler (or cross-compiler)?
Off the top of my head I'd guess Nintendo Gameboy, but I don't
actually know whether it has an ISO C compiler.
--
Forward all spam to u...@ftc.gov
Jonadab the Unsightly One
> Come to think of it, though, the non-universality of various features
> of the Z-machine does effectively limit the portability of Z-code games
> that have a crucial reliance on those features. For example, you
> couldn't very well play Border Zone on a 'terp that doesn't support
> timed input. So in fact, at best only *some* Z-code games are as
> portable as ISO C, and there's no simple way to find out which ones.
Timed input is the one known issue that not all terps support
that can make a game unplayable if it isn't supported. I
suppose if a terp didn't support a fixedwidth font that
would make some ASCII drawings practically illegible. But
I don't know of a terp that doesn't support a fixedwidth
font (though I know of any number that *only* support
fixedwidth fonts, of course, but that's because All True
Fonts Are Fixed-Width(TM)).
Jonadab the Unsightly One
> But this whole discussion assumes that "ISO C" will solve the problems
> of portability, which is not the case. A study of the Inform source will
> demonstrate some of the challenges involved in writing portable C,
Most notably, the horrificity[1] of allocating RAM on various
platforms.
> Configure scripts such as those generated by Autoconf can help,
Autoconf impedes portability. Ask the folks on comp.sys.vms
> Inform, although billed as a portable language, is really only playable
> on one platform (or two, if you count glulx).
That's the *beauty* of the design, though. Who needs real
portability, if you give everyone free computer of the one
kind that can run your program? Give everyone a free
computer? Impossible! But if it's a *virtual* computer...
[1] That's a word now. Perhaps. It's better than
horrificality would have been, anyway.
Jonadab the Unsightly One
> Moreover, I'm pretty sure that there
> were interpreters that didn't support a status line;
If a terp can't do screen writes in specific locations
(say, if it's running on a dumb tty), it usually just
reprints the status line each time it changes -- so it
appears in the flow of text. In practice, this doesn't
look as nice but doesn't really impede playability.
(The lack of command-editing features and the ability
to use colours other than white on black is more of a
turnoff for such terps.)
> I seem to recall
> this being mentioned in the docs of some of the Infocom games. Unlike
> the font issue, this is a case where the game would pretty much have to
> be able to execute code conditionally depending on what it can
> determine about the terp's capabilities.
No, DrawStatusLine works just like normal. Try it. You
can run games in DumbFrotz that have all kinds of neat
status line code. The only difference is that instead
of being fixed at the top of the screen, the status line
appears as a line between "turns" in the text flow.
I think it has a CRLF before and after it, IIRC.
Jonadab the Unsightly One
> And even if I were writing an adventure in a general-purpose programming
> language, I still wouldn't use C. In fact, C is about the worst
> possible programming language for the choice, because it has terrible
> string handling, poor type-checking, no object orientation, and no
> automatic memory management.
In particular, the poor string handling of C makes even modern
versions of (non-visual) BASIC a better choice (portability
aside). And the lack of good OO in C and C++ really hurts
too. Perl or Python make good sense from an implementation
standpoint, if we ignore the issue of getting everyone to
install an interpreter.
The worst possible programming language for the choice,
though, isn't C. It's either Lingo or machine code;
not sure which.
Jonadab the Unsightly One
> I would hazard a guess that nearly 99% of all computers
> (aside from the 8 bit generation)
Excluding the 8-bit generation may be practical, but it
also may hurt feelings.
> >OTOH, Python is still sufficiently obscure that I wouldn't
> >want to distribute Python source code and expect people to
> >download and install an interpreter for it
>
> Hmm. The Windows and Mac versions are no harder to install than any
> other app for that OS.
I've installed Python for Windows. I know it's not hard
to install. That isn't the point. If I'm asking someone
to go out, download, and install over 20 megabytes[1] of
Python *stuff*, the thing I'm giving them had better
be worth 20 megabytes. Think about it. How many text
adventures are worth 20 megabytes of HD space, LET ALONE
20 megabytes of bandwidth (which may be a couple of hours
of download time for people on a standard phone line,
and that time may be charged by the minute...)?
NTEmacs is easy to install too. Would you want to
download and install that just to play a game?
I *could* write a game in elisp... (Of course,
that would be rather silly since there's a z-machine
written in elisp, and I already know Inform...)
> On top of which, they have to download a z-machine so
> there's little practical difference.
For sake of comparison, the version of Frotz I use
weighs in at 54,896 bytes. I'd say that's an extremely
significant practical difference, even if we ignore
the fact that downloading one z-machine provides
the ability to play *hundreds* of games. (Of course,
you still have to download the games, too. But that's
unavoidable.)
[1] My directory tree shows almost 40 MB, but I
have some extras installed like PythonWin.
I'm not sure of the exact size of just plain
ActiveState Python, but I know it's not small.
Kevin Russell
> I've installed Python for Windows. I know it's not hard
> to install. That isn't the point. If I'm asking someone
> to go out, download, and install over 20 megabytes[1] of
> Python *stuff*, the thing I'm giving them had better
> be worth 20 megabytes. Think about it. How many text
> adventures are worth 20 megabytes of HD space, LET ALONE
> 20 megabytes of bandwidth (which may be a couple of hours
> of download time for people on a standard phone line,
> and that time may be charged by the minute...)?
The basic no-questions-asked self-extracting file for Python
1.6 in Windows weighs in at just over 5 megs. But that's the
package for Python *developers*. It includes all kinds of
junk that most end-users never need to have on their machine.
Things like: module files for practically everything (almost
none of which would get used in IF), every scrap of documentation
(with a separate HTML file for practically every subsubsection),
the entire installer for Tcl/Tk (which probably contributes
about half the 5 megs on its own).
The player of a game written in Python doesn't need any of this
stuff, and you don't have to give any of it to them. There are
utilities for creating distribution files that contain your
application files, the Python interpreter and the bare minimum
of other files needed to make your application run -- I think
some of them even fake a suitably named .exe executable under
Windows. The results are a heck of a lot smaller (to quantify it
precisely :-)) than the basic give-em-everything-just-in-case
installer for Python developers. Still considerably bigger
than Frotz, but way smaller than the sizes you've been worrying
about.
> NTEmacs is easy to install too. Would you want to
> download and install that just to play a game?
> I *could* write a game in elisp... (Of course,
> that would be rather silly since there's a z-machine
> written in elisp, and I already know Inform...)
You mean there's someone who doesn't have it already? :-)
-- Kevin
Jonadab the Unsightly One
[Emacs]
> You mean there's someone who doesn't have it already? :-)
Heh. It would be better if most people even knew
there was such a thing.