IF Authoring Systems
Jeff Hatch
What would a great interactive fiction authoring system be like?
I don't mean to rehash the "Tads vs. Inform vs. new systems" debate.
I've seen snippets of code from each of the most popular IF languages,
and I know that Inform and Tads are both *good* languages. No, I'm
thinking of something else entirely.
Perhaps you'd rather create new works of art than improve your set of
tools. That's understandable, but in the long run a better IF authoring
system will greatly benefit the genre. Ancient Egyptians carved
hieroglyphs in stone with chisels, but 19th-Century American authors had
access to paper, ink, and quill pens. It's no wonder fewer books were
written in ancient Egypt! Similarly, time-saving new tools for IF
writers can only increase creative output.
A great interactive fiction authoring system should be more than a
compiler. Even the "easy-to-use" IF systems obey the same paradigm:
Edit text file. Recompile. Execute. Locate bug. Repeat. Debuggers are
perhaps the only modern innovation. Why are we writing interactive
fiction using the linear programming methods of the '60s? Yes,
algorithms have to be linear, but interactive fiction is more
"object-oriented" than algorithm-oriented. We make Rooms, Doors,
Actors, Fuses, Items. There should be a simple, fast way to create
these things!
A great interactive fiction authoring system should be a cross between a
database and a compiler. It should present the attributes of
user-created "objects" in a table so they're easy to edit.
Practical Example: Suppose your game has a Kitchen next to a Landing,
and you want to put a door between them. Your library doesn't have a
specific Door class, but it has "Obstacle" and "Openable" classes, which
suffice. You define a "Door" object that's derived from the Openable and
Obstacle classes. A menu appears, and a portion of your screen shows
this:
Obj Door COpenable CObstacle
Cls COpenable CLocal
Var Text
Var Location 0
Fnc Commands
Var IsOpen 0
Cls CObstacle
Var Location2 0
In a matter of seconds, you move the cursor to the right-hand column and
set Text = "door," Location = "Kitchen," and Location2 = "Landing."
Then you go set the Kitchen's West field and the Landing's East field to
"Door." That's all--no compiling necessary! An experienced programmer
would be able to do that in thirty seconds, and a beginner would find
the database format much easier to understand than any compiler's text
source file.
A great interactive fiction authoring system should be available in six
to twelve months.
-Rúmil
Graham Nelson
In article <34139C...@juno.com>, Jeff Hatch
<URL:mailto:jeff...@juno.com> wrote:
>
> What would a great interactive fiction authoring system be like?
Modesty forbids...
> I don't mean to rehash the "Tads vs. Inform vs. new systems" debate.
> I've seen snippets of code from each of the most popular IF languages,
> and I know that Inform and Tads are both *good* languages. No, I'm
> thinking of something else entirely.
>
> Perhaps you'd rather create new works of art than improve your set of
> tools. That's understandable, but in the long run a better IF authoring
> system will greatly benefit the genre. Ancient Egyptians carved
> hieroglyphs in stone with chisels, but 19th-Century American authors had
> access to paper, ink, and quill pens. It's no wonder fewer books were
> written in ancient Egypt! Similarly, time-saving new tools for IF
> writers can only increase creative output.
You aren't the first to think so, and perhaps you're right. It's
not quite so clearcut, though, and the history of IF authoring
systems has seen compilers like TADS triumph over simplistic
point-and-click database front-ends of the kind you propose. The
comparison with chisels versus quill pens is not valid because it
implicitly assumes that the range of text writable with each
implement is the same. This is not true: a cute, easy-to-get-started
adventure creation system (of which there are very many already)
is usually crippled by its inability to handle the full flexibility
needed by designers of even the most modest games. When you have
that full flexibility, you pretty much have something as powerful
and necessarily complex as TADS.
Incidentally, books were written in ancient Egypt, and perhaps one
might point out that you could write the above backwards to lament
the decline of monumental inscriptions in 19th-century America
due to a culture of ephemerality based on wood-pulp...
> A great interactive fiction authoring system should be more than a
> compiler. Even the "easy-to-use" IF systems obey the same paradigm:
> Edit text file. Recompile. Execute. Locate bug. Repeat. Debuggers are
> perhaps the only modern innovation. Why are we writing interactive
> fiction using the linear programming methods of the '60s? Yes,
> algorithms have to be linear, but interactive fiction is more
> "object-oriented" than algorithm-oriented. We make Rooms, Doors,
> Actors, Fuses, Items. There should be a simple, fast way to create
> these things!
To some extent there is. The present system is not so bad as it
sounds: modularity into objects makes it pretty easy to cut out,
e.g., the lantern from "Advent" and glue it directly into a
different game, where it will continue to work well.
Ask also: why are we writing procedural code using the programming
methods of the 60s? (We are.) Possibly because the basic techniques
of programming were perfected in the 60s, leaving out preferences in
the nuance of language design.
> A great interactive fiction authoring system should be a cross between a
> database and a compiler. It should present the attributes of
> user-created "objects" in a table so they're easy to edit.
TADS, Inform, etc., all do this. You seem to be proposing no more
than a pretty windowed text editor to be glued onto the side of
an existing system. This has been done, too, but usually people have
found that it doesn't save as much time as the bother it causes.
The trouble is that a fancy text editor may indeed save a little time
on the routine jobs, such as typing in map connections, but these
jobs represent only a tiny proportion of the coding time involved in
getting a game up to releasable quality. And the best authorship
systems are targetted toward producing quality, finished work,
not toward making it easy to set up primitive demos of adventure
games.
> Practical Example: Suppose your game has a Kitchen next to a Landing,
> and you want to put a door between them. Your library doesn't have a
> specific Door class, but it has "Obstacle" and "Openable" classes, which
> suffice. You define a "Door" object that's derived from the Openable and
> Obstacle classes. A menu appears, and a portion of your screen shows
> this:
>
> Obj Door COpenable CObstacle
> Cls COpenable CLocal
> Var Text
> Var Location 0
> Fnc Commands
> Var IsOpen 0
> Cls CObstacle
> Var Location2 0
>
> In a matter of seconds, you move the cursor to the right-hand column and
> set Text = "door," Location = "Kitchen," and Location2 = "Landing."
> Then you go set the Kitchen's West field and the Landing's East field to
> "Door."
As I said, this is no more than a text editor optimised to a language
like TADS or Inform. Such text editors have not caught on, partly
because they're difficult to make universal across a broad range of
computer systems (whereas tools such as compilers are relatively easy
to spread).
> That's all--no compiling necessary!
You plan to interpret rather than compile? This will have a significant
impact on the running speed of the final game.
> An experienced programmer
> would be able to do that in thirty seconds, and a beginner would find
> the database format much easier to understand than any compiler's text
> source file.
Are you really arguing that the textual example you give above is
easier to follow for beginners than the equivalent code in TADS?
> A great interactive fiction authoring system should be available in six
> to twelve months.
TADS and Inform each took about three years to reach their present
levels of maturity, and represent a very substantial wodge of
practical experience and contributions by many hands. It just isn't
a trivial, or even a six-month problem.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Edan Harel
Jeff Hatch <jeff...@juno.com> writes:
>What would a great interactive fiction authoring system be like?
The human mind...
Well, It would be like a great story teller surrounded by a group of people
interacting together, because, of course, the most truly intelligent,
flexible, able to deal with new input type of storyteller would be the
human mind. Mind you, the human mind is as fast, or as able to store
as much info as a computer but then, you win some, you lose some.
Oh, and you don't have to program a mind :)
Edan
--
"I have yet to see any problem, however complicated, which, when you looked
at it the right way, did not become still more complicated." -Poul Anderson
"For every problem, there is one solution which is simple, neat and wrong."
-H. L. Mencken
Brandon Van Every
Jeff Hatch <jeff...@juno.com> wrote in article
<34139C...@juno.com>...
>
> Perhaps you'd rather create new works of art than improve your set of
> tools. That's understandable, but in the long run a better IF authoring
> system will greatly benefit the genre. Ancient Egyptians carved
> hieroglyphs in stone with chisels, but 19th-Century American authors had
> access to paper, ink, and quill pens. It's no wonder fewer books were
> written in ancient Egypt! Similarly, time-saving new tools for IF
> writers can only increase creative output.
Uh, I think the difference is the printing press, not paper, ink, and quill
pens. The Egyptians had that stuff, where do you think the word "paper"
comes from? (A. Papyrus.) Also, Ptolemey's library burned to the ground,
so it's not certain that they were as un-prolific as you suggest. We
simply don't have access to their works. Broadly speaking, I think my
point is that dissemination of texts is not the same thing as creative
output, and one should be careful not to confuse the technologies of
dissemination with the possibility of creative effort. An awful lot of
nuclear physics was worked out before anyone had computers to do it....
Cheers,
--
Brandon J. Van Every <vane...@blarg.net> DEC Commodity Graphics
http://www.blarg.net/~vanevery Windows NT Alpha OpenGL
------------------------------------------------------------------------
The anvil upon which you hammer another's words is as hard or as soft
as you care to make it. Wherein lies insight?
Brandon Van Every
Neil K. <fake...@anti-spam.address> wrote in article
<fake-mail-080...@van-as-10c03.direct.ca>...
> In article <34139C...@juno.com>, Jeff Hatch <jeff...@juno.com>
wrote:
>
> The problem is that the really interesting parts of IF are the parts
> hardest to code. All those special-case routines that don't form part of
> the library code, etc. It would be one hell of a development system that
> even tried to automate that stuff well. Ask any IF author and he or she
> will tell you that the only puzzles worth implementing are those which
> require custom code beyond anything in any existing library.
This is true of any "novel" programming endeavor. You only get to use
automated tools when the problem domain is extremely well-understood, such
as in accounting software. That's why writing accounting software is
boring. :-)
> Still, that aside, I'd be delighted if someone were really to sit down
> and produce such a timesaving tool. A TADS tool that let you build custom
> verbs without worrying about all the verify routines and order of method
> calls would be great. Or one that had a truly rich object library so you
> could plug in attributes with ease. Or which helped you code more complex
> NPCs.
First there has to be a robust conceptual framework for how those entities
interrelate. Can't save labor if you don't even know what the labor is.
To date, nobody has come to agreement on what "the labor" is. That's the
first step.
> Such a system couldn't address the really complex special-case code, but
> it could save some drudgery by making the framework, the skeleton, of the
> game easy to construct. Thing is, it would be a massive undertaking to do
> well. Which is why, I think, that nobody's ever done it.
It depends on what your personal time tradeoffs are. At a certain level of
scale, I myself would design such tools as I needed 'em. But if the time
to write the tools is greater than the time to produce the game by manual
methods, then it is not worth it. Also, let's say one really wants to
produce the be-all, end-all system. Then it's important to consider the
potential obsolescense of the system. If I write a great system, but by
the time it's done it's obsolete, then it's not worth it. So, the big
question here is what goal you're trying to accomplish. A tool that's good
by hobbyist standards? Or a tool that will re-shape the way the games
industry produces adventure games? You have different levels of quality,
timescale, and interface to deal with here. Are you going to try to make
$$$$ for your efforts? This has a big effect on the feasibility of the
product, how much time you're going to put into it, etc. After all, the
endgame is to make a living doing what you want, instead of shovelling crap
just to make a buck.
Magnus Olsson
In article <5v137m$d...@romulus.rutgers.edu>,
Edan Harel <edh...@romulus.rutgers.edu> wrote:
>Jeff Hatch <jeff...@juno.com> writes:
>
>>What would a great interactive fiction authoring system be like?
>
>The human mind...
>
>Well, It would be like a great story teller surrounded by a group of people
>interacting together,
You mean a role-playing game? Witha a godd gamemaster, a role-playing
session can indeed take on much of the characteristics of IF. There are
of course differences as well...
> because, of course, the most truly intelligent,
>flexible, able to deal with new input type of storyteller would be the
>human mind.
To turn this around: to obtain truly open-ended, "simulationist" IF,
or interactive mythos, would porbably require either a human
storyteller or a Turing-complete AI.
> Mind you, the human mind is as fast, or as able to store
>as much info as a computer but then, you win some, you lose some.
But the human could be assisted by a computer (an RPG game master could
use a computer to keep track of all details of his world).
>Oh, and you don't have to program a mind :)
On the other habnd, you can't duplicate it and distribute it on
floppies either.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
Jeff Hatch
Graham Nelson wrote:
> A cute, easy-to-get-started
> adventure creation system (of which there are very many already)
> is usually crippled by its inability to handle the full flexibility
> needed by designers of even the most modest games. When you have
> that full flexibility, you pretty much have something as powerful
> and necessarily complex as TADS.
I agree. Any system without power and complexity wouldn't be "great,"
now matter how pretty. (Heck, I've never seen a "cute"
adventure-creation system that's *adequate*!) But just because a
system's powerful doesn't mean it can't look nice, too. Another
analogy: I got my first car for just $650. I could have bought a
decent-looking car without an engine for that price, but instead I chose
an incredibly ugly VW bug that ran. I would never trade the performance
for better looks. But I'd rather have both.
I care *more* about flexibility than the average IF writer, as far as I
can tell. Tads's built-in parser bothers me; if Tads is so powerful,
how come the parser can't just be part of the default library? (From my
perspective, your built-in Inform attributes are also less than ideal,
though not as irritating since there's some room left for new
attributes.)
> You seem to be proposing no more than a
> pretty windowed text editor to be glued onto the side of
> an existing system.
> You plan to interpret rather than compile? This will have a significant
> impact on the running speed of the final game.
Nah, there's little point to just prettifying an existing system.
Couldn't hurt, but I don't think it'd be worth the trouble. And I don't
care much about speed, but direct interpretation of a text file would be
intolerable even on a Pentium. I agree with you there!
But I'm not talking about just a text editor; I propose a database-style
program that's in charge of object information. When you type values
into a field on a database, the database doesn't wait until you
recalculate formulas to "interpret" the text characters you typed in.
It stores them immediately in an appropriate format. Similarly, an IF
editor could be designed that would directly "compile" object
information as it's typed in and store it in the appropriate place.
Obviously, since the database and the compiler would need to share
access to object information, you'd have to do more than "paste" this
editor onto something.
> Are you really arguing that the textual example you give above is
> easier to follow for beginners than the equivalent code in TADS?
In a word, yes.
In a paragraph, no. The textual example I gave is ugly and confusing.
But the full-color version with a nice status bar, pull-down menus, and
discrete input fields will be easier. Too, there's a difference between
being able to *follow* the code and being able to *create* it.
Beginners wouldn't even have to know the names of the appropriate object
fields if they use the "database method"! Another plus is that if they
misspelled "Kirchen" as the Location of a Door, the database would warn
them immediately, rather than waiting until they came to the compilation
step. For us experienced programmers, that makes no difference. But
for a newbie, sequential streams of accumulated error messages can be
somewhat daunting.
To sum up my position, the IF genre would be better off with a pretty,
easy-to-use authoring system, if and only if that system had power
equivalent to Tads or Inform. Given that minimal power, the easier to
use the better! C and C++ are far more powerful than Tads or Inform.
But when Tads and Inform were created, more people began writing
interactive fiction. You, sir, are sufficiently intelligent and
sufficiently dedicated to IF to write your own system virtually from
scratch if necessary! (Correct me if I'm wrong.) But most creative
people aren't. I think more people would write IF if it were easier
still.
> It just isn't a trivial, or even a six-month problem.
I agree completely. Technically, I never said it was.
-Rúmil
Thomas Nilsson
Jeff Hatch wrote:
>
> What would a great interactive fiction authoring system be like?
>
> A great interactive fiction authoring system should be a cross between a
> database and a compiler. It should present the attributes of
> user-created "objects" in a table so they're easy to edit.
Although a more visual environment is a very good thing I think this can
only solve part of the problem. Why? Because this can only be used to
define the simple things such as the static environment. Have you tried
to imagine what programming the simple Dam Control panel in Zork/Dungeon
would be like?
To do anything more complex your back at "typing" or "building"
expressions, sequences of statements etc. even though they would be in a
tool where you could find your way around more easily.
So my theory is that these types of systems have not emerged for IF (nor
in great numbers for any computer language really) because the benefits
does not currently greately overcome the trouble it is to develop them.
Another problem that has to be resolved is how to handle to flow of the
story. Most IF has a beginning, a middle and an end. A simple-minded
implementation using a database would be cumbersome to use because you
need to set and reset the "state of the world" to test if your story
plays as you want it to. As an example, I use many short initial, start
sections that set up different situations so that I can test them.
Something similar has to be available.
This is *not* to say I wouldn't want such a system, au contaire. This is
of course the next step forward. I am just saying watch your step, there
might be a large hole there...
Thomas
PS. I have been looking for many years for a system or tool which would
allow one to *define* such an environment, much like the parser and
compiler generators now part of every software engineers toolset, a
programming environment generator, if you will. I have yet to find such
a system, but when I do (or build) I will have hundreds of applications
for it! DS.
--
"Little languages go a long way..." (ThoNi of SoftLab in 1985)
------------------------------------------------------------------------
Thomas Nilsson Phone Int:(+46)13235704 Nat:013-235704
SoftLab Mobile: 070-5617541
Datalinjen 1, S-583 30 LINKÖPING E-mail: th...@softlab.se
SWEDEN http: www.softlab.se, www.rational.com
Alan Conroy
On Sun, 07 Sep 1997 23:36:03 -0700, Jeff Hatch <jeff...@juno.com>
wrote:
>A great interactive fiction authoring system should be a cross between a
>database and a compiler. It should present the attributes of
>user-created "objects" in a table so they're easy to edit.
>Practical Example: Suppose your game has a Kitchen next to a Landing,
>and you want to put a door between them. Your library doesn't have a
>specific Door class, but it has "Obstacle" and "Openable" classes, which
>suffice. You define a "Door" object that's derived from the Openable and
>Obstacle classes. A menu appears, and a portion of your screen shows
>this:
>
> Obj Door COpenable CObstacle
> Cls COpenable CLocal
> Var Text
> Var Location 0
> Fnc Commands
> Var IsOpen 0
> Cls CObstacle
> Var Location2 0
>
<start Adventure Builder pitch...>
Adventure Builder uses exactly this approach. There are two
compilers: 1) a source compiler for algorithmic stuff, and 2) a
database compiler which takes something for input which resembles what
you provided above. I'm sure it is not the only authoring system out
there which does this.
>In a matter of seconds, you move the cursor to the right-hand column and
>set Text = "door," Location = "Kitchen," and Location2 = "Landing."
>Then you go set the Kitchen's West field and the Landing's East field to
>"Door." That's all--no compiling necessary! An experienced programmer
>would be able to do that in thirty seconds, and a beginner would find
>the database format much easier to understand than any compiler's text
>source file.
The Windows IDE for Adventure Builder has a dialog which allows you to
click on/off various boolean attributes, quickly edit quantitative
values, and so on, instead of using a text file (although you can do
that too). That sounds easier even than what you are suggesting.
However, I personally like the requirement that you must still do
something (hit the compile button) to commit the changes, otherwise
you can mess yourself up. But I suppose there could be an optional
"Auto-compile" so long as there was a decent undo feature.
<end Adventure Builder pitch...>
As far as other qualifications for a "great" authoring system.
Shouldn't multi-platform support rank rather highly? I'd like to see
anyone implement an authoring system across a dozen platforms within
6-12 months. I mean, how many people even have ACCESS to a dozen
platforms? Fortunately, Inform (and others) already have this
advantage.
Finally, I think you need to define your audience before you can
really answer the question. Are you targeting techno-geeks like me?
Or are you trying to provide a tool for people with minimal technical
skills? The answer to that, I believe, will have a huge influence on
just what the tool ends up looking like.
- Alan Conroy
Magnus Olsson
In article <01bcbc79$a4f7cfe0$a69f...@hammurabi.blarg.net>,
Brandon Van Every <vane...@blarg.net> wrote:
>
>Jeff Hatch <jeff...@juno.com> wrote in article
><34139C...@juno.com>...
>>
>> Perhaps you'd rather create new works of art than improve your set of
>> tools. That's understandable, but in the long run a better IF authoring
>> system will greatly benefit the genre. Ancient Egyptians carved
>> hieroglyphs in stone with chisels, but 19th-Century American authors had
>> access to paper, ink, and quill pens. It's no wonder fewer books were
>> written in ancient Egypt! Similarly, time-saving new tools for IF
>> writers can only increase creative output.
>
>Uh, I think the difference is the printing press, not paper, ink, and quill
>pens. The Egyptians had that stuff, where do you think the word "paper"
>comes from? (A. Papyrus.) Also, Ptolemey's library burned to the ground,
>so it's not certain that they were as un-prolific as you suggest.
IIRC, the library of Alexandria (built by Ptolemy) is estimated to
have contained on the order of half a million different works - about
the size of a largish library today. To pick nits, most of these works
were by Greek authors, not native Egyptians.
Writing books was just as popular in ancient times as it is now. It was
duplicating them that was the problem.
>Broadly speaking, I think my
>point is that dissemination of texts is not the same thing as creative
>output, and one should be careful not to confuse the technologies of
>dissemination with the possibility of creative effort.
That's true.
> An awful lot of
>nuclear physics was worked out before anyone had computers to do it....
But, on the other hand a large part of contemporary physics would be
impossible without computers. Not impossible to disseminate, impossible
to do, or even to conceive of doing.
For some kinds of creative effort you need the proper tools.
To get back to IF, there are some things - such as realistic NPC's - that
aren't impossible to do today, but prohibitively complicated. Better tools
could lead to better IF.
Graham Nelson
In article <3414B5...@juno.com>, Jeff Hatch
<URL:mailto:jeff...@juno.com> wrote:
>
> ... But just because a
> system's powerful doesn't mean it can't look nice, too. Another
> analogy: I got my first car for just $650. I could have bought a
> decent-looking car without an engine for that price, but instead I chose
> an incredibly ugly VW bug that ran. I would never trade the performance
> for better looks. But I'd rather have both.
Of course, a very fair point. Inform could be improved, in theory,
at once simply by cleaning up odd areas of syntax, judiciously
altering a couple of features of the Z-machine (the run-time format)
and so on. (But the improvements wouldn't make a lot of difference
compared to the upheaval they'd cause.)
> But I'm not talking about just a text editor; I propose a database-style
> program that's in charge of object information. When you type values
> into a field on a database, the database doesn't wait until you
> recalculate formulas to "interpret" the text characters you typed in.
> It stores them immediately in an appropriate format. Similarly, an IF
> editor could be designed that would directly "compile" object
> information as it's typed in and store it in the appropriate place.
> Obviously, since the database and the compiler would need to share
> access to object information, you'd have to do more than "paste" this
> editor onto something.
This is a little more vexed than it sounds. What state of the game
is the designer altering -- the initial state of the game, or the
one that she's currently playing? What if the map connection (say)
is meant to change over time, so that by the time the player reaches
the stage of the game being tested it's appropriate for that
connection to run to the Kitchen, but at the start of the game it
isn't?
Graham Nelson
In article <3414e86f...@news.accessone.com>, Alan Conroy
<URL:mailto:al...@accessone.com> wrote:
>
> Finally, I think you need to define your audience before you can
> really answer the question. Are you targeting techno-geeks like me?
> Or are you trying to provide a tool for people with minimal technical
> skills? The answer to that, I believe, will have a huge influence on
> just what the tool ends up looking like.
Yes. It tends to be people who are prepared to invest the effort
in learning to hack through the arcana, who are prepared to invest
the effort in finishing a worthwhile game. "Minimal technical
skills" people won't be able to write a very good game, I'm afraid,
in any system, just because it's not a routine task to write a
good game.
Where these make-it-easy tools might help is in easing the initial
burden on designers, though. The hope would be that by the time the
game's basics are in place, a designer will be savvy enough to take
off into flights of unassisted coding. I think this often does
happen with TADS or Inform, in fact, though it's a struggle.
Brandon Van Every
> In article <3414B5...@juno.com>, Jeff Hatch
> <URL:mailto:jeff...@juno.com> wrote:
> >
> > ... But just because a
> > system's powerful doesn't mean it can't look nice, too. Another
> > analogy: I got my first car for just $650. I could have bought a
> > decent-looking car without an engine for that price, but instead I
chose
> > an incredibly ugly VW bug that ran. I would never trade the
performance
> > for better looks. But I'd rather have both.
Then you'll have to spend more money. :-)
Brandon Van Every
Alan Conroy <al...@accessone.com> wrote in article
<3414e86f...@news.accessone.com>...
>
> As far as other qualifications for a "great" authoring system.
> Shouldn't multi-platform support rank rather highly? I'd like to see
> anyone implement an authoring system across a dozen platforms within
> 6-12 months. I mean, how many people even have ACCESS to a dozen
> platforms? Fortunately, Inform (and others) already have this
> advantage.
Well, this depends on whether you find Microsoft an acceptable evil or not,
and whether you want to make money or not. From past experience, I'd say
(1) design for portability, (2) defer actual porting until later, (3) pick
a "home" operating system. If there are conflicts between the needs of
different operating systems, the home system wins. (4) don't have endless
discussions with people about portability. You'll lose momentum. Above
all, the important thing is to get the project done in the real world, not
to set up design requirements that will likely go unfulfilled in practice.
Personally, I'd rank portability beyond Win95/NT at about zero. Although
if I knew Java, and I thought I could do the whole thing in Java, I'd use
Java. And in any event, I certainly wouldn't worry about portability until
I'd achieved a 1.0 release. Even things that are "designed for
portability" will reveal places where they're not-so-portable, and unless
you have a lot of experience with all the OS's you're trying to port to,
you're not going to know what those sticky spots are beforehand. It's
better to solve that kind of problem from hindsight.
[All religious discussins about foresight/hindsight in program design to >
/dev/null.
The answer is "It Depends."]
Jeff Hatch
Alan Conroy wrote:
>
> <start Adventure Builder pitch...>
>
> Adventure Builder uses exactly this approach.
[The "approach" he refers to is a mix between a database and a compiler,
which is rather vaguely defined so far.]
> There are two
> compilers: 1) a source compiler for algorithmic stuff, and 2) a
> database compiler which takes something for input which resembles what
> you provided above. I'm sure it is not the only authoring system out
> there which does this.
>
> The Windows IDE for Adventure Builder has a dialog which allows you to
> click on/off various boolean attributes, quickly edit quantitative
> values, and so on, instead of using a text file (although you can do
> that too). That sounds easier even than what you are suggesting.
> However, I personally like the requirement that you must still do
> something (hit the compile button) to commit the changes, otherwise
> you can mess yourself up. But I suppose there could be an optional
> "Auto-compile" so long as there was a decent undo feature.
>
> <end Adventure Builder pitch...>
Sounds interesting, Alan. I've kept track of rec.arts.int-fiction
enough to make sure that there's no widely accepted implementation of a
system that resembles my conception. But I haven't thoroughly
researched every authoring system yet, so I'd never heard of Adventure
Builder. I'll probably take a look at it sometime and see how I like
it...depending on how much time I have. (Is it as powerful as Tads and
Inform? Is parsing built-in or part of the library? I'd appreciate it
if you'd email me a sample source file, and save me some research
effort.)
> As far as other qualifications for a "great" authoring system.
> Shouldn't multi-platform support rank rather highly? I'd like to see
> anyone implement an authoring system across a dozen platforms within
> 6-12 months. I mean, how many people even have ACCESS to a dozen
> platforms? Fortunately, Inform (and others) already have this
> advantage.
I've never worried about multi-platform support much. I figure a Dos or
Windows program is sufficient for at least 60% of the IF writers, with
an Apple version covering most of the rest. If you have a more obscure
operating system, you're probably already used to missing out on some
good products. So I've ranked this ability quite low. It seems I could
be wrong...if anyone has some good statistics about the platforms
available to IF writers, I'd love to hear them!
> Finally, I think you need to define your audience before you can
> really answer the question. Are you targeting techno-geeks like me?
> Or are you trying to provide a tool for people with minimal technical
> skills? The answer to that, I believe, will have a huge influence on
> just what the tool ends up looking like.
I think a system that is just as powerful as Inform and Tads, but easier
to use, would be the system of choice for both techno-geeks and people
with minimal technical skills. Another analogy: Many professional
secretaries have the technical skills to be able to print an attractive
document using a Dos-based word processor. But they prefer the more
visual Windows or Mac-based word processors, just as computer
illiterates do.
When given the choice, though, I'd rather see a tool that's easy for the
techno-geeks to use, since I'm one myself. Example: I'd like to see a
language with syntax that's very similar to C++. I'd guess that some
newbies would be better off learning an established language with a good
pedigree, like C, but mainly I'd prefer it just to make things easier
for the techies.
-Rúmil
Edan Harel
fake...@anti-spam.address (Neil K.) writes:
[snip data-base compiler]
> The problem is that the really interesting parts of IF are the parts
>hardest to code. All those special-case routines that don't form part of
>the library code, etc. It would be one hell of a development system that
>even tried to automate that stuff well. Ask any IF author and he or she
>will tell you that the only puzzles worth implementing are those which
>require custom code beyond anything in any existing library.
Well this is true, to the programmer and to pretty much anyone who's
interested in creating good interesting puzzles and interesting
characters. But I'm still convinced that one can make a good game of IF
without fancy or complex (reletivly speaking) programming. Demon Tomb is
a good example which concentrates on it's writing style and story, bringing
it together with rather ordinary puzzles. Such examples tend to have less
"interactivity" but can still be good IF. There are even examples
of such kind of IF in a "weaker language" (in terms of programming
capabilities... such as AGT. Well, they're buggy sometimes, but they
(sometimes) have pretty good writing...
C.P.Briscoe-Smith
In article <5v137m$d...@romulus.rutgers.edu>,
Edan Harel <edh...@romulus.rutgers.edu> wrote:
>
>Oh, and you don't have to program a mind :)
Of course you do! What do you think all the schools and universities
are there for?
(Of course, a lot more goes into programming a personality into a
brain than just school work, but you get the idea?)
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Edan Harel
cp...@ukc.ac.uk (C.P.Briscoe-Smith) writes:
>In article <5v137m$d...@romulus.rutgers.edu>,
>Edan Harel <edh...@romulus.rutgers.edu> wrote:
>>
>>Oh, and you don't have to program a mind :)
>Of course you do! What do you think all the schools and universities
>are there for?
Ummm..... For show? ;-)
Esa Peuha
In article <5v3300$1me$1...@bartlet.df.lth.se>,
m...@bartlet.df.lth.se (Magnus Olsson) wrote:
> But, on the other hand a large part of contemporary physics would be
> impossible without computers. Not impossible to disseminate, impossible
> to do, or even to conceive of doing.
Do you mean at the experimental or the theoretical level? I can think of
cases where computers are essential at either level, but I wouldn't say
that these are a "large part of contemporary physics".
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Magnus Olsson
In article <8738796...@dejanews.com>,
Esa Peuha <Esa....@helsinki.fi> wrote:
>
>In article <5v3300$1me$1...@bartlet.df.lth.se>,
> m...@bartlet.df.lth.se (Magnus Olsson) wrote:
>> But, on the other hand a large part of contemporary physics would be
>> impossible without computers. Not impossible to disseminate, impossible
>> to do, or even to conceive of doing.
>
>Do you mean at the experimental or the theoretical level? I can think of
>cases where computers are essential at either level, but I wouldn't say
>that these are a "large part of contemporary physics".
Perhaps I should have called it a "significant" or "important" part instead.
With my background, I'm seeing things from the theoretical
side. Before computers, theoretical physics was basically limited to
what you could do with pen and paper - once the equations got more
complicated than that, you were lost. Today, there are entire fields
of research that that would be inconceivable without computers: the
ones where the equations are too difficult to solve, such as lattice
QCD, and the ones where the equations are too difficult even to write
down without computer-algebra systems, such as perturbative quantum
field theory. And then you have all the fields where results are
obtained by simulation rather than by solving a set of equations.
In experimental physics, most experiments in modern particle physics
would be inconceivable without computers selecting the interesting
events in real time, and computers analyzing the mountains of data.
Martin Julian DeMello
Neil K. (fake...@anti-spam.address) wrote:
: In article <34139C...@juno.com>, Jeff Hatch <jeff...@juno.com> wrote:
: > A great interactive fiction authoring system should be a cross between a
: > database and a compiler. It should present the attributes of
: > user-created "objects" in a table so they're easy to edit.
: Well, I don't disagree that such an authoring system would save some
: time. In fact, I wrote a fair bit of simple HyperCard code to output TADS
: code to do just that, a couple years ago. (it's loosely based on the
: HyperCard stack someone put into the if-archive a while back, and my
: version is of no interest to anyone except me because it produces code
: that only works with my libraries.) Once I got the stack working it was of
: some use in throwing basic locations together.
: The problem is that the really interesting parts of IF are the parts
: hardest to code. All those special-case routines that don't form part of
: the library code, etc. It would be one hell of a development system that
: even tried to automate that stuff well. Ask any IF author and he or she
: will tell you that the only puzzles worth implementing are those which
: require custom code beyond anything in any existing library.
: Still, that aside, I'd be delighted if someone were really to sit down
: and produce such a timesaving tool. A TADS tool that let you build custom
: verbs without worrying about all the verify routines and order of method
: calls would be great. Or one that had a truly rich object library so you
: could plug in attributes with ease. Or which helped you code more complex
: NPCs.
: Such a system couldn't address the really complex special-case code, but
: it could save some drudgery by making the framework, the skeleton, of the
: game easy to construct. Thing is, it would be a massive undertaking to do
: well. Which is why, I think, that nobody's ever done it.
I've been thinking of trying something like this. The basic idea is that
writing (or, rather, coding) an IF game can be (roughly) divided into two
parts, 'sketching' and 'painting'. The sketching part basically involves
drawing the [initial] map, defining objects and possibly NPCs and perhaps
writing some of the room prose. Note that this is routine but tedious,
codingwise. The painting part then involves adding all the details,
quirks, interactions etc.
Our proposed environment (I use this term in preference to 'authoring
system') could include
(i) A map-drawing tool, which would output high-level code (Inform/Tads)
(ii) An object-forest editor, in which the initial configuration of the
objects could be specified, and which would run in parallel with the
map editor.
(iii) A VB-style interface, in which said code could then be edited using
a desktop in which separate objects are contained in separate windows,
said windows being called up by clicking on the object from a list.
(iv) A BC-style debugger, with lines of code being highlighted as the
cursor moves over the error window
Basically, the system does no more than simplify and hopefully speed up
some of the more routine tasks involved in writing a game, and is as such
more an environment/editor than an authoring system.
(And yes, if I manage to write it, it will be for Windows - better a
nonportable system than no system at all).
--
Martin DeMello
Remove the sep_field from my address to reply
Jeff Hatch
Thomas Nilsson wrote:
> Although a more visual environment is a very good thing I think this can
> only solve part of the problem. Why? Because this can only be used to
> define the simple things such as the static environment. Have you tried
> to imagine what programming the simple Dam Control panel in Zork/Dungeon
> would be like?
>
> To do anything more complex you're back at "typing" or "building"
> expressions, sequences of statements etc. even though they would be in a
> tool where you could find your way around more easily.
You're right.
Let me show you my original example post again:
Obj Door COpenable CObstacle
Cls COpenable CLocal
Var Text
Var Location 0
Fnc Commands
Var IsOpen 0
Cls CObstacle
Var Location2 0
Here the left-hand column indicates what kind of thing each element is.
That is: the Door is an object, COpenable and CObstacle are the classes
it's built from, and most of the other things are variables. What's
does "Fnc" stand for? It stands for "Function," which means: put your
special procedural source code for the Door here.
Yes, my system can implement objects with complex behavior. But I'll
describe my function-editing scheme in better detail next week.
-Rúmil
LFrench106
>I've never worried about multi-platform support much. I figure a Dos or
>Windows program is sufficient for at least 60% of the IF writers, with
>an Apple version covering most of the rest. If you have a more obscure
>operating system, you're probably already used to missing out on some
>good products. So I've ranked this ability quite low. It seems I could
>be wrong...if anyone has some good statistics about the platforms
>available to IF writers, I'd love to hear them!
Just a tip: keep Linux in your rear view mirror every now and again. It
should be VERY easy to support, particularly if you use XWindows as a
requirement.
Luc French
Member of Narnwatch
General Fool Around the Group
Cameron Kaiser
>I've never worried about multi-platform support much. I figure a Dos or
>Windows program is sufficient for at least 60% of the IF writers, with
>an Apple version covering most of the rest. If you have a more obscure
>operating system, you're probably already used to missing out on some
>good products. So I've ranked this ability quite low. It seems I could
If you write in Inform, your object code can run the gamut of operating
systems. Why, even I with my Commodore 128 could play it.
--
Cameron Kaiser
cdkaiser at concentric dot net (it hasn't helped the spam yet though)
*** visit the Spectre Server at www.sserv.com
*** C64 software lives! www.computerworkshops.home.ml.org
Andrew Plotkin
Cameron Kaiser (cdka...@delete.these.four.words.concentric.net) wrote:
> >I've never worried about multi-platform support much. I figure a Dos or
> >Windows program is sufficient for at least 60% of the IF writers, with
> >an Apple version covering most of the rest. If you have a more obscure
> >operating system, you're probably already used to missing out on some
> >good products. So I've ranked this ability quite low. It seems I could
> If you write in Inform, your object code can run the gamut of operating
> systems. Why, even I with my Commodore 128 could play it.
Better, if you don't like Inform, have your IF system compile to Z-code.
Let me pull my irritableness out of hiding for a moment: Just because
I've written two good Mac IF interpreters, does not mean I want to write
three. Or five. It is *hard* work, and for what? Another engine with the
same interface capacity as all the others. Yes, the engine is different,
but that's just code.
Yes, hard work. Anyone who suggests that it should be trivial to slap the
Max* interface onto a new engine, is invited to try it.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Julian Arnold
Dunno who wrote this. Jeff Hatch I guess:
> >I've never worried about multi-platform support much. I figure a Dos or
> >Windows program is sufficient for at least 60% of the IF writers, with
> >an Apple version covering most of the rest. If you have a more obscure
> >operating system, you're probably already used to missing out on some
> >good products. So I've ranked this ability quite low. It seems I could
> >available to IF writers, I'd love to hear them!
From reading this group for a couple of years I'd say that Acorn users
make up a not insignificant proportion of IF authors and
players--probably on a par with Mac-men and greater than Amiga-folk.
Some big guns too--Graham Nelson (author of Inform and games including
_Curses_ and _Jigsaw_), Neil Brown (_The Wedding_), ct (shoots his mouth
off sometimes :), li'l ol' me (hangs around pretending to be clever).
Also, *part* of the reason for Inform's success is that it, and more
importantly the Z-machine interpreters, is available for such a range of
platforms--even semi-obscure ones.
IMO, any system which restricts itself even to DOS/Windows, is destined
to only be a minor leaguer.
(Of course, if anyone ports a new system to the Mac before Hugo I'll cry
conspiracy.)
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me
from ever completing anything." -- Herman Melville, "Moby Dick"
[ Please reply to jo...@arnod.demon.co.uk ]
Jeff Hatch
Julian Arnold wrote:
>
> Dunno who wrote this. Jeff Hatch I guess:
> > >I've never worried about multi-platform support much.
Yep, that's me.
> Also, *part* of the reason for Inform's success is that it, and more
> importantly the Z-machine interpreters, is available for such a range of
> platforms--even semi-obscure ones.
>
> IMO, any system which restricts itself even to DOS/Windows, is destined
> to only be a minor leaguer.
In my mind, it works the other way: any program that's a major-leaguer
is destined to be ported to other platforms. Once my system is regarded
as the best system available on a PC, obviously I'll be willing to
commit the time and/or money needed to support other platforms. Quality
comes first.
-Rúmil
Julian Arnold
In article <341A31...@juno.com>, Jeff Hatch
<URL:mailto:jeff...@juno.com> wrote:
> Julian Arnold wrote:
> > Also, *part* of the reason for Inform's success is that it, and more
> > importantly the Z-machine interpreters, is available for such a range of
> > platforms--even semi-obscure ones.
> >
> > IMO, any system which restricts itself even to DOS/Windows, is destined
> > to only be a minor leaguer.
>
> In my mind, it works the other way: any program that's a major-leaguer
> is destined to be ported to other platforms. Once my system is regarded
> as the best system available on a PC, obviously I'll be willing to
> commit the time and/or money needed to support other platforms. Quality
> comes first.
Bit of both then. You've got to be flexible with your code so that
porting it isn't too much trouble. I think Kent had to mame a lot of
changes to Hugo's internals for the Acorn port. From your original post
I thought you were saying "It's for DOS/Windows, fuck everyone else."
This is obviously not the case though.
BTW, is your system going to be freeware or commercial?
Robert Masenten
erky...@netcom.com (Andrew Plotkin) writes:
> Better, if you don't like Inform, have your IF system compile to Z-code.
>
Z-code. The Z-machine imposes some fairly tight memory limitations as
among other restrictions; I can easily imagine language features
which would be difficult or impossible to implement on it.
For example, I doubt that a TADS-to-Z compiler could be written.
Of course, we haven't seen the language in question, so it may be
perfectly feasible to retarget the compiler to Z-code-- but I don't
think it's reasonable to demand that all new I-F systems be
shoehorned into the Z-machine.
> Let me pull my irritableness out of hiding for a moment: Just because
> I've written two good Mac IF interpreters, does not mean I want to write
> three. Or five. It is *hard* work, and for what? Another engine with the
> same interface capacity as all the others. Yes, the engine is different,
> but that's just code.
Perhaps the correct solution would be to create a well-defined
(and ideally platform-independent) interface between the engine and the
front-end, which interpreter authors could then write to?
(I'm not suggesting that this is a trivial task; but I think that
the interface needs of I-F games are well enough defined that it
should be possible. Am I missing some obvious complication?)
Robert Masenten
Andrew Plotkin
Robert Masenten (mase...@hans.math.upenn.edu) wrote:
> erky...@netcom.com (Andrew Plotkin) writes:
> > Better, if you don't like Inform, have your IF system compile to Z-code.
> >
>
> This assumes that it's *possible* to compile his new language to
> Z-code. The Z-machine imposes some fairly tight memory limitations as
> among other restrictions; I can easily imagine language features
> which would be difficult or impossible to implement on it.
Actually, the memory limitation is the only significant one. But yes.
> For example, I doubt that a TADS-to-Z compiler could be written.
True.
> > Another engine with the
> > same interface capacity as all the others. Yes, the engine is different,
> > but that's just code.
> Perhaps the correct solution would be to create a well-defined
> (and ideally platform-independent) interface between the engine and the
> front-end, which interpreter authors could then write to?
That is certainly a good solution.
> (I'm not suggesting that this is a trivial task; but I think that
> the interface needs of I-F games are well enough defined that it
> should be possible. Am I missing some obvious complication?)
Only that it's very hard to enforce. Everybody would wind up making some
teeny little non-portable extension in their engine, and eventually there
would be no benefit left.
Mark J Musante
Andrew Plotkin (erky...@netcom.com) wrote:
> Robert Masenten (mase...@hans.math.upenn.edu) wrote:
> > For example, I doubt that a TADS-to-Z compiler could be written.
>
> True.
Are you saying you believe he doubts it, or are you agreeing with his
doubt?
There is only one restriction (admittedly off the top of my head) that
I can think of -- TADS's ability to create objects on the fly -- that
would cause a problem. True, Inform allows this, but (correct me
if I'm wrong) the game author must specify the maximum number of objects
that can be created for a given class BECASE Inform pre-creates them as
part of the story file and just allocates new ones as the *.create()
method is called.
So there is a work-around for it although it would require a change to the
TADS game source files.
It's times like these that I wish I were independantly wealthy and didn't
have an Honest Job take up most of my time. :-( I'd love to try to write
a TADS-to-Z-machine compiler. Or would that be a cross-compiler? :-)
-=- Mark -=-
Jeff Hatch
Julian Arnold wrote:
> Bit of both then. You've got to be flexible with your code so that
> porting it isn't too much trouble. I think Kent had to mame a lot of
> changes to Hugo's internals for the Acorn port. From your original post
> I thought you were saying "It's for DOS/Windows, fuck everyone else."
> This is obviously not the case though.
Oh, I would never say that! I wouldn't swear in such a public forum.
:-)
Seriously, DOS and Windows are two very different platforms. In my
mind, this has always been a Windows program, but I've been mostly
developing it in Dos. The only possible issues are replacing the
Microsoft Foundation Classes calls for a system that doesn't have a
Microsoft C++ compiler avaiable, and making sure that my program is fast
enough and uses little enough memory for feeble platforms. (Right now,
I haven't dealt with some major technical issues related to multiple
inheritance and virtual functions. Translation: My system is very
powerful, but not fast enough for a 386, or for a host of other
platforms.)
> BTW, is your system going to be freeware or commercial?
Commercial.
-Rúmil
Andrew Plotkin
Mark J Musante (olo...@world.std.com) wrote:
> Andrew Plotkin (erky...@netcom.com) wrote:
> > Robert Masenten (mase...@hans.math.upenn.edu) wrote:
> > > For example, I doubt that a TADS-to-Z compiler could be written.
> >
> > True.
> Are you saying you believe he doubts it, or are you agreeing with his
> doubt?
The latter. (I hope I don't have to say that I believe everyone's
statement about their own opinions!)
> There is only one restriction (admittedly off the top of my head) that
> I can think of -- TADS's ability to create objects on the fly -- that
> would cause a problem.
For some reason, people have a very limited view of what it means to
implement one system in another. (Sorry for harshin' on you, but I've
heard similar objections about an Inform-to-Java compiler, and they don't
make much sense either.)
Why would this compiler have to represent a TADS object as an Inform
object? TADS already runs on my Macintosh CPU, which has *no* provisions
for native object creation; it can only manipulate bytes. The Z-machine
virtual CPU can also manipulate bytes. End of story, except for the
programming work. :)
(Similarly, in an Inform-to-Java compiler, you wouldn't want to represent
Inform objects as Java objects. Just allocate a big byte array, and
generate JVM code to manipulate it the same way a Z-machine interpreter
manipulates the byte array that is its memory.)
The problem is just memory. TADS is pretty complicated, and TADS game
files tend to be larger than Z-machine game files. You'd have to fit all
the memory used by the runtime system *and* the game into 64K of
Z-machine RAM. (That assuming you could store all the TADS string
constants into Z-machine ROM. The TADS system wasn't designed to separate
constant strings from dynamic data; I believe both are stored together in
a TADS object.)
Mark J Musante
Andrew Plotkin (erky...@netcom.com) wrote:
> The problem is just memory. TADS is pretty complicated, and TADS game
> files tend to be larger than Z-machine game files. You'd have to fit all
> the memory used by the runtime system *and* the game into 64K of
> Z-machine RAM. (That assuming you could store all the TADS string
> constants into Z-machine ROM. The TADS system wasn't designed to separate
> constant strings from dynamic data; I believe both are stored together in
> a TADS object.)
Well, you wouldn't have to store the objects in the Z-Machine the same
way that TADS stores them in memory.
But I agree with you about the TADs run-time: anyone who wanted to port
it would have to re-write it in Z-code (if that's the correct term).
However, I don't see it as being any different (from a conceptual
point of view) than the Inform parser.
-=- Mark -=-
Andrew Plotkin
Mark J Musante (olo...@world.std.com) wrote:
> Andrew Plotkin (erky...@netcom.com) wrote:
> > The problem is just memory. TADS is pretty complicated, and TADS game
> > files tend to be larger than Z-machine game files. You'd have to fit all
> > the memory used by the runtime system *and* the game into 64K of
> > Z-machine RAM. (That assuming you could store all the TADS string
> > constants into Z-machine ROM. The TADS system wasn't designed to separate
> > constant strings from dynamic data; I believe both are stored together in
> > a TADS object.)
> Well, you wouldn't have to store the objects in the Z-Machine the same
> way that TADS stores them in memory.
That's what I meant by "storing all the TADS constants into Z-machine
ROM." That's a minimal first step; otherwise, the dynamic memory needed
for a TADS game is pretty much equal to the size of the TADS game file.
(TADS interpreters can choose to cache information on disk, which is how
they play large games on 640K machines. But even the extended Z-machine
save opcodes don't allow you to write data to a specific location in a
file. So you'd probably have to write a separate cache file for *each game
object*. Yowza.)
> But I agree with you about the TADs run-time: anyone who wanted to port
> it would have to re-write it in Z-code (if that's the correct term).
> However, I don't see it as being any different (from a conceptual
> point of view) than the Inform parser.
It's not conceptually any different. I'm saying that it probably requires
more than 64K of RAM.
Edan Harel
erky...@netcom.com (Andrew Plotkin) writes:
>> > > For example, I doubt that a TADS-to-Z compiler could be written.
>> >
>> > True.
>> Are you saying you believe he doubts it, or are you agreeing with his
>> doubt?
>The latter. (I hope I don't have to say that I believe everyone's
>statement about their own opinions!)
I agree that you hope that you don't have to say that you believe
everyone's statement about their own opinions. But that's only
my opinion. :)
Julian Arnold
In article <341CAB...@juno.com>, Jeff Hatch
<URL:mailto:jeff...@juno.com> wrote:
> Julian Arnold wrote:
>
> > Bit of both then. You've got to be flexible with your code so that
> > porting it isn't too much trouble. I think Kent had to mame a lot of
> > changes to Hugo's internals for the Acorn port. From your original post
> > I thought you were saying "It's for DOS/Windows, fuck everyone else."
> > This is obviously not the case though.
>
> Oh, I would never say that! I wouldn't swear in such a public forum.
> :-)
But it's big and clever! You don't know what you're missing!
> > BTW, is your system going to be freeware or commercial?
>
> Commercial.
Oo-er. The thing is, even if your system is only ein bisschen better
than Inform/TADS (I've noticed you daren't compare it to Hugo :) people
aren't going to frok out cash when these other systems are free.
Specially as the products which these tools help create have virtually
no commercial value.
Andrew Plotkin
Dan Shiovitz (scy...@u.washington.edu) wrote:
> The bounded-vs-unbounded memory model makes a surprising difference, I
> think.
Not really. The Mac versions run in a bounded memory model. If the fixed
memory size isn't big enough, you have to use caching or else not play
the game. But if it *is* big enough, there's no problem either way. (Of
course "big enough" is over a megabyte, not 64K.)
> You can't use lists (and there's no easy way for a compiler to
> translate those lists into arrays, I don't think), you can't
> dynamically add vocabulary, you can't dynamically create objects,
> umm.. stuff like that.
Huh? None of this is true. You can dynamically do anything in Inform
until you run out of Z-machine memory. Lisp is as dynamic as it gets, and
I wrote "Lists".
You just have to write your own memory manager code.
Dan Shiovitz
In article <EGK4G...@world.std.com>,
Mark J Musante <olo...@world.std.com> wrote:
>Andrew Plotkin (erky...@netcom.com) wrote:
>> The problem is just memory. TADS is pretty complicated, and TADS game
>> files tend to be larger than Z-machine game files. You'd have to fit all
>> the memory used by the runtime system *and* the game into 64K of
>> Z-machine RAM. (That assuming you could store all the TADS string
>> constants into Z-machine ROM. The TADS system wasn't designed to separate
>> constant strings from dynamic data; I believe both are stored together in
>> a TADS object.)
>
>Well, you wouldn't have to store the objects in the Z-Machine the same
>way that TADS stores them in memory.
>
>it would have to re-write it in Z-code (if that's the correct term).
>However, I don't see it as being any different (from a conceptual
>point of view) than the Inform parser.
The bounded-vs-unbounded memory model makes a surprising difference, I
think. You can't use lists (and there's no easy way for a compiler to
translate those lists into arrays, I don't think), you can't
dynamically add vocabulary, you can't dynamically create objects,
umm.. stuff like that. I was thinking about doing it myself for a
while, but decided there really wasn't enough demand for it, since
what you'd end up with is a language that looked kinda like TADS but
wasn't, and it would probably be easier just to write a new language
that compiled to ZCode that looked like TADS.
> -=- Mark -=-
--
Dan Shiovitz :: scy...@u.washington.edu :: sh...@cs.washington.edu
..................................................................
"Alas, I do not rule the world and that, I am afraid, is the story
of my life: always a godmother, never a God." -- Fran Lebowitz
...http://weber.u.washington.edu/~scythe/home.html................
Mark J Musante
Andrew Plotkin (erky...@netcom.com) wrote:
> Dan Shiovitz (scy...@u.washington.edu) wrote:
>
> > The bounded-vs-unbounded memory model makes a surprising difference, I
> > think.
>
> memory size isn't big enough, you have to use caching or else not play
> the game.
>
> > You can't use lists (and there's no easy way for a compiler to
> > translate those lists into arrays, I don't think), you can't
> > dynamically add vocabulary, you can't dynamically create objects,
> > umm.. stuff like that.
>
> until you run out of Z-machine memory. Lisp is as dynamic as it gets, and
> I wrote "Lists".
Well, at least we agree on this. :-) But you also said, about writing
a TADS parser under the Z-machine:
> I'm saying that it probably requires more than 64K of RAM.
I'm going to go away & think about this for a while...
-=- Mark -=-
Den of Iniquity
On Fri, 12 Sep 1997, Julian Arnold wrote:
>Dunno who wrote this. Jeff Hatch I guess:
>> >I've never worried about multi-platform support much. I figure a Dos or
>> >Windows program is sufficient for at least 60% of the IF writers, with
>> >an Apple version covering most of the rest.
>From reading this group for a couple of years I'd say that Acorn users
>make up a not insignificant proportion of IF authors and
>players--probably on a par with Mac-men and greater than Amiga-folk.
Do not underestimate the power of the Amiga-folk. :)
Part of the popularity of i-f to Acorn users has got to be the coverage it
got in one of the Acorn magazines (you'll forgive me for not knowing which
one). Maybe we Amigans could persuade one or two of the more popular Amiga
mags to run a favourable article, maybe stick some games, langauges and
interpreters on the cover CD. We even have at least the interest of one
major contributor to CU Amiga (are you listening, Jason Compton?).
Persuade them to run monthly tutorial on programming in
(Inform/TADS/Hugo/Alan - ah, I can see that might be problematic).
Whaddayou say, amigos?
--
Den [A1200/030/50MHz | 2.5Gb HD | 2+7.5Mb (ks 3.0/3.1 in fast) | M1428S]
(my comp.sys.amiga .sig :)
Branko Collin
On Wed, 24 Sep 1997 15:13:07 +0100, Den of Iniquity <dms...@york.ac.uk> wrote
The Amiga mag I used to write for went belly up. But before that I had
already taken the opportunity to mention the IF-archive and Inform in
an article (see http://www.xs4all.nl/~collin/teksten.html).
--
Branko Collin - col...@xs4all.nl
"ze had niets in de gaten / ze sliep zo diep en stil
heb ik haar laat verlaten / twas ochtend twee april"
- Jaap Fisher
Jouni Alkio
>On Fri, 12 Sep 1997, Julian Arnold wrote:
>
>>Dunno who wrote this. Jeff Hatch I guess:
>>> >I've never worried about multi-platform support much. I figure a Dos or
>>> >Windows program is sufficient for at least 60% of the IF writers, with
>>> >an Apple version covering most of the rest.
>
>>From reading this group for a couple of years I'd say that Acorn users
>>make up a not insignificant proportion of IF authors and
>>players--probably on a par with Mac-men and greater than Amiga-folk.
>
>Do not underestimate the power of the Amiga-folk. :)
And don´t forget the Atari androids, either!
The reason I play IF is because I _can_ (at least most of it, the TADS
and almost all Inform games).
Greetings, Jouni
Jason Compton
Branko Collin (col...@xs4all.nl) wrote:
: >one). Maybe we Amigans could persuade one or two of the more popular Amiga
: >mags to run a favourable article, maybe stick some games, langauges and
: >interpreters on the cover CD. We even have at least the interest of one
: >major contributor to CU Amiga (are you listening, Jason Compton?).
: >Persuade them to run monthly tutorial on programming in
: >(Inform/TADS/Hugo/Alan - ah, I can see that might be problematic).
: >
: >Whaddayou say, amigos?
:
: The Amiga mag I used to write for went belly up. But before that I had
: already taken the opportunity to mention the IF-archive and Inform in
: an article (see http://www.xs4all.nl/~collin/teksten.html).
Well, I've already done some articles on text gaming (and run another one)
in Amiga Report, and I've had a proposal and even a one-page preview of a
text game feature on the editor's desk at CU for months now. I'm still
trying to push it through.
A tutorial on Inform/etc. would be harder since I don't have a clue how to
use them. Someone else would have to step in for something like that.
--
Jason Compton jcom...@xnet.com
Editor-in-Chief, Amiga Report Magazine Anchor, Amiga Legacy
http://www.cucug.org/ar/ http://www.xnet.com/~jcompton/
There are only dreams... ...like any other.
Richard H. Poser II
On 24-Sep-97 10:13:07 in response to Den of Iniquity, I stopped lurking and
replied to the following:
>On Fri, 12 Sep 1997, Julian Arnold wrote:
>>Dunno who wrote this. Jeff Hatch I guess:
>>> >I've never worried about multi-platform support much. I figure a Dos or
>>> >Windows program is sufficient for at least 60% of the IF writers, with
>>> >an Apple version covering most of the rest.
>>From reading this group for a couple of years I'd say that Acorn users
>>make up a not insignificant proportion of IF authors and
>>players--probably on a par with Mac-men and greater than Amiga-folk.
>Do not underestimate the power of the Amiga-folk. :)
Definitely not!!
>Part of the popularity of i-f to Acorn users has got to be the coverage it
>got in one of the Acorn magazines (you'll forgive me for not knowing which
>one). Maybe we Amigans could persuade one or two of the more popular Amiga
>mags to run a favourable article, maybe stick some games, langauges and
>interpreters on the cover CD. We even have at least the interest of one
>major contributor to CU Amiga (are you listening, Jason Compton?).
>Persuade them to run monthly tutorial on programming in
>(Inform/TADS/Hugo/Alan - ah, I can see that might be problematic).
Could be problematic...(But could probably be done - not sure how)
>Whaddayou say, amigos?
I'm working on the beginings of a Graphical User Interface for Inform,
hopefully I'll be done more sooner then later.
Since I'm also the porter for Amiga Inform, I plan to include this
interface in the Inform compiler which will act like the original when
used from the command line but has a WB interface when started from an
icon on the Workbench.
Happy IF Writing and Playing (Even though I wom't have much time while
working on the above project :^)
Richard H. Poser II (The Next Regeneration) <mailto:who...@missingpiece.com>
--
The Whomiga Times: http://www.missingpiece.com/whomiga
Doctor Who Pinball: http://www.missingpiece.com/pinball/drwho.html
Selected RADW Links: http://www.missingpiece.com/RADW
--
Official RADW Birthday Clearinghouse / Team AMIGA / IRC: Whomiga
Phil Goetz
In article <ant12212...@arnod.demon.co.uk>,
Julian Arnold <piss...@having.too.much.spam> wrote:
>
>From reading this group for a couple of years I'd say that Acorn users
>make up a not insignificant proportion of IF authors and
>players--probably on a par with Mac-men and greater than Amiga-folk.
>_Curses_ and _Jigsaw_), Neil Brown (_The Wedding_), ct (shoots his mouth
>off sometimes :), li'l ol' me (hangs around pretending to be clever).
Pardon my ignorance... Having never seen an Acorn, nor an Acorn
dealer, nor an Acorn ad, nor an ad for Acorn software, I assumed
Acorns were some old, obsolete, and dying computer from the early
1980's. Something like the Atari 800. Is there still an Acorn
computer? Do they still produce new machines? What sort of
capabilities do they have? Does anyone have statistics on how many
Acorns are out there, and where?
Patrick Kellum
For some reason, Phil Goetz was chatting and out came these words of greatness:
>Pardon my ignorance... Having never seen an Acorn, nor an Acorn
>dealer, nor an Acorn ad, nor an ad for Acorn software, I assumed
>Acorns were some old, obsolete, and dying computer from the early
>1980's. Something like the Atari 800. Is there still an Acorn
>computer? Do they still produce new machines? What sort of
>capabilities do they have? Does anyone have statistics on how many
>Acorns are out there, and where?
I've wondered the same thing for a while (I'm not curious enough to search
for the answer though, I'm rather lazy). As far as I can figure, they're
a Risc based system that doesn't allow "." in the filenames. Anyone got a
good URL for the answer?
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
"Pity there are no Martians to witness the spectacle of a kind of 15-foot
beach ball suddenly falling out of the sky and bouncing all about."
- Description of the Mars Pathfinder landing on Mars.
From a New York Times News Service story by John Noble Wilford
Magnus Olsson
In article <60i77l$k2a$1...@neko.syix.com>,
Patrick Kellum <pat...@syix.com> wrote:
>For some reason, Phil Goetz was chatting and out came these words of greatness:
>
> >Pardon my ignorance... Having never seen an Acorn, nor an Acorn
> >dealer, nor an Acorn ad, nor an ad for Acorn software, I assumed
> >Acorns were some old, obsolete, and dying computer from the early
> >1980's. Something like the Atari 800. Is there still an Acorn
> >computer? Do they still produce new machines? What sort of
> >capabilities do they have? Does anyone have statistics on how many
> >Acorns are out there, and where?
>
>I've wondered the same thing for a while (I'm not curious enough to search
>for the answer though, I'm rather lazy). As far as I can figure, they're
>a Risc based system that doesn't allow "." in the filenames. Anyone got a
>good URL for the answer?
I don't have a URL, sorry, but I think the reason many people haven't
heard of them is that Acorn don't market their machines very
forcefully outside Britain. Actually, that's a bit of an
understatement - I don't think they market them at all outside
of Britain. I suppose you could buy one via mail order.
I bought an Acorn Atom kit computer by mail order from them in
1982. That was a small, 6502 based machine with a whopping 12 Kb of
RAM. The current Archimedes is a RISC machine with a little more power
than that... AFAIK, they still make them.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
Chris Marriott
In article <fake-mail-270...@van-52-0303.direct.ca>, "Neil K."
<fake...@anti-spam.address> writes
> Never been to the UK, I presume. :)
>
> http://www.acorn.com/acorn/
I do live in the UK, Neil, and I'm sure you'll agree that Acorn aren't
exactly a "mass market" machine. They are basically used in one field,
and one field alone - the schools market. If you look in a typical high
street shop you'll see shelves full of PC software, but no trace of
Acorn software.
Chris
----------------------------------------------------------------
Chris Marriott, Microsoft Certified Solution Developer.
SkyMap Software, U.K. e-mail: ch...@skymap.com
Visit our web site at http://www.skymap.com
Erik Max Francis
Neil K. wrote:
> > Pardon my ignorance... Having never seen an Acorn, nor an Acorn
> > dealer, nor an Acorn ad, nor an ad for Acorn software [...]
>
> Never been to the UK, I presume. :)
>
> http://www.acorn.com/acorn/
I've asked the question as well (also never having been to the UK) on
this newsgroup. I think it's funny that the Acron architecture is
frequently mentioned here -- even though it obviously doesn't have
anything to directly do with interactive fiction -- presumably because
it just so happens that some of the interactive fiction authors and
development system authors are also Acorn users. Whether that's a direc
consequence of them being in the UK or not I couldn't tell.
But I'm always interested in weird (or at least unfamiliar!) computer
systems. Can you tell me what it is about the Acorn that you like (and
don't like)?
--
Erik Max Francis, &tSftDotIotE / mailto:m...@alcyone.com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm://+37.20.07/-121.53.38
\
"After each war there is a little / less democracy to save."
/ Brooks Atkinson
ct
In article <fake-mail-270...@van-52-0236.direct.ca>, Neil K.
> In article <342D54D2...@alcyone.com>, Erik Max Francis
> <m...@alcyone.com> wrote:
>
> > I think it's funny that the Acron architecture is
> > frequently mentioned here. [snip] Whether that's a direct
> > consequence of them being in the UK or not I couldn't tell.
> Hm. Well, here are some possible starting points for conjecture:
[Snipped - effectively intellectual snobbery]
> - Graham, as Inform's creator, has been quietly evangelical about
> promoting Inform with Acorn users.
(This could be seen as a failing, on other platforms, on other people's
part, rather than a major advantage for Acorns; Graham's hardly been
quiet in his evangelism, anyway.)
> - IF as a genre is not about market dominance and popularity contests -
> it's about something you enjoy for its own sake. Acorns are not about
> market dominance either. They're both about niches.
Perhaps 'Using Acorn computers' and 'Enjoying text adventures' are echos of
the same thing - good taste?
regards, ct
Julian Arnold
> I've asked the question as well (also never having been to the UK) on
> this newsgroup. I think it's funny that the Acron architecture is
> frequently mentioned here -- even though it obviously doesn't have
> anything to directly do with interactive fiction -- presumably because
> it just so happens that some of the interactive fiction authors and
> development system authors are also Acorn users. Whether that's a direc
Not really. If you use an Acorn chances are you live in the UK (with
Germany and NZ being the other main possibilities, I think). However
the reverse is certainly not true, although as Acorn is the biggest (?)
name in computers in schools most people below a certain age will
probably have had some exposure.
> But I'm always interested in weird (or at least unfamiliar!) computer
> systems. Can you tell me what it is about the Acorn that you like (and
> don't like)?
Hm, without wanting to start one of those system wars, use Windows, then
use RISC OS, then don't look back. :)
The main thing I don't like about them is that they're almost completely
lacking in entertainment software (ie, games) and those funky add-on
cards PC users get to play with, like the 3dfx card, etc. (this last
could've been solved more than 2 years ago, but it was not to be). :(
Whether the pros really outweigh the cons, I don't know. There are
undoubtedly more technical arguments on both sides (cue StrongARM vs.
Pentium performance tables).
Neil Brown
At 11:47:46 on Sat, 27 Sep 1997, Erik Max Francis wrote:
>Neil K. wrote:
>
>> > Pardon my ignorance... Having never seen an Acorn, nor an Acorn
>> > dealer, nor an Acorn ad, nor an ad for Acorn software [...]
>>
>> Never been to the UK, I presume. :)
>>
>> http://www.acorn.com/acorn/
>
>this newsgroup. I think it's funny that the Acron architecture is
>frequently mentioned here -- even though it obviously doesn't have
>anything to directly do with interactive fiction -- presumably because
>it just so happens that some of the interactive fiction authors and
>development system authors are also Acorn users. Whether that's a direc
>consequence of them being in the UK or not I couldn't tell.
>
>systems. Can you tell me what it is about the Acorn that you like (and
>don't like)?
Like: ease of use, and the fact that Acorns don't become obsolete in the
space of a year. (My A3000 is seven years old and still going strong.
Well, strongish.) I much prefer the RiscOS desktop to Windows 3.11 - the
style, and the fact that it seems to run quicker, even when using a
slower processor. Haven't seen Windows 95 or the Mac desktop, so I can't
commend on those. Also, Acorn software generally has a higher code
density - my memory might be playing tricks on me, but I seem to
remember the DOS port of Inform coming to 600k+. The Acorn port is 250k.
This means that an Acorn doesn't need as much RAM or hard drive space to
install and run similar software to that on a PC.
Dislike: cost of hardware is higher than in PC market. Software lacking
in some areas. Games market almost non-existant. Oh, and you also get a
few UK PC users saying things like "Acorns are just for education" in a
really patronising manner. :-(
(Didn't we have a discussion like this at the start of the year?)
- NJB
Neil Brown
At 12:55:51 on Sat, 27 Sep 1997, Neil K. wrote:
> Hm. Well, here are some possible starting points for conjecture:
>
>believe, in UK universities.
Perhaps that should be rephrased: "Acorn users here are currently at, or
have once been to, university".
> - I believe people brought up with an upper-tier UK education are more
>likely than their North American counterparts to be trained in and have an
>appreciation for writing and literature. (I note that all academic UK
>posters to this group are from universities, notably Oxford and York. And
>not from, say, modest local polytechnics.)
Erm... until I graduated in June, I went to a modest local ex-poly
(University of Central England - ex Birmingham Poly). I didn't post from
UCE because it didn't have any news facilities. Perhaps I can suggest
another point here - most Acorn users gravitate towards the larger, 'red
brick' universities. After four years at UCE, I only knew of one other
person who owned an Acorn, but I know of lots of Oxford and ex-Oxford
Acorn users.
> - Graduate students and younger lecturers are of the right age to
>remember the golden age of text games in the 1980s, and probably get all
>misty-eyed and nostalgic over it.
I dabbled with adventures in the 1980s but I don't remember any golden
age.
> - Graham, as Inform's creator, has been quietly evangelical about
>promoting Inform with Acorn users. (eg: including Inform and Inform games
>on Acorn CD collections, etc.)
Very true.
Another point to add is that the Acorn games scene is a bit of a joke,
so perhaps that's one reason why IF receives more attention in Acorn
circles.
- NJB
Magnus Olsson
In article <NTiHBCAR...@highmount.demon.co.uk>,
Neil Brown <ne...@this.address.is.fake> wrote:
>Perhaps I can suggest
>another point here - most Acorn users gravitate towards the larger, 'red
>brick' universities. After four years at UCE, I only knew of one other
>person who owned an Acorn, but I know of lots of Oxford and ex-Oxford
>Acorn users.
This is totally off-topic, but doesn't the term "red brick" refer to
the English universities that were founded during the Victorian era,
that is, excluding Oxbridge and Durham as well as the newer "upstarts"?
Chris Marriott
In article <rmPecFAl...@highmount.demon.co.uk>, Neil Brown
<ne...@this.address.is.fake> writes
> Haven't seen Windows 95 or the Mac desktop, so I can't
>commend on those.
How can you "not have seen" Windows 95? Have you lived at the bottom of
a coal mine since August 95? When I walk down my local high street I
probably see a dozen Windows 95 machines in shop windows!
Graham Nelson
In article <60j41f$kb5$1...@bartlet.df.lth.se>, Magnus Olsson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
>
> I bought an Acorn Atom kit computer by mail order from them in
> 1982. That was a small, 6502 based machine with a whopping 12 Kb of
> RAM. The current Archimedes is a RISC machine with a little more power
> than that... AFAIK, they still make them.
I had an Atom, too -- a bottom of the range one, with only 2K,
but after a year or two I'd managed to upgrade it to 12. I had
the circuit diagram pinned to my wall (hey, that was how much fun
it was being a geek teenager in the 80s) and it was the last
machine I ever owned where you could actually see exactly how it
worked, and how it would go wrong if you cut any particular track
on the PCB -- there were no mysterious black boxes called just "ULA"
in those days.
The current Acorn model is the Risc PC, and it made the cover of
Byte magazine as the fastest thing since sliced bread, as did the
Archimedes in its day. My StrongARM RiscPC was substantially
better than a Pentium Pro-powered PC until about last month, when
the clock speeds of the latter went up another notch. You can't
own the world's fastest desktop computer for more than about six
months these days... so I'm back in the slip-stream again.
You'll be pleased to know the basic operating system design of
the Acorn Atom lives on in the Risc PC, though. Commands are
entered at the same * prompt: *LOAD, *SAVE, *CAT, they're all
still in there, as are the OSWRCH and OSRDCH vectors, and...
Oh dear. I shall come out in nostalgic acne in a moment.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Nick
On Sat, 27 Sep 1997, Chris Marriott wrote:
> I do live in the UK, Neil, and I'm sure you'll agree that Acorn aren't
> exactly a "mass market" machine. They are basically used in one field,
> and one field alone - the schools market. If you look in a typical high
> street shop you'll see shelves full of PC software, but no trace of
> Acorn software.
> Chris
comp.sys.acorn.advocacy, but it isn't true that acorns are only used in
the schools market. They are found in significant numbers in HE and in
less significant numbers in many other areas.
Nick
Giovanni Riccardi
Magnus Olsson wrote:
> I don't have a URL, sorry, but I think the reason many people haven't
> heard of them is that Acorn don't market their machines very
> forcefully outside Britain. Actually, that's a bit of an
> understatement - I don't think they market them at all outside
> of Britain. I suppose you could buy one via mail order.
Some times ago I noticed an italian distributor importing Acorn machines
from Britain...
--
`'´
(. .)
---oOO-- (_) --OOo------------------------------------
"How do you know I'm mad?"
said Alice. "You must be,"
Giovanni Riccardi said the Cat "or you
g.ric...@speednet.it wouldn't have come here."
Terracina Italy
- L. Carrol "Alice's
Adventures in Wonderland"
Visit P.O.V. Online, a place for your stories & poems:
http://www.geocities.com/Athens/Delphi/8758/index.html
------------------------------------------------------
Graham Nelson
> - Graham, as Inform's creator, has been quietly evangelical about
> promoting Inform with Acorn users. (eg: including Inform and Inform games
> on Acorn CD collections, etc.)
Quietly? QUIETLY? Inform 6.14 is on the Acorn User cover CD
for December, incidentally, complete with HTML Designer's Manual.
In fact, more is true: Inform would not exist at all if TADS had
been ported to the Acorn (at that time, 1993, it hadn't been and
source code was somewhat restricted-access, as an entirely
understandable measure of caution on the part of TADS's authors --
let's not start _that_ row again). I had to write Inform in order
to write Curses, and I had to write Curses to make good use of
Inform, and...
Neil Brown
At 11:30:28 on Sun, 28 Sep 1997, Chris Marriott wrote:
>In article <rmPecFAl...@highmount.demon.co.uk>, Neil Brown
><ne...@this.address.is.fake> writes
>> Haven't seen Windows 95 or the Mac desktop, so I can't
>>commend on those.
>How can you "not have seen" Windows 95? Have you lived at the bottom of
>a coal mine since August 95?
No mate, I've lived in Hednesford, which is almost the same. My old uni
only had Windows 3.11, because the technical services people refused to
support 95 (don't ask me why), and my Dad's PC only has 3.11 as well.
>When I walk down my local high street I
>probably see a dozen Windows 95 machines in shop windows!
Even in the big towns I go to (Walsall, Birmingham) I don't see Windows
95 in shop windows. I know of a few computer software shops in B'ham,
but they're on the outskirts of the city centre.
- NJB
-
>
> > I've asked the question as well (also never having been to the UK) on
> > this newsgroup. I think it's funny that the Acron architecture is
> > frequently mentioned here -- even though it obviously doesn't have
> > anything to directly do with interactive fiction -- presumably because
> > it just so happens that some of the interactive fiction authors and
> > development system authors are also Acorn users. Whether that's a direc
> > consequence of them being in the UK or not I couldn't tell.
>
>
> - Beginning with the observation that the Acorn users here are all, I
> believe, in UK universities.
into the ranks of PC mediocrity.
[snip]
--
Nicholas Daley
(from New Zealand)
<dal...@ihug.co.nz>
J. Holder
In a fit of lunacy, Neil Brown (ne...@this.address.is.fake) escribed:
: commend on those. Also, Acorn software generally has a higher code
: density - my memory might be playing tricks on me, but I seem to
: remember the DOS port of Inform coming to 600k+. The Acorn port is 250k.
: This means that an Acorn doesn't need as much RAM or hard drive space to
: install and run similar software to that on a PC.
Actually, the DOS port is ~414k, due to the fact that the compiler used
(DJGPP) has specially memory handling code and protected mode stuff in it,
because the OS sucks. On the other hand, Inform for Win95 / WinNT is
only 284k, which is a lot more believable, since the OS comes closer to
doing its job.
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/
Ben Chalmers
On Mon, 29 Sep 1997 10:06:30 -0700, Erik Max Francis <m...@alcyone.com>
wrote:
>Neil K. wrote:
>
>> Graham has been noisily, passionately and indefatigably trumpeting
>> the
>> virtues of Inform in every public forum to which he has access. And
>> many
>> more besides.
>
>Anytime anyone uses the word _indefatigable_ I crack up. I have yet to
>find out why.
Because many times you're given lines that are quite un-sing-able?
Let's not go to Camelot... it is a silly place 8)
Ben
Chris Marriott
In article <60lheh$5s2$1...@bartlet.df.lth.se>, Magnus Olsson
<m...@bartlet.df.lth.se> writes
>This is totally off-topic, but doesn't the term "red brick" refer to
>the English universities that were founded during the Victorian era,
>that is, excluding Oxbridge and Durham as well as the newer "upstarts"?
Yes it does. It's used to refer to universities like Manchester,
Liverpool, Sheffield, etc. It's not normally used for the "modern"
universities.
Erik Max Francis
Neil K. wrote:
> Graham has been noisily, passionately and indefatigably trumpeting
> the
> virtues of Inform in every public forum to which he has access. And
> many
> more besides.
Anytime anyone uses the word _indefatigable_ I crack up. I have yet to
find out why.
--
Gord Jeoffroy
On 27 Sep 1997 00:11:35 GMT, go...@cs.buffalo.edu (Phil Goetz) wrote:
>I assumed Acorns were some old, obsolete, and dying
>computer from the early 1980's.
I'm normally loath to contribute to off-topic threads but....
One of my first computers was an Acorn Atom (yes, back in the early
80s). I learned more about computers from that machine than from any
other. It was immensely fun and flexible. I even wired up an RS-232
interface for a remote controlled toy robot and had the thing
following hour-long sequences of commands.
If it weren't for Acorn computers, I don't think I'd be the incredibly
talented, fabulously wealthy, eligible bachelor (are you reading,
ladies?) that I am today.
--Gord, waxing nostalgic...
Phase
jho...@deimos.frii.com (J. Holder) writes:
>Actually, the DOS port is ~414k, due to the fact that the compiler used
>(DJGPP) has specially memory handling code and protected mode stuff in it,
>because the OS sucks. On the other hand, Inform for Win95 / WinNT is
>only 284k, which is a lot more believable, since the OS comes closer to
>doing its job.
--
PHASEFX @ VM.SC.EDU - http://www.cs.sc.edu/~jason-e
For my 8088, I want nothing but DOS. (:
J. Holder
In a fit of lunacy, Phase (lo...@my.sig) escribed:
: jho...@deimos.frii.com (J. Holder) writes:
: >Actually, the DOS port is ~414k, due to the fact that the compiler used
: >(DJGPP) has specially memory handling code and protected mode stuff in it,
: >because the OS sucks. On the other hand, Inform for Win95 / WinNT is
: >only 284k, which is a lot more believable, since the OS comes closer to
: >doing its job.
:
: Just to be fair, please add in the sizes of said operating systems.
Lest anyone think I am a proponant of M$, I will freely admit that
these OS's are ugly pigs. You will conceed, however, that the majority
of the space used by these OS's are wasted frills... apps like: email,
web browsers, wallpaper, sound, video, games, fonts, GUI, etc, etc, etc.
Perhaps the next box I build up I will attempt a minimum install of
NT and see just how small I can make it.
For the record, professionally I develop entirely on UNIX variants,
although my code has to be portable to NT, AS/400 and IBM system 39.
Magnus Olsson
In article <ant272342b49M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>In article <60j41f$kb5$1...@bartlet.df.lth.se>, Magnus Olsson
><URL:mailto:m...@bartlet.df.lth.se> wrote:
>>
>> I bought an Acorn Atom kit computer by mail order from them in
>> 1982. That was a small, 6502 based machine with a whopping 12 Kb of
>> RAM. The current Archimedes is a RISC machine with a little more power
>> than that... AFAIK, they still make them.
>
>I had an Atom, too -- a bottom of the range one, with only 2K,
>but after a year or two I'd managed to upgrade it to 12. I had
>the circuit diagram pinned to my wall (hey, that was how much fun
>it was being a geek teenager in the 80s) and it was the last
>machine I ever owned where you could actually see exactly how it
>worked, and how it would go wrong if you cut any particular track
>on the PCB -- there were no mysterious black boxes called just "ULA"
>in those days.
Apart from the fact that there was no documentation of the internals
(at least none I knew of), it was a very nice and "open" machine for
hacking. Something that was made easier by the (BCPL-inspired)
low-level operators in Basic (much more convenient than PEEK and POKE)
and the in-line assembler. I bought an extension ROM from Watford
Electronics (after reading an advert in some British computer
magazine), which provided me with a disassembler and some other tools
that made for great fun exploring the ROMs.
>You'll be pleased to know the basic operating system design of
>the Acorn Atom lives on in the Risc PC, though. Commands are
>entered at the same * prompt: *LOAD, *SAVE, *CAT, they're all
>still in there, as are the OSWRCH and OSRDCH vectors, and...
Ah, nostalgia...
In case anyone wonders, this is relevant to the newsgroup, since Imade
my first acquaintances with text adventures on the Atom: the Acornsoft
adventures. They weren't really IF, but combat-based games in a
room-based world (like a single-user MUD).
I alsow wrote my first own adventure on the Atom - see the file
atomia.zoo on the IF archive.
Larry Smith
Erik Max Francis wrote:
> Neil K. wrote:
> > Graham has been noisily, passionately and indefatigably trumpeting [...]
> Anytime anyone uses the word _indefatigable_ I crack up. I have yet to
> find out why.
I suppose if Graham ever stopped it would just prove
he was defatigable after all...
--
.-. .---..---. .---. .-..-. |If Gov. Fields is right, I'll stand
| |__ | | || |-< | |-< > / |by him because he is right. If he's
`----'`-^-'`-'`-'`-'`-' `-' |wrong, I'll stand by him because he's
My opinions. Edit addr to reply|a Democrat.-Senator Stanley(D-Ky)1922
Den of Iniquity
On 25 Sep 1997 (sorry, newsreader is still lagging), Jason Compton wrote:
>Well, I've already done some articles on text gaming (and run another one)
>in Amiga Report, and I've had a proposal and even a one-page preview of a
>text game feature on the editor's desk at CU for months now. I'm still
>trying to push it through.
Excellent! Y'know, I think I'll drop them an email and suggest text gaming
as a source of new 'Amiga' games. Maybe a show of interest from more than
one direction will help them make up their minds.
As for producing a programming tutorial, maybe I was fantasising a little.
Putting the major text adventure creators on the CD with full
documentation (is anyone working on/ has anyone finished AmigaGuide
versions of the latest manuals?) in Amigaguide or HTML would be easy -
after all, they're probably always looking for material to fill the cover
CDs.
--
Den