Are there any C++ library routines to support IF programming?
Eric Hansen
--
+-------------------------------------+-----------------------------+
| Eric Hansen <eha...@ix.netcom.com> | Mime/pgp capable |
| http://www.netcom.com/~ehansen | See web page for public key |
+-------------------------------------+-----------------------------+
Jesse Mcgrew
system designed for that.
--
Jesse "Monolith" McGrew
http://www.concentric.net/~jmcgrew
Eric Hansen
Jmc...@cris.com (Jesse Mcgrew) wrote:
>If you want to do IF programming, do it with Inform or TADS or some other
>system designed for that.
>
That's just the point. I think C++ *is* designed for IF programming. While
trying to learn Inform, it seems that in order to do anything beyond fairly
simple games, you have to do a lot of programming that looks like C++ anyway.
So why not write some generic c++ classes and functions? Then there are no
limitations...the sky's the limit.
I've never written an IF game, but thought I'd take a crack at it. Inform
seems to be the one most use. But when reading the manual, so many of the
concepts sound just like C++.
Don't get me wrong, Inform is an amazing system (based on the documentation
and the games I've played that were written with it). But I don't feel like
learning another language.
Matthew Amster-Burton
>That's just the point. I think C++ *is* designed for IF programming. While
>trying to learn Inform, it seems that in order to do anything beyond fairly
>simple games, you have to do a lot of programming that looks like C++ anyway.
>So why not write some generic c++ classes and functions? Then there are no
>limitations...the sky's the limit.
You can certainly create yourself an IF authoring system in C++.
After all, TADS and Inform are written in C. I don't understand what
this buys you over TADS or Inform, though. I guarantee it will take
you MUCH, MUCH longer to create your own system than to learn and use
Inform.
>Don't get me wrong, Inform is an amazing system (based on the documentation
>and the games I've played that were written with it). But I don't feel like
>learning another language.
Instead you feel like writing one? That's what you'd be doing. Even
if you use the STL, you're going to have to go gaga for data types in
order to make your code maintainable. In effect you will have created
a new development system that happens to be C++ based.
Since you are a programmer, undoubtedly you understand the importance
of using the right tool for the job. If I'm going to construct a
database, I'm not going to do it in straight ANSI C. I'll use Visual
Basic or Delphi, and write SQL if I have to. If I'm writing a CGI
script, I'll do it in Perl. Once you have the basic concepts of
programming under your belt (as you undoubtedly do, as a C++ coder),
learning a new language simply isn't that hard.
Writing an IF development system is quite hard, though. Luckily,
talented programmers have already done this for you. Graham, Mike
Roberts, Kent Tessman, and the rest have worked long hours for little
or no pay so that you do not have to recreate their efforts and can
put a little time into learning their systems a lot into writing a
game. Isn't that what you want to do, after all? Since you are
experienced in C++, you should be able to learn enough Inform or TADS
in a day to start developing your game.
If you do decide to code in a base language rather than a prepackaged
development system, however, let me strongly suggest you consider
doing it in Scheme or Common LISP or Prolog instead of C++--the
AI-oriented languages are far better suited to the task and will cause
you many fewer headaches.
Matthew
Bruce Stephens
That's just the point. I think C++ *is* designed for IF
programming. While trying to learn Inform, it seems that in order
to do anything beyond fairly simple games, you have to do a lot of
programming that looks like C++ anyway. So why not write some
generic c++ classes and functions? Then there are no
limitations...the sky's the limit.
I'm sure it would be possible to write C++ classes to do all the
things Inform (and, most importantly, its libraries) does, but would
that be a good idea? How much would it actually buy?
My favourite platform for playing interactive fiction is a machine
with some severe memory restrictions: executables are limited to 64K
(with some ways of getting around this, but none that would be useful
in this case). Having the game as a data file makes it possible for
me to play Jigsaw (a 1/2M game) on this platform, since the
interpreter is well below 64K. If Jigsaw had been written in C++, it
would be unplayable on this platform, as would all reasonable sized
games.
dor...@scsud.ctstateu.edu
>
> [ comments following the "don't use C++, use TADS/Inform/Hugo" reasoning ]
> My favourite platform for playing interactive fiction is a machine
> with some severe memory restrictions: executables are limited to 64K
Perhaps his "favourite platform" for programming is C++. Surely, there are
better machines out there that don't have the memory restrictions that yours
does, and, by the same reasoning then, shouldn't you be playing on one of
those instead?
Jennifer
David Baggett
Eric Hansen <eric....@worldnet.att.net> wrote:
>That's just the point. I think C++ *is* designed for IF programming.
Many of us here have done this both ways. Take our word for it: you want
to use a language designed specifically for interactive fiction. If there
are any benefits to using C++ (and, aside from performance, I see none),
they will be far outweighed by the amount of wheel re-invention you will
have to do.
>While trying to learn Inform, it seems that in order to do anything beyond
>fairly simple games, you have to do a lot of programming that looks like
>C++ anyway.
In my opinion, Inform has serious, basic problems (like the fact that it's
built on an ad hoc parser that causes weird quirks in the syntax --- see
recent threads on the broken switch statement). But you are far better off
putting up with its limitations than redoing the months of work that's gone
into designing, writing, and tuning the parser, and creating a
comprehensive set of classes --- as easy as that may at first seem.
You also might consider using another IF authoring system. Despite its
popularity, Inform isn't the only full-featured system out there. TADS and
Alan are both better candidates in my opinion. Bob Newell has written a
reasonably well-balanced assessment of the major systems.
>So why not write some generic c++ classes and functions? Then there are no
>limitations...the sky's the limit.
There are no limitations if you write in turing machine instructions,
either, but doesn't mean it's the wisest way to proceed.
>But I don't feel like learning another language.
If you are planning on writing a decent-sized IF work, learning a new
language will be the easy part! You'd be surprised how much work it is.
These languages are designed *for the task*, and consequently offer you
many shortcuts when compared to general purpose languages like C++.
(*Especially* C++, which is a godawful language!)
Dave Baggett
__
d...@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)
Andrew C. Plotkin
> Perhaps his "favourite platform" for programming is C++.
He can program where he likes, but if he doesn't give me a Macintosh
binary, a TADS game file, or a Z-machine game file, I won't be playing
his game. That's the only consideration I have to toss into the pot.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Gareth Rees
> Are there any C++ library routines to support IF programming?
Whether there are or not, if you write IF in C++ then you must decide
from two options:
(1) distribute the source code and expect all your players to compile
it themselves.
(2) distribute the executable code for a few platforms (let's say,
Solaris 2 and Irix 4.0) and expect your players to get hold of
such a platform.
--
Gareth Rees
Magnus Olsson
Eric Hansen <eric....@worldnet.att.net> wrote:
> Jmc...@cris.com (Jesse Mcgrew) wrote:
>>If you want to do IF programming, do it with Inform or TADS or some other
>>system designed for that.
>>
>
Not in any reasonable sense. C++ was designed for general-purpose
programming. Being an object oriented language, it is good for IF
programming, but it wasn't designed with IF in mind and lacks many
things that the languages that *were* designed for IF have. For
example, there are no C++ primitives for writing parsers.
Of course, you can extend C++ by writing a set of IF-oriented classes,
just as you propose. I've thought about doing it myself (that was when
TADS and Inform where still in their infancy). The problem is that it
is a *lot* of work. Far more work than you suppose.
There seems to be some confusion among some of the people here
about the difference between writing a class library for IF and
writing an entirely new language. Creating a new language means just
that: you design your own language (like Graham designed Inform) and
then you write a compiler and a run-time system for it. This can be
done in any language, C++, Pascal, Ada, even Basic. The resulting
language has nothing whatsoever to do with the language used to
implement it.
Extending an existing language, for example by writing an IF class
library for C++, is a different thing. What Eric seems to be proposing
is to write a counterpart of the Inform library (including a parser)
in C++. That way, he could use his C++ compiler and the familiar C++
syntax to write IF.
While this latter approach is much less work than designing a new
language, it's still a *big* task.
Also, despite what you write, I think the syntax and semantics of C++
aren't as suitable for IF programming as those of languages like
Inform and TADS. A trivial example: the syntax for printing static
text in TADS (a double-quoted string by itself is an executable
statement that prints the string) saves a lot of typing with the
enormous amounts of text in an adventure game.
Another example: the way inheritance and instantiation work in C++
makes it a bit awkward for IF. C++ allows you to extend a class by
creating a new class that inherits from it. The new class can modify
the old class' behaviour, add new members, and so on.
However, one thing you can do in TADS and Inform is to do this while
creating an instance. In C++, you first have to create a new class,
then instantiate that class. This means that a large piece of IF will
have hundreds and hundreds of classes, each with only one or a few
instances.
>While
>trying to learn Inform, it seems that in order to do anything beyond fairly
>simple games, you have to do a lot of programming that looks like C++ anyway.
Correct.
>So why not write some generic c++ classes and functions?
The problem with this is the word "some". You're probably talking
about several man years of development time before you can begin to
compete with TADS or Inform.
>Then there are no
>limitations...the sky's the limit.
There are no (practical) limits in TADS either. Inform has some
limits, but those are due to the Z-code interpreters that run the
programs. That format has been extended before and can be extended in
the future.
>I've never written an IF game, but thought I'd take a crack at it. Inform
>seems to be the one most use. But when reading the manual, so many of the
>concepts sound just like C++.
This argument makes just as much sense as saying "When reading the C++
manual, so many of the concepts sound just like C, so why bother with
C++ at all?".
Many parts of Inform are very similar to C++. Most of C++ simply *is* C.
In both cases, what makes it worth using Inform instead of C++, or C++
instead of C, are the parts that are *not* similar.
>Don't get me wrong, Inform is an amazing system (based on the documentation
>and the games I've played that were written with it). But I don't feel like
>learning another language.
...but instead you're willing to invest an enormous amount of time and
effort in writing your own development system.
There's nothing whatsoever wrong with that. Inform isn't perfect, and
it's possible that you'd come up with something better. But you should
be aware of how difficult a task it is.
--
Magnus Olsson (m...@df.lth.se)
Matthew Amster-Burton
>Whether there are or not, if you write IF in C++ then you must decide
>from two options:
> (1) distribute the source code and expect all your players to compile
> it themselves.
> (2) distribute the executable code for a few platforms (let's say,
> Solaris 2 and Irix 4.0) and expect your players to get hold of
> such a platform.
I don't know about that--since everybody has a C++ compiler these
days, you could just pass it off to a couple of friends to compile.
Off the top of my head, I know I could easily get code compiled for:
Mac
DOS (16- and 32-bit)
Solaris
SunOS
Linux
OSF/1
AIX
Irix
etc.
If you posted to the group saying, "I've got some portable C++ code I
need compiled for GrueNIX 17.4revB," someone would say, "I use that at
work, and it's got GCC--no problem." You'd probably even find someone
willing to sign an NDA, if necessary.
Matthew
P.S.: This is not an open invitation for everyone to come to me with
RFC's (requests for compile)....
The Ur-Grue
: In article <4l448b$e...@tribune.concentric.net>,
: Jmc...@cris.com (Jesse Mcgrew) wrote:
: >If you want to do IF programming, do it with Inform or TADS or some other
: >system designed for that.
: >
: That's just the point. I think C++ *is* designed for IF programming. While
: trying to learn Inform, it seems that in order to do anything beyond fairly
: simple games, you have to do a lot of programming that looks like C++ anyway.
: So why not write some generic c++ classes and functions? Then there are no
: limitations...the sky's the limit.
: I've never written an IF game, but thought I'd take a crack at it. Inform
: seems to be the one most use. But when reading the manual, so many of the
: concepts sound just like C++.
: Don't get me wrong, Inform is an amazing system (based on the documentation
: and the games I've played that were written with it). But I don't feel like
: learning another language.
But with inform you get the entire parser and libraries already made
for you, and chances are they are a lot better than you could write.
(that's not a personal insult, i'm just saying that i've never seen
a better parser, especially in home-made IF, than inform's).
Anyway inform is pretty easy to learn, especially if you know C.
Eric Hansen
m...@marvin.df.lth.se (Magnus Olsson) wrote:
>In article <4l5pjh$q...@mtinsc01-mgt.ops.worldnet.att.net>,
>Eric Hansen <eric....@worldnet.att.net> wrote:
You've perfectly summarized exactly what I was steering toward. Not designing
a new game writing system, but simply employing existing c++ syntax to support
IF.
>....but instead you're willing to invest an enormous amount of time and
>effort in writing your own development system.
Well...no I'm not willing to do that. I simply asked the question if there
are any such libraries and classes available so I could use a language I
already know. Apparently there aren't. So my first attempt at IF programming
will (probably) be Inform. Although Hugo looks interesting.
>
>There's nothing whatsoever wrong with that. Inform isn't perfect, and
>it's possible that you'd come up with something better. But you should
>be aware of how difficult a task it is.
I'm sure it's very difficult. Maybe that's why there are so few IF games and
tons of 'video' games.
Nulldogma
>designing
>a new game writing system, but simply employing existing c++ syntax to
>support
>IF.
You know that TADS supports writing sections of code in C or other
languages, right? (It's Appendix F in the manual.) Not knowing any other
languages, I haven't tried it, but the documentation's there, and some
sample code.
Neil
Magnus Olsson
Matthew Amster-Burton <mam...@u.washington.edu> wrote:
>gd...@cl.cam.ac.uk (Gareth Rees) wrote:
>
>>Whether there are or not, if you write IF in C++ then you must decide
>>from two options:
>
>> (1) distribute the source code and expect all your players to compile
>> it themselves.
>> (2) distribute the executable code for a few platforms (let's say,
>> Solaris 2 and Irix 4.0) and expect your players to get hold of
>> such a platform.
>
>I don't know about that--since everybody has a C++ compiler these
>days, you could just pass it off to a couple of friends to compile.
Well, the problem remains: you'd have to distribute the executables for
a number of platforms, rather than just some platform-independent game
file.
Also, don't overstimate the portability of C++ code. There are amaizng
differrences between how much of the lagnuage has been implemented by
different compiler vendors. Many compilers offer no, or broken,
support for templates and exceptions, for example.
--
Magnus Olsson (m...@df.lth.se)
Magnus Olsson
Eric Hansen <eha...@iz.netcom.com> wrote:
>In article <4l87h7$4...@news.lth.se>,
> m...@marvin.df.lth.se (Magnus Olsson) wrote:
[about writing a C++ class library for writing IF]
>>There's nothing whatsoever wrong with that. Inform isn't perfect, and
>>it's possible that you'd come up with something better. But you should
>>be aware of how difficult a task it is.
>
>I'm sure it's very difficult. Maybe that's why there are so few IF games and
>tons of 'video' games.
I'm not sure if you're bing sarcastic or not (emotions don't carry too
well in Usenet postings), but seriously, you're comparing apples and
oranges. There's a market for 'video' games. That means that people
will pay professional programmers to write them. If there was the
same sort of money in text adventures, I'm sure we'd see tons of them,
as well as tons of development tools including C++ class libraries.
--
Magnus Olsson (m...@df.lth.se)
Berek Halfhand aka John Bowlin
>>Don't get me wrong, Inform is an amazing system (based on the documentation
>>and the games I've played that were written with it). But I don't feel like
>>learning another language.
>
> ...but instead you're willing to invest an enormous amount of time and
> effort in writing your own development system.
>
> There's nothing whatsoever wrong with that. Inform isn't perfect, and
> it's possible that you'd come up with something better. But you should
> be aware of how difficult a task it is.
Not to mention all the additional work you'd have to do to port your C++
code over to other platforms that TADS and Inform already support with
no effort at all. Learning someone else's library/language is much
easier than writing your own. Either way, you're going to have to learn
new things to get started in i-f, and one major advantage of TADS and
Inform is that there are a lot of people using them already.
Trevor Barrie
>But with inform you get the entire parser and libraries already made
>for you, and chances are they are a lot better than you could write.
>(that's not a personal insult, i'm just saying that i've never seen
>a better parser, especially in home-made IF, than inform's).
I have, every time I play a TADS game. But maybe we don't want to get
into that...:)
Dan Shiovitz
Actually, this is something I'm curious about. I've heard there's differences
between Inform's and TADS's parsers, but I haven't really seen any in practice.
Could someone more knowledgable enlighten me on the subject?
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more sensible
people ... remember to speak up for freedom because no one else will do it
for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Andrew C. Plotkin
> >>But with inform you get the entire parser and libraries already made
> >>for you, and chances are they are a lot better than you could write.
> >>(that's not a personal insult, i'm just saying that i've never seen
> >>a better parser, especially in home-made IF, than inform's).
> >
> >I have, every time I play a TADS game. But maybe we don't want to get
> >into that...:)
>
> Actually, this is something I'm curious about. I've heard there's differences
> between Inform's and TADS's parsers, but I haven't really seen any in practice.
There are plenty of *differences*. (I'm talking about the standard
libraries here; obviously you could rewrite the Inform parser from the
ground up if you wanted, and presumably the TADS parser as well.)
TADS tells you when it doesn't recognize a word; Inform doesn't let
on, pretending there might be a object by that name in the next room.
TADS allows "examine all", Inform doesn't. (I'm still talking the
standard libraries.) TADS allows you to refer to a person as "it";
Inform only accept "him" or "her", as appropriate. I'm sure I've
encountered different quirks in the two object-name resolution
schemes, but I can't remember what they are. If you have an object in
your backpack, TADS allows you to drop it; Inform makes you take it
first.
These are not huge difference, but they are exactly the sort of thing
that make people arbitrarily say "I hate this!" Particularly if you're
used to one system and then play a game in the other. I find Inform
games a *lot* more comfortable, but then of course I've written lots
of Inform code and two Z-interpreters.
I also have a long-term impression that I encounter a larger
percentage of canned responses (library messages) in TADS games.
This is just an impression.
Jesse Mcgrew
: >for you, and chances are they are a lot better than you could write.
: >(that's not a personal insult, i'm just saying that i've never seen
: >a better parser, especially in home-made IF, than inform's).
: I have, every time I play a TADS game. But maybe we don't want to get
: into that...:)
And you will again, every time you play a Snack game. Once Snack is
finished, of course. :)
"bob, find jones. tell him to put the soup in the bowl using the ladle. then
take the bowl from him, get in the car, and drive to your house."
(I'm working on the manual now because it will give the language and library
a more concrete definition.)
Neil K. Guy
Jonathan Fry (jf...@saims.skidmore.edu) wrote:
: I don't think I've seen anyone mention the foremost reason I chose to
: use Inform over TADS--I, at least, find it to be more "aesthetically
: pleasing". Inform uses bold for short room descriptions and plain
: for long descriptions. This is (in my opinion) much more readable
: than the plain on plain style that TADS uses. [...]
That isn't a requirement. You can use the boldface stuff in TADS. My
(still highly stalled) game in progress uses boldface to indicate room
descriptions like the Inform libraries do. One major problem, though. It
doesn't work on Macs - the Mac TADS runtime can't display boldface text.
Ironic, given that Macintoshes have more display flexibility than most
other machines. It's because TADS' author hasn't rewritten the Mac
runtime to use styled TextEdit. Oh, well.
: [...] Also, I don't
: think I've seen any TADS games include visual components (like the
: Jigsaw pieces in "Jigsaw" or the status bar option)--can TADS
: handle this kind of stuff?
Nope. Unfortunately TADS does not have the ability to specify monospace
fonts and other such tricks.
- Neil K. Guy
--
Neil K. Guy * ne...@sfu.ca * n...@vcn.bc.ca
49N 16' 123W 7' * Vancouver, BC, Canada
Nulldogma
>I don't think I've seen anyone mention the foremost reason I chose to
>use Inform over TADS--I, at least, find it to be more "aesthetically
>pleasing". Inform uses bold for short room descriptions and plain
>for long descriptions. This is (in my opinion) much more readable
>think I've seen any TADS games include visual components (like the
>Jigsaw pieces in "Jigsaw" or the status bar option)--can TADS
>handle this kind of stuff?
TADS can allegedly use bold (I'm not sure about ital), but I don't know
anyone who's ever gotten it to work. It's the one thing I prefer about
Inform, certainly.
Neil
Jonathan Fry
I don't think I've seen anyone mention the foremost reason I chose to
use Inform over TADS--I, at least, find it to be more "aesthetically
pleasing". Inform uses bold for short room descriptions and plain
for long descriptions. This is (in my opinion) much more readable
than the plain on plain style that TADS uses. Also, I don't
think I've seen any TADS games include visual components (like the
Jigsaw pieces in "Jigsaw" or the status bar option)--can TADS
handle this kind of stuff?
+-------------------------------------------------------+
| Jonathan Fry ---------------------- jf...@skidmore.edu |
| --- COMING: 1996 I-F COMPETITION ENTRY: STARGAZER --- |
+-------------------------------------------------------+
Jesse Mcgrew
Nulldogma (null...@aol.com) wrote:
: TADS can allegedly use bold (I'm not sure about ital), but I don't know
: anyone who's ever gotten it to work. It's the one thing I prefer about
: Inform, certainly.
I've seen bold in the Unkuulian (sp?) games. I think \( and \) turn bold on
and off in a string.
ler...@classic25.rz.uni-duesseldorf.de
Saluton!
Matthew Amster-Burton (mam...@u.washington.edu) wrote:
: I don't know about that--since everybody has a C++ compiler these
: days, you could just pass it off to a couple of friends to compile.
: Off the top of my head, I know I could easily get code compiled for:
I don't. I could, but I don't want to. I dislike Cxx quite
strongly. Actually, Inform is already a little too C-like
for my taste.
Ad Astra!
JuL
We are the forces of chaos and anarchy | At least, AMIGA makes it better !
Everything they say we are we are |------------------------------------
And we're very proud of ourselves... | IMPORT StdDisclaimer; (... Modula,
Jefferson Airplane | NOT C ! :):)
-----------------------------------------------------------------------------
Flameproof .sig? Bah, dragons are fireproof anyway! | - Frei f"ur Notizen -
Matthew Amster-Burton
ler...@classic25.rz.uni-duesseldorf.de () wrote:
>: I don't know about that--since everybody has a C++ compiler these
>: days, you could just pass it off to a couple of friends to compile.
>: Off the top of my head, I know I could easily get code compiled for:
>I don't. I could, but I don't want to. I dislike Cxx quite
>strongly. Actually, Inform is already a little too C-like
>for my taste.
Whether you personally like or dislike C++ has nothing to do with it.
The fact remains that C++ compilers are readily available for most
major platforms, and if you write your code with portability as a high
priority, you should be able to compile it without much trouble on any
of these platforms.
Hell, on my machine I've got interpreters for Tcl (a language I hate)
and Python (which I don't know), as well as a Scheme compiler. I've
made use of all of them. In fact, come to think of it, I believe I
could handle Pascal or Fortran, also.
Admittedly, I'm speaking from the Unix perspective, where if you don't
have a C compiler, your hands are tied. Back when I paid $250 for
Borland C++, I probably wouldn't have started this thread. These
days, there's DJGPP, and all is well. (Is there a free Mac compiler?)
Sorry to be so off-topic today. I'm about to attempt to redeem myself
by starting a new thread....
Matthew
P.S.: Okay, while I'm off-topic, a little question for the
technically-minded folks who've made it this far. Lately I've been
playing with TeX and reading the TeXbook. I don't like it very much.
Is there any chance I'll like LaTeX if I dislike plain TeX? I know a
lot of people swear by it, and I wonder if anyone could e-mail me some
LaTeX pro and cons.
---
Matthew Amster-Burton .sig revision 0, 5/1/96
I speak for myself, not for UW
Andrew C. Plotkin
mam...@u.washington.edu (Matthew Amster-Burton) writes:
> Whether you personally like or dislike C++ has nothing to do with it.
> The fact remains that C++ compilers are readily available for most
> major platforms, and if you write your code with portability as a high
> priority, you should be able to compile it without much trouble on any
> of these platforms.
>
> Hell, on my machine I've got interpreters for Tcl (a language I hate)
> and Python (which I don't know), as well as a Scheme compiler. I've
> made use of all of them. In fact, come to think of it, I believe I
> could handle Pascal or Fortran, also.
>
> Admittedly, I'm speaking from the Unix perspective, where if you don't
> have a C compiler, your hands are tied. Back when I paid $250 for
> Borland C++, I probably wouldn't have started this thread. These
> days, there's DJGPP, and all is well. (Is there a free Mac compiler?)
Sort of. You can find a port of GCC for the Mac, but it's either hard
or impossible to get it to hook into the Mac toolbox routines.
This brings up another point. If you write a game in C++, it will have
no Mac interface. This is not a small point. I've worked hard to make
a decent Mac interface (and an X windows one, for that matter), and I
did it explicitly because I have a vast and miserable hatred for
fixed-width windows and fixed-size fonts and no cursor controls or
scrollback or command history or... Ahem. The point is, we've gone
beyond the point of saying "All text adventures look like Zork running
on an Apple II." You really are throwing away a lot more than a
parser, when you start over from scratch.
Matthew Amster-Burton
"Andrew C. Plotkin" <erky...@CMU.EDU> wrote:
>This brings up another point. If you write a game in C++, it will have
>no Mac interface. This is not a small point. I've worked hard to make
>a decent Mac interface (and an X windows one, for that matter), and I
>did it explicitly because I have a vast and miserable hatred for
>fixed-width windows and fixed-size fonts and no cursor controls or
>scrollback or command history or... Ahem. The point is, we've gone
>beyond the point of saying "All text adventures look like Zork running
>on an Apple II." You really are throwing away a lot more than a
>parser, when you start over from scratch.
Another excellent reason not to do so. I didn't even think about
this. In other words, authors: Don't write games in C unless you're
prepared to give the next five years of your life over to coordinating
development for an entirely new platform or are an incurable
masochist.
Matthew