Any interest in a new IF development language?
Tommy Nordgren
hobby/shareware project.
I'm considering to implement the following features:
1) Generating C++ code and a datafile from object-oriented source.
2) Support Multimethod dispatching based on pattern matching.
3) Possibly also implement a parser generator, so support multiple
natural languages (Not in the same game)
Do you folks out there on the net think there would be any interest
for such a language
--
Tommy Nordgren <nordgre...@telia.com>
<http://w1.866.telia.com/~u86627430/>
Torstenssonsgatan 7A,2Tr,114 56 Stockholm
SWEDEN
+ 46 8 662 88 04
Nikos Chantziaras
> I'm considering writing a new adventure deveopment language as a
> hobby/shareware project.
> I'm considering to implement the following features:
> 1) Generating C++ code and a datafile from object-oriented source.
> 2) Support Multimethod dispatching based on pattern matching.
> 3) Possibly also implement a parser generator, so support multiple
> natural languages (Not in the same game)
> Do you folks out there on the net think there would be any interest
> for such a language
Well, actually no. More so if it's going to be released as shareware. And
even more so if it's based on C++, since the games will be OS specific,
which means I have to set up a *lot* of cross-compilers to provide
executables for those OSes.
But I think some people might actually use it, since such a system can be
extended in many ways; 3D IF games for example.
-- Niko
David Thornley
Tommy Nordgren <nordgre...@telia.com> wrote:
>I'm considering writing a new adventure deveopment language as a
>hobby/shareware project.
"As a hobby" is a very good reason; "shareware" isn't. There are plenty
of good IF languages that are free, and a shareware one isn't going to
get much use. (Adrift is something of an exception, but AFAIK it became
popular while freeware, and then the author released the 4.0 generator
as shareware.) Even if it's superior to everything else out there,
if it isn't obviously and clearly superior it isn't going to get much
use.
If you want it to have a chance at popular success, you should release
at least the first few versions as freeware.
>I'm considering to implement the following features:
>1) Generating C++ code and a datafile from object-oriented source.
There are several problems here.
First, it sounds like a game writer would need to have a C++ compiler,
and not everybody does. Unix people can get one easily, if they
don't already have one (and Linux and MacOSX count as Unix here).
For older MacOS versions, there's the Macintosh Programmer's Workshop
for free, and I suppose for MS Windows there's djgpp. I don't know about
C++ compilers on other platforms, and this is a very diverse group
in terms of platforms. Commercial C++ compilers normally cost hundreds
of dollars, so if would-be authors have to buy one that would be a big
obstacle.
Second, C++ normally compiles to native code, which means that
every platform would have to have its own binary version.
So, if you're thinking of supporting Microsoft Windows only, you
really do have to make integration with djgpp fairly seamless to
get any attention at all, and I don't really know of a community
that will be interested in a MS-only IF system designed for techies.
If you wanted acceptance in the r.a.i-f community, you'd be much
better off bypassing this with compilation to the z-machine,
glulx, the T3 virtual machine, or one of the languages that compiles
to that (basically, Inform and TADS 3). Alternatively, you could
compile to Java, since compilers are generally available and compiled
code can run on multiple platforms, or even Python or Perl. (Make
it Tcl and I won't touch it with an eleven-foot pole.)
>2) Support Multimethod dispatching based on pattern matching.
I'm not completely sure what you mean here, but, yes, multimethod
dispatching sounds like a natural for IF. I'm not sure anybody's
done it, but ISTM that it could make certain things very much easier
to code and get right. However, this by itself isn't going to get
it used.
Cool idea, though. It's worth remembering and maybe sticking in
some other time.
>3) Possibly also implement a parser generator, so support multiple
>natural languages (Not in the same game)
Again, I'm not completely sure what you mean, but Inform has been
used in multiple natural languages, and I don't see why TADS should
be different. They come with parsers that can be hacked to suit
(well, TADS 2 to a lesser extent, but you have to be impressed by
rematch.gam).
>Do you folks out there on the net think there would be any interest
>for such a language
>
As stated, no, not unless there was some other very compelling reason
to use it. I like the multimethod idea, though.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
John W. Kennedy
> First, it sounds like a game writer would need to have a C++ compiler,
> and not everybody does. Unix people can get one easily, if they
> don't already have one (and Linux and MacOSX count as Unix here).
> For older MacOS versions, there's the Macintosh Programmer's Workshop
> for free,
MacOS X includes the equivalent on a second CD-ROM in the package.
> and I suppose for MS Windows there's djgpp.
There's also plain ol' gcc.
--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
-- G. K. Chesterton, "The Man Who Was Thursday"
David A. Cornelson
news:BA6098D3.26CA%nordgre...@telia.com...
> I'm considering writing a new adventure deveopment language as a
> hobby/shareware project.
> I'm considering to implement the following features:
> 1) Generating C++ code and a datafile from object-oriented source.
> 2) Support Multimethod dispatching based on pattern matching.
> 3) Possibly also implement a parser generator, so support multiple
> natural languages (Not in the same game)
> Do you folks out there on the net think there would be any interest
> for such a language
With all of the OO languages out these days that have nowhere near the
complexity and leaning curve as C++, I'd say my opinion is no, there would
be no interest.
Since we already have languages like TADS, which is already very similar to
C/C++, Inform and Hugo, which have some C-like syntax, but stray into their
own syntax, it seems that your idea has been accomplished.
Now, having said that, is there a reason to design and build a new IF
development syntax, language, parser, compiler, interpreter? Sure. Just
because it's been done, doesn't mean you shouldn't try to do it better.
But here's a list of the complexity in what you intend:
1. syntax/language (easy): I think if you've played enough IF and maybe even
written some, have a strong programming background, syntax should be pretty
straight-forward.
2. parser (damn difficult): Even Inform, noted for its parser flexibility,
has some very complex and annoying patterns. Doing the parser is very likely
the hardest part of building a new IF system. Not to mention the fact that
Inform has successfully been ported to several languages.
3. compiler (difficult): Since you brought it up, my assumption is that you
know what goes into building a compiler. This is the part that I find
daunting, but others may think it's easy, especially with syntax-parsing
tools that build libraries for you.
4. interpreter (medium, but messy): Do you make it cross-platform? Does your
IF compiler create the whole program for one platform? Does it do full
graphics or simple text? Sound, speech?
Then there are other things that you can do that haven't been done, like
building a client/server paradigm (not a mud) specifically for 2, 3, 4
player IF games (not 10,000), which is something I have great interest in.
Now, having said all of that, if you have any interest in building a new
language syntax and writing an IF compiler to create C# Windows programs,
I'm all for it. Sadly, most on the newsgroups would find this to be some
horrible joke. I like C# and I'd like to see what could be done if we went
away from a limited Virtual Machine model.
That's my two cents.
Jarb
Tommy Nordgren
Cornelson (david dot cornelson at iflibrary dot com) wrote:
> "Tommy Nordgren" <nordgre...@telia.com> wrote in message
> news:BA6098D3.26CA%nordgre...@telia.com...
>> I'm considering writing a new adventure deveopment language as a
>> hobby/shareware project.
>> I'm considering to implement the following features:
>> 1) Generating C++ code and a datafile from object-oriented source.
>> 2) Support Multimethod dispatching based on pattern matching.
>> 3) Possibly also implement a parser generator, so support multiple
>> natural languages (Not in the same game)
>> Do you folks out there on the net think there would be any interest
>> for such a language
>
> With all of the OO languages out these days that have nowhere near the
> complexity and leaning curve as C++, I'd say my opinion is no, there would
> be no interest.
>
I DONT definitely don't intend to write the language as a C++ clone.
I intend to COMPILE the games to C++ code. C++ code can exucute much more
efficiently than a runtime based on a byte-code interpreter.
One of the major reasons I'm considering writing the language as a
source to source translator, is that I can use the c++ dynamic_cast operator
to support pattern matching.
I intend approximately the following syntax:
OBJECT HyperdimensionalStorageChest: container
.. //parts omitted
ioPutIn(a_Actor,dobj_Container) = {
"As you put << dobj.theDesc >> in << theDesc >> a rupture occurs
in space, sucking you through.";
die();
}
ioPutIn(a_,dobj_) = {
container::ioPutIn(a,dobj);
}
;
In this example, the Identifier after the underscore stands for a type
(usually a class or object) that the parameter must match.
I intend to supply default disambiguation rules to control in which
order arguments are matched agains methods.
--
John R. Strohm
Read Abelson & Sussman's "Structure and Interpretation of Computer
Programs". Spend some time playing with Scheme (a dialect of LISP).
Consider embedding your language in LISP, rather than writing Yet Another
Language With Weird Syntax. It will make it a lot easier for you to write
your translator.
If you can find a copy, take a look at Dave Betz's AdvSys authoring
language. It is basically a very simple dialect of LISP, with a few
interesting things built-in.
"Tommy Nordgren" <nordgre...@telia.com> wrote in message
news:BA6220ED.277E%nordgre...@telia.com...
Magnus Olsson
David A. Cornelson <david dot cornelson at iflibrary dot com> wrote:
>Now, having said all of that, if you have any interest in building a new
>language syntax and writing an IF compiler to create C# Windows programs,
>I'm all for it.
What about the portability issues? Are there .NET VMs for other systems
than Windows, or C# compilers that target other platforms than .NET?
--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol
David A. Cornelson
news:b1jbgn$2in$1...@news.lth.se...
> In article <oIednQNBLri...@speakeasy.net>,
> David A. Cornelson <david dot cornelson at iflibrary dot com> wrote:
> >Now, having said all of that, if you have any interest in building a new
> >language syntax and writing an IF compiler to create C# Windows programs,
> >I'm all for it.
>
> What about the portability issues? Are there .NET VMs for other systems
> than Windows, or C# compilers that target other platforms than .NET?
In the interest of doing something different, I'm not terribly interested in
cross-platform. Besides, with the Mono project well on its way to being a
productive platform (http://www.go-mono.com), I'd say the answer to your
question is yes. There is also a port of the entire CLI to both Linux and
Mac OS X, although those are for education purposes. When (not If), Mono
becomes strong enough to run apps in Gnome and Windows, then there will
probably be someone right around the corner porting it to Mac OS X and other
unices. Will these things run on a non-WinCE handheld, who knows.
Before a flame war erupts, my interest is solely in my own little ideas of
IF and are not community based. I wouldn't expect anyone else to care about
what I was trying to accomplish and would probably be stunned if anyone did
care. I've been around the IF community for about 6 years now and I know all
the ins and outs of the religion and some of it I'd adhere to and some of it
I'd dump faster than you can say "". The things I want to do I've discussed
ad-nauseum and the reactions have been across the entire spectrum.
Eventually, I just decided to stop communicating my ideas and work on them
either by myself or with people that have contacted me directly via e-mail.
Sadly, I think many other older community members are going this route as
well. It's my personal belief that innovation in the Interactive Fiction
community is being stifled by the whole cross-platform, anti-Microsoft,
open-source religious wars. I would prefer IF move towards a component-based
or object compostion architecture where reusable objects are the foundation.
.NET provides this paradigm, yet it does change many of the assumptions
about how we currently author/play IF games. I'd like to look past those so
called pre-requisites like using a cross-platform virtual machine because
there is more that can be done without it.
NOTE: .NET does not have a VM. It has an intermiediate language that is
just-in-time compiled to machine language.
If anyone wants to flame me for loving .NET, try reading this article by
Bertrand Meyer from Eiffel:
http://archive.eiffel.com/doc/manuals/technology/bmarticles/sd/dotnet.html.
I think this column pretty much explains the good, bad, and ugly about .NET.
Until I read this article, it never ocurred to me that someone out there
would _not_ appreciate Overloads. I guess Eiffel doesn't believe in them.
But even better, this article explains the dirty details of .NET that I
haven't seen anywhere else, not even on Microsoft's website. At least not as
clearly anyway. Between Mr. Meyer and Miguel de Icaza from Ximian, the one
point they make that's been my philosophy all along is that even if it _is_
Microsoft (despite their monopolistic tendancies), if it's great technology,
then as a developer, you owe it to your self to look at it.
Of course I still believe Inform, Tads, and Hugo are the elite class of
platforms for IF and will remain so for awhile. It doesn't stop me from
wanting to do something new despite the fact that some people will find this
a horribly stupid course of action.
Jarb
Mark 'Kamikaze' Hughes
<daviddotcornelsonatiflibrarydotcom>:
> In the interest of doing something different, I'm not terribly interested in
> cross-platform.
Go, you rebel single-platform Windoze developer, you! Nobody's ever
tried *that* before!
--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"We remain convinced that this is the best defensive posture to adopt in
order to minimize casualties when the Great Old Ones return from beyond
the stars to eat our brains." -Charlie Stross, _The Concrete Jungle_
Stephen Granade
> Sun, 2 Feb 2003 10:50:55 -0600, David A. Cornelson
> <daviddotcornelsonatiflibrarydotcom>:
> > In the interest of doing something different, I'm not terribly interested in
> > cross-platform.
>
> Go, you rebel single-platform Windoze developer, you! Nobody's ever
> tried *that* before!
In the context of IF, Windows-based projects are far fewer than
cross-platform ones, and have been since the late days of AGT. This
trend has only strengthened in the last five years.
Stephen
--
Stephen Granade
ste...@granades.com
Adam Thornton
Mark 'Kamikaze' Hughes <kami...@kuoi.asui.uidaho.edu> wrote:
>Sun, 2 Feb 2003 10:50:55 -0600, David A. Cornelson
><daviddotcornelsonatiflibrarydotcom>:
>> In the interest of doing something different, I'm not terribly interested in
>> cross-platform.
> Go, you rebel single-platform Windoze developer, you! Nobody's ever
>tried *that* before!
Mr. Hughes: Please do not encourage Mr. Cornelson's heresy.
Thank you,
Adam Thornton, IF Cabal Member #93, Sub-Chief of Speculative Repression,
Junior Grade
John W. Kennedy
> Read Abelson & Sussman's "Structure and Interpretation of Computer
> Programs". Spend some time playing with Scheme (a dialect of LISP).
Or with Common LISP. (There is a GNU implementation at
http://www.clisp.org.)
Neil Cerutti
Are Actor and Container types?
You may run into complaints from programmers used to freely using
underscores in identifiers.
> "As you put << dobj.theDesc >> in << theDesc >> a rupture occurs
> in space, sucking you through.";
> die();
> }
> ioPutIn(a_,dobj_) = {
> container::ioPutIn(a,dobj);
> }
> ;
I think it might be the first IF language with static
overloading. ;-)
> In this example, the Identifier after the underscore stands for
> a type (usually a class or object) that the parameter must
> match.
How do you plan to make the resulting C++ code compatible with
all known C++ implementations? If you won't do that, which
implementations will you support? Do you have a portable IO layer
in mind, like wxWindows, the Fox toolkit, ncurses or Glulx?
--
Neil Cerutti <cer...@trans-video.net>
Benjamin Fan
a new IF system/language, yes there is interest. Of course, not
everyone will be interested. However, at least one person (and
probably more) will be interested.
"David A. Cornelson" <david dot cornelson at iflibrary dot com> wrote:
> 2. parser (damn difficult): Even Inform, noted for its parser flexibility,
> has some very complex and annoying patterns. Doing the parser is very likely
> the hardest part of building a new IF system. Not to mention the fact that
> Inform has successfully been ported to several languages.
Not difficult. I apologize for the almost-entirely contrary
opinion, but I've just been working on a essay called "Parsers are
Easy" and thinking about this topic recently. Basically, I think that
writing the parser is not difficult because the first 80% is not
difficult. I suspect that other people think that writing the parser
is difficult because the last 20% is extremely difficult to do well.
Luckily, the last 20% is not really necessary, in my opinion.
(Non-standard grammar and disambiguation is in the last 20%.) Also,
depending on how the system is designed, the parser can be
written/improved incrementally so the difficult parts don't hinder
development of the rest of the system.
To add to my apology, I suspect that my standards for what
constitutes an acceptable IF system is lower than those of others who
use/develop the more-polished, mainstream IF systems.
Ben
--
To get my current email address, concatenate these three strings:
1. "benjamin_fan" 2. "_2002a" 3. "@yahoo.com"
It will look a lot like: xxxxxxxx_yyy_zzzzz @ yahoo . com
Daryl McCullough
>"David A. Cornelson" <david dot cornelson at iflibrary dot com> wrote:
>> 2. parser (damn difficult): Even Inform, noted for its parser flexibility,
>> has some very complex and annoying patterns. Doing the parser is very likely
>> the hardest part of building a new IF system. Not to mention the fact that
>> Inform has successfully been ported to several languages.
>
> Not difficult. I apologize for the almost-entirely contrary
>opinion, but I've just been working on a essay called "Parsers are
>Easy" and thinking about this topic recently.
I think that there are several different issues mixed up in the
question of whether a parser for IF is difficult or not. What makes
it difficult: (1) Interaction between the world model and the
parser: Commands typed by a player must generate actions that
affect the state of the game. Also, the game state (what objects
are in scope, for example) can affect the way commands are parsed.
(2) The parser needs to be easily extensible, so that the game
designer can easily add new words and new commands.
For a fixed grammar, a parser that converts text written in that grammar
into some structured parse tree is not very difficult (although to do
it efficiently may be more difficult, if the grammar is complex).
--
Daryl McCullough
Ithaca, NY
Magnus Olsson
Benjamin Fan <junkaccou...@yahoo.com> wrote:
>"David A. Cornelson" <david dot cornelson at iflibrary dot com> wrote:
>> 2. parser (damn difficult): Even Inform, noted for its parser flexibility,
>> has some very complex and annoying patterns. Doing the parser is very likely
>> the hardest part of building a new IF system.
>Basically, I think that
>writing the parser is not difficult because the first 80% is not
>difficult. I suspect that other people think that writing the parser
>is difficult because the last 20% is extremely difficult to do well.
>Luckily, the last 20% is not really necessary, in my opinion.
>(Non-standard grammar and disambiguation is in the last 20%.)
Well, there's the rub. I think you're correct in saying that when
people are speaking about parsers being difficult, they're talking
about those last 20%. But they're including those 20% for a reason -
they seem to think that those 20% *are* necessary.
Perhaps the argument should be reformulated:
Writing a simple parser isn't very difficult. If you can accept a
really simple parser, writing a two-word (verb-noun) parser a la
ADVENT is actually rather easy. And you can obviously play a game with
such a parser - people are still playing ADVENT and enjoying it.
But when it comes to designing a new adventure writing system, it
will not only have to be usable, it will have to be better than
the existing systems. If a new system doesn't have a parser that's
at least as good as that of Inform or TADS, people will be reluctant
to scrap those systems and use the new one instead.
Mike Roberts
> One of the major reasons I'm considering writing the language
> as a source to source translator, is that I can use the c++
> dynamic_cast operator to support pattern matching.
>
> I intend approximately the following syntax:
> OBJECT HyperdimensionalStorageChest: container
> ioPutIn(a_,dobj_) = { ... }
> ;
> In this example, the Identifier after the underscore stands for
> a type (usually a class or object) that the parameter must match.
You could just as well implement this with TADS or Inform source as the
target, you know. If TADS 2 were the target language, your compiler would
emit something like this:
ioPutIn(a, dobj) =
{
if (isclass(a, actor) && isclass(dobj, container)) { ... }
else { ... }
}
Which is exactly the way you'd do it with dynamic_cast<> in C++. I'm not
saying this is a reason you shouldn't use C++; just pointing out that C++
offers no advantage here, since you raised this as an example of why to you
plan to use C++.
--Mike
mjr underscore at hotmail dot com
Benjamin Fan
> Well, there's the rub. I think you're correct in saying that when
> people are speaking about parsers being difficult, they're talking
> about those last 20%. But they're including those 20% for a reason -
> they seem to think that those 20% *are* necessary.
I'm not so sure that the 20% is absolutely necessary. If the
Adams-Meretzky-Adams Co. were to announce that they had written a
new game but it had only a two-word parser, I would still play it
(I might even buy it). Most of my Infocom game play involved only
"verb the direct object on the indirect object"-type input, with
80% of input being just one- or two-word. Conversely, the best
parser in the world won't save a poorly-written game (like the
kind I might write).
> But when it comes to designing a new adventure writing system, it
> will not only have to be usable, it will have to be better than
> the existing systems. If a new system doesn't have a parser that's
> at least as good as that of Inform or TADS, people will be reluctant
> to scrap those systems and use the new one instead.
I'm not sure why everyone thinks that a new system *must* be
better than existing systems. I'm also not sure why everyone thinks
that people who write new IF systems want their system to replace
the existing systems. Neither of these are necessarily true.
David A. Cornelson
news:9ea00d5e.03020...@posting.google.com...
> m...@df.lth.se (Magnus Olsson) wrote:
>
> I'm not sure why everyone thinks that a new system *must* be
> better than existing systems. I'm also not sure why everyone thinks
> that people who write new IF systems want their system to replace
> the existing systems. Neither of these are necessarily true.
>
It's not that they need to be better, but in 18 years of being in the IT
industry I have yet to meet anyone that wants to build a
not-quite-as-good-but-different mousetrap.
I think the pre-requisite of all mouse traps is that you get rid of the
mice. So say, if you build a mouse trap that only gets rid of 80% of the
mice, well, that 20% will very likely turn into 120% and then you have a
real problem.
Jarb
Adam Thornton
David A. Cornelson <david dot cornelson at iflibrary dot com> wrote:
>industry I have yet to meet anyone that wants to build a
>not-quite-as-good-but-different mousetrap.
Scott Adams, sort of.
The _Adventureland_ parser is much, much less sophisticated than what
Zork could do at the same time. But _Adventureland_ would run in 16K of
ROM and a pittance of RAM, on a Vic-20 (for example), while Zork
required something like 32K of RAM and a disk drive.
Adam
ka...@henchmonkey.org
> I'm not so sure that the 20% is absolutely necessary. If the
> Adams-Meretzky-Adams Co. were to announce that they had written a
> new game but it had only a two-word parser, I would still play it
> (I might even buy it). Most of my Infocom game play involved only
> "verb the direct object on the indirect object"-type input, with
> 80% of input being just one- or two-word. Conversely, the best
> parser in the world won't save a poorly-written game (like the
> kind I might write).
Well, that's really the problem, isn't it? To be blunt, you're not
Adams, or Meretzkey, or even Plotkin or Short. We're not really sure
what sort of game you're going to be writing in your system. I might
give it a shot, if it's available on an OS I can use (hint: not
Microsoft), but if it's a two-word parser with none of the bells and
whistles that I've come to expect, you're flawless prose and stunning
imagery and inventive puzzles had better capture me _real_ fast.
katre
David Thornley
David A. Cornelson <david dot cornelson at iflibrary dot com> wrote:
>
>In the interest of doing something different, I'm not terribly interested in
>cross-platform.
Depending on what you're doing, this isn't necessarily a bad idea.
If you're trying to do something different, compiling to C++ or
something like that will probably save you time and trouble, and
there's really no point in making it portable when you don't know
quite where it's going.
If you're going to do it on one platform, it should be one you're
familiar with and have tools for. For many people, this winds up
being MS Windows. (Editorial comment about desirability of that
fact deleted.)
>open-source religious wars. I would prefer IF move towards a component-based
>or object compostion architecture where reusable objects are the foundation.
That's a heavyweight architecture for IF. It isn't clear to me that
the advantages are all that great, considering that it comes at a cost.
One of the current advantages is that most games are playable as is on
multiple platforms, and for some this includes PalmOS.
>.NET provides this paradigm, yet it does change many of the assumptions
>about how we currently author/play IF games. I'd like to look past those so
>called pre-requisites like using a cross-platform virtual machine because
>there is more that can be done without it.
>
I'm not convinced, but then I'm not somebody you have to convince.
Go ahead, and find out where your ideas lead you.
>Of course I still believe Inform, Tads, and Hugo are the elite class of
>platforms for IF and will remain so for awhile. It doesn't stop me from
>wanting to do something new despite the fact that some people will find this
>a horribly stupid course of action.
>
Well, I don't think it will work, but stupidity does not consist merely
of contradicting my first impressions. Go for it.
David Thornley
Anybody could implement a Scott Adams-style parser in BASIC without
a problem. All you really needed to write a SA-style game was an idea
and an interpreted BASIC, as long as you didn't care about split-screen
effects.
Magnus Olsson
>> Well, there's the rub. I think you're correct in saying that when
>> people are speaking about parsers being difficult, they're talking
>> about those last 20%. But they're including those 20% for a reason -
>> they seem to think that those 20% *are* necessary.
>
> I'm not so sure that the 20% is absolutely necessary. If the
>Adams-Meretzky-Adams Co. were to announce that they had written a
>new game but it had only a two-word parser, I would still play it
>(I might even buy it).
Yes, I might as well, but now we're talking individual *games*, not
development systems.
Games are unique. When wondering whether to download "A Grange in the
Heather" or "Uncle Febulon's Bill", you don't usually say "Well,
'Heather' has a slightly better parser, so I'll play that one first" -
there are so many other things that are more important. (Of course, a
truly awful parser may make a game a real pain to play, but we're not
talking truly awful parsers here, we're talking about those last 20%).
Devlopment systems, on the other hands, are like mousetraps. As Jarb
noted, people want a better mousetrap, not a new-but-slightly-inferior
one. A new development system has to be better than Inform or TADS to
be a success, not almost-but-not-quite as good.
>Most of my Infocom game play involved only
>"verb the direct object on the indirect object"-type input, with
>80% of input being just one- or two-word.
It's not really about accepting more complicated sentences than
that. It's about things like disambiguation, and guessing what the
player means, and supplying omitted words, like in
>light
(the flashlight)
>kill troll
(with the sword)
>Conversely, the best
>parser in the world won't save a poorly-written game (like the
>kind I might write).
That's very true - but when choosing a development system, people (at
least not most people) aren't assuming that their games will be so bad
that people won't notice a sub-standard parser. To put it another way,
which tool would you choose, one that makes it possible for you to
write games with a parser as good as Infocom's, or one which makes
it impossible to do so?
> I'm not sure why everyone thinks that a new system *must* be
>better than existing systems.
Because otherwise people won't use it. The world tends to work that
way (unless you're Bill Gates).
>I'm also not sure why everyone thinks
>that people who write new IF systems want their system to replace
>the existing systems.
I'm not really speaking about replacing the existing systems. I'm
talking about being used at all.
Magnus Olsson
I'd say that Infocom built rat traps and Adams built mousetraps, not
better rat traps.
Benjamin Fan
> industry I have yet to meet anyone that wants to build a
> not-quite-as-good-but-different mousetrap.
Not-quite-as-good-but-different mousetraps that are being built
today:
- Ones that leave the mouse alive, so you can release them outside.
- Ones that use glue, for those who don't want to see squashed mice.
- Ones that use cheese-scented plastic as bait, so you don't have to
provide your own food-based bait.
- Ones that kill the mice inside an enclosed box, so you don't have
to see dead mice.
- Ones that trap more than one mouse at a time.
- Ones that poison mice so they go somewhere else to die (not really
a trap) .
- Ones made out of cheaper materials and cheaper labor.
- Cats (require daily maintenance).
Other reasons why someone might want to produce a not-quite-as-good
mousetrap:
- National/Regional pride (buy mousetraps made right here in
Kreplachistan!)
- "Religion" (MS Mouse, GNUtrap 2.0, etc.)
- Different styles (art-deco, gilded, different colors, etc.)
- Hobbyist reasons (solar-powered, X10-enabled, "I built it myself!",
etc.)
- Historical sentiment (re-creations of 1800's-era wooden mousetraps,
the mousetrap designed from DaVinci sketches, etc.)
I guess my point is that there are many, valid reasons to be
different.
Ben
P.S. Reasonding to katre's post: Yes, I am no Adams or Meretzky.
No, the parser will be more than the two-word variety. Yes,
it will run on Java 1.2. No, there will be few or no puzzles--
I don't like puzzles. No, I write for me, and pleasing others
is not my highest priority. More generally, I am creating the
new system for me primarily. If others use it, then that's
okay. If they don't use it, then that's okay, too.
Mark 'Kamikaze' Hughes
<daviddotcornelsonatiflibrarydotcom>:
> "Benjamin Fan" <junkaccou...@yahoo.com> wrote in message
> news:9ea00d5e.03020...@posting.google.com...
>> better than existing systems. I'm also not sure why everyone thinks
>> that people who write new IF systems want their system to replace
>> the existing systems. Neither of these are necessarily true.
> It's not that they need to be better, but in 18 years of being in the IT
> industry I have yet to meet anyone that wants to build a
> not-quite-as-good-but-different mousetrap.
Ever hear of a little company called Microsoft? It's become a cliche,
but it's still true. MS has never created an original piece of
software, it's entirely based on seeing what's succeeding and ripping it
off: Tiny BASIC (MS Altair BASIC), CP/M (MS-DOS), file commanders
(MS-DOS Shell), the Mac (MS Windows), Word Perfect (MS Word Imperfect),
Netscape (MSIE, which was even based on Mosaic's source!)... Want me to
go on? At their very best, they do as well as the original software but
maybe a bit clunkier; 99% of the time, they just extend the
functionality somewhat, but add twice as many bugs and security holes
("Hey, let's make an email client that automatically runs any software
sent to it!").
The less awful answer is the open source community, which mostly does
not make original software, and often produces incomplete or ugly
software... But it's free, works on the platform of your choice, and
you've got the source if you want to fix or extend it.
People write new software for the sake of writing software *all the
time*. It's fun. It's not the same activity as using another person's
software, and you can't just transfer someone's desire for the former to
the latter. Few programmers can resist the challenge of writing some
program just because someone else has written it; the virtue of Hubris
often triumphs over the virtues of Laziness and Impatience.
I'm writing Aiee! <http://kuoi.asui.uidaho.edu/~kamikaze/Aiee/>
mostly because I have design goals that cannot be met with Inform or
TADS or Hugo, and I don't like working in those languages. But there's
also just a strong urge to write some code.
You cannot have worked 18 years in IT and never met a real programmer.
Where do you get off telling people not to write the software they
want to write?
Magnus Olsson
>> It's not that they need to be better, but in 18 years of being in the IT
>> industry I have yet to meet anyone that wants to build a
>> not-quite-as-good-but-different mousetrap.
>
>Not-quite-as-good-but-different mousetraps that are being built
>today:
>
> - Ones that leave the mouse alive, so you can release them outside.
> - Ones that use glue, for those who don't want to see squashed mice.
(etc).
It could be argued that all of these are actually *better* mousetraps,
for people who want some special feature.
The same goes for adventure writing systems, of course. If your new
system is better than Inform in some non-parser-related way, people
may want to use it even though the parser isn't as good.
>Other reasons why someone might want to produce a not-quite-as-good
>mousetrap:
>
> - National/Regional pride (buy mousetraps made right here in
> Kreplachistan!)
> - "Religion" (MS Mouse, GNUtrap 2.0, etc.)
> - Different styles (art-deco, gilded, different colors, etc.)
> - Hobbyist reasons (solar-powered, X10-enabled, "I built it myself!",
> etc.)
> - Historical sentiment (re-creations of 1800's-era wooden mousetraps,
> the mousetrap designed from DaVinci sketches, etc.)
>
> I guess my point is that there are many, valid reasons to be
>different.
Of course. And this is, after all, a hobby. If you *like* creating
a new adventure system, do so. And other people may learn from what
you do, even if they don't elect to use the system.
But most people posting here seem to have been addressing another
question: will people want to *use* your system?
> No, I write for me, and pleasing others
> is not my highest priority. More generally, I am creating the
> new system for me primarily. If others use it, then that's
> okay. If they don't use it, then that's okay, too.
This is a good reason for doing what you're doing.
Mark J. Tilford
> P.S. Reasonding to katre's post: Yes, I am no Adams or Meretzky.
> No, the parser will be more than the two-word variety. Yes,
> it will run on Java 1.2. No, there will be few or no puzzles--
I suggest trying to target Java 1.1, if you can; pre-MacOS X macs can only run
up to 1.1.(7 or 8), which I discovered after releasing jAsea.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Mark 'Kamikaze' Hughes
> On 4 Feb 2003 05:52:46 -0800, Benjamin Fan <junkaccou...@yahoo.com> wrote:
>> P.S. Reasonding to katre's post: Yes, I am no Adams or Meretzky.
>> No, the parser will be more than the two-word variety. Yes,
>> it will run on Java 1.2. No, there will be few or no puzzles--
> I suggest trying to target Java 1.1, if you can; pre-MacOS X macs can only run
> up to 1.1.(7 or 8), which I discovered after releasing jAsea.
It's nice if you can, but there's enough improvements in JDK1.2+ that
it's not really a good idea to weaken your code on other platforms.
I think it's time to write off MacOS 9-. Apple has. Most(? stats are
hard to come by, but apparently >50%) users on PPC systems have
upgraded. Most Mac developers have. Time for us "non-Mac developers
who still like having our code run on Macs" to join in.
John Colagioia
[...]
> I'm not so sure that the 20% is absolutely necessary. If the
> Adams-Meretzky-Adams Co. were to announce that they had written a
> new game but it had only a two-word parser, I would still play it
> (I might even buy it).
That's because the *game* would undoubtedly be "better" in a
measurable way. That is, the story would compensate for the
infuriating interface.
> Most of my Infocom game play involved only
> "verb the direct object on the indirect object"-type input, with
> 80% of input being just one- or two-word. Conversely, the best
> parser in the world won't save a poorly-written game (like the
> kind I might write).
But why handicap it to begin with? A good parser won't save a game,
but a bad parser will certainly harm it by making it less playable.
All the beautiful prose won't be seen, if you can't guess the verb/
noun pair that represents "open all doors except the skull-faced" on
the first move, right?
[...]
> I'm not sure why everyone thinks that a new system *must* be
> better than existing systems.
There are three reasons, as far as I can see, to build a new IF
system:
1. You just feel like it. If this were the case, you probably
wouldn't be telling us about it, and wouldn't be asking what the
interest level was. You'd be doing it, and maybe one day making
"killer games" to show us how cool you are.
2. You have some nifty idea from which you think the IF world would
benefit. Here, the rest of the system can probably slack off, since
it's really just there to highlight a feature you hope everyone else
will steal. *But*, that feature has to be interesting enough
("better") to get the attention of, say, Messieurs Roberts, Tessman,
et al.
3. You want to have your "name in lights" on the newsgroup. That
means you need a following. That means you need a way to "sell" your
system. That means it has to outclass somebody. TADS is the most
general language. Inform has a similar following because it's a
solid system which targets the really-nifty Z-Machine. Hugo (from
what I've heard) is "easier." ADRIFT has the GUI programming
environment. Each of these has succeeded to the extent it has
because it is demonstrably "better" in at least one way that matters
to a large group of people.
Does that explain it?
> I'm also not sure why everyone thinks
> that people who write new IF systems want their system to replace
> the existing systems. Neither of these are necessarily true.
One or the other almost certainly has to be. If you want a
substandard system that can't compete with what's out there, then why
bother? See item #1, above, if your answer is "because it'll be
fun"--you're wasting time arguing that would be better spent doing
what you want to do.
Or is there some alternative motive that I'm not seeing?
John Colagioia
I disagree, here, for exactly the reasons you state. The Scott Adams
games were clearly better for those on smaller machines. The parser,
itself, was inferior to Infocom's, but the overall system is (from
the proper perspective) vastly superior.
But you knew that, of course, which was why you qualified that with
"sort of," and wrote "Fellowship."
David Betz
"John Colagioia" <JCola...@csi.com> wrote in message
news:3E43B9F4...@csi.com...
Adam Thornton
David Betz <db...@xlisper.mv.com> wrote:
>In what way was the Scott Adams system "vastly superior" to Infocom's?
In the way that it would let you play something that resembled an
adventure game on a Vic-20 or TI-99/4a.
Adam
L. Ross Raszewski
TI Basic will let me play something that resembles an adventure game
on a TI-81 Graphics calculator. TI-Basic is a vastly superior IF
system to Infocom's.
Andrew Plotkin
> On Fri, 7 Feb 2003 16:36:36 +0000 (UTC), Adam Thornton <ad...@fsf.net> wrote:
>>In article <A9R0a.19789$2H6.677@sccrnsc04>,
>>David Betz <db...@xlisper.mv.com> wrote:
>>>In what way was the Scott Adams system "vastly superior" to Infocom's?
>>
>>In the way that it would let you play something that resembled an
>>adventure game on a Vic-20 or TI-99/4a.
> TI Basic will let me play something that resembles an adventure game
> on a TI-81 Graphics calculator. TI-Basic is a vastly superior IF
> system to Infocom's.
You're snipping the context and qualifiers that were in Adam's
original statement.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Joe Mason
> TI Basic will let me play something that resembles an adventure game
> on a TI-81 Graphics calculator. TI-Basic is a vastly superior IF
> system to Infocom's.
It's certainly a vastly superior IF system for the TI-81 Graphics
calculator than Infocom's.
Joe
Adam Thornton
If what you *have* is a TI-81, and not a computer capable of running a
Z-code interpreter, sure.
You may be too young to remember--I don't know for sure--but if I recall
correctly, at the time, a Vic-20 which could run the Scott Adams games,
plus the Commodore Datasette would run you maybe $300. A 48K Apple ][+
with a floppy drive was almost certainly north of $1000 at the same time.
I, personally, know that I had a Vic-20 a good long time before I had an
Apple, precisely *because* the Vic was a whole lot cheaper. Luckily my
parents eventually relented and bought me a *real* microcomputer, so I
won't have to murder them even though they never *DID* get me a pony.
Adam
David Betz
had never heard that suggested before.
"Adam Thornton" <ad...@fsf.net> wrote in message
news:b20nak$mdr$1...@news.fsf.net...
Benjamin Fan
> One or the other almost certainly has to be. If you want a
> substandard system that can't compete with what's out there, then why
> bother? See item #1, above, if your answer is "because it'll be
> fun"--you're wasting time arguing that would be better spent doing
> what you want to do.
>
> Or is there some alternative motive that I'm not seeing?
There are other reasons to build a new IF system, other than
the three you list (#1 to just do it but to do so quietly, #2 to
get established IF systems to use my great ideas, #3 to get fame
and a following of authors using my system). Here are some of my
motivations.
1. The reason why people play golf, even if they know they
will never be competitive enough to become a professional.
The reason why these same people like talking about golf.
2. To encourage others to experience the fun of creating a new
IF system.
3. The reason why the TADS developers don't give up developing
TADS and work on Inform instead. The same reason why Inform
developers don't give up developing Inform to go work on
TADS. Ditto and vice versa for all the other systems.
4. All new systems under development will be substandard at
first. Just because something is substandard now does not
mean that it will always be so. Just because I work on a new
system which is substandard now does not mean that my intent
is to create a product which is, and always will be, inferior.
5. To paraphrase Gekko, being different, for lack of a better
word, is good. Diversity benefits the IF community.
6. And, yes writing a new IF system is fun. I don't think that
I am wasting time when I talk about this activity.
Ben
P.S. I've been meaning to write to you to ask about your
recommendation to use a recursive-descent parser to parse
IF languages. I'll probably do this later, when I have
more time to concentrate on this project. I am still
thinking, in the back of my mind, of writing that
cleanroom Inform-to-glulx compiler.
Gadget
Fan) wrote:
> I am still
> thinking, in the back of my mind, of writing that
> cleanroom Inform-to-glulx compiler.
Erm... Maybe a silly question: what *is* a cleanroom Inform-to-glux
compiler?
-------------
It's a bird...
It's a plane...
No, it's... Gadget?
-------------------
To send mail remove SPAMBLOCK from adress.
L. Ross Raszewski
<junkaccou...@yahoo.com> wrote:
>4. All new systems under development will be substandard at
> first. Just because something is substandard now does not
> mean that it will always be so. Just because I work on a new
> system which is substandard now does not mean that my intent
> is to create a product which is, and always will be, inferior.
It sounded a lot like you wanted to place harsh limitations at the
heart of your system, and that locking it into being substandard was a
"goal"; you presented it as if you thought that the standard was
unnecessarily high.
>5. To paraphrase Gekko, being different, for lack of a better
> word, is good. Diversity benefits the IF community.
Lots of people who come in here wanting to produce some new IF system
claim this. It's not true.
Being different for the sake of being different is not good. "I'll
write a new programming language. It'll be just like C, only all the
Semicolons will be changed to dollar-signs. It's different, therefore
good." No, it's not. And it's not just a matter of it being "too
trivially different".
Diversity is good when what is different addresses something that what
came before didn't. Most people who come here wanting to build a new
IF engine really want to create a new IF engine just for the sake of
there now being n+1 rather than n of them. They don't really have
anything new to add to what's available in IF engines. You don't
create something for the sake of being different. You create something
for the sake of its being a worthwhile thing to be there. The beign
different happens on its own.
bd
> In article <9ea00d5e.03020...@posting.google.com>,
> Benjamin Fan <junkaccou...@yahoo.com> wrote:
>>"David A. Cornelson" <david dot cornelson at iflibrary dot com> wrote:
>>> 2. parser (damn difficult): Even Inform, noted for its parser
>>> flexibility, has some very complex and annoying patterns. Doing the
>>> parser is very likely the hardest part of building a new IF system.
>
>>Basically, I think that
>>writing the parser is not difficult because the first 80% is not
>>difficult. I suspect that other people think that writing the parser
>>is difficult because the last 20% is extremely difficult to do well.
>>Luckily, the last 20% is not really necessary, in my opinion.
>>(Non-standard grammar and disambiguation is in the last 20%.)
>
> Well, there's the rub. I think you're correct in saying that when
> people are speaking about parsers being difficult, they're talking
> about those last 20%. But they're including those 20% for a reason -
> they seem to think that those 20% *are* necessary.
>
> Perhaps the argument should be reformulated:
>
> Writing a simple parser isn't very difficult. If you can accept a
> really simple parser, writing a two-word (verb-noun) parser a la
> ADVENT is actually rather easy. And you can obviously play a game with
> such a parser - people are still playing ADVENT and enjoying it.
>
> But when it comes to designing a new adventure writing system, it
> will not only have to be usable, it will have to be better than
> the existing systems. If a new system doesn't have a parser that's
> at least as good as that of Inform or TADS, people will be reluctant
> to scrap those systems and use the new one instead.
>
Why not make the parser extensible in the resulting code? You could specify
a yacc-like grammar and the parser'd be extended with it. That way, you
could add those non-standard grammar rules as people notice them by adding
a few new rules in a central file.
--
Freenet distribution (temporary):
http://bd-home-comp.no-ip.org:8891/0qDGCziHJGY/
BARRY ... That was the most HEART-WARMING rendition of "I DID IT MY
WAY" I've ever heard!!
Benjamin Fan
> On 8 Feb 2003 09:56:26 -0800, Benjamin Fan
> <junkaccou...@yahoo.com> wrote:
> >5. To paraphrase Gekko, being different, for lack of a better
> > word, is good. Diversity benefits the IF community.
> You don't
> create something for the sake of being different. You create something
> for the sake of its being a worthwhile thing to be there. The beign
> different happens on its own.
Our opinions differ on this matter. If someone is
interested in creating something different, the fact that it is
different automatically makes it worthwhile. I'll concede that
if someone were to say "I don't want to create a new IF system,
but I'll make one anyway just to be different," then perhaps that
may not be worthwhile. However, most people who create something
different do so because they want something different
(plus, they tend to have additional reasons for wanting the
specific differences).
Ben
John Colagioia
> John Colagioia <JCola...@csi.com> wrote:
>>Or is there some alternative motive that I'm not seeing?
> There are other reasons to build a new IF system, other than
> the three you list (#1 to just do it but to do so quietly, #2 to
> get established IF systems to use my great ideas, #3 to get fame
> and a following of authors using my system). Here are some of my
> motivations.
> 1. The reason why people play golf, even if they know they
> will never be competitive enough to become a professional.
> The reason why these same people like talking about golf.
This doesn't strike me as a reason, but rather an attempt to handwave
needing to have a reason. Again, self-motivation (which is what I
think you're getting at) is fine (and encouraged), but if that's your
primary motivation, then you're literally wasting your time trying to
explain this.
> 2. To encourage others to experience the fun of creating a new
> IF system.
I'll grant that mileage may vary on this point, but, personally, I'd
rather see the creative folk work more toward new and better games,
or fixing perceived problems with existing systems.
The people who genuinely want to build a new system will do so,
regardless, and rarely need an outside push.
> 3. The reason why the TADS developers don't give up developing
> TADS and work on Inform instead. The same reason why Inform
> developers don't give up developing Inform to go work on
> TADS.
This is for two reasons, neither of which applies to a new system.
First, each of TADS and Inform have clear advantages over the other,
for particular purposes. Second, they both have a massive user-base
that would get rather ticked, should development stop.
> Ditto and vice versa for all the other systems.
This is more of that dangerous handwave-y stuff...
> 4. All new systems under development will be substandard at
> first. Just because something is substandard now does not
> mean that it will always be so. Just because I work on a new
> system which is substandard now does not mean that my intent
> is to create a product which is, and always will be, inferior.
On the other hand, if your initial target is inferiority, it will
likely not only start out as inferior, but will become very difficult
to improve.
If you're going to design something new, design it to be vastly
superior, then fall short for the first few iterations. It's a lot
easier to update code than it is to redesign something that already
exists.
> 5. To paraphrase Gekko, being different, for lack of a better
> word, is good. Diversity benefits the IF community.
Diversity benefits a community when there's an actual benefit to
the difference.
For example, when a newcomer stops by and asks "what language should
I use," which part of the community benefits from the deluge of
responses from people who say, "I have a substandard system that I
think you should use"? Who benefits from the dozens of unused IF
systems that live on the archive?
The community benefits far more from, say, ADRIFT showing what an IF
IDE might look like, or from TADS experimenting with new ideas in
text processing (as an example) for its new version.
Difference, just for the sake of difference, though ("I'm going to
make a language just like TADS, but data types will be named after my
ex-girlfriends, the semi-colon will be replaced by the tilde, and
arithmetic will be Reverse-Polish Notation") is just going to make
people ask "why."
> 6. And, yes writing a new IF system is fun. I don't think that
> I am wasting time when I talk about this activity.
Where I believe you *are* wasting time is telling me what a good idea
it is, and debating the merits. This time would be far better spent
either in development or in asking specific questions to help you on
your way.
> Ben
>
> P.S. I've been meaning to write to you to ask about your
> recommendation to use a recursive-descent parser to parse
> IF languages. I'll probably do this later, when I have
> more time to concentrate on this project. I am still
> thinking, in the back of my mind, of writing that
> cleanroom Inform-to-glulx compiler.
Sure. I'm around.
John Colagioia
John Colagioia wrote:
>> 5. To paraphrase Gekko, being different, for lack of a better word,
>> is good. Diversity benefits the IF community.
> Diversity benefits a community when there's an actual benefit to
> the difference.
I should have added, down here, that *competition* is good.
Diversity, just for the sake of diversity, is of marginal amusement,
sometimes, but isn't necessarily of any benefit.
John Colagioia
> On 8 Feb 2003 09:56:26 -0800, junkaccou...@yahoo.com (Benjamin
> Fan) wrote:
>> I am still
>> thinking, in the back of my mind, of writing that
>> cleanroom Inform-to-glulx compiler.
> Erm... Maybe a silly question: what *is* a cleanroom Inform-to-glux
> compiler?
"Cleanroom" in software, tends to mean a creation-from-scratch, with
nothing but textual reference material. In this case, the compiler
would be created using the Inform and Glulx reference material, but
no existing code.
I see this as potentially beneficial, because the multiple compiler
implementations can each add divergent features, allowing the Inform
language to evolve in the same way "real world" languages do.
Other people think it's just better to have a GPL Inform compiler.
Gadget
But wouldn't that mean there would be 'dialects' of Inform? I'm not
sure this would be a good thing... Especially since it is so easy to
add features to the language through libraries...
L. Ross Raszewski
It also has nice properties as a "test" of the technical documents;
far too many technical specifications I've seen rest very heavily on
the assumption that anyone who needs this is going to be using it
alongside the "reference" implementation. The nitfol interpreter was
developed from the ground up (I don't know whether it was developed in
isolation equivalent to a cleanroom), and a few of its more bizarre
behaviors come from things which are ambiguous in the spec, but which
never became an issue because everyone "already knew what was really
meant"
L. Ross Raszewski
<gad...@SPAMBLOCKhaha.demon.nl> wrote:
>
>But wouldn't that mean there would be 'dialects' of Inform? I'm not
>sure this would be a good thing... Especially since it is so easy to
>add features to the language through libraries...
>
>
Hopefully, we're talking more about divergent features in the compiler
(optimizations, etc.), but it is the case that the way many languuages
evolve is by compiler-specific language changes growing in popularity
and then being reintegrated into the "official" language.
Kevin Forchione
> I should have added, down here, that *competition* is good.
> Diversity, just for the sake of diversity, is of marginal amusement,
> sometimes, but isn't necessarily of any benefit.
One could argue that competition just for the sake of competition is of
marginal benefit as well. Unless something of value is produced from the
experience, then the act of multiple actors taxing a resource isn't
necessarily benificial or productive. The current state of spam is a case in
point. Surely these email can be said to be in some kind of competition, but
whether this is a *good* thing or not is dubious.
--Kevin
John R. Strohm
What was REALLY nice about it was that it paved the way for the Commodore
64.
I never did get around to buying a C-64.
"Adam Thornton" <ad...@fsf.net> wrote in message
news:b21kgl$t7a$1...@news.fsf.net...
Richard Bos
> I, personally, know that I had a Vic-20 a good long time before I had an
> Apple, precisely *because* the Vic was a whole lot cheaper. Luckily my
> parents eventually relented and bought me a *real* microcomputer, so I
> won't have to murder them even though they never *DID* get me a pony.
Be grateful. You would never have been able to get the pony to play
Zork.
Richard
Benjamin Fan
> On the other hand, if your initial target is inferiority, it will
> likely not only start out as inferior, but will become very difficult
> to improve.
>
> If you're going to design something new, design it to be vastly
> superior, then fall short for the first few iterations. It's a lot
> easier to update code than it is to redesign something that already
> exists.
Sorry to be contrary again, but the agile methodology that I am
using (eXtreme Programming) says the exact opposite. This is the
first time I've used this methodology, and the JIGSAW project is still
in its early stages. So, whether or not eXtreme Programming provides
long-term sustainability is still to be seen. However, from what
I've seen so far, the methodology works.
Regarding the other issues (valid reasons to do something, the
value of difference, etc.) I think that we just have a fundamental
difference of opinion.
Ben
Tommy Nordgren
Cerutti (cer...@trans-video.net) wrote:
> In article <BA6220ED.277E%nordgre...@telia.com>, Tommy Nordgren wrote:
>> in oIednQNBLri...@speakeasy.net, on 2003-02-01 23.24, David A.
>> Cornelson (david dot cornelson at iflibrary dot com) wrote:
>>
>>> "Tommy Nordgren" <nordgre...@telia.com> wrote in message
>>> news:BA6098D3.26CA%nordgre...@telia.com...
>>>> I'm considering writing a new adventure deveopment language as a
>>>> hobby/shareware project.
>>>> I'm considering to implement the following features:
>>>> 1) Generating C++ code and a datafile from object-oriented source.
>>>> 2) Support Multimethod dispatching based on pattern matching.
>>>> 3) Possibly also implement a parser generator, so support multiple
>>>> natural languages (Not in the same game)
>>>> Do you folks out there on the net think there would be any interest
>>>> for such a language
[some deleted]
>> I DONT definitely don't intend to write the language as a C++
>> clone. I intend to COMPILE the games to C++ code. C++ code can
>> exucute much more efficiently than a runtime based on a
>> byte-code interpreter.
>>
>> One of the major reasons I'm considering writing the language
>> as a source to source translator, is that I can use the c++
>> dynamic_cast operator to support pattern matching.
>> I intend approximately the following syntax:
>> OBJECT HyperdimensionalStorageChest: container
>> .. //parts omitted
>> ioPutIn(a_Actor,dobj_Container) = {
>
> Are Actor and Container types?
>
> You may run into complaints from programmers used to freely using
> underscores in identifiers.
>
I've thought of this. I might use some other operator character.
The underscore is used in the Mathematica Language, by the way.
>> "As you put << dobj.theDesc >> in << theDesc >> a rupture occurs
>> in space, sucking you through.";
>> die();
>> }
>> ioPutIn(a_,dobj_) = {
>> container::ioPutIn(a,dobj);
>> }
>> ;
>
> I think it might be the first IF language with static
> overloading. ;-)
>
Nope!!
Dynamic overloading. The dispatch will be done at runtime,
by a dispatch function that uses dynamic_cast to resolve
the parameter types.
Dispatching on classes of both recieving object and parameters
dyamically is what multimethods mean. This concept, by the way,
is used by the common lisp object system.(I don't know the syntax used
there).
Also, the mathematica expression evaluator works in a similar way.
>
> How do you plan to make the resulting C++ code compatible with
> all known C++ implementations? If you won't do that, which
> implementations will you support? Do you have a portable IO layer
> in mind, like wxWindows, the Fox toolkit, ncurses or Glulx?
Initialtially, I will support text io via standard streams.
This is very portable. For macintosh, where I know how, I'll
probably write a support function for save/restore
Here follows the example again, with comments:
OBJECT HyperdimensionalStorageChest: Container
.. //parts omitted
ioPutIn(a_Actor,dobj_Container) = {
"As you put << dobj.theDesc >> in << theDesc >> a rupture occurs
in space, sucking you through.";
die();
}
ioPutIn(a_,dobj_) = {
container::ioPutIn(a,dobj);
}
;
This would cause the following code to be generated:
class HyperdimensionalStorageChest_impl:public container_impl {
//Some parts left out
virtual void ioPutinDispatch(object* a,object * dobj) {
Actor_impl * aa;Container * cont;
if( (aa=dynamic_cast<Actor_impl *>(a))&&(cont=
dynamic_cast<Container_impl *>(dobj))) ioPutin_impl(aa,cont);
else
ioPutin_impl(a,dobj);
}
void ioPutin_impl(Actor_impl *,Container_impl*);
void ioPutin_impl(object *,object *);
}
--
Tommy Nordgren <nordgre...@telia.com>
<http://w1.866.telia.com/~u86627430/>
Torstenssonsgatan 7A,2Tr,114 56 Stockholm
SWEDEN
+ 46 8 662 88 04
Kevin Forchione
> "Cleanroom" in software, tends to mean a creation-from-scratch, with
> nothing but textual reference material. In this case, the compiler
> would be created using the Inform and Glulx reference material, but
> no existing code.
>
> I see this as potentially beneficial, because the multiple compiler
> implementations can each add divergent features, allowing the Inform
> language to evolve in the same way "real world" languages do.
>
> Other people think it's just better to have a GPL Inform compiler.
Does the Inform language need to evolve? Is there something wrong with it?
--Kevin
Kevin Forchione
news:YJx1a.7075$wH5....@nwrddc04.gnilink.net...
> Hopefully, we're talking more about divergent features in the compiler
> (optimizations, etc.), but it is the case that the way many languuages
> evolve is by compiler-specific language changes growing in popularity
> and then being reintegrated into the "official" language.
Is the user population big enough to support this? What features do you see
lacking in the current compiler?
--Kevin
Andrew Plotkin
> "John Colagioia" <JCola...@csi.com> wrote in message
> news:3E467824...@csi.com...
>> I see this as potentially beneficial, because the multiple compiler
>> implementations can each add divergent features, allowing the Inform
>> language to evolve in the same way "real world" languages do.
>>
>> Other people think it's just better to have a GPL Inform compiler.
> Does the Inform language need to evolve? Is there something wrong with it?
Nobody is claiming that Inform is perfect -- at least, nobody sensible.
Gadget
The one thing I'd like (I've said it before) is advanced string
handling... I still find it odd that a language for text-based
computer games does not have the equivalent of left$, mid$ and right$.
But it seems there are libraries for that now.
Matthew Russotto
Gadget <gad...@SPAMBLOCKhaha.demon.nl> wrote:
>On 8 Feb 2003 09:56:26 -0800, junkaccou...@yahoo.com (Benjamin
>Fan) wrote:
>
>> I am still
>> thinking, in the back of my mind, of writing that
>> cleanroom Inform-to-glulx compiler.
>
>Erm... Maybe a silly question: what *is* a cleanroom Inform-to-glux
>compiler?
A compiler from Inform to Glulx done by someone who had never seen any
Inform compiler code, and who therefore could not have copied it.
--
Matthew T. Russotto mrus...@speakeasy.net
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue." But extreme restriction of liberty in pursuit of
a modicum of security is a very expensive vice.
Matthew Russotto
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>
>It also has nice properties as a "test" of the technical documents;
>far too many technical specifications I've seen rest very heavily on
>the assumption that anyone who needs this is going to be using it
>alongside the "reference" implementation. The nitfol interpreter was
>developed from the ground up (I don't know whether it was developed in
>isolation equivalent to a cleanroom), and a few of its more bizarre
>behaviors come from things which are ambiguous in the spec, but which
>never became an issue because everyone "already knew what was really
>meant"
ZPlet was also developed ground-up, though not cleanroom (since I've
had extensive contact with ZIP and other interpreter) source, and I
noted a few ambiguities in the spec (resolved by the ZIP source, which
definitely ain't cleanroom -- in a cleanroom, if you have such an
ambiguity, your "clean" implementation team asks your "dirty" reverse
engineering team to find out the answer, so the implementation team
never sees that which will make them "dirty") when I did that.
John Colagioia
news:vHZ1a.177$fa4.18...@newssvr15.news.prodigy.com:
> Does the Inform language need to evolve? Is there something wrong with
> it?
I'm suspicious of questions like this. Is this intended to get me to say
something I'll regret? Instinct says no, but...
The word "need" and "wrong" are extremely loaded terms.
Does Inform "need" to evolve? No. Does Inform "need" to exist? Also
no, and neither does TADS, Hugo, or any other IF programming language.
Or any other programming language, for that matter.
Would the community of Inform users be well-served if Inform *did*
evolve? If it evolved in the sense of actual evolution--features
changing based on some form of selection mechanism--then it's impossible
for users to not see a benefit.
Is there anything "wrong" with Inform? It's serviceable, certainly,
and I'm a rather avid user of the language (despite my lack of published
works).
However, I had a professor who was fond of saying, "the story does not go
to describe how Moses received ten commandments and a piece of software."
Of course there's *something* wrong with it, whether or not I've seen it.
In fact, I've probably used Inform long enough that I'm blind to its
faults due to "ancient" workarounds.
The only practical way to find out is to try some variations, and find
out how it's received by new and old users alike. It seems to me that
it's certainly a healthier approach than to sit from up on high and
"deduce" (from user clamoring) which features should be added and
removed. That way lies "bloatware"...
Sorry for the long response, but I want to make sure I actually answered
what I believe is your question, rather than just blowing you off or
posting something incomplete.
John Colagioia
It depends on your perspective. Within their "community," there's
certainly a benefit--easier, cheaper, and more effective ways to blast
people with advertising. You and I might not find this beneficial, but
neither do (warning: generalization approaching) the First-Person
Shooter fanatics find improvements in the IF state of the art to be of
any benefit.
I'd go so far as to say that, within a community, competition among
tools *always* has some benefit, even if it is to only prove that a
particular feature is not needed (or needs work before it can be used)
at that particular time.
There's a potential drawback in possibly splintering a small community,
but we can't seriously think that, with all the IF systems sitting on
the IF Archive, and (presumably) all those that never made it to the
Archive, we're sitting at critical mass and that some small number of
added systems will destroy us.
Oh, sure, there's the added drawback that those people won't be working
on games, or on enhancing existing systems, but they probably weren't
going to (immediately) be doing these things, anyway.
John Colagioia
> John Colagioia <JCola...@csi.com> wrote:
>> On the other hand, if your initial target is inferiority, it will
>> likely not only start out as inferior, but will become very difficult
>> to improve.
>> If you're going to design something new, design it to be vastly
>> superior, then fall short for the first few iterations. It's a lot
>> easier to update code than it is to redesign something that already
>> exists.
> Sorry to be contrary again,
This would be an extremely boring thread if we were agreeing...
> but the agile methodology that I am
> using (eXtreme Programming) says the exact opposite. This is the
> first time I've used this methodology, and the JIGSAW project is still
> in its early stages. So, whether or not eXtreme Programming provides
> long-term sustainability is still to be seen. However, from what
> I've seen so far, the methodology works.
My (very brief) experience with it says the opposite. It seems to be one
of those things that will work if you're already building things
"right," but, of course, if you're doing that, then you don't need the
additional methodology...
I'd like to be proven wrong, though. I've seen too many development
methodologies come down the pipe that were utterly useless, and would
like to hear a success story.
My trained skepticism, though, says that changing a core design goal is
never going to work, once coding has started. I'd be irresponsible if I
didn't at least mention that.
> Regarding the other issues (valid reasons to do something, the
> value of difference, etc.) I think that we just have a fundamental
> difference of opinion.
Probably. I honestly don't mean to seem harsh. What I was hoping would
come out of the discussion were the specific points where you found the
existing systems lacking, in (obnoxiously arrogant, I'll grant) hopes of
making sure the development actually hits some of those goals.
But, as I said (or should have, if I haven't), don't let me stop you. I
just don't want to see yet another substandard system that gets hawked
at various opportunities.