Delurking, getting back to Adventure Programming
Paul 'Ozymandias' Harman
Back in the dim and distant past, I played an adventure game (I think it was
called VIKING) on the BBC Model B, as part of a primary school project (I
was 9 IIRC). I loved it, I was hooked. [Don't worry, I'm posting this to the
right group. Bare with me]
Two years later and now in Secondary School, I read "How to write Adventure
Games" by Peter Killworth. By this time I had some programming under my belt
and thought *why not*? So I started writing adventure games. And writing.
And writing. I wrote in BASIC, to be honest, but that's nothing to be
ashamed of. Not back then.
Since then, I graduated to the Atari ST and now on to the PC. I write in
several languages, and have written arcade games and platform games. But I'm
itching to get back to writing what started me off - Adventures.
So I have a few questions, and since I haven't seen the FAQ drift past
recently I thought I'd come out and ask.
Most importantly, does anyone write their own Adventure systems any more, or
do you just all use Inform or TADS?
If you use one of these, why? Is it because they are multi-platform, or
because you don't have to do so much work, or what?
Are they *really* that flexible?
I assume they are compilers/interpreters for their own languages. If so, are
there any systems out there that are (effectively) libraries or APIs
designed to be called from C? Would there be a market for such an animal?
Thanks for your time, feel free to email me if you don't want to clutter the
group up.
Ozzy
Simon 'tufty' Stapleton
> Thought I'd stick my oar in and see what I stir up.
At which, Simon, who is easily baited, verily leaps onto the hook.
> Back in the dim and distant past, I played an adventure game (I think it was
> called VIKING) on the BBC Model B, as part of a primary school project (I
> was 9 IIRC). I loved it, I was hooked. [Don't worry, I'm posting this to the
> right group. Bare with me]
Cool. My brother was introduced to adventure games at primary
school. Lucky little sod. Some people get all the luck.
> Two years later and now in Secondary School, I read "How to write Adventure
> Games" by Peter Killworth. By this time I had some programming under my belt
> and thought *why not*? So I started writing adventure games. And writing.
> And writing. I wrote in BASIC, to be honest, but that's nothing to be
> ashamed of. Not back then.
Also cool. Still got any of them? Fancy uploading them to GMD?
> Most importantly, does anyone write their own Adventure systems any more, or
> do you just all use Inform or TADS?
Most people, as far as I can tell, use either inform or tads. There
are people out there developing their own stuff, but they're in the
minority.
> If you use one of these, why? Is it because they are multi-platform, or
> because you don't have to do so much work, or what?
I use inform, mainly because it's there, I've spent some time playing
with it, and because it means I don't have to write a f******
parser of my own, deal with my own object tree, etc, etc. I can get
down to what really matters, which is the logic of the game itself.
Also, I know that when (if) I finish, it will be available to
people on most if not all current platforms. This is a non-trivial
point. As is the fact that if I have a problem, I can call on the
resources of the group, and all the source code on GMD, to help me.
> Are they *really* that flexible?
I don't think we've seen anything better yet. There are people out
there developing new and krayzee stuff, which may or may not be the
future of I-F. But they're not there yet.
> I assume they are compilers/interpreters for their own languages.
You assume correctly (nearly). They both generate platform
independent binaries. There are interpreters for most hardware
platforms.
> If so, are
> there any systems out there that are (effectively) libraries or APIs
> designed to be called from C? Would there be a market for such an animal?
I don't know if there are any good ones. Would there be a market?
Maybe. The problem with this is mainly portability. Any game would
have to be recompiled for each platform it runs on. And we all know
how *standard* 'C' compilers are. Harrumph!
My opinion is that, unless your proposed library is revolutionary in
its approach, you are unlikely to get many takers. You'll need a
really good parser, decent NPC AI and a whole shedload (tm) of other
stuff before people will look at it.
Your binaries will tend to be larger than those created by inform or
TADS, due to the fact the screen-handling, parsing and other code
will have to be included in the executable. This could cause problems
for people (like me) who have dial-up (and, in my case, very flaky)
internet connections and who want to download games off the net.
It will also need to be cross-platform, and (preferably) generate
some sort of platform-independent runtime environment.
Once you've done that, you can prepare for the inevitable barrage of
flamage from people who can't play games based on your toolkit due to
hardware considerations, blah blah blah
Before you even try, You'll need to get into inform and TADS, play
games based on both of them, and see what you're up against.
I'd say don't bother unless you're coming up with something really
special. And for god's sake, if you *do* do it, don't restrict it to
one platform. Not unless you *enjoy* being flamed.
Simon
--
_______
| ----- | Biased output from the demented brain of
||MacOS|| Simon Stapleton.
|| NOW ||
| ----- | sstaple AT liffe DoT com
| -+-.| (if you can't figure it out...)
|洵洵洵洱
-------
Joyce Haslam
Simon 'tufty' Stapleton <nob...@no.bloody.where> wrote:
> "Paul 'Ozymandias' Harman" <oz...@kasterborus.demon.co.uk> writes:
> > Most importantly, does anyone write their own Adventure systems any
> > more, or do you just all use Inform or TADS?
Be glad you missed the thread with flames on this one. :-)
> Most people, as far as I can tell, use either inform or tads. There
> are people out there developing their own stuff, but they're in the
> minority.
>
> > If you use one of these, why? Is it because they are multi-platform, or
> > because you don't have to do so much work, or what?
> I use inform, mainly because it's there, I've spent some time playing
> with it, and because it means I don't have to write a f******
> parser of my own, deal with my own object tree, etc, etc. I can get
> down to what really matters, which is the logic of the game itself.
> Also, I know that when (if) I finish, it will be available to
> people on most if not all current platforms. This is a non-trivial
> point. As is the fact that if I have a problem, I can call on the
> resources of the group, and all the source code on GMD, to help me.
>
I emphasize this. A game written in inform (or tads or...) can be
playtested on any of the major platforms and when finished is available
ditto. Also there are some real wizards on this group, but their advice
on writing your own is likely to be much less useful than their advice
on using the standard systems.
> > If so, are there any systems out there that are (effectively)
> > libraries or APIs designed to be called from C? Would there be a
> > market for such an animal?
What _market_ is there for IF? You are talking leisure interest here
(apologies to Avalon). Don't try for money, try for excellence and your
own enjoyment (a lot of which comes from interaction with playtesters and
this newsgroup).
[lots more good stuff snipped]
Joyce.
--
Joyce Haslam
q u e r c u s @ a r g o n e t . c o . u k
Paul 'Ozymandias' Harman
Simon 'tufty' Stapleton wrote in message ...
Adventure
>> Games" by Peter Killworth. By this time I had some programming under my
belt
>> and thought *why not*? So I started writing adventure games. And writing.
>> And writing. I wrote in BASIC, to be honest, but that's nothing to be
>> ashamed of. Not back then.
>
>Also cool. Still got any of them? Fancy uploading them to GMD?
I tried finding them recently but they've got "lost" in my filing system. I
can't even find my old maps... }:*(
Since I can't believe I'd've thrown them away on purpose I suppose someone
must have junked them by accident. And I haven't got my Archimedes BASIC-V
code any more either, not sure where that went (that was my A-level Computer
Science coursework).
>Most people, as far as I can tell, use either inform or tads. There
>are people out there developing their own stuff, but they're in the
>minority.
Why re-invent the wheel? (see below).
>I don't think we've seen anything better yet. There are people out
>there developing new and krayzee stuff, which may or may not be the
>future of I-F. But they're not there yet.
Since I don't know very much about TADS or Inform, I'm commenting "in the
dark" as it were. So bare with me.
Th trouble with any language geared towards a particular programming area
(such as Inform/TADS for Adventures, or VB (say) for Applications) is that
by their very nature they impose certain ways of doing things. This means
that if you want to program something slightly unusual, the system doesn't
have the syntax/commands to allow you to do it.
>> If so, are
>> there any systems out there that are (effectively) libraries or APIs
>> designed to be called from C? Would there be a market for such an animal?
>
>I don't know if there are any good ones. Would there be a market?
>Maybe. The problem with this is mainly portability. Any game would
>have to be recompiled for each platform it runs on. And we all know
>how *standard* 'C' compilers are. Harrumph!
I was just wondering if it would be a worthwhile venture; if I'm going to
write my own adventures in C (rather than have to learn a new language and
conform to it's way of writing adventures) then I may as well wrap the
adventure-housekeeping stuff into a library and offer that to anyone that
wants it.
>My opinion is that, unless your proposed library is revolutionary in
>its approach, you are unlikely to get many takers. You'll need a
>really good parser, decent NPC AI and a whole shedload (tm) of other
>stuff before people will look at it.
Oh, most likely.
>Your binaries will tend to be larger than those created by inform or
>TADS, due to the fact the screen-handling, parsing and other code
>will have to be included in the executable. This could cause problems
>for people (like me) who have dial-up (and, in my case, very flaky)
>internet connections and who want to download games off the net.
>
>It will also need to be cross-platform, and (preferably) generate
>some sort of platform-independent runtime environment.
Well, if I was going to be serious about it then I'd do it either in Perl/Tk
or in Java, which are both (allegedly) platform independent. I only envisage
supporting text-only games, so I don't see what the problem is with screen
handling etc....
I'm not seriously suggesting I can write a competitor for TADS/Inform which
(I assume) have a large professional team behind them. Just wondered if a
project I started on for my own amusement would be of interest to anyone.
Ozzy
Paul 'Ozymandias' Harman
Joyce Haslam wrote in message <488363a1...@argonet.co.uk>...
>In article <wzyars5...@no.bloody.where>,
> Simon 'tufty' Stapleton <nob...@no.bloody.where> wrote:
>> > more, or do you just all use Inform or TADS?
>
>Be glad you missed the thread with flames on this one. :-)
I assume that'd be the TADS vs Inform flamewars? Don't worry, I'm also on
the games.programmer newsgroups and I've seen enough DirectX vs OpenGL
flamwars to prevent me asking the obvious "Which is Better" question.
That's a hint. Please do not answer that question. I don't want to
know. };*) And if I did want to know, I'd get them both for myself and test
drive them both and make up my own mind.
>I emphasize this. A game written in inform (or tads or...) can be
>playtested on any of the major platforms and when finished is available
>ditto. Also there are some real wizards on this group, but their advice
>on writing your own is likely to be much less useful than their advice
>on using the standard systems.
>What _market_ is there for IF? You are talking leisure interest here
>(apologies to Avalon). Don't try for money, try for excellence and your
>own enjoyment (a lot of which comes from interaction with playtesters and
>this newsgroup).
Well... I write games for fun anyway. I'm not asking about a financial
market for such a development toolkit; I was just wondering if anyone would
use it if I made it available.
Of course this is all completely hypothetical, I haven't put pen to paper
yet.
Ozzy
wy...@cxo.com
"Paul 'Ozymandias' Harman" <oz...@kasterborus.demon.co.uk> wrote:
> Thought I'd stick my oar in and see what I stir up.
> Games" by Peter Killworth. By this time I had some programming under my belt
> and thought *why not*? So I started writing adventure games. And writing.
> And writing. I wrote in BASIC, to be honest, but that's nothing to be
> ashamed of. Not back then.
It's still nothing to be ashamed of. :)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Den of Iniquity
>Since I don't know very much about TADS or Inform, I'm commenting "in the
>dark" as it were. So bare with me.
>
>Th trouble with any language geared towards a particular programming area
>(such as Inform/TADS for Adventures, or VB (say) for Applications) is that
>by their very nature they impose certain ways of doing things. This means
>that if you want to program something slightly unusual, the system doesn't
>have the syntax/commands to allow you to do it.
Well, if you want to stick to text adventure games, there's very little
reasonable Inform can't do - see Andrew Plotkin's Tetris game (Freefall)
and Scheme interpreter (Lists and Lists) for outstanding examples.
But here's a very important point to you: Inform, TADS, as well as Hugo
and Alan (and some other less used formats) are all _free_ (freeware; I'm
not sure which if any are public domain). You'd be mad not to have a look
at them, at least - see what they are like, whether they could meet your
needs. If nothing else, you could learn from them and it might help you
write your projected C libraries.
--
Den
Andrew Plotkin
> Thought I'd stick my oar in and see what I stir up.
>
> recently I thought I'd come out and ask.
>
> do you just all use Inform or TADS?
Most people finishing games these days are using one of the existing
creation systems. Most of them are using Inform and TADS.
> If you use one of these, why? Is it because they are multi-platform, or
> because you don't have to do so much work, or what?
>
> Are they *really* that flexible?
Actually, yes. Both have pretty much the same expressive power as the C
language (though not, obviously, all the standard C libraries.)
More important: creating a new adventure-building system is a tremendous
amount of work.
1) Language design
2) Architecture design
3) Compiler program
4) Interpreter program, or run-time support if you're building native code
5) Repeat 4 for Windows, DOS, Mac, Unix, Acorn, Pilot...
6) Getting people to download and run your brainchild
All this work is done for TADS and Inform, and to a lesser extent for
Hugo, Alan, etc. (Step 5 is the never-ending job; you have to find
volunteers crazy enough to port your code.)
Now, I think we're entering an era where these tasks can be modularized;
someone can work on just one of them, rather than having to build the
whole lot. I'm working on 4, for example. (Actually, I've split 4 in half
-- there's the interpreter engine and the interpreter I/O, and I'm working
on the I/O. The result will be equally applicable to C programs and
virtual machine interpreters.) Someone else is working on the other half
of 4.
> I assume they are compilers/interpreters for their own languages. If so, are
> there any systems out there that are (effectively) libraries or APIs
> designed to be called from C? Would there be a market for such an animal?
It would have some disadvantages compared to the Inform/TADS model.
Portability is the big one. If the program is in C, then every *game* has
to be ported to every platform. (No matter how portable the code is,
it's still more work than downloading a file.) I have Macs, and reality
says that almost nothing will make it to my machine; even I'm not
volunteering to compile every game that comes out.
Also: All the major systems are C-like enough to handle all the
commonplace tasks of IF programming. (If, loop, switch, variables and
arrays -- most of any program is this stuff.) I think it makes more sense
to figure out what *else* one might want to do, and then figure out how to
add it in to the Standard Model. (TADS has a concept of user exits, where
the game author can provide an compiled C library which the TADS engine
will call for you. This has been a resounding failure. See recent
newsgroup discussion of virtual machines for better ways to define the
problem.)
(Also: what you want is harder than you think. "undo" and "save" are easy
to apply to a virtual machine state, incredibly difficult to apply to a C
program environment.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Paul 'Ozymandias' Harman
Den of Iniquity wrote in message ...
>Well, if you want to stick to text adventure games, there's very little
>reasonable Inform can't do - see Andrew Plotkin's Tetris game (Freefall)
>and Scheme interpreter (Lists and Lists) for outstanding examples.
Wow. Okay, it all sounds pretty "open" to me.
>But here's a very important point to you: Inform, TADS, as well as Hugo
>and Alan (and some other less used formats) are all _free_ (freeware; I'm
>not sure which if any are public domain). You'd be mad not to have a look
>at them, at least - see what they are like, whether they could meet your
>needs. If nothing else, you could learn from them and it might help you
>write your projected C libraries.
I intend to! Certainly since they are free I have no excuse not to; and
besides checking out what the "professional" systems are capable of is a
good guideline to see what sort of thing I'd need to support.
But it's all for fun on my side anyway. If Inform/TADS and the others are as
flexible as you suggest, I'll probably not bother and choose one of them for
my own use.
Paul.
Paul 'Ozymandias' Harman
Andrew Plotkin wrote in message ...
>Most people finishing games these days are using one of the existing
>creation systems. Most of them are using Inform and TADS.
There's an implicit hint buried in that statement: I should stop mentioning
Inform and TADS by name because that implies I've already judged the other
"IF creation environments" (for want of a better phrase) unworthy of my
attention. This is not the impression I want to convey!
>More important: creating a new adventure-building system is a tremendous
>amount of work.
Oh, I fully aprreciate that!
>1) Language design
Well I'm in the process of creating my own scripting language for my
Arcade-style games, and I see no reason why it can't be used here. In other
words, I've already given myself this headache so it's no extra work!
>2) Architecture design
I've got my own rather firm ideas on "how an adventure works" (*) and so
this will not be a problem for me. In actual fact this is why I'm reluctant
to leap on the "IF creation environments" bandwaggon because I find it
unlikely that they have the same way of doing things as me [it also depends
on how open they are].
(*) - This, of course, may not be such a good thing if I ever intend to
throw the utilities open to the public. After all, why should anyone want to
write adventures *my* way?
>3) Compiler program
>4) Interpreter program, or run-time support if you're building native code
See (1). It'd be interpreted anyway; I can't see speed being a major problem
in a text adventure scenario and if it's an interpreter it makes platform
independence simpler (see later).
>5) Repeat 4 for Windows, DOS, Mac, Unix, Acorn, Pilot...
Ah... if one is serious about multi-platform support, one writes in Perl or
in Java (urgh).
>It would have some disadvantages compared to the Inform/TADS model.
>Portability is the big one. If the program is in C, then every *game* has
>to be ported to every platform. (No matter how portable the code is,
>it's still more work than downloading a file.) I have Macs, and reality
>says that almost nothing will make it to my machine; even I'm not
>volunteering to compile every game that comes out.
At the great, great risk of starting a flame-war: I'd stick to PCs to start
with because by far the largest chunk of the "market" (as I see it) is
there. Adding UNIX later would be fairly simple for me (I'm quite an old
hand in UNIX now). Macs would be more difficult.
And no, you don't write it in C - you use Perl or Java as I said above. Or
you write the whole adventure system in the custom language you have already
developed for adventure creation (cunning) and thus have a nice small, light
interpreter at the bottom.
>(Also: what you want is harder than you think. "undo" and "save" are easy
>to apply to a virtual machine state, incredibly difficult to apply to a C
>program environment.)
Not really. Saving all the arrays and variables to disk is not difficult,
just awkward.
Ozzy
Andrew Plotkin
> Den of Iniquity wrote in message ...
> >Well, if you want to stick to text adventure games, there's very little
> >reasonable Inform can't do - see Andrew Plotkin's Tetris game (Freefall)
> >and Scheme interpreter (Lists and Lists) for outstanding examples.
>
> Wow. Okay, it all sounds pretty "open" to me.
We try. :-)
> >But here's a very important point to you: Inform, TADS, as well as Hugo
> >and Alan (and some other less used formats) are all _free_ (freeware; I'm
> >not sure which if any are public domain). You'd be mad not to have a look
> >at them, at least - see what they are like, whether they could meet your
> >needs. If nothing else, you could learn from them and it might help you
> >write your projected C libraries.
> I intend to! Certainly since they are free I have no excuse not to; and
> besides checking out what the "professional" systems are capable of is a
> good guideline to see what sort of thing I'd need to support.
Quick note: None of the current systems had a big professional team behind
them. TADS was made by Mike Roberts, in a basement shareware company (now
freeware); Inform was made by Graham Nelson, as freeware from the start.
One reason I love this genre is that we're all in it for the joy of it.
It's all personal. Anyone more interested in money than in game quality
chooses a different kind of game.
Andrew Plotkin
> >5) Repeat 4 for Windows, DOS, Mac, Unix, Acorn, Pilot...
>
> Ah... if one is serious about multi-platform support, one writes in Perl or
> in Java (urgh).
I'm serious about multiplatform support, and I write in Inform. The
result runs on my Pilot, on people's Amigas (which people do use to play
these games), on Acorns, and on other platforms which don't support Java.
Perl is a priori pretty reasonable as a "VM" system, but I don't think it
has any advantages over Inform as an adventure language.
Check the "OS Poll" thread. There are a lot of non-Windows users here.
Some of us are here because every other kind of computer game *is*
Windows-only, these days.
I think this is the point where you should dig through the Inform or TADS
specs (yeah, now I'm being prejudiced) and see exactly what the state of
the art is. I get the sense you're making assumptions which aren't
entirely accurate.
Paul 'Ozymandias' Harman
Andrew Plotkin wrote in message ...
>result runs on my Pilot, on people's Amigas (which people do use to play
>these games), on Acorns, and on other platforms which don't support Java.
>Perl is a priori pretty reasonable as a "VM" system, but I don't think it
>has any advantages over Inform as an adventure language.
Apologies...
[Thought to self (please don't reply): There are platforms that don't
support Java?]
What is Inform written in? That's the level I'm thinking about here. Also
the sort of API/Library I am considering is not something I'd expect people
to write adventures *in*, I see it as a tool to help people manage their own
adventure-like sections of other projects.
For example, what I'm writing at the moment is an arcade game using DirectX
on the PC. Now, it's going to be a graphical adventure. So I need some way
of controlling the object interactions: what happens when you eat the
mushroom, what happens if you use the axe on the table; and so on. This sort
of thing could be of use to other people writing games that are not used to
Adventure Game programming, but would like to write a similar project as
mine but don't have the know-how.
>Check the "OS Poll" thread. There are a lot of non-Windows users here.
>Some of us are here because every other kind of computer game *is*
>Windows-only, these days.
Ah... experience has taught me to avoid "vs" threads or anything discussing
which OS to use.
My take here is that adventure games - especially text-based games - should
be relatively easy to convert to different platforms (as compared to, say,
3D or other graphical extravaganzas). In this regard, I'd really have no
excuse *not* to have a Mac/UNIX/Archimedes/Amiga version of anything I
produce.
Of course, from a Library point of view that's gonna be mighty difficult to
achieve. But not as difficult as supplying a whole development environment
such as TADS, Inform, and so on.
>I think this is the point where you should dig through the Inform or TADS
>specs (yeah, now I'm being prejudiced) and see exactly what the state of
>the art is. I get the sense you're making assumptions which aren't
>entirely accurate.
Absolutely. All of my posts come with a caveat that I haven't used any of
these products, and believe me I am not attempting to bad-mouth them. I hope
that my first posts haven't marked me up as an arrogant know-all git,
because that certainly wasn't my intention and definitely is not what I
believe.
So I apologise if I've offended anyone.
I have no real intention or desire to "compete" with these products because
I don't think I have the skill and I don't see the point - there are 2
perfectly good products out there so why bother? I want to develop something
slightly different which approaches the problem from a different level of
abstraction. And if that interests anyone else enough to want to take a look
at what I've done, so much the better.
Ozzy
Adam J. Thornton
>write my own adventures in C (rather than have to learn a new language and
>conform to it's way of writing adventures) then I may as well wrap the
>adventure-housekeeping stuff into a library and offer that to anyone that
>wants it.
Sure, but isn't this kinda what GNAT does? Or is it YAAL?
Also, there are a lot of really complex issues involved in writing a parser
and libraries. Unless you're doing it specifically *to* write a parser and
libraries, I woiuldn't bother. After many years and many iterations,
Inform and TADS (and maybe Hugo, but I don't know Hugo) have finally gotten
it close to right.
>Well, if I was going to be serious about it then I'd do it either in Perl/Tk
>or in Java, which are both (allegedly) platform independent. I only envisage
>supporting text-only games, so I don't see what the problem is with screen
>handling etc....
Then why Perl/Tk? You don't need a GUI if it's text only, do you?
>I'm not seriously suggesting I can write a competitor for TADS/Inform which
>(I assume) have a large professional team behind them. Just wondered if a
>project I started on for my own amusement would be of interest to anyone.
I think Mike Roberts and Graham Nelson would both be amused at being called
a "large professional team." From my perspective, your project would be
somewhat interesting: I'd take it and look at the code to see how it
worked, but would probably just eventually stick with one of the big two.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Den of Iniquity
>Paul 'Ozymandias' Harman (oz...@kasterborus.demon.co.uk) wrote:
>> Ah... if one is serious about multi-platform support, one writes in Perl or
>> in Java (urgh).
>
>I'm serious about multiplatform support, and I write in Inform. The
>result runs on my Pilot, on people's Amigas (which people do use to play
>these games), on Acorns, and on other platforms which don't support Java.
Just a quick Amigan point: AFAIK, there is AmigaJava. I'd hazard a guess
that there's Acorn Java, too. But AmigaJava is, as you can imagine, not
quick (dunno if it's been ported to PPC Amigas). Like Amiga Quake C, the
only people who'll appreciate your creations are the ones with the fastest
machines. Inform (or TADS, Hugo, Alan, whatever) is much less 'intense' on
the processor and therefore a much better choice in the cross-platform
compatibility stakes.
--
Den
Paul 'Ozymandias' Harman
Adam J. Thornton wrote in message <6t8put$a77$1...@cnn.Princeton.EDU>...
>Sure, but isn't this kinda what GNAT does? Or is it YAAL?
I dunno, I'm new to this sort of thing.
>Also, there are a lot of really complex issues involved in writing a parser
>and libraries. Unless you're doing it specifically *to* write a parser and
>libraries, I woiuldn't bother. After many years and many iterations,
>Inform and TADS (and maybe Hugo, but I don't know Hugo) have finally gotten
>it close to right.
Absolutely. I don't really want to write a competitor product to these
systems; they do what they do very well thank you very much and there's
problebly not much point (and not much market share) in doing so.
>>Well, if I was going to be serious about it then I'd do it either in
Perl/Tk
>>or in Java, which are both (allegedly) platform independent. I only
envisage
>>supporting text-only games, so I don't see what the problem is with screen
>>handling etc....
>
>Then why Perl/Tk? You don't need a GUI if it's text only, do you?
True. Just perl then. But it might be nice to have some button and window
widgets, and maybe show the odd graphic for particular locations.
>I think Mike Roberts and Graham Nelson would both be amused at being called
>a "large professional team." From my perspective, your project would be
>somewhat interesting: I'd take it and look at the code to see how it
>worked, but would probably just eventually stick with one of the big two.
};*) Well, to *me* they're professional because they're out there and
running. They've certainly made it large in the "market". And IIRC they
distribute the source for their projects so people could theoretically
submit bug-fixes for things they've found (the Linux approach).
Ozzy
Simon 'tufty' Stapleton
I would suggest that you go and take a long, hard look at inform
and TADS. I mean *hard*. Read the manuals. Look at some source
code. Play the games. Read the z-machine specification. Read
Andrew's Glk and BLORB specs. Read up on virtual machine creation.
Go back to dejanews and look at the interminable Virtual machine
and z-machine threads. Read and digest the source to both inform
and TADS. Read and digest the source for some interpreters. Repeat
this step until you're thoroughly sick of it.
I'm serious. There is so much good stuff in that little lot that
you *need* to look at before trying to implement a modern IF
machine. Otherwise, unless you're *very* lucky, you'll make a load
of mistakes which will render anything you produce inferior to
inform / tads games.
Reconsider your "I'll use the PC and port to other stuff later"
stance. The i-f community is resolutely multi-platform. Witness
the current platform thread. There are a lot of authors out
there using Linux. Gamers - who knows? Probably mainly PC
based but I'm sure someone will pop up and tell me 98% of IF
players are using Commodore PETs. Back to the point. Porting
stuff that was created for a specific platform is a bastard. I
know. I've lost hair doing it. Lots of hair. If you want
multi-platform, do it from the start. Saying "I'll use java"
doesn't cut it, I'm afraid. There are a lot of people out there
using machines that don't have the power to run java. Or even
have a port of java available. Likewise perl.
Consider *why* you want to create a new system.
If it's so you can create your own games, I would recommend
grabbing one of inform or TADS and just doing it. They're both
pretty close to 'C', syntactically, and shouldn't prove too much
of a handful. So unless you're trying to do something that they
simply cannot do, which I find unlikely, what's the problem
with using them? Creating your own system will take a helluva
lot longer than learning either or both of them to guru level.
If it's so other people can create games, you need to make it
somehow better than inform or TADS. Not necessarily easier,
but better. Better AI, better parser, whatever. It has to be
better. And it has to be accessible. And well documented.
And supported.
I really, really reccomend that you go and play some of the
modern games, to see what can be done with the relevant
platforms. I'd recommend 'The Edifice', 'So Far', 'Freefall',
'Christminster' and 'Spider and Web' for inform.
I don't know about TADS (mainly because I haven't played that
many outstanding games under that platform - not saying there
aren't, mind you - and I can't be bothered to run off to the
archives to look).
Then come back and say where exactly your system will improve
on what we have already.
Not that I'm saying you shouldn't do it. It's an interesting
exercise, for its own sake. But I doubt if you will improve on
what we have now. Maybe, just maybe, I'm being negative. I
don't think so, though.
Lucian Paul Smith
: Since I don't know very much about TADS or Inform, I'm commenting "in the
: dark" as it were. So bare with me.
: Th trouble with any language geared towards a particular programming area
: (such as Inform/TADS for Adventures, or VB (say) for Applications) is that
: by their very nature they impose certain ways of doing things. This means
: that if you want to program something slightly unusual, the system doesn't
: have the syntax/commands to allow you to do it.
I can't speak for TADS, but, while the 'default' syntax of Inform is
definitely geared towards a certain way of doing things, Inform also has
special syntax that calls machine opcodes directly. If they don't allow
you to do what you want to do, I shall be quite surprised. Actually, for
most things, I'd be surprised if even the 'default' syntax didn't allow
you to do what you wanted.
For an example of the range of Inform, play:
ftp://ftp.gmd.de/if-archive/games/inform/freefall.z5
You can then see the source in:
ftp://ftp.gmd.de/if-archive/programming/inform6/examples/games/freefall.inf
(but play the game before you look at the code. Really.)
For examples of more 'normal' source, that directory has many more
examples you could look at.
Enjoy!
-Lucian
Paul 'Ozymandias' Harman
Simon 'tufty' Stapleton wrote in message ...
>I would suggest that you go and take a long, hard look at inform
>and TADS. I mean *hard*. Read the manuals. Look at some source
>code. Play the games. Read the z-machine specification. Read
>Andrew's Glk and BLORB specs. Read up on virtual machine creation.
>Go back to dejanews and look at the interminable Virtual machine
>and z-machine threads. Read and digest the source to both inform
>and TADS. Read and digest the source for some interpreters. Repeat
>this step until you're thoroughly sick of it.
};*)
I think I have been putting over the wrong impression here. Part of the time
I have been saying "Hey, I'd like to write a library to help people do
adventure-like things in their projects"; and the rest of the time I've been
saying "If I was going to write a TADS/Inform like system, then this is how
I'd do it".
I don't see the point in writing a TADS/Inform clone because it's been done.
>Reconsider your "I'll use the PC and port to other stuff later"
>stance. The i-f community is resolutely multi-platform. Witness
>the current platform thread. There are a lot of authors out
>there using Linux. Gamers - who knows? Probably mainly PC
>based but I'm sure someone will pop up and tell me 98% of IF
>players are using Commodore PETs. Back to the point. Porting
>stuff that was created for a specific platform is a bastard. I
>know. I've lost hair doing it. Lots of hair. If you want
>multi-platform, do it from the start.
If I were writing a new system, then I'd either write it for the PC or for
UNIX, to start with. But I'm not. I'm writing a set of libraries which, at
the end of the day, will manipulate objects and will [probably] involve some
kind of custom scripting language.
Writing C code that manipulates data structures is not (usually) platform
dependent; the only thing one has to worry about is byte ordering which is a
trivial problem to overcome. Obviously writing a whole adventure system is
far, far more difficult and does have far-reaching platform specific issues.
For example, writing a non-OO application on the Mac is bloody difficult (I
am told), whereas it's simpler on the PC.
>Saying "I'll use java"
>doesn't cut it, I'm afraid. There are a lot of people out there
>using machines that don't have the power to run java. Or even
>have a port of java available. Likewise perl.
I was under the misguided assumption that Java and Perl were available for
most platforms, seems I'm wrong. Certainly Perl is 'available' on any
platform that C is available for; it's simply a matter of compiling the Perl
interpreter. (This may not be quite so simple but the Perl community
probably has someone running Perl on your platform).
And I don't like Java anyway.
>If it's so you can create your own games, I would recommend
>grabbing one of inform or TADS and just doing it. They're both
>pretty close to 'C', syntactically, and shouldn't prove too much
>of a handful. So unless you're trying to do something that they
>simply cannot do, which I find unlikely, what's the problem
>with using them? Creating your own system will take a helluva
>lot longer than learning either or both of them to guru level.
Absolutely. Agreed 100%.
>If it's so other people can create games, you need to make it
>somehow better than inform or TADS. Not necessarily easier,
>but better. Better AI, better parser, whatever. It has to be
>better. And it has to be accessible. And well documented.
>And supported.
It's not quite that; it's so people who are writing (say) Arcade games that
want a bit of puzzle content have got a library to call that handles all
that sort of stuff.
But actually, at the end of the day, it's to prove to myself that I can do
it. Whether anyone else ever gets to see it or not is beside the point!
Ozzy
Doeadeer3
<oz...@kasterborus.demon.co.uk> writes:
>But actually, at the end of the day, it's to prove to myself that I can do
>it. Whether anyone else ever gets to see it or not is beside the point!
You'll find that may not be enough, even if you think it is. Several have
attempted this (with various degrees of success) but because their systems are
not as cross-platform and not as flexible as Inform and TADS already are, most
of us on raif remain uninterested. Be sure you can really live with that
disinterest before launching yourself on such a massive project.
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Paul 'Ozymandias' Harman
Doeadeer3 wrote in message
<199809101623...@ladder03.news.aol.com>...
>You'll find that may not be enough, even if you think it is. Several have
>attempted this (with various degrees of success) but because their systems
are
>not as cross-platform and not as flexible as Inform and TADS already are,
most
>of us on raif remain uninterested. Be sure you can really live with that
>disinterest before launching yourself on such a massive project.
If Inform, TADS, and the others didn't exists then I'd have to do this work
for myself anyway };*) especially if I ever wanted to write more than one
adventure.
It might sound ridiculous to other people, but I like writing things like
that just for the challenge of doing it. At the moment, for example, I'm
writing a side-on platform game involving tiled maps and parallaxing. I'm
writing a whole back-end engine to control the maps with. This is so I can
write other games like this in the future. The fact that if I write the game
I'm intending it'll be the last of it's kind that I write is magnificently
irrelevant!
I believe in doing the job properly and I'm sure I waste far too much time
and effort doing so. But writing in excess functionality has become a kind
of habit for me... especially because in my experience of game programming
(and programming in general) something always crops up 6 months down the
line, and you think "Damn, why didn't I leave room for that?".
I'm not writing a competing product, anyway. I don't have the time or the
inclination to do so. However, once I've written the library - assuming I've
done a good job - someone else could conceivably write such a product using
the library. It's not what I'm intending, though.
Ozzy
Adam J. Thornton
Paul 'Ozymandias' Harman <oz...@kasterborus.demon.co.uk> wrote:
>>>Well, if I was going to be serious about it then I'd do it either in
>Perl/Tk
>>>or in Java, which are both (allegedly) platform independent. I only
>envisage
>>>supporting text-only games, so I don't see what the problem is with screen
>>>handling etc....
>>Then why Perl/Tk? You don't need a GUI if it's text only, do you?
>True. Just perl then. But it might be nice to have some button and window
>widgets, and maybe show the odd graphic for particular locations.
Then you need to design a system with integrated support for graphics, from
the ground up. Don't kluge it in later.
Me, I want an X port of HTML TADS, but I'm not holding my breath. Or even
XFrotz, linked with something open source (NOT KDE, NOT Qt!), particularly
if someone would develop a good Inform debugger. And no, I'm *still* not
volunteering.
>};*) Well, to *me* they're professional because they're out there and
>running. They've certainly made it large in the "market". And IIRC they
>distribute the source for their projects so people could theoretically
>submit bug-fixes for things they've found (the Linux approach).
Or build it on their own machines.
FWIW, Inform's source is much nicer than TADS. But that's mostly
historical: Mike Roberts designed TADS as a DOS system back in the days
when that mean you had to leap through enormous hoops to build anything of
any consequence on a DOS box, and the source has evolved from there.
Inform is extremely portable ANSI C.
Of course, Inform doesn't include a runtime environment, either, which
simplifies it immensely, since Graham doesn't have to deal with any sort of
formatted output or interpreter (except implicitly as far as the Z-machine
is defined in terms of an interpreter).
Frank Filz
I think part of the problem is that you really haven't communicated what
your goals are. Depending on what your goals are you may want to:
1 just use Inform, Tads, Hugo, Alan, or whatever
2 write some new add on libraries for one of the above
3 write a new standard library for one of the above
4 add some feature to the compiler, run time, or both
for one of the above systems
5 utilize part of one of the above systems to plug
the capabilities into some other game system
6 design a whole new adventure system from scratch
Most people are reading that you want to do #6, and making the
assumption that your goals don't require it.
--
Frank Filz
-----------------------------
Work: mailto:ff...@us.ibm.com
Home: mailto:ff...@mindspring.com
Frank Filz
goals I have burried at the back of my head, so I thought I'd share a
few of my ideas...
One of the things I've wanted to have was a graphical adventure system
with the rich flexibility of text adventures, but to have a console or
menu to select some of the common verbs (and a way for the player to add
to it as they discover new verbs). The player could also point at
picture elements.
One implementation idea I just had is: If the player had typed (or
selected) "take" and then pointed at a graphical element (say a cup),
the system would plop the picture of the cup into the command (so you
would get something like:
\ /
> take | |
-----
The system would create the internal command line: "take #5" (the cup
happens to be object #5). The display code would put up the picture of
an object anytime it tried to display a string element of the form
"#n". Of course the above game would also respond to "take cup". The
big advantage to the player is not having to guess one of the synonymns
for an object. Of course the adventure author is then obligated to
create "objects" for just about every part of a picture. One thing that
would help is to allow "scenery" elements to be defined by a selection
area, and then just display the text name, so when the player tries to
examine the table the cup was sitting on, the result is:
> examine table
Another way would be to still have an image (but the player will still
be clued in as to the "sceneryness" of the object as the object image
doesn't match the picture - though maybe the object image needs to be an
icon, separate from the picture element - then the player wouldn't get
the "scenery" clue).
Doeadeer3
<oz...@kasterborus.demon.co.uk> writes:
>It might sound ridiculous to other people, but I like writing things like
>that just for the challenge of doing it.
No, it doesn't. A lot of us do try various programming projects for just that
reason. And most of the current (and newer) systems were written with that as
at least a partial motivation (as well as other reasons, such as, wanting to
write good games, one having their own idea how a parser, compiler, adventure
system should work, etc.) I certainly think Mr. Roberts and Mr. Nelson also
enjoyed the challenge.
Andrew Plotkin
> };*)
> I think I have been putting over the wrong impression here. Part of the time
> I have been saying "Hey, I'd like to write a library to help people do
> adventure-like things in their projects"; and the rest of the time I've been
> saying "If I was going to write a TADS/Inform like system, then this is how
> I'd do it".
Since there's been a flood of posts averaging to a somewhat critical
total -- although polite -- let me throw in one to say that we love people
like you. That's how we got all these tools; we challenged ourselves to
come up with new stuff.
Yes, once we were all like you.
Now we're burnt-out shells of humanity, mumbling in abandoned wiring
closets and halon-filled machine rooms, twitching neurotically when
someone says the words "Visual C++". But we were idealistic young hackers
*once*.
Jason Compton
: And no, you don't write it in C - you use Perl or Java as I said above. Or
: you write the whole adventure system in the custom language you have already
: developed for adventure creation (cunning) and thus have a nice small, light
: interpreter at the bottom.
A considerable chunk of IF enthusiasts are using platforms that don't lend
themselves particularly well to Perl or Java as a "cross-platform"
language. Andrew mentioned the Acorn and Pilot, and there's other
palmtops, the Atari ST, the Amiga...hell, you can run many new Inform
games on C64s, and build the game files very easily.
--
Jason Compton jcom...@xnet.com
Editor-in-Chief, Amiga Report Magazine VP, Legacy Maker Inc.
http://www.cucug.org/ar/ http://www.xnet.com/~jcompton/
Jason Compton
: Just a quick Amigan point: AFAIK, there is AmigaJava. I'd hazard a guess
: that there's Acorn Java, too. But AmigaJava is, as you can imagine, not
: quick (dunno if it's been ported to PPC Amigas). Like Amiga Quake C, the
I also don't think it actually runs anything. It's a very rudimentary
compiler that can't really compile very much, from my experience with it.
Adam J. Thornton
Andrew Plotkin <erky...@netcom.com> wrote:
>Yes, once we were all like you.
>
>Now we're burnt-out shells of humanity, mumbling in abandoned wiring
>closets and halon-filled machine rooms, twitching neurotically when
>someone says the words "Visual C++". But we were idealistic young hackers
>*once*.
Don't forget the part about swilling cheap Scotch by the light of a failing
monitor and posting bitter little rants to alt.sysadmin.recovery about how
much we hate everything. And chainsmoking unfiltered Camels in the gutted
shells of IBM DASD cabinets, pounding away with our crabbed claw-like
carpal-tunnelled fingers at Wyse-50 terminals with the "h" key missing.
Doeadeer3
Thornton) writes:
>Don't forget the part about swilling cheap Scotch by the light of a failing
>monitor and posting bitter little rants to alt.sysadmin.recovery about how
>much we hate everything. And chainsmoking unfiltered Camels in the gutted
>shells of IBM DASD cabinets, pounding away with our crabbed claw-like
>carpal-tunnelled fingers at Wyse-50 terminals with the "h" key missing.
Hey! I have carpal tunnel and I smoke (low-tar, though. But I don't have a Wyse
and I just replaced my keyboard so the "e" key works again.)
And I was never really a hacker, so I guess it doesn't fit, anyway.
But can I still be bitter?
Erik Max Francis
> > If so, are
> > there any systems out there that are (effectively) libraries or APIs
> > designed to be called from C? Would there be a market for such an
> > animal?
>
> I don't know if there are any good ones. Would there be a market?
> Maybe. The problem with this is mainly portability. Any game would
> have to be recompiled for each platform it runs on. And we all know
> how *standard* 'C' compilers are. Harrumph!
Uh, the Inform and TADS compilers and interpreters are all written in C
and thus had to be ported too.
Well-written ANSI C is in fact _very_ portable. It's just that many
people don't know how to write ANSI C.
--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon (efnet) / finger m...@sade.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
\
/ Who's not sat tense before his own heart's curtain?
/ Rainer Maria Rilke
ka...@mousetrap.ml.org
: Uh, the Inform and TADS compilers and interpreters are all written in C
: and thus had to be ported too.
: Well-written ANSI C is in fact _very_ portable. It's just that many
: people don't know how to write ANSI C.
Have you looked at the inform source? The large number of #include calls for
the various systems is amazing. Each one wants something completely
different. And, as someone said earlier, that's assuming you've got a _fully_
ANSI compiler, which many laim to be, but few are.
katre
L. Ross Raszewski
Frank Filz <ff...@mindspring.com> wrote:
> 6 design a whole new adventure system from scratch
>
> Most people are reading that you want to do #6, and making the
> assumption that your goals don't require it.
>
Though we can't be blamed, really -- mopst people who come along thinking
that their goals require that they do (6) _DON'T_ need to, and they only
think so due to a misunderstanding of what exactly you _can_ do with the
extant tools
Also, very few people who claim that they need to do #6 don't give us a full
set of the reasons WHY they feel this need. Often, we just get a "I found the
existing systems too limiting" -- a concept which is plainly incomprehensible
ot someone like me, who has written 3 arcade games in inform.
I'm sure that if someone could provide us with a list of things that he wants
to do in a game, and can't, using the current systems, we'd all support his
choice to make a new system. As someone who's spent a LOT of time working out
just what you can and can't do with inform, I'd be impressed to learn what
_CAN'T_ be done (ANd, odds are that there are one or two things on any such
list that someone here will contest _are_ fully possible in inform, tads, or
hugo
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Kevin Forchione
Andrew Plotkin wrote in message ...
Is there any more to the story behind this? I've gathered bits and pieces
from the home page and other places, but none of the real depth of it. In
some ways this must have been the furore of a decade.
Call me sentimental, but I'd love to read a "history of Inform".
>One reason I love this genre is that we're all in it for the joy of it.
>It's all personal. Anyone more interested in money than in game quality
>chooses a different kind of game.
For myself I discovered Zork at college during the early 80s on a friend's
apple II computer. I still remember vividly the hours of exploration, and
the time when sailing down the river on the raft I "took the raft and ate
it" which caused the program to crash!
Not owning a computer until well into the 90s I was later to find the game
all over again in "Lost Treasures" only to give them up with my machine
when I moved to the U.K. two years ago. At last I've picked up where I left
off (in Sherlock, on the Thames, going after the ruby!) through the release
of Masterpieces (I mourn the loss of Hitchhiker!) and have discovered this
wonderful world of IF (first through AGT, believe it or not... and then
finally last year through Inform).
We are an odd community in the eyes of the commercially driven world.
Imagine people spending countless hours sweating over whether or not you can
"see" the red queen under a rug when you're standing on it.
A little bit like poets...
Kevin
Drone
Harman" <oz...@kasterborus.demon.co.uk> wrote:
> I have no real intention or desire to "compete" with these products because
> I don't think I have the skill and I don't see the point - there are 2
> perfectly good products out there so why bother? I want to develop something
> slightly different which approaches the problem from a different level of
> abstraction. And if that interests anyone else enough to want to take a look
> at what I've done, so much the better.
>
It's very likely that you can do what you want by playing around with (or
even replacing many of) Inform's standard libraries -- I don't know much
about TADS.
I have written my own C++ authoring libraries, and in the learning of
Inform, I was surprising at how 'low-level' it is -- and how similar the
result is in concept to a C++ implementation (only instantly
cross-platform). IE, there is an Inform language, which is independent
from the task of writing IF, much like the C or C++ language (think
hybrid), and there are Inform standard libraries, which adapt that fairly
generic language to the task of writing IF. The libraries have public
source code, and you can easily, knowing the Inform language, screw around
with them to change *any* of the standard text adventure behaviours to
something totally screwy.
For example, I'm in the middle right now of updating my third-person
patches from the 6.04 libraries to the 6.15 libraries (I think I have
those numbers right).
So even with my own authoring system already in place using C++ (with a
parser just as complex) -- I found myself completely converted to Inform.
It's that flexible.
You might want to check out some of the non-IF programs that have been
written in Inform (facetiously called "abuses"). I believe they're on
ftp.gmd.de though I don't know the directory. There is an implementation
of Tetris among them.
Drone.
Drone
Harman" <oz...@kasterborus.demon.co.uk> wrote:
> I have no real intention or desire to "compete" with these products because
> I don't think I have the skill and I don't see the point - there are 2
> perfectly good products out there so why bother? I want to develop something
> slightly different which approaches the problem from a different level of
> abstraction. And if that interests anyone else enough to want to take a look
> at what I've done, so much the better.
>
<sigh> Part two of my response. When I first saw this thread it was very
short, I wrote my reply, sent it off, looked for new articles, and WHAM!
twenty more appeared all at once, and of course, all my points have been
made. My patience with my ISP is wearing very thin.
Regards,
Redundant Boy.
Drone
doea...@aol.com (Doeadeer3) wrote:
> Hey! I have carpal tunnel and I smoke (low-tar, though. But I don't have
a Wyse
> and I just replaced my keyboard so the "e" key works again.)
>
Ouch. Do you really have carpal tunnel? Is it bad? I ran into an old
university roommate of mine the other day on the subway and heard a sad
story. This guy was *heavily* into playing the guitar. Now he's got CTS so
bad he can never touch the thing again, and he considers himself lucky to
have regained the ability to use a pen.
I started to think after that about how I have taken my fingers for granted.
Drone.
Drone
When I was writing my own C++ opus I had two techniques that allowed me,
within two days of finishing the Mac version, have a DOS version compiled
and running. One was, delegate all I/O commands, which are the most
mutable, to a single object called "interfacer". That puts 90% of the
problems in one small piece of code. The second was, though I was
programming on the Mac, have three manuals for different platforms of C++
implementations handy and only use functions that I can find in all three.
This prevented me from using a lot of special Think C "features" but I was
glad for it later.
Drone.
David Glasser
> I can't speak for TADS, but, while the 'default' syntax of Inform is
> definitely geared towards a certain way of doing things, Inform also has
> special syntax that calls machine opcodes directly. If they don't allow
> you to do what you want to do, I shall be quite surprised. Actually, for
> most things, I'd be surprised if even the 'default' syntax didn't allow
> you to do what you wanted.
>
> For an example of the range of Inform, play:
>
> ftp://ftp.gmd.de/if-archive/games/inform/freefall.z5
>
> You can then see the source in:
>
> ftp://ftp.gmd.de/if-archive/programming/inform6/examples/games/freefall.inf
>
> (but play the game before you look at the code. Really.)
>
> For examples of more 'normal' source, that directory has many more
> examples you could look at.
One piece of source code that expands text adventure parsing that Lucian
is being modest enough not to mention is nalian.inf, the code to
recognize a language from his excellent game Edifice. It's not quite
AI-complete natural language, but it at least makes you think it is.
(It might be in /if-archive/programming/inform6/examples/ or
/incoming/if-archive/.)
Also, though the parser is part of the run-time and written in C (as
opposed to Inform, where all the libraries are in Inform), TADS is
reasonably extendable, and newer versions are making it more and more
powerful.
If you do decide on some non-portable PC-only solution, some people may
get mad at you. Ignore them. You're writing it because you *want* to.
Someone will try to port it to Mac and UNIX and whatever, and even if
they can't, what's important is you enjoying it. Do whatever you want.
--David Glasser
gla...@NOSPAMuscom.com | dgla...@NOSPAMfcs.pvt.k12.pa.us
http://onramp.uscom.com/~glasser | http://www.geocities.com/SoHo/6028
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Interactive Fiction! MST3K! David Eddings! Macintosh!
David Glasser
> [Thought to self (please don't reply): There are platforms that don't
> support Java?]
OK, I know you said you don't want a reply, but...
One thing that isn't clear at first about Inform is that, though Inform
itself only runs on PCs, Macs, UNIX, Acorn, and a few others, it
compiles into the format that Infocom uses. This "ZCode" format has
several different 'strands' of interpreters (zip, frotz, pinfocom, itf,
etc.) and has been ported to everywhere from the above-mentioned
computers to early 80's personal computers (Apple II's, Spectrums, etc.)
to handhelds such as the Palm Pilot.
(TADS is also well ported, but the runtime requires enough memory to
make it unfeasible on smaller computers. TADS is great, though, and my
constant mention of Inform is not meant to put it down.)
Mark Stevens
<oz...@kasterborus.demon.co.uk> wrote:
>Most importantly, does anyone write their own Adventure systems any more, or
>do you just all use Inform or TADS?
Nope, these days I just use Inform.
And before that I used STAC.
And before that I used GAC.
And before that I used PAWS.
And before that I used Quill.
>If you use one of these, why? Is it because they are multi-platform, or
>because you don't have to do so much work, or what?
Mainly because they're multi-patform. Also because in the time it
would take me to write my own system and a set of stable libraries, I
could have written half a dozen decent bits of IF.
So personally, as a fiction writer, I'd prefer to write six pieces of
excellent Inform-based IF and have everyone enjoy them, rather than
get bogged down developing a new system that probably wouldn't be much
good anyway.
>Are they *really* that flexible?
For the moment. Something's got to give sooner or later. It's been
nearly 20 years since Zork first arrived -- and apart from an increase
in game size and speed, we're still using more-or-less the same code
engine. Elsewhere, in the shoot-em up genre, we've gone from Space
Invaders to Quake2.
Perhaps that's an unfair comparison. After all, no-one's complained
much about the format of the novel for the past 200 years.
/\/)ark
http://www.sonance.demon.co.uk/
HarryH
>Perl is a priori pretty reasonable as a "VM" system, but I don't think it
>has any advantages over Inform as an adventure language.
It does if you want to do Eliza style kind of conversation. Perl excels in
string handling and manipulation. Of course, Perl does not come with text
adventure library the way TADS and Inform do.
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Darin Johnson
> : Well-written ANSI C is in fact _very_ portable. It's just that many
> : people don't know how to write ANSI C.
>
> Have you looked at the inform source? The large number of #include
> calls for the various systems is amazing. Each one wants something
> completely different. And, as someone said earlier, that's assuming
> you've got a _fully_ ANSI compiler, which many laim to be, but few
> are.
That's a separate issue really. All the system dependent code can be
hidden inside a single interface file (don't know if Inform does that
or not though). All the rest of the code can be standard.
Part of the problem though is Inform is ported to systems that don't
have ANSI compilers available. But you don't need a fully compatible
ANSI compiler in order to use ANSI C, ie, you work around the bugs,
and stay away from esoteric features (trigraphs). For what Inform
does, I should think there doesn't need to be a lot of system
dependent code (unlike a runtime system).
--
Darin Johnson
da...@usa.net.delete_me
Todd Baumann-Fern
Paul 'Ozymandias' Harman wrote:
> I assume that'd be the TADS vs Inform flamewars? Don't worry, I'm also on
> the games.programmer newsgroups and I've seen enough DirectX vs OpenGL
> flamwars to prevent me asking the obvious "Which is Better" question..
Nah, there's not much of a flame war between the systems. Some people use or
are knowledgeable in more than one system.
You might get flamed for releasing a game that can only* be played on a IBM
compatible system. IF is used on such diverse systems. This news-group stands
testament to that....
--
--Bud tf...@midstate.tds.net
Jonadab the Unsightly One
> "Paul 'Ozymandias' Harman" <oz...@kasterborus.demon.co.uk> writes:
>
> > Thought I'd stick my oar in and see what I stir up.
>
> At which, Simon, who is easily baited, verily leaps onto the hook.
Teeheehee.
> > Most importantly, does anyone write their own Adventure systems any
more, or
> > do you just all use Inform or TADS?
>
> Most people, as far as I can tell, use either inform or tads. There
> are people out there developing their own stuff, but they're in the
> minority.
It seems of late that Inform is used most, and TADS second. Both Alan
and Hugo have followings as well. There's also AGT, but it's aimed
more at making the process easy, and experienced programmers
generally prefer a more flexible system. After that you get into various
systems (there are a couple dozen at least, I think) that have only
occasional finished games produced and only infrequent traffic on
this newsgroup.
> > If you use one of these, why? Is it because they are multi-platform, or
> > because you don't have to do so much work, or what?
Both of those reasons, plus the base of fellow users to help us when
we get into trouble ;-)
> > Are they *really* that flexible?
Yes. Inform can do anything from space invaders to tetris,
and it comes with an extensive library for text adventure games,
any part of which can be replaced or edited at will. It's even
designed to let you write adventures in other languages than
English if you so desire. It's completely flexible. Almost any
programming problem you invent can be solved in it several
different ways, according to preference.
I don't use TADS myself, but it's fairly flexible as well.
There are two different libraries for it, in fact.
> > I assume they are compilers/interpreters for their own languages.
>
> You assume correctly (nearly). They both generate platform
> independent binaries. There are interpreters for most hardware
> platforms.
By most, he means "pretty much everything, except certain older
brands of pocket calculator". You can run a z-code module on
several different types of palmtops, on mainframes, on most any
Mac, on Apple // series, on Commodore 64, on TRS 80, on PCjr,
under Unix, VMS, and DOS, and pretty much anything with
a c compiler, basically. I think the z-machine for the BBC micro
is still under development...
Say, how many platforms support z8, though?
> > If so, are
> > there any systems out there that are (effectively) libraries or APIs
> > designed to be called from C? Would there be a market for such an
animal?
>
> I don't know if there are any good ones. Would there be a market?
> Maybe.
Yeah, there would. If it were free, and if it were full-featured (see
below).
> The problem with this is mainly portability. Any game would
> have to be recompiled for each platform it runs on. And we all know
> how *standard* 'C' compilers are. Harrumph!
Well, how many *major* desktop platforms are left without gcc?
> My opinion is that, unless your proposed library is revolutionary in
> its approach, you are unlikely to get many takers.
The trouble is that we're all already using one of the existing systems
for our game-in-progress. So converting would be a major deal.
It'd have to be really worthwhile. AI-complete NPCs would do it...
But even to attract new users, you need to match the existing free systems,
particularly Inform and TADS.
> You'll need a
> really good parser, decent NPC AI and a whole shedload (tm) of other
> stuff before people will look at it.
Save. Restore.
(Same saved game format on all platforms would be a plus).
Undo. (Multi-Undo is a big plus, I'm told).
Cross-platform VM (more portable than Java).
Your parser will need to be able to cope with "Bob, take all the golden
keys except number six and toss them in the big black pit."
You'll need to be able to handle having the player character change
in play.
Automatic light checking.
Scope checking flexible enough to handle a red ball in a transparent
cube which is in an open box on a bench in the room the
player can see through the window.
If all that doesn't scare you off, go for it. I'd like to see a C library
to handle all that stuff. It'd be cool.
> Before you even try, You'll need to get into inform and TADS, play
> games based on both of them, and see what you're up against.
Yeah. If you haven't played any of the large IF released in the
last couple of years, play a couple before you start, even if you
rely on hints from rec.games.int-fiction to solve the puzzles.
--
All my usenet posts are General Public License.
Dyslexic email address: ten.thgirb@badanoj
Adam J. Thornton
Doeadeer3 <doea...@aol.com> wrote:
>Hey! I have carpal tunnel and I smoke (low-tar, though. But I don't have a Wyse
>And I was never really a hacker, so I guess it doesn't fit, anyway.
>
>But can I still be bitter?
I guess you can. If you *must*. <grumble> As if it'd help. As if life
weren't an endless series of system calls that don't work the way they say
they will, and vaporware, and man pages *five years* out of date[1]. Sure,
be bitter, if you think it'll make you feel better. See if *I* care.
<grouch>
Adam
[1] I'm running Linux 2.1.120. In my current project I have a need to pass
open file descriptors between unrelated processes. This requires sendmsg()
and recvmsg(). sendmsg(2), on a Red Hat 5.1 system, is the BSD man
page--although the actual call has SysV syntax and semantics--and is dated
24 July 1993. Further, it claims
WARNING: This is a BSD man page. As of Linux 0.99.11,
sendmsg was not implemented.
Sometime between 0.99.11 and 2.1.120, the SysV sendmsg *was* implemented.
I'm pretty sure it was there in 2.0.34, which is what ships with Red Hat,
so it's not just that I am playing kernel-of-the-day.
Fortunately I had access to a Solaris box, so I could discover what was
going wrong when I got an error not specified in the BSD man pages.
Aaargh.
Andrew Plotkin
> nearly 20 years since Zork first arrived -- and apart from an increase
> in game size and speed, we're still using more-or-less the same code
> engine.
No, no, I can't accept that. The Inform programming environment is
*vastly* different from what Infocom used. (And Michael Berlyn has
testified that it's better. :-) We're building the same kind of games --
that was the fundamental point of my "'Spective" rant -- but the OO
approach (uneven as it is) and the full-imperative-language model makes it
a whole lot easier.
> Elsewhere, in the shoot-em up genre, we've gone from Space
> Invaders to Quake2.
> Perhaps that's an unfair comparison. After all, no-one's complained
> much about the format of the novel for the past 200 years.
That's absolutely my point of view. (But it applies to what's being done,
not the code we use to do it.)
Andrew Plotkin
> That's a separate issue really. All the system dependent code can be
> hidden inside a single interface file (don't know if Inform does that
> or not though). All the rest of the code can be standard.
This winds up being slightly fuzzy, because some systems like to put
non-portable code on *top*. For example, Robert Pelak's excellent Mac port
of Inform has a Mac-native log window that starts up first; then you push
a "compile" button that effectively calls Inform as a function. So there
have to be #ifdefs around what would normally be main().
And then the Mac needs #ifdefs inside tight loops, because it uses
(razafrazzing grn blah) cooperative process scheduling, so you have to
yield every so often as well as check for update events and interrupt
keystrokes... et cetera. It's the little ugly details that get you. A
non-ANSI file system is peanuts by comparison.
This is why Glk abstracts file stuff and I/O stuff into an interface, but
doesn't even try to abstract the *top* level. That has to be ported. It's
the nature of the task.
Al Staff
>amount of work.
>
>1) Language design
>2) Architecture design
>3) Compiler program
>4) Interpreter program, or run-time support if you're building native code
>5) Repeat 4 for Windows, DOS, Mac, Unix, Acorn, Pilot...
>6) Getting people to download and run your brainchild
I'd like to point out that if you're writing your own game from scratch, it
doesn't necessarily mean you are creating an entire game creation system for
others to use so it doesn't have to be any where near as hard as some may think
unless you are trying to support multiple platforms which I am not doing (that
is the only real downside I see to writing my own). I've written my own text
adventure game without TADS, Inform, or any others. I did it myself. When (if)
I make another game, it will be my own design again. Why? First because I like
doing it that way. Second because I'm fluent in the computer language I use
which in my opinion is easier than trying to learn the language of one of the
well known creation systems.
Al Staffieri Jr.
Lucian Paul Smith
: One piece of source code that expands text adventure parsing that Lucian
: is being modest enough not to mention is nalian.inf, the code to
: recognize a language from his excellent game Edifice. It's not quite
: AI-complete natural language, but it at least makes you think it is.
*blush*
: (It might be in /if-archive/programming/inform6/examples/ or
: /incoming/if-archive/.)
Well, I'm not so embarrased that I won't tell you where it actually is.
It's still at:
ftp://ftp.gmd.de/if-archive/unprocessed/nalian.inf
as of 9/10/98, but I *hope* it will move to the inform6/examples/
directory soon (which is where the XYZZY link leads. Aargh!)
-Lucian
Paul 'Ozymandias' Harman
Frank Filz wrote in message <35F806...@mindspring.com>...
> 1 just use Inform, Tads, Hugo, Alan, or whatever
> 2 write some new add on libraries for one of the above
> 3 write a new standard library for one of the above
> 4 add some feature to the compiler, run time, or both
> for one of the above systems
> 5 utilize part of one of the above systems to plug
> the capabilities into some other game system
> 6 design a whole new adventure system from scratch
My goal is to write a library which handles the object manipulation side of
Adventure programming: putting objects into other objects, taking, dropping,
inventory lists, moving from room to room, meeting people; and so on. The
parser and human-computer interaction parts of writing an adventure would be
left to the programmer since the way I see it, that's game dependent (is it
a graphical or text game, to bring it to it's most crude level).
Of course, if there was an Inform API (or TADS/Alan/HUGO) then the sort of
things I'd want to do have already been done.
What I want to have is something that can do the drudgery of Adventures for
me, but leave the input/output with the player alone.
So it's not really any of the above options!
Where I have confused people is part-way throughout this discussion I got
side-tracked into how *I* would design a new system - option 6 above. That's
not quite what I have in mind.
Ozzy
Paul 'Ozymandias' Harman
Mark Stevens wrote in message <36035cb1...@news.demon.co.uk>...
>Nope, these days I just use Inform.
>And before that I used STAC.
>And before that I used GAC.
>And before that I used PAWS.
>And before that I used Quill.
Crikey.
I used STAC, and found it incredibly frustrating because it had its own very
stong ideas about how an adventure should be written, which weere at odds
with my own. Didn't stop me knocking up a few things though!
And I remmeber GAC on a friend's Amstrad CPU464 and a tape drive... took
forever to load but it was excellent fun watching it take 30 seconds to draw
the graphics! And I loved the Gen-Lock thingummy you had to put on the
screen to get it to run.
>Mainly because they're multi-patform. Also because in the time it
>would take me to write my own system and a set of stable libraries, I
>could have written half a dozen decent bits of IF.
};*)
I'm not a big IF writer, actually (although I'll probably get bitten by the
bug again while I'm working on my current project). So I'm not so keen to
churn out quality IF by the ton. It's of more interest to me to help others
write good IF.
>For the moment. Something's got to give sooner or later. It's been
>nearly 20 years since Zork first arrived -- and apart from an increase
>in game size and speed, we're still using more-or-less the same code
>engine. Elsewhere, in the shoot-em up genre, we've gone from Space
>Invaders to Quake2.
But for text-only games, there can't be much to improve on, really, can
there? The only directions left to go are *good* networked multi-player text
games (not MUDs, I've never seen anyone playing a game in a MUD, they just
hang around in the chat room), and better parsers and AI for creatures
inhabiting the world.
>Perhaps that's an unfair comparison. After all, no-one's complained
>much about the format of the novel for the past 200 years.
You can't improve on perfection. (implicit smiley)
Ozzy
Paul 'Ozymandias' Harman
Jonadab the Unsightly One wrote in message
<01bddd00$c46a9620$06118fd1@jonadab>...
>Yes. Inform can do anything from space invaders to tetris,
>and it comes with an extensive library for text adventure games,
>any part of which can be replaced or edited at will. It's even
>designed to let you write adventures in other languages than
>English if you so desire. It's completely flexible. Almost any
>programming problem you invent can be solved in it several
>different ways, according to preference.
Nothing but nothing is completely flexible.
I'm willing to admit that Inform/TADS/Hogo/Alan look incredibly powerful,
but I dare say that (since it's designed for writing IF) it has pretty good
ideas about how IF should be written. And if they are in conflict with your
own, then all of a sudden it doesn't seem so flexible.
[Although I expect you could write your own parsers in them, and so on, if
you really wanted to]
Which is why I feel that having a set of libraries for C or whatever can
only be more powerful (but possibly more obfuscated).
>But even to attract new users, you need to match the existing free systems,
>particularly Inform and TADS.
That depends - what I'm considering is not aimed at the same people.
>Save. Restore.
> (Same saved game format on all platforms would be a plus).
Simple.
>Undo. (Multi-Undo is a big plus, I'm told).
Fairly simple... record each set of moves as a delta and roll each one back
when undo is called. Or just RAM-save everything!
>Cross-platform VM (more portable than Java).
That's the sticking point. What do you write your VM in? If Java is out,
that leaves ANSI C and (possibly) Perl, or Tcl/Tk (urgh).
>Your parser will need to be able to cope with "Bob, take all the golden
> keys except number six and toss them in the big black pit."
Ah, but I don't intend to have a parser. I/O will be the job of the
programmer, not the libraries. Because I don't see the libraries being used
exclusively for Text adventures, but also from pure graphical ones; or
arcade platform adventures. Or 3D games.
>You'll need to be able to handle having the player character change
> in play.
?
>Automatic light checking.
An absolute must in any game.
>Scope checking flexible enough to handle a red ball in a transparent
> cube which is in an open box on a bench in the room the
> player can see through the window.
Ouch. That's not very nice. But it's not prohibitively difficult... you just
keep scanning objects inside objects until you reach something that's
completely opaque on all sides, then stop.
>If all that doesn't scare you off, go for it. I'd like to see a C library
>to handle all that stuff. It'd be cool.
Oh, I'll go for it. But don't expect too much success this side of this time
next year. I don't get much free time for programming at home.
Anyone want to offer me a job to do this for lots of cash? };*)
Ozzy
Joyce Haslam
David Glasser <gla...@NOSPAMuscom.com> wrote:
> If you do decide on some non-portable PC-only solution, some people may
> get mad at you. Ignore them.
Don't answer them, don't explain yourself, don't subject us to another
flame war.
> You're writing it because you *want* to.
> Someone will try to port it to Mac and UNIX and whatever, and even if
> they can't, what's important is you enjoying it. Do whatever you want.
Joyce.
--
Joyce Haslam
q u e r c u s @ a r g o n e t . c o . u k
Mark J Musante
> I used STAC, and found it incredibly frustrating because it had its own very
> stong ideas about how an adventure should be written, which weere at odds
> with my own. Didn't stop me knocking up a few things though!
I imagine the phrase "knocking <something> up" means something entirely
different in the UK.
In the States, it's a very crude way of expressing the fact that intercourse
has resulted in pregnancy.
"And then I found out I'd knocked her up." "Wow. What's that make now?
Three? Four?" "Seven." "Ouch."
-=- Mark -=-
Simon 'tufty' Stapleton
>
> Don't answer them, don't explain yourself, don't subject us to another
> flame war.
Spoilsport! Now that the N*rni* thread has disintegrated, it's only
generating 60-70% of traffic on rgif. And the OS Poll thread isn't
performing up to expectations, either. The only real flamage is from
interpretation of spaces in unix for god's sake. What we need is a
*real* flame war.
I suggest a post along the lines of this, crossposted to the various
system advocacy groups.
You sad gits! I'm developing a new Adventure system that will blow
all your rubbish away. I'm only developing it for windows 98 on
pentium 400s because all other operating systems are trash. I
tried to use inform and TADS but they were rubbish, as are all the
games developed using them. The system will be free, but the
runtime engine will cost $300. Narf! Fnord! £%^*%^$%NO CARRIER
Paul 'Ozymandias' Harman
Mark J Musante wrote in message ...
>Paul 'Ozymandias' Harman (oz...@kasterborus.demon.co.uk) wrote:
>> I used STAC, and found it incredibly frustrating because it had its own
very
>> stong ideas about how an adventure should be written, which weere at odds
>> with my own. Didn't stop me knocking up a few things though!
>
>I imagine the phrase "knocking <something> up" means something entirely
>different in the UK.
Cobbled it together. Threw it together. Knocked it up.
"Banged up" is the UK equivalent to "Knocked up"
Ozzy
Den of Iniquity
>Paul 'Ozymandias' Harman (oz...@kasterborus.demon.co.uk) wrote:
>> Didn't stop me knocking up a few things though!
>
>I imagine the phrase "knocking <something> up" means something entirely
>different in the UK.
Nope. :)
Watch a few Carry-On films. You'll probably hear it again.
--
Den Surely you also have the sense 'to quickly put together' in the US?
Den of Iniquity
>Andrew Plotkin <erky...@netcom.com> wrote:
>>Now we're burnt-out shells of humanity, mumbling in abandoned wiring
>>closets and halon-filled machine rooms, twitching neurotically when
>>someone says the words "Visual C++". But we were idealistic young hackers
>>*once*.
>
>Don't forget the part about swilling cheap Scotch by the light of a failing
>monitor and posting bitter little rants to alt.sysadmin.recovery about how
>much we hate everything. And chainsmoking unfiltered Camels in the gutted
>shells of IBM DASD cabinets, pounding away with our crabbed claw-like
>carpal-tunnelled fingers at Wyse-50 terminals with the "h" key missing.
I feel obliged to make an admission: I'm an imposter.
I'm typing tis on a Wyse-85 terminal, for a start. onestly.
--
Den
Mary K. Kuhner
Andrew Plotkin <erky...@netcom.com> wrote:
>And then the Mac needs #ifdefs inside tight loops, because it uses
>(razafrazzing grn blah) cooperative process scheduling, so you have to
>yield every so often as well as check for update events and interrupt
>keystrokes... et cetera. It's the little ugly details that get you. A
>non-ANSI file system is peanuts by comparison.
I'd like to emphasize Zarf's point here. As a programmer of
freeware, widely distributed scientific software, I can say from
bitter experience that while you can whump up some ANSI C and
get it *running* on the Mac fairly quickly, your users will hate
it. An early release of one of our packages ignored interrupts,
so you could accidentally start a number-crunching analysis that
would take hundreds of hours to complete, and there was no way
to make it stop. Reboot time. There are also issues like leaving
windows lying around after the program terminates, getting output
in an appropriate place, and so forth. Our Unix-native code
was portable, all right, but it was really unpleasant to use on
a Mac, and we heard about it a *lot*.
Mary Kuhner mkku...@genetics.washington.edu
Mark Stevens
<oz...@kasterborus.demon.co.uk> wrote:
>I used STAC, and found it incredibly frustrating because it had its own very
>stong ideas about how an adventure should be written, which weere at odds
>with my own.
I know what you mean. I seem to recall a few of us actually hacking
into it to knock down some of its limitations -- especially with
things like room descriptions, which seemed to be limited to something
like 255 characters. I found a cunning way of getting round that
within the engine though -- something like writing some high priority
routines that captured the room number and appended a corresponding
message number to the room's description.
>And I remmeber GAC on a friend's Amstrad CPU464 and a tape drive...
The BBC B version was an interesting experience -- you had all of 13k
in which to write your adventure! Needless to say, a bit of
hackery-whackery went on there in order to get GAC to read its data
off a disk instead of memory.
>I'm not a big IF writer, actually (although I'll probably get bitten by the
>bug again while I'm working on my current project). So I'm not so keen to
>churn out quality IF by the ton. It's of more interest to me to help others
>write good IF.
If that's the case, then you should be positively encouraged to
develop your own authoring system.
>But for text-only games, there can't be much to improve on, really, can
>there?
I think AI's the most logical step forward. After all, the Infocom
gang were heavily into that at MIT. I seem to remember seeing an
edition of Micro Live (or whatever it was) back in the mid-80s that
had a feature on Infocom, where they were talking more about AI
development than their actual adventure games.
It's a tricky thing though -- by its very nature, AI development is
naturally heading towards a desire to create "self aware" and
"sentient" AIs. But within the context of a piece of interactive
fiction, the author needs to keep a very tight reign on what his
non-player characters should and shouldn't do.
I've got visions of a near future whereby you're playing a piece of
interactive fiction, only for the troll guarding the bridge to stand
up, pull off his mask to reveal an AI actor, who promptly storms off
in a virtual huff, moaning about the degrading script and how he never
had any of this sort of trouble when Graham Nelson was directing.
>The only directions left to go are *good* networked multi-player text
>games (not MUDs, I've never seen anyone playing a game in a MUD, they just
>hang around in the chat room)...
You ought to try Avalon (the MUD, not the IF). Strong role-playing is
positively encouraged and the whole game's set up in such a way that
it becomes very difficult *not* to role play. The fact that you also
have to pay for it (albeit an extremely affordable fee) means that you
automatically cut out about 95% of the troublesome element. And I
suppose the fact that they actively advertist it as an interactive
RPG, rather than a MUD, helps.
Check out http://www.avalon-rpg.com/
Last I knew, they had a 10 hour free trial period thing going, so it's
certainly worth checking out. Although I must add that it does take
considerably more than 10 hours to get a proper feel for the game, so
use as many free trials as you want!
/\/)ark
http://www.sonance.demon.co.uk/
Adam J. Thornton
Paul 'Ozymandias' Harman <oz...@kasterborus.demon.co.uk> wrote:
>But for text-only games, there can't be much to improve on, really, can
>games (not MUDs, I've never seen anyone playing a game in a MUD, they just
>inhabiting the world.
Interestingly, there *are* systems that implement some pretty darn
sophisticated multi-player games.
The question becomes: WHY do players want to hang out in the Adventurer's
Lounge and talk rather than play with the objects and puzzles.
Your system worries me because I don't see anyone but other system
developers using it. If I'm writing a 3D game, I'll probably use
CrystalSpace because I don't have to put a 3D API on top of the object
library. If I'm writing a text adventure, I'll use Inform, because I don't
have to put a parser on top of the object library. If...you get the
picture.
And what if your notion of "object" isn't what theirs is? Either you're
going to be making some specific statements about what objects can and
can't be in games built around your engine, or your library is going to be
so abstract that it takes a prohibitive amount of work for a programmer to
make it useful for his specific case.
Joyce Haslam
> >Paul 'Ozymandias' Harman (oz...@kasterborus.demon.co.uk) wrote:
> >> Didn't stop me knocking up a few things though!
> >
> >I imagine the phrase "knocking <something> up" means something entirely
> >different in the UK.
> Nope. :)
It usta, but the natives are being educated in the correct use of their
language.
Joyce Haslam
Simon 'tufty' Stapleton <nob...@no.bloody.where> wrote:
> Joyce Haslam <que...@argonet.co.uk> writes:
> >
> > Don't answer them, don't explain yourself, don't subject us to another
> > flame war.
> Spoilsport! Now that the N*rni* thread has disintegrated, it's only
> generating 60-70% of traffic on rgif. And the OS Poll thread isn't
> performing up to expectations, either. The only real flamage is from
> interpretation of spaces in unix for god's sake. What we need is a
> *real* flame war.
Right, I'm going to write my next competition game in Archimedes Basic and
complain to the roof tops that I am being discriminated against because
only a minority of you lot have a machine that will run my masterpiece.
AISTR, that started the last one.
L. Ross Raszewski
> Den Surely you also have the sense 'to quickly put together' in the US?
>
The closest thing meaning that would be "knocked togehter", whic his rare in
most places,or (ironically enough) "banged up", though neither has the scope
or commonality of "thrown together"
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
L. Ross Raszewski
ad...@princeton.edu (Adam J. Thornton) wrote:
>
> The question becomes: WHY do players want to hang out in the Adventurer's
> Lounge and talk rather than play with the objects and puzzles.
Mostly because every time someone considers it, the internet gods send us a DB
crash to spite us for our arrogance
Drone
(Mark Stevens) wrote:
> On Fri, 11 Sep 1998 09:10:12 +0100, "Paul 'Ozymandias' Harman"
> <oz...@kasterborus.demon.co.uk> wrote:
>
> >But for text-only games, there can't be much to improve on, really, can
> >there?
>
> I think AI's the most logical step forward. After all, the Infocom
> gang were heavily into that at MIT. I seem to remember seeing an
> edition of Micro Live (or whatever it was) back in the mid-80s that
> had a feature on Infocom, where they were talking more about AI
> development than their actual adventure games.
>
Well, this seals it for *my* AI 'spective I think. You know a post landed
with a resounding 'thud' when there were no takers among the opposed. Ah
well, I'll file it in my already fat file of 'reasons I'm a kook'. Might
be useful when I have to pose an insanity defence.
:\
Drone.
Darin Johnson
> But for text-only games, there can't be much to improve on, really, can
> there? The only directions left to go are *good* networked multi-player text
> games (not MUDs, I've never seen anyone playing a game in a MUD, they just
> hang around in the chat room), and better parsers and AI for creatures
> inhabiting the world.
I've seen countless players actually playing games in MUDs. These
were of course, gaming MUDs, not social MUDs. Ie, the point of gaming
MUDs is to go out and explore, solve puzzles, slay beasts, and role
play. While there would usually be a handful of players in the bar,
most would be out adventuring. They were quite popular. Some were
quite sophisticated (though the more sophisticated, the more bogged
down the machine would inevitably be).
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
> I'd like to emphasize Zarf's point here. As a programmer of
> freeware, widely distributed scientific software, I can say from
> bitter experience that while you can whump up some ANSI C and
> get it *running* on the Mac fairly quickly, your users will hate
> it.
Hmm, last time I did UNIX-Windows portable code (never did Macs), I
did have an init and cleanup routine, along with a yield-like function
that was just a stub on UNIX but tested for some messages under
Windows (there was some wierd MAPI bug where I had to do this even
though I did not have any windows). Those three functions should
have been enough to support the Mac though.
--
Darin Johnson
da...@usa.net.delete_me
Frank Filz
> My goal is to write a library which handles the object manipulation side of
> Adventure programming: putting objects into other objects, taking, dropping,
> inventory lists, moving from room to room, meeting people; and so on. The
> parser and human-computer interaction parts of writing an adventure would be
> left to the programmer since the way I see it, that's game dependent (is it
> a graphical or text game, to bring it to it's most crude level).
>
> Of course, if there was an Inform API (or TADS/Alan/HUGO) then the sort of
> things I'd want to do have already been done.
At a low level, the Infocom Virtual Machine (which is what Inform
compiles to) provides some of what you are talking about. Inform and
TADS do already have an object library. They also give you a parser to
go with it. With Inform, you could very easily ditch the included parser
and build your own (which has been done). TADS has an alternate
standard library which builds a more complex basic object model.
To some extent, the parser isn't seperable from the object model. This
is because most of the code in the objects is reponses to interractions,
most of which come from the parser. Of course it is possible to set up
a graphical environment which would allow the same types of
interractions.
> What I want to have is something that can do the drudgery of Adventures for
> me, but leave the input/output with the player alone.
>
> So it's not really any of the above options!
I guess I should have included that option.
> Where I have confused people is part-way throughout this discussion I got
> side-tracked into how *I* would design a new system - option 6 above. That's
> not quite what I have in mind.
One question is once you make your library, how are you going to use
it? Do you have a system you can plug your library into?
Also, don't discount the value of having a parser library. TADS is
proof that this is valuable (since the TADS parser is only partially
under programmer control). 95% (or more) of Inform programs also use
the built in parser, just extending it to add new verbs or senses of
verbs.
--
Frank Filz
-----------------------------
Work: mailto:ff...@us.ibm.com
Home: mailto:ff...@mindspring.com
HarryH
>Right, I'm going to write my next competition game in Archimedes Basic and
>complain to the roof tops that I am being discriminated against because
>only a minority of you lot have a machine that will run my masterpiece.
And *I* am going to write the smallest, most realistic IF comp entry ever and
complain to the roof tops that I am being discriminated against because the
majority of the judges are too cheap to buy full-blown IF works and therefore
punish entrants whose entry can realistically be completed in under two
hours. :)
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
HarryH
mkku...@kingman.genetics.washington.edu says...
>bitter experience that while you can whump up some ANSI C and
>get it *running* on the Mac fairly quickly, your users will hate
So it's Apple's fault, right? ;)
>so you could accidentally start a number-crunching analysis that
>would take hundreds of hours to complete, and there was no way
>to make it stop. Reboot time.
Shouldn't the design take this into account and split the process into
multiple sessions, rather than relying on pre-emptive multitasking?
>There are also issues like leaving
>windows lying around after the program terminates, getting output
>in an appropriate place, and so forth.
Ah, it IS Apple's fault. Don't they have a shell or something like that
is just for this kind of programming? Especially since ANSI doesn't have
standards for graphics.
HarryH
>Your parser will need to be able to cope with "Bob, take all the golden
> keys except number six and toss them in the big black pit."
I've asked this before, and I'll ask this again:
What's wrong with
BOB, TAKE CHAIN (on which hang the keys)
BOB, GET SIX
BOB, PUT CHAIN IN PIT
?
What's wrong with two word parsers? Doesn't LucasArts uses them?
Then again, parsers that can parse this would be really cool.
Bob, take me to Jedi Master you will.
Tell Yoda: never Bob's mind on where he is!
HarryH
says...
>Perhaps that's an unfair comparison. After all, no-one's complained
>much about the format of the novel for the past 200 years.
If no one else will, then I will:
Contemporary novels have paragraphs that are way too short!
Limited vocabulary! Too market driven! Yada yada. :)
co...@innocent.com
>
> Back in the dim and distant past, I played an adventure game (I think it was
> called VIKING) on the BBC Model B, as part of a primary school project (I
> was 9 IIRC). I loved it, I was hooked. [Don't worry, I'm posting this to the
> right group. Bare with me]
>
> Two years later and now in Secondary School, I read "How to write Adventure
> Games" by Peter Killworth. By this time I had some programming under my belt
> and thought *why not*? So I started writing adventure games. And writing.
> And writing. I wrote in BASIC, to be honest, but that's nothing to be
> ashamed of. Not back then.
>
> Since then, I graduated to the Atari ST and now on to the PC. I write in
> several languages, and have written arcade games and platform games. But I'm
> itching to get back to writing what started me off - Adventures.
>
> So I have a few questions, and since I haven't seen the FAQ drift past
> recently I thought I'd come out and ask.
>
> Most importantly, does anyone write their own Adventure systems any more, or
> do you just all use Inform or TADS?
>
> If you use one of these, why? Is it because they are multi-platform, or
> because you don't have to do so much work, or what?
>
> Are they *really* that flexible?
>
> I assume they are compilers/interpreters for their own languages. If so, are
> there any systems out there that are (effectively) libraries or APIs
> designed to be called from C? Would there be a market for such an animal?
>
> Thanks for your time, feel free to email me if you don't want to clutter the
> group up.
>
> Ozzy
>
>
I
Alan Conroy
>there any systems out there that are (effectively) libraries or APIs
>designed to be called from C? Would there be a market for such an animal?
Adventure Builder uses its own compiler, like most (all?) of the other
authoring systems, but for a different reason. The precursors to
Adventure Builder were, in fact, a subroutine library. Each game
program would call these routines to do all the house keeping chores,
etc. However, when I created the first version for the PC (what was
Quest V1.0 in 1987), I didn't want people to have to own a compiler to
write an adventure game. First of all, my desire was to make a tool
for non-programmers (yes, some programming is required, but you don't
have to be a career programmer). Second, it was written in Turbo
Pascal and I didn't want to require that everyone need to buy Turbo
Pascal to use the system. Besides, even if a professional programmer
used Quest, who knew which particular language compiler they had - and
I decided against C for the initial reason stated above. Thus, I
wrote a compiler/interpreter to go with the system so that you had
everything you needed.
Since I used a general-purpose language and kept the subroutine
library, Adventure Builder is much like the approach you mention.
What really integrates things is the intepreter, which calls all the
hosuekeeping functions at the appropriate times so that the game code
is straight-forward.
Incidentally, because Adventure Builder uses a general purpose
language (Sirius), the interpreter is a general-purpose Virtual
Machine, which could easily be ported to other platforms. I simply
lack the time or desire to do so (nor do I have a MAC, Palmtop, etc
etc). What little time I have to program on my own time is spent
working on the next version of Adventure Builder rather than porting
it to a bunch of different platforms.
Of course, that's all for the algorithmic part. The database
(objects, locations, words, etc) is compiled with a very
Adventure-Builder specific database compiler. Although one could use
a generic database product to manage the database, you'd still have to
have an adventure-specific schema for the database. Or you could take
the approach of other IF authoring tools and incorporate the
declarative stuff with the algorithmic code, which has both advantages
and disadvantages.
- Alan Conroy
I don't think much of our profession, but, contrasted
with respectability, it is comparatively honest. No,
Frederic, I shall live and die a Pirate King.
-- The Pirate King
TenthStone
in our collective minds on 12 Sep 1998 01:00:10 GMT:
>In article <36035cb1...@news.demon.co.uk>, ma...@sonance.demon.co.uk
>says...
>>Perhaps that's an unfair comparison. After all, no-one's complained
>>much about the format of the novel for the past 200 years.
>
>If no one else will, then I will:
>Contemporary novels have paragraphs that are way too short!
It's a conspiracy to make the novels seem longer than they are. Authors
can churn out cheap thrillers at a faster rate without the publishers
complaining that they look too thin.
>Limited vocabulary!
It's a conpiracy to make the novels seem shorter than they are. Shorter
words fit in less space, make the novel denser and therefore cheaper to
produce. Publishers don't mind because of the inferior teaching of new
schools makes young readers hesitant to sit down to too long of a novel.
>Too market driven!
It's a conspiracy to make novels seem better than they are. Readers
connect more with language and concepts they experience in daily life.
Authors can dispense with careful planning and research because they
already know everything important for their novel.
>Yada yada. :)
It's a conspiracy to make novels seem worse than they are. Repeated
use of buzzwords causes readers to laugh at the poor writing skills of the
authors. Publishers know readers want the ensuing superiority rise.
-----------
The inperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
HarryH
>har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) caused this to appear
>in our collective minds on 12 Sep 1998 01:00:10 GMT:
>It's a conpiracy to make the novels seem shorter than they are. Shorter
>words fit in less space, make the novel denser and therefore cheaper to
I think you are confusing narrow range of words with short words. "She is
inarticulate" is shorter than "Listening at her talk makes one wonder how
could a female expresses words in such a long and winded manner."
Limited vocabulary results in longer novels.
>>Too market driven!
>
>It's a conspiracy to make novels seem better than they are. Readers
[snip]
>>Yada yada. :)
>
>It's a conspiracy to make novels seem worse than they are. Repeated
>use of buzzwords causes readers to laugh at the poor writing skills of the
>authors. Publishers know readers want the ensuing superiority rise.
Actually, this is an example of market driven implementation. The original
was "Etc, etc.", but the focus group found it old-fashioned, preferring
instead the modern "hip" style. The same said group also shot down "Wakko
wakko" as the new, original alternative.
TenthStone
>In article <35fb080d...@news.erols.com>, mcc...@erols.com says...
>>har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) caused this to appear
>>in our collective minds on 12 Sep 1998 01:00:10 GMT:
>>>Limited vocabulary!
>>It's a conpiracy to make the novels seem shorter than they are. Shorter
>>words fit in less space, make the novel denser and therefore cheaper to
>
>I think you are confusing narrow range of words with short words. "She is
>inarticulate" is shorter than "Listening at her talk makes one wonder how
>could a female expresses words in such a long and winded manner."
>Limited vocabulary results in longer novels.
I knew this when I posted. I just had to contrast it with something, and
then I had to come up with, admittedly, markedly abstracted reasons.
Incidently, the second example's vocabulary isn't so poor as one might
think, and also expresses a more complex thought than the first. I don't
mean to argue with your statements -- they certainly have merit.
Moreover, the first sentence is choppy. Most authors would probably feel
a need to expand upon the concept, thus making the sentence as long as the
first.
Lastly, I don't really believe in any of the four conspiracies I listed;
but surely you understood that. I merely restate to clarify.
>>>Too market driven!
>>
>>It's a conspiracy to make novels seem better than they are. Readers
>[snip]
>>>Yada yada. :)
>>
>>It's a conspiracy to make novels seem worse than they are. Repeated
>>use of buzzwords causes readers to laugh at the poor writing skills of the
>>authors. Publishers know readers want the ensuing superiority rise.
>
>Actually, this is an example of market driven implementation. The original
>was "Etc, etc.", but the focus group found it old-fashioned, preferring
>instead the modern "hip" style. The same said group also shot down "Wakko
>wakko" as the new, original alternative.
Hmmm...
(this is how I laugh, by the way)
As an aside, if your sarcasm were be more pointed, it might be more
condusive to misunderstanding.
-----------
The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
Paul 'Ozymandias' Harman
Frank Filz wrote in message <35F987...@mindspring.com>...
>One question is once you make your library, how are you going to use
>it? Do you have a system you can plug your library into?
Well, at the moment I'm writing an Arcade Platform game that's going to need
an Adventure back-end to it... hence all the hints I've been dropping so
far. So yes and no - I have a project to plug it into, but it's not finished
yet.
Essentially the player can pick up, drop and activate items; and some items
are triggered by the presence of others. Such triggers would then be passed
on to the Adventure engine, and the effects would fall back to the graphical
front end.
With me?
>Also, don't discount the value of having a parser library. TADS is
>proof that this is valuable (since the TADS parser is only partially
>under programmer control). 95% (or more) of Inform programs also use
>the built in parser, just extending it to add new verbs or senses of
>verbs.
At the time of writing a parser library is of no use to me... but I get your
point if anyone in the real world wants to use the library to build text
adventures they'd be pretty peeved not to have a parser. At the end of the
day, the parser is just another way of generating the same triggers...
Ozzy
Paul 'Ozymandias' Harman
Adam J. Thornton wrote in message <6tbga4$rjd$1...@cnn.Princeton.EDU>...
>Your system worries me because I don't see anyone but other system
>developers using it.
Do you mean "Developers of other systems such as TADS" in this statement?
I can see where you're going with this...
> If I'm writing a 3D game, I'll probably use
>CrystalSpace because I don't have to put a 3D API on top of the object
>library. If I'm writing a text adventure, I'll use Inform, because I don't
>have to put a parser on top of the object library. If...you get the
>picture.
I suppose so.
But if you write games in a number of genre (as I do) - 3D, text adventure,
platform, isometric - it might be nice to be able to use the same back-end
for all the games you write. At least that's been the theory with my other
back-ends that I've developed.
>And what if your notion of "object" isn't what theirs is? Either you're
>going to be making some specific statements about what objects can and
>can't be in games built around your engine, or your library is going to be
>so abstract that it takes a prohibitive amount of work for a programmer to
>make it useful for his specific case.
That's the danger with everything of course: if you try to bow to
everybody's wishes, your library has to become extremely general and thus
loses it's power.
But then again that's a problem that everyone faces: if I'm to invent a new
language, how powerful should it be? If I'm going to write an adventure
creation system, should I make it "open" like Inform or "closed" like STAC?
You're damned either way.
I think Inform and TADS have hit a nice happy medium from the IF point of
view. But since I'd like to use my adventure library for other game genres
(notably 3D, and I don't see anyone claiming you can write Quake-like 3D
games in Inform!) then I can't really use any of the existing systems.
I'm just gonna write it so it can o all the stuff I want to do - and that's
not too limiting, I hope - and see what that gives me. Each object int he
game will have ample spare boolean and numeric attributes free for the
user's use and some "expandable space" hanging off the end. And they'll also
be able to use the scripting language to get the engine to do unusual things
if the API doesn't let them do it at an abstract enough level.
Just toying with ideas...
Ozzy
Adam J. Thornton
>>Your system worries me because I don't see anyone but other system
>>developers using it.
>Do you mean "Developers of other systems such as TADS" in this statement?
Pretty much. It looks like only people writing game engines are going to
find this useful. And I think there are lots fewer of those than there are
people writing games.
But since you're in the first category, have fun. If I design a game
engine after your libraries have appeared, I'll have a look at them.
Den of Iniquity
>>Perhaps that's an unfair comparison. After all, no-one's complained
>>much about the format of the novel for the past 200 years.
>
>If no one else will, then I will:
>Contemporary novels have paragraphs that are way too short!
>Limited vocabulary! Too market driven! Yada yada. :)
Perhaps it's time you progressed beyond those Dick and Jane books then. ;)
--
Den
Jonadab the Unsightly One
Paul 'Ozymandias' Harman <oz...@kasterborus.demon.co.uk> wrote in article
> >5) Repeat 4 for Windows, DOS, Mac, Unix, Acorn, Pilot...
>
> Ah... if one is serious about multi-platform support, one writes in Perl
or
> in Java (urgh).
Not necessarily.
AFAIK there is no Java interpreter available for DOS, which still
has an astounding number of users (some of whom still don't
have a second OS, even, although an increasing number of them
do have Windows, if that counts). Someone said Perl was available
for DOS, but I have yet to see it myself, and it is highly unlikely that
Joe DOS User has already downloaded it. If you're serious about
cross-platform support, especially for text games, you probably
target something akin to the z-machine.
Speaking of which, if you made a C compiler that targeted (for
example) the z-machine, that would solve your entire game
portability problem.
And if you wrote the compiler itself in C, then it wouldn't be *too* hard
to compile it for various platforms. It probably wouldn't make it to the
Pilot, but it might make it to Unix, DOS, and Mac, which between them
probably account for 75%* of the IF community.
* - just a guess. Acorn and Amiga have fair userships as well.
I was figuring all Windows people as being able to run
a DOS binary.
--
All my usenet posts are General Public License.
Dyslexic email address: ten.thgirb@badanoj
Jonadab the Unsightly One
Paul 'Ozymandias' Harman <oz...@kasterborus.demon.co.uk> wrote in article
> >If it's so other people can create games, you need to make it
> >somehow better than inform or TADS. Not necessarily easier,
> >but better. Better AI, better parser, whatever. It has to be
> >better. And it has to be accessible. And well documented.
> >And supported.
>
> It's not quite that; it's so people who are writing (say) Arcade games
that
> want a bit of puzzle content have got a library to call that handles all
> that sort of stuff.
*SOUNDS* interresting. Actually, it's almost the reverse approach to what
I think some other people were thinking, i.e. to insert arcade snippets
into otherwise normal text adventures.
> But actually, at the end of the day, it's to prove to myself that I can
do
> it. Whether anyone else ever gets to see it or not is beside the point!
Then absolutely go for it.
And probably some other people will take a look at it, too.
Gevan
> [...]
> Speaking of which, if you made a C compiler that targeted (for
> example) the z-machine, that would solve your entire game
> portability problem.
I was thinking about that a few months ago when I was first working
on zRogue. It seems like most of the current ANSI C standard would
be doable -- at least, nothing leaps out of my memory and screams
"Ha! I'm way too hard!". The upcoming C9x standard, on the other
hand, wouldn't be possible.
The implementation of the standard library functions poses far more
of a problem, I suspect. Also, any straight-forward implementation
would not use some of the features of the Z-machine that would help
save resources -- for example, obvious approaches using, say, lcc
(the retargetable C compiler) would probably not use the standard
Z-machine stack. 64k of dynamic memory. Mmm-mmm. Not much to share
around, even if you're going to be as efficient as possible.
Ah, well. It remains on my list of neat-hacks-to-attempt-in-copious-
spare-time.
Drone
har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) wrote:
> In article <6tb9ik$19pe$1...@nntp3.u.washington.edu>,
> mkku...@kingman.genetics.washington.edu says...
> >bitter experience that while you can whump up some ANSI C and
> >get it *running* on the Mac fairly quickly, your users will hate
>
> So it's Apple's fault, right? ;)
>
> >so you could accidentally start a number-crunching analysis that
> >would take hundreds of hours to complete, and there was no way
> >to make it stop. Reboot time.
>
> Shouldn't the design take this into account and split the process into
> multiple sessions, rather than relying on pre-emptive multitasking?
>
> >There are also issues like leaving
> >windows lying around after the program terminates, getting output
> >in an appropriate place, and so forth.
>
> Ah, it IS Apple's fault. Don't they have a shell or something like that
> is just for this kind of programming? Especially since ANSI doesn't have
> standards for graphics.
>
(sigh) The same exact sorts of things can happen when programming in
Windows, or have you never seen a Windows program get in a tight-loop that
admits no external events or foul its clean-up duties? You might be more
accurate to say, the fault lies with GUIs.
Drone.
Drone
har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) wrote:
> I think you are confusing narrow range of words with short words. "She is
> inarticulate" is shorter than "Listening at her talk makes one wonder how
> could a female expresses words in such a long and winded manner."
> Limited vocabulary results in longer novels.
>
Heh heh. Perfect example of a perfectly logical argument that has nothing
to do with reality because it fails to take into account irrational
influences. A preponderance of authors with large vocabulary love to use
them. A lot. Thus ... longer novels.
Drone.
HarryH
dms...@york.ac.uk says...
>Perhaps it's time you progressed beyond those Dick and Jane books then. ;)
Absolutely right! In fact, I'm trying to decipher Shakespeare, right now.
Although I missed on Dick and Jane (since I have not been educated in US), I
understand that it is a required reading of some kind. However, few writers
progressed beyond the sixth grade level ability.
The problem is that even morons can claim that experience is the best
teacher. This I don't agree. I can have tons of bad experience and still be
less capable than someone with less (but high quality) experience. Do you
know that the advice most people give to novel writer wanna-be?
1. If you want to write, read! or
2. If you want to write, write!
Obviously something's wrong here. Here's my understanding of what steps are
REALLY needed for those novel writer wannabes:
1. Read
2. Read "How to Read a Book"
3. Read "How to Write a Damn Good Novel"
4. Write
Repeat until satisfactory. And, no, I am not joking.
Iain Merrick
> On 14 Sep 1998 17:14:18 GMT, Jonadab the Unsightly One wrote:
> > [...]
> > Speaking of which, if you made a C compiler that targeted (for
> > example) the z-machine, that would solve your entire game
> > portability problem.
> > [...]
>
> I was thinking about that a few months ago when I was first working
> on zRogue. It seems like most of the current ANSI C standard would
> be doable -- at least, nothing leaps out of my memory and screams
> "Ha! I'm way too hard!". The upcoming C9x standard, on the other
> hand, wouldn't be possible.
What on earth is the 'upcoming C9x standard'? I thought you were
referring to the standard library at first, but it looks like you're
talking about C itself.
What are They going to do to C? (Apart from giving it a dodgy non-Y2K
name.)
Gevan
> What on earth is the 'upcoming C9x standard'? I thought you were
> referring to the standard library at first, but it looks like you're
> talking about C itself.
>
> What are They going to do to C? (Apart from giving it a dodgy non-Y2K
> name.)
I shall attempt to avoid revealing my ignorance to too great a degree:
All sorts of things. Fixing up a few odd or inconsistent areas, clarifying
things, adding some standard library functions. On the feature line, it
looks like a few gcc extensions are being taken up, although all receiving
some modification -- struct member initialisation and array element initial-
isation (designated initialisers), variable length arrays, C++ style
comments, and the "inline" keyword. The implicit "int" for variable and
function declarations is gone, I think. Something like C++ mixing of
declarations and code is added, as is far more information about integral
type widths, including some fixed width integral types. A "restrict"
keyword (noalias back after much thought and fixing.) Um... ah... other
stuff. Perhaps somebody with more of a clue could step in?
As to the name, I guess it'll be given another one when it moves from
draft to final standard and they actually know what year it is. Or maybe
not. I think that's still expected to be in the next year or so.
If you're into that sort of thing, you can find the draft standard
(may not be the latest, I don't know) at:
TenthStone
appear in our collective minds on Mon, 14 Sep 1998 10:42:56 +0100:
>But if you write games in a number of genre (as I do) - 3D, text adventure,
>platform, isometric
Aside: this is counter the typical use of the word "genre" in these
regions of Usenet. More acceptable would be "interface."
>That's the danger with everything of course: if you try to bow to
>everybody's wishes, your library has to become extremely general and thus
>loses it's power.
I don't agree with that at all. I think expandibility has a lot to do
with pwoer. What it is, unfortunately, quite unhelpful with is ease of
use/development.
>I think Inform and TADS have hit a nice happy medium from the IF point of
>view. But since I'd like to use my adventure library for other game genres
>(notably 3D, and I don't see anyone claiming you can write Quake-like 3D
>games in Inform!) then I can't really use any of the existing systems.
What you're talking about is a portable graphics standard. A portable,
quick (emphasis) graphics standard. Not a bad idea, but... good luck.
One problem I foresee is that most people wouldn't use your standards
until they need graphics -- and few authors are willing to take the time
(or even have the time) to draw consistent graphics. Unless the entire
community banded together and hired an artist for general use (hmm...).
Andy Leighton
>
>> On 14 Sep 1998 17:14:18 GMT, Jonadab the Unsightly One wrote:
>> > [...]
>> > Speaking of which, if you made a C compiler that targeted (for
>> > example) the z-machine, that would solve your entire game
>> > portability problem.
>> > [...]
>>
>> I was thinking about that a few months ago when I was first working
>> on zRogue. It seems like most of the current ANSI C standard would
>> be doable -- at least, nothing leaps out of my memory and screams
>> "Ha! I'm way too hard!". The upcoming C9x standard, on the other
>> hand, wouldn't be possible.
>
>referring to the standard library at first, but it looks like you're
>talking about C itself.
>
>What are They going to do to C? (Apart from giving it a dodgy non-Y2K
>name.)
Add the C++ // comment for one.
Actually there are a number of bits and pieces that they are playing
with. The standard library has been fiddled with tod deal with the
new types - there are now complex numbers, long longs and multibyte
characters amongst others.
Fortunately the suggestion that C had primitive classes was rightly
junked.
And it is no means certain that it will be called C9X - the actual
standard might be published in the year zero so we could have C2K.
--
Andy Leighton => an...@azaal.dircon.co.uk
"... January is your third most common month for madness" - _Sarah Canary_
Drone
har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) wrote:
> 1. Read
> 2. Read "How to Read a Book"
> 3. Read "How to Write a Damn Good Novel"
> 4. Write
>
> Repeat until satisfactory. And, no, I am not joking.
>
The most important step is missing here. If you want to write, think. Do
that a lot. Do that more than you do any other step. Then once you've
thought, make decisions, and write about them. No other steps are
absolutely required.
Drone.
David Glasser
> "Paul 'Ozymandias' Harman" <oz...@kasterborus.demon.co.uk> caused this to
> appear in our collective minds on Mon, 14 Sep 1998 10:42:56 +0100:
>
> >I think Inform and TADS have hit a nice happy medium from the IF point of
> >view. But since I'd like to use my adventure library for other game genres
> >(notably 3D, and I don't see anyone claiming you can write Quake-like 3D
> >games in Inform!) then I can't really use any of the existing systems.
>
> What you're talking about is a portable graphics standard. A portable,
> quick (emphasis) graphics standard. Not a bad idea, but... good luck.
> One problem I foresee is that most people wouldn't use your standards
> until they need graphics -- and few authors are willing to take the time
> (or even have the time) to draw consistent graphics. Unless the entire
> community banded together and hired an artist for general use (hmm...).
Really? I was reading it as "portable (over interfaces and platforms)
object relations library". A portable graphics standard is PNG or JPEG,
nu?
--David Glasser
gla...@NOSPAMuscom.com | dgla...@NOSPAMfcs.pvt.k12.pa.us
http://onramp.uscom.com/~glasser | http://www.geocities.com/SoHo/6028
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Interactive Fiction! MST3K! David Eddings! Macintosh!
Greg Ewing
>
> In article <6tcfqt$lm6$3...@supernews.com>,
> har...@iu.net.idiotic.com.skip.idiotic.com (HarryH) wrote:
>
> > In article <6tb9ik$19pe$1...@nntp3.u.washington.edu>,
> > mkku...@kingman.genetics.washington.edu says...
> > >bitter experience that while you can whump up some ANSI C and
> > >get it *running* on the Mac fairly quickly, your users will hate
> >
> > So it's Apple's fault, right? ;)
Only if you think Apple did something wrong when
they showed us such a nice user interface style
that Mac users immediately fell in love with it
and came to expect all Mac programs to look that
way.
> > >so you could accidentally start a number-crunching analysis that
> > >would take hundreds of hours to complete, and there was no way
> > >to make it stop. Reboot time.
Since System 7, command-option-escape kills the
current foreground process (very rudely and abruptly,
like control-C in unix).
More of a problem is a program which you *want* to
leave running in the background, but which isn't
designed to yield processing time. Cooperative
multitasking isn't very multi when the players
don't cooperate...
> > >There are also issues like leaving
> > >windows lying around after the program terminates,
MacOS doesn't have that particular problem -
the Window Manager is usually smart enough to
remove any windows owned by a process when
it terminates.
> > Don't they have a shell or something like that
> > is just for this kind of programming?
Most Mac development environments provide a
text-only terminal emulation window, but
MacOS itself doesn't have anything like
that.
> You might be more
> accurate to say, the fault lies with GUIs.
Or with OSs that don't provide any pre-emptive
multitasking or memory protection.
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
Frank Filz
> > > >There are also issues like leaving
> > > >windows lying around after the program terminates,
>
> MacOS doesn't have that particular problem -
> the Window Manager is usually smart enough to
> remove any windows owned by a process when
> it terminates.
I once had a very intriguing "window leftover" in Windows...Even after a
re-boot, I had this window with no title, and a tiny, transparent,
client area. It finally turned out that it was being created by a
program which I was using which remembered what was running when you
exited Windows. It didn't know what application to run, but knew that
this window had existed, so it recreated it. Of course there was no
code to re-draw any of the program generated parts of the window.
--
Frank Filz
-----------------------------
Work: mailto:ff...@us.ibm.com
Home: mailto:ff...@mindspring.com
Joyce Haslam
>so you could accidentally start a number-crunching analysis that
>would take hundreds of hours to complete, and there was no way
>to make it stop. Reboot time.
Ah, but if that number crunching was the main thing on your mind, how
wonderful to set it going and know that it would be done soonest -
unless some bozo picked the do-not-disturb sign off the keyboard and
rebooted.
I think the subject line should be "getting back to fractals" but who
would find&follow it?
Joyce.
--
Joyce Haslam
http://argonet.co.uk/users/dljhaslam/ for Gateway to Karos [INFORM]
Powerbase is for Acorn RO3.1+ HTH. HAND.
q u e r c u s @ a r g o n e t . c o . u k
TenthStone
collective minds on Wed, 16 Sep 1998 16:51:14 -0500:
>TenthStone <mcc...@erols.com> wrote:
>
>> "Paul 'Ozymandias' Harman" <oz...@kasterborus.demon.co.uk> caused this to
>> appear in our collective minds on Mon, 14 Sep 1998 10:42:56 +0100:
>>
>> >I think Inform and TADS have hit a nice happy medium from the IF point of
>> >view. But since I'd like to use my adventure library for other game genres
>> >(notably 3D, and I don't see anyone claiming you can write Quake-like 3D
>> >games in Inform!) then I can't really use any of the existing systems.
>>
>> What you're talking about is a portable graphics standard. A portable,
>> quick (emphasis) graphics standard. Not a bad idea, but... good luck.
>> One problem I foresee is that most people wouldn't use your standards
>> until they need graphics -- and few authors are willing to take the time
>> (or even have the time) to draw consistent graphics. Unless the entire
>> community banded together and hired an artist for general use (hmm...).
>
>Really? I was reading it as "portable (over interfaces and platforms)
>object relations library".
I was reading the "Quake-like" part, which is why I came down so squarely
on the nay-sayer's side. 3D graphics... I wouldn't want to try that in
Windows NT.
>A portable graphics standard is PNG or JPEG, nu?
Um... yes.
But the difficulty is interpreters; sure, jpg would be fine, but what
about gif (especially -89a, the "animation" format)? I could see uses
for animated graphics in IF, but with every step in this direction more
compatibility issues arise.
Even more, how are graphics displayed? Full animation combined with text,
like King's Quest I? Just pop-ups, like The Hollywood Murders? The
latter would be a fairly easy case -- but where to display it? Should
one completely cover the screen, or make a special graphics window?
Paul 'Ozymandias' Harman
TenthStone wrote in message <3601b558...@news.erols.com>...
>gla...@NOSPAMuscom.com (David Glasser) caused this to appear in our
>collective minds on Wed, 16 Sep 1998 16:51:14 -0500:
>
>>TenthStone <mcc...@erols.com> wrote:
>>
>>> "Paul 'Ozymandias' Harman" <oz...@kasterborus.demon.co.uk> caused this to
>>> appear in our collective minds on Mon, 14 Sep 1998 10:42:56 +0100:
>>>
>>> >I think Inform and TADS have hit a nice happy medium from the IF point
of
>>> >view. But since I'd like to use my adventure library for other game
genres
>>> >(notably 3D, and I don't see anyone claiming you can write Quake-like
3D
>>> >games in Inform!) then I can't really use any of the existing systems.
>>>
>>> What you're talking about is a portable graphics standard. A portable,
>>> quick (emphasis) graphics standard. Not a bad idea, but... good luck.
>>> One problem I foresee is that most people wouldn't use your standards
>>> until they need graphics -- and few authors are willing to take the time
>>> (or even have the time) to draw consistent graphics. Unless the entire
>>> community banded together and hired an artist for general use (hmm...).
>>
>>Really? I was reading it as "portable (over interfaces and platforms)
>>object relations library".
>
>I was reading the "Quake-like" part, which is why I came down so squarely
>on the nay-sayer's side. 3D graphics... I wouldn't want to try that in
>Windows NT.
STOP!
The library I have in mind would be designed for handling the adventure side
of things. Graphics and player input would be the responsibility of the
programmer for the game.
That way, you can use my library for the generic adventure stuff, and your
own display code (Direct3D, OpenGL, QuickDraw, Tcl/TK, or whatever takes
your fancy).
I have no intention of inventing my own graphics standard! That's not what
the point is here. The point is to develop a library that can be used in
*any* style of adventure, be it textual or graphical; and leave the
"front-end" issues to the developer. That's where the mark of individuality
is stamped and where you make the game more personal (cf Company Style). I
wouldn't dream of attempting to impose a style on someone else's work.
Ozzy.