[SUDS] Review (long)
David Cornelson
remarks about the new SUDS IF development too, I downloaded it. What the
heck, it looks like the developers put a lot of effort into it and didn't
even warn us about until they were actually done, a novelty in recent years
where new IF tool development is concerned.
Installation went without a hitch. The tutorial left something to be
desired. I was expecting windows to pop-up and tell me what to do, but it
just pointed me at their website. But I'm pretty windows savvy, so I just
busted right into the constructor.
The constructor is this tool bar that takes up about a fifth of my screen at
the top. It has menus and buttons for building objects, the map, people,
conversations, and relationships for these things. I played around with it
for while, but the thought that occurred to me was very simple, "This is not
better than using UltraEdit and writing Inform code. I'm not really
interested in learning a new language. I can see where someone new to the
genre may have an easier time with this though."
I like the idea of a windows development environment for Inform. I've
mentioned it a few times and even tried to get conversations going with
Plotkin and Nelson, all to no avail. They firmly believe that an IDE for
Inform or any other IF language is a waste of time. So far, they're right.
This IDE has one major flaw and it has to do with how the games are played.
If you open the player and open a game within the environment, you get this
left hand frame with objects and people listed. On the right-hand side you
get a description of the location on the top half and a description of
resulting actions in the bottom half. Yuck. If there's one thing that I
believe will or never should change about Interactive Fiction is the playing
environment. I don't like colors. I don't like bold type. Just grey or
yellow on a blue screen with a status bar at the top. No more, no less.
The next thing that's fundamental to me and should be improved, not
replaced, is the parsing ability of IF. SUDS basically removes the parser in
favor of a point and click environment. Since the current trend in IF is to
spell everything out for the user and concentrate on your writing and
storyline, this seems okay, but we still like to throw things in the middle
of a sentence or paragraph that the player needs to pick up on. I personally
hate the idea of reducing IF to a grid of options where you just list things
that you should try until you get the desired response. When you replace the
parser with a point and click environment, you've pretty much changed IF to
PACIF. They're just not the same in my book.
If the authors of SUDS had created a parsing environment, well, then we'd
have something. They could take some solid advice and build a player that
resembes an Inform interpreter (or TADS or HUGO) and they might actually get
some attention from the RAIF crowd. But without improving on what we already
have, they fall far short of making any impact at all. I would go so far as
to say they should have asked the RAIF crowd what _would_ be accepted. Then
spend all of that coding and design time building a tool that we _would_ be
interested in. Heck, if they built a really nice Inform Editor, I'd pay $100
for it. Most on RAIF wouldn't spend that much money, but if it was a very
effective tool that saved development time without hindering coding
flexibility, people _would_ pay for it.
I will say this though. SUDS is very well written and documented. Clearly,
the authors knew what they were doing and had a clear vision when doing it.
The problem is that they didn't get RAIF involved in the process and they
failed to target the IF audience properly. Then coming out and annoucning it
as shareware. Well, that was just naive. As everyone knows, IF folk are
notoriously frugal.
Anyway, that's my two cents. Build something that we want that helps us do
what we're already doing. Don't create something that tries to change us.
David Cornelson
aka Jarb
Liz & Andy
David Cornelson <dcorn...@placet.com> wrote in message
news:802ltt$544$1...@bgtnsc03.worldnet.att.net...
> After watching the endless banter about shareware vs. freeware and other
> remarks about the new SUDS IF development too, I downloaded it.
Thanks for your interest in SUDS. A few comments :
> Installation went without a hitch. The tutorial left something to be
> desired. I was expecting windows to pop-up and tell me what to do, but it
> just pointed me at their website. But I'm pretty windows savvy, so I just
> busted right into the constructor.
It's unfortunate that you're not "Windows-savvy" enough to recognise help
written in HTML, rather than WinHelp; or when a browser is pointing at a
local file rather than a 'net site. Many modern software packages go for
this approach. If you re-visit this area, you'll find significant effort
has gone into a full Tutorial, which is entirely separate from the online
web site. Perhaps the consistent house-style fooled you ;).
> If you open the player and open a game within the environment, you get
this
> left hand frame with objects and people listed. On the right-hand side you
> get a description of the location on the top half and a description of
> resulting actions in the bottom half. Yuck. If there's one thing that I
> believe will or never should change about Interactive Fiction is the
playing
> environment. I don't like colors. I don't like bold type. Just grey or
> yellow on a blue screen with a status bar at the top. No more, no less.
I'm disappointed that, whatever your views on the interface, you've devoted
no time to reviewing the actual game (Roman Adventure II) delivered with the
Player. This seems to reflects the group's obsession with system over
content.
> I will say this though. SUDS is very well written and documented. Clearly,
> the authors knew what they were doing and had a clear vision when doing
it.
Thanks!
> The problem is that they didn't get RAIF involved in the process and they
> failed to target the IF audience properly.
Sorry to break it to you but the IF audience consists of more people than
those who contribute to RAIF - as evidenced by those who've already
registered SUDS.
> Then coming out and annoucning it
> as shareware. Well, that was just naive.
Been there.
> Anyway, that's my two cents. Build something that we want that helps us do
> what we're already doing. Don't create something that tries to change us.
Apologies that daring to be different is perceived by you as a threat, not
an opportunity. I hope nevertheless that you'll enjoy any games produced
with
SUDS.
Andy Elliot
Nat Lanza
> > If you open the player and open a game within the environment, you get
> > this left hand frame with objects and people listed. On the right-hand
> > side you get a description of the location on the top half and a
> > description of resulting actions in the bottom half. Yuck. If there's
> > one thing that I believe will or never should change about Interactive
> > Fiction is the playing environment. I don't like colors. I don't
> > like bold type. Just grey or yellow on a blue screen with a status
> > bar at the top. No more, no less.
>
> I'm disappointed that, whatever your views on the interface, you've devoted
> no time to reviewing the actual game (Roman Adventure II) delivered with the
> Player. This seems to reflects the group's obsession with system over
> content.
Concentrating on the interface of the development environment seems
perfectly reasonable here. He's reviewing a _tool_, not a _game_. This
is a group of people who are interested in using IF systems to create
their own games with their own content; your complaint is rather like
criticizing a pilot for concentrating on how a plane's cockpit is laid
out instead of on how wonderful the places it can fly are.
I'm also not entirely sure why you decided to add the condescending
and insulting remark about "obsession with system over content". I
haven't really seen any indication that this is in fact true.
It seems to me that you've decided that the folks on r.a.i.f. are
little more than sadly misguided weirdos who don't understand what's
really important or why your approach is better, and I think that's a
shame. Your approach may well _be_ better, but as I haven't used it, I
can't really judge that. Even if it is, I believe you're doing both
yourself and the IF community a disservice with this attitude. Many of
the r.a.i.f. regulars have written many wonderful games and have years
of experience with IF. Tossing their opinions away because you don't
like them is short-sighted.
> > Anyway, that's my two cents. Build something that we want that helps us do
> > what we're already doing. Don't create something that tries to change us.
>
> Apologies that daring to be different is perceived by you as a threat, not
> an opportunity. I hope nevertheless that you'll enjoy any games produced
> with SUDS.
Is this how you plan to deal with all criticism of your system?
Insults and condescension? That's certainly an interesting public
relations choice.
I'm not really in the market for a Windows-only IF system, but if I
was I'm pretty sure I wouldn't want to use any system produced by
people who insult potential customers like this.
--nat
--
nat lanza --------------------- research programmer, parallel data lab, cmu scs
ma...@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/
there are no whole truths; all truths are half-truths -- alfred north whitehead
Mike Snyder
>"Liz & Andy" <lizn...@liznandy.freeNOSPAMTAserve.co.uk> writes:
>
>It seems to me that you've decided that the folks on r.a.i.f. are
>little more than sadly misguided weirdos who don't understand what's
>really important or why your approach is better, and I think that's a
>shame. Your approach may well _be_ better, but as I haven't used it, I
>can't really judge that. Even if it is, I believe you're doing both
>yourself and the IF community a disservice with this attitude. Many of
>the r.a.i.f. regulars have written many wonderful games and have years
>of experience with IF. Tossing their opinions away because you don't
>like them is short-sighted.
IF has advanced (as far as I can tell) in two ways. There are now
sophistocated languages available which make command recognition (not to
mention the process of creating the games themselves) much nicer and more
robust. This emphasises "I"nteractive. Second, the writing is better and
stories have advanced from "explore the dungeon and collect artifacts." This
emphasises "f"iction.
Despite these advancements (which isn't a *bad* thing at all) the current
state of IF is pretty true to the concept from 20 years ago. Along comes
SUDS.
Perhaps the moral is it's not a product for the "IF Community" at all. It's
a product for a much larger audiance which (according to David's review)
doesn't entirely fit with IF as it's implemented here. David said:
"Anyway, that's my two cents. Build something that we want that helps us do
what we're already doing. Don't create something that tries to change us."
I think that's a fair summation since SUDS was mentioned here as a new IF
system, although it's not my own opinion. I think SUDS (from David's review)
will have a wonderful chance among thousands of people who can't (or won't)
grasp the concept of code-based programming. It can (and may) be quite
successful even if shunned by r.*.i-f. I think this is Andy's reckoning as
well, and I truly wish him as much success as is possible. :)
Mike.
Liz & Andy
news:uock8nu...@evelake.pdl.cs.cmu.edu...
> is a group of people who are interested in using IF systems to create
> their own games with their own content;
>
OK, fair comment and apologies - that's the focus of the group, you're
right. It's been a long day.
David Cornelston wrote :
>> They could take some solid advice and build a player that
>> resembes an Inform interpreter (or TADS or HUGO) and they might actually
get
>> some attention from the RAIF crowd.
Now, run that comment about "condescending" by me again??
Andy Elliot
Suzanne Skinner
Liz & Andy <lizn...@liznandy.freeNOSPAMTAserve.co.uk> wrote:
>It's unfortunate that you're not "Windows-savvy" enough to recognise help
>written in HTML, rather than WinHelp
>This seems to reflects the group's obsession with system over content.
>Sorry to break it to you but the IF audience consists of more people than
>those who contribute to RAIF - as evidenced by those who've already
>registered SUDS.
>Apologies that daring to be different is perceived by you as a threat, not
>an opportunity.
[among other lovely bits of condescension]
*shaking head*
*plonk* HTH FOAD
Suzanne
--
tr...@igs.net http://www.igs.net/~tril/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"I'm sure the authors will write me and say yes, there were playtesters.
Sorry. It's a rhetorical question. What I meant to ask was, please, can I meet
the playtesters and *set them on fire*?" -- Andrew Plotkin
David Samuel Myers
I applaud the SUDSers for creating an IDE. I think it's pretty short
sighted of people to say b-b-but it's not one of the BIG languages, so it
DOESN'T MATTER (!!?!?!?!!), which if I read it correctly seems to be a
sentiment that some people have had. I realize that there are a spectrum
of opinions out there, and that this probably in no way represents the sum
total of any single person's feelings about SUDS, but you can see it
coming through in some of the posts.
Ok, well, the same thing has happened before. The move from command line
compilers to IDEs was not universally or immediately embraced in the
programming community. The big innovators in this arena weren't C people.
It was Pascal that really took the lead.
You have to give the SUDSers credit for taking the time to show us *one*
way that you might structure an IDE that could be of use to the world.
In line with that, I have another suggestion of a game-creation IDE which
some of you might want to look at. There is a game system for Palm Pilot
called "Kyle's Quest". Now, this is a Zelda like game, and not really very
sophisticated. It does support limited conversations with yes/no answers,
but it isn't IF at all. Fine. . . But the Windows-based game-writer is
utterly easy to understand and use. Only a very few of the features really
have anything you could borrow into the IF world, but it is still nice to
see that people *can* create these things and they *can* work.
I'm also eagerly awaiting CAVE, which will be yet another IDE-driven entry
into the full blown game systems arena. I say, the more the merrier. It's
a very reasonable way to achieve innovation, despite the fact that it
ain't Inform, kiddos.
-david
Graham Nelson
<URL:mailto:ma...@cs.cmu.edu> wrote:
> I'm also not entirely sure why you decided to add the condescending
> and insulting remark about "obsession with system over content". I
> haven't really seen any indication that this is in fact true.
Oddly, I think I agree with this remark, though in a slightly
different way. Something like 50 adventure design systems have
been created since 1984 or so, and 3 or perhaps 4 are widely
used today: these things are not easy to get going. One major
reason why many systems fall by the way-side is that their
authors spend all of their effort on syntax and neat programming,
being (often) interested more in the software engineering than
in the actual problem to be solved -- which, I suggest, is the
framework of rules governing the model world, and how it can be
made alterable by the player. A good world model with a so-so
syntax for writing code (e.g. Inform, I think) is probably a lot
more viable than a sparse and inflexible world model with a
beautifully engineered compiler (there are many examples of such
systems in the silicon hell of ftp.gmd.de).
I went through the manuals and example code for every existing
design language when writing the "IF history" appendix to the
Inform manual, and another point which vividly came home to me
was that about three-quarters of design systems are written with
the intention that "designers don't need to learn to program".
Phrases like "a descriptive language, not a programming language"
recur. But no such language has prospered since the early days
of AGT (and in fact more recent versions of AGT have been quite
sophisticated).
Again, I think this is because no adequate world model for IF
can be anything other than complex. I certainly think that the
first thing anyone making a new design system needs to do is
to think long and hard about the world model, plan it all out on
paper, work out what the attractions and shortcomings of the
best models are (e.g. Dave's "WorldClass" model)... and only
last of all work out a programming syntax or a windowed front
end, which is the easy bit.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Kevin Forchione
news:ant080920c72M+4%@gnelson.demon.co.uk...
> Again, I think this is because no adequate world model for IF
> can be anything other than complex.
You've hit the nail on the head. Work on the world model, object
relationships and interactions, is of chiefest interest for anyone hoping to
expand the boundaries of IF.
>I certainly think that the
> first thing anyone making a new design system needs to do is
> to think long and hard about the world model, plan it all out on
> paper, work out what the attractions and shortcomings of the
> best models are (e.g. Dave's "WorldClass" model)... and only
> last of all work out a programming syntax or a windowed front
> end, which is the easy bit.
A comparative study of these systems is extremely rewarding. My work in TADS
has benefitted immensely from my knowledge of Inform and my brief delvings
into WorldClass. What interests me most is where the world model is heading?
How can it be enhanced? A discussion on this would be greatly appreciated.
With today's faster machines and larger memory capacities we are at present
not substantially further along than we were 5 years ago... Part of the
problem is, as you point out, that it requires a *great* deal of planning in
the design of a *new* model. It is far, far easier to tweak the old systems.
And there is risk. Risk that countless hours invested in a new approach may
prove fruitless -- either through some fatal flaw creeping into the work, or
through an inability to rouse interest in the fledgling system.
Our two most popular systems: TADS and Inform, both owe much of their
existences to the original games which they spawned or from which they were
derived (I'm not completely sure of the chicken-egg relationship). Needless
to say they developed in an evolving manner, bearing the evidence of
vestigal algorithms and subroutines no longer needed or used. Backward
compatibility has slowed progress, hampered the implementation of new ideas,
even while it permitted the establishment and growth of a strong user base.
People have talked about developing a more "physics"-oriented world model
for years. But physical rules don't integrate easily into the
exception-ridden world of IF: the rules of which must be more metaphysical
in nature: handling exceptions as part of the process, not in spite of it.
Far more important than simplicity is the elegance and expressiveness of the
code involved: the power of calculus over algebra, to describe the complex
interplay of the model world.
A word-processor facilites production... But without knowledge of rhythm and
rhyme I cannot hope to write sonnets. Without knowledge of the complex
interplay of scene and sequel, character and conflict, dialogue and
narrative, I cannot hope to write stories that grip the audience, suspending
disbelief, and ushering in new worlds.
Let's not be afraid of complexity or pander to simplicity for its own sake,
but expect more from ourselves and be pleasantly surprised.
--Kevin
Mike Snyder
news:OYOQnHgK$GA.249@cpmsnbbsa02...
> Let's not be afraid of complexity or pander to simplicity for its own
sake,
> but expect more from ourselves and be pleasantly surprised.
Explain this to the enthusiastic kid who thinks it'd be fun to write a game
but just can't grasp these complex constructs. I think (s)he'll move on to
other interests (Diablo II is coming out soon) and I think that's a shame.
(S)he may have had something great to add if only a system had been
available that didn't require such a learning curve.
[shrug].
Mike.
Mike Snyder
news:806su7$n3h$1...@bgtnsc03.worldnet.att.net...
To clarify my own sentiment, I mean that I'd encourage anybody who wants to
"create" to do it by whatever means is at their disposal and comprehension.
Mike.
Andrew Plotkin
> Again, I think this is because no adequate world model for IF
> first thing anyone making a new design system needs to do is
> to think long and hard about the world model, plan it all out on
> paper, work out what the attractions and shortcomings of the
> best models are (e.g. Dave's "WorldClass" model)... and only
> last of all work out a programming syntax or a windowed front
> end, which is the easy bit.
I agree with this, but I want to expand on that last bit.
One of the problems with writing an entirely new IF system is that you're
reinventing not only the wheel, but the chassis, the motor, the hull
design, and the dashboard as well.
Of *course* all of those regions can be improved. But we have a few
established and experimental solutions for all of them. People these days
tend to look and say, "Could you have used an existing I/O layer? *Or* an
existing VM? Or an existing library, or language, or compiler? Does the
experimental approach you're suggesting really require redoing every
single one of those?"
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
okbl...@my-deja.com
David Samuel Myers <dmy...@sparky.ic.sunysb.edu> wrote:
> Continuing in line with what Mike Snyder said ---
>
> I applaud the SUDSers for creating an IDE. I think it's pretty short
> sighted of people to say b-b-but it's not one of the BIG languages, so
it
> DOESN'T MATTER (!!?!?!?!!), which if I read it correctly seems to be a
> sentiment that some people have had. I realize that there are a
spectrum
> of opinions out there, and that this probably in no way represents the
sum
> total of any single person's feelings about SUDS, but you can see it
> coming through in some of the posts.
I think you have read it incorrectly. There are doubtless some of us
who blanch--or yawn--at the thought of learning yet another adventure
language. But the sentiment was that really, that was all this was: yet
another adventure language, in a well-done IDE.
> Ok, well, the same thing has happened before. The move from command
line
> compilers to IDEs was not universally or immediately embraced in the
> programming community. The big innovators in this arena weren't C
people.
> It was Pascal that really took the lead.
And then BASIC, when VB first emerged. But the two situations aren't
quite analogous. The original Borland Pascal IDE increased productivity
by contracting the multi-step edit/save/compile/link/load process, and
VB increased productivity by encapsulating huge amounts of IDE code into
libraries which could be accessed dynamically to (in essence) create
code.
I actually use the old TP/BP environment as my IDE and, in any event, IF
never approaches (as far as I've seen) the level of complexity (in terms
of compilation) that TP/BP IDE excelled at simplifying.
IF, text or graphical, doesn't have the same heavy reliance on GUI calls
as other programs. Text IF doesn't need any such calls, and most of
the work in a GUI based IF would be in the artwork (and, one presumes,
hiding the hot spots) which is not something greatly assisted by a
VB-like GUI painter.
What I'm getting at is that you can't just shoehorn traditional
programming advancements into IF and expect to get the same overall
gains.
If you want to get oohs-and-ahs out of people who *know* what they're
doing, you need to make progress in an IF-specific area:
* General parsing
* Dialogue parsing
* Artificial intelligence
* Handling combinatorial explosion
* Physics/world modelling
* Emotional modeling
I believe that if anyone came up with a significant improvement in any
of these areas, this improvement would sell the system, regardless of
whether it paid obeisance to Inform or TADS.
> [snippage]
> into the full blown game systems arena. I say, the more the merrier.
It's
> a very reasonable way to achieve innovation, despite the fact that it
> ain't Inform, kiddos.
If you demonstrate actual innovation, you won't find as much resistance
you think. I don't mean that as a knock to SUDS, although it may be.
One thing you could add to the list above is "easy to use", but you'd
also have to add "without being too resitrictive or limiting".
If SUDS is at the level of Inform or TADS, it may do quite well by
attracting people who are intimidated by those languages, and there's
nothing wrong with that. But you can't expect people to be doing
handsprings over something which doesn't expand the field, limits the
target platforms *and* costs money to boot.
--
[ok]
Sent via Deja.com http://www.deja.com/
Before you buy.
Mike Snyder
> Indeed! Note that Inform 1 in 1993 compiled code for an existing
> virtual machine, not for a newly-created one.
I bet this is answered in some "history of" text somewhere I haven't run
into yet, but I was curious. Was it an open architecture, or did you just
"figure out" how it worked to create Inform?
Mike.
Graham Nelson
<URL:mailto:erky...@netcom.com> wrote:
> I agree with this, but I want to expand on that last bit.
>
> One of the problems with writing an entirely new IF system is that you're
> reinventing not only the wheel, but the chassis, the motor, the hull
> design, and the dashboard as well.
Indeed! Note that Inform 1 in 1993 compiled code for an existing
virtual machine, not for a newly-created one.
--
David Samuel Myers
>What I'm getting at is that you can't just shoehorn traditional
>programming advancements into IF and expect to get the same overall
>gains.
>If you want to get oohs-and-ahs out of people who *know* what they're
>doing, you need to make progress in an IF-specific area:
>* General parsing
>* Dialogue parsing
>* Artificial intelligence
>* Handling combinatorial explosion
>* Physics/world modelling
Many good points.
-d
David Cornelson
> In article <38264...@dilbert.ic.sunysb.edu>,
> David Samuel Myers <dmy...@sparky.ic.sunysb.edu> wrote:
> > Continuing in line with what Mike Snyder said ---
> >
> programming advancements into IF and expect to get the same overall
> gains.
I disagree with this statement enormously. By adding the simplicities of a
Visual Basic like environment, you reduce the barrier to entry for whichever
language you've chosen to simplify, which I believe was the whole point of
Visual Basic. Beforehand, you needed to know C++ and the Windows SDK which
for many people was a huge barrier.
When I first started in this whole hobby three years ago, I really didn't
understand oo programming despite being a professional and successful
software developer. It took me three major writings in Inform before the
lights went on and that amounted to well over two years. I still don't
consider myself all that good of an oo programmer.
Using an IDE for Inform, I believe that two years could have been reduced
significantly. In fact, I believe it would have helped reduce many of the
coding bugs that I released in Town Dragon as well as spelling (assuming any
well-written IDE would have spell-checking within and possibly grammar). Now
it would not have improved my story-telling, only a good ass-kicking on RGIF
can do that. But the ass-kicking would have been more centered on my
story/game and less on my grammar and poor coding. And by this fact, I would
likely have written a better game because I would have been spending less
time on little nitpicky things.
An IDE could also 'guide' you into writing better IF by keeping a check list
of objects that need to be described. It could point out that you have two
or more similar objects and ask if you want to merge them or create a class
for them. It could help you implement doors, which I believe is an
enormously confusing task at times. It could help you build NPC code that
works and possibly even ask you if you want to use some of the library
contributions, such as follower or movelcass. It could help you manage the
complexity of all of your objects by keeping tabs on all of their
relationships. You would be able to 'see' the big pictuire. All of these
things would reduce the barrier to building successful, well-written games
for new programmers. The IDE need only adhere to one simple rule. It must
not in any way shape or form reduce the flexibility of writing ones own
code. It must be able to import a text version of the code and export a text
version of the code and understand it without problems. But I believe this
is doable.
And then you have...
> * General parsing
> * Dialogue parsing
> * Artificial intelligence
> * Handling combinatorial explosion
> * Physics/world modelling
> * Emotional modeling
Of course these are all wonderful things too, but why can't we reduce the
barrier to coding AND improve the overall programming depth with these types
of enhancements? I still don't understand why this is such a difficult
concept to understand.
Jarb
PS: By the way, I've been working with a psychologist friend in trying to
build emotional modeling. It ain't even close to easy and I'm not sure of
the value of it in anything but a very large, complex game. But we're
trying. You'll see the results in my WIP, whenever I finish it. Probably 8
years from now.
Irene Callaci
>If you want to get oohs-and-ahs out of people who *know* what they're
>doing, you need to make progress in an IF-specific area:
>
>* General parsing
>* Dialogue parsing
>* Artificial intelligence
>* Handling combinatorial explosion
>* Physics/world modelling
>* Emotional modeling
Amen, brother, amen.
irene
Adam J. Thornton
And, of course, if you solve *any* of these, you will
a) be rich beyond your wildest imagination,[*] and
b) change the world.
No, I'm really not joking.
Adam
[*] Or, if an academic, spectacularly famous, not badly off, and The Man
for the rest of your life.
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Dan Shiovitz
Mike Snyder <mikes...@worldnet.att.net> wrote:
>Mike Snyder <mikes...@worldnet.att.net> wrote in message
>news:806su7$n3h$1...@bgtnsc03.worldnet.att.net...
>> Kevin Forchione <Lys...@email.msn.com> wrote in message
>> news:OYOQnHgK$GA.249@cpmsnbbsa02...
>>
>> > Let's not be afraid of complexity or pander to simplicity for its own
>> sake,
>> > but expect more from ourselves and be pleasantly surprised.
>>
>> Explain this to the enthusiastic kid who thinks it'd be fun to write a
>game
>> but just can't grasp these complex constructs. I think (s)he'll move on to
>To clarify my own sentiment, I mean that I'd encourage anybody who wants to
>"create" to do it by whatever means is at their disposal and comprehension.
Yeah, but look: IF languages really aren't that hard. Really. There are
plenty of non-programmers here, people who didn't know C or Pascal or BASIC
or anything, and they've gone on to write great games. If someone wants to
spend their energy writing a simple IF system that lets you write simple
games, fine. But I don't think it's needed, and frankly, I think the IF
community as a whole would benefit more if their energy was spent, say,
writing a more user-friendly manual for TADS, or working out a visual
development environment for Inform. Or even just answering newbie questions
on the newsgroup.
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW
Magnus Olsson
>news:802ltt$544$1...@bgtnsc03.worldnet.att.net...
>no time to reviewing the actual game (Roman Adventure II) delivered with the
>content.
Please don't judge the entire group by one poster. David is outspoken
and has interesting views, but they're far from always representative
of the group as a whole.
BTW, I fully agree with you that we really should look primarily at
the games produced by a system rather than at the system itself. If we
see a lot of great games produced with SUDS we'll no doubt view it in
a favourable light. I think that what made Inform so popular was (at
least to start with) the fact that Curses was available as an example
of what you could do with the language. Had Graham not been as good
at writing games as at writing compilers, I think TADS might still
have dominated the scene.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Magnus Olsson
Mike Snyder <mikes...@worldnet.att.net> wrote:
>Kevin Forchione <Lys...@email.msn.com> wrote in message
>news:OYOQnHgK$GA.249@cpmsnbbsa02...
>
>> Let's not be afraid of complexity or pander to simplicity for its own
>sake,
>> but expect more from ourselves and be pleasantly surprised.
>
>Explain this to the enthusiastic kid who thinks it'd be fun to write a game
>but just can't grasp these complex constructs.
I'll stick my neck out a bit: if the "complex constructs" of TADS or
Inform are so difficult that you *can't* grasp them, then I don't think
you can write a good game.
That sounded terribly arrogant, didn't it? Well, let me put a more
positive spin on it:
If you have the capacity to write a good adventure game, then you
can learn TADS or Inform. It's simply not that hard.
Of course, that doesn't mean that the learning curve of, say, Inform
is quite steep, and that it wouldn't be a worthwhile task to make it
easier to learn.
But my point is that "requiring some effort to learn" is not the same
thing as "difficult".
I do think that a lot of work can be done to simplify the game
creation process. For example, one could write an IDE for Inform, or a
tool where you build the game map by clicking and dragging. But I
don't think such tools would simplify the process enough for it to
matter very much. It would, perhaps, be easy to write a very simple
game, and *then* when you wanted to add add more complexity you'd run
smack into the learning curve. Or, which would be much worse, you'd
find that the nice, shiny tool wouldn't *let* you add the complexity
you needed.
Graham Nelson
<URL:mailto:ad...@princeton.edu> wrote:
> And, of course, if you solve *any* of these, you will
> a) be rich beyond your wildest imagination,[*] and
> b) change the world.
>
> No, I'm really not joking.
>
> Adam
>
> [*] Or, if an academic, spectacularly famous, not badly off, and The Man
> for the rest of your life.
Or, if you don't *quite* solve any of these, you can be mildly
well-known in certain places, scrape a bare living, and be
Something Of A Geek for the foreseeable future...
Daniel Barkalow
> In article <806su7$n3h$1...@bgtnsc03.worldnet.att.net>,
> Mike Snyder <mikes...@worldnet.att.net> wrote:
> >Kevin Forchione <Lys...@email.msn.com> wrote in message
> >news:OYOQnHgK$GA.249@cpmsnbbsa02...
> >
> >> Let's not be afraid of complexity or pander to simplicity for its own
> >sake,
> >> but expect more from ourselves and be pleasantly surprised.
> >
> >Explain this to the enthusiastic kid who thinks it'd be fun to write a game
> >but just can't grasp these complex constructs.
>
> I'll stick my neck out a bit: if the "complex constructs" of TADS or
> Inform are so difficult that you *can't* grasp them, then I don't think
> you can write a good game.
This is more of a point for the next generation: it would be good if even
people who did not yet have the capacity to write a good game could write
a lousy game they could play now, and when they're more mature, they
would think to write a game which would turn out to be good.
> I do think that a lot of work can be done to simplify the game
> creation process. For example, one could write an IDE for Inform, or a
> tool where you build the game map by clicking and dragging. But I
> don't think such tools would simplify the process enough for it to
> matter very much. It would, perhaps, be easy to write a very simple
> game, and *then* when you wanted to add add more complexity you'd run
> smack into the learning curve. Or, which would be much worse, you'd
> find that the nice, shiny tool wouldn't *let* you add the complexity
> you needed.
I think that an IDE for Inform would be worthwhile, provided it was not
restrictive, and let you just write code when you wanted to. If nothing
else, an editor with an Inform interpreter, such that you could modify
things in the code and have them change in the game without restarting,
would greatly speed game development.
I think a map editor could be a useful part, continuing to assume that it
would get out of the way when you were doing things other than maps
(including map-like things that are not actually normal maps).
Of course, I also think that, at this point, Inform could acquire a slick
syntax and would be improved, so long as it retained the libraries and
the language functionality.
We've already had the hard part done, but the (reletively) easy part
remains. There's nothing inherently bad about a slick IF system; it's
just that if you start out making the IF system slick, you'll miss the
important parts.
-Iabervon
*This .sig unintentionally changed*
okbl...@my-deja.com
"David Cornelson" <dcorn...@placet.com> wrote:
> [stuff, and then]
>
> Using an IDE for Inform, I believe that two years could have been
reduced
> significantly. In fact, I believe it would have helped reduce many of
the
> coding bugs that I released in Town Dragon as well as spelling
(assuming any
> well-written IDE would have spell-checking within and possibly
grammar).
But these are not things a traditional IDE or visual development
enviroment (VDE?) does. They don't check spelling or grammar--which I
think should be a complete separate issue anyway, but that's a long
story and, more relevant to your post, they don't help you program/learn
programming/understand the object model/etc.
For example, (in a VDE) if you have a window with a button on it, and
the button closes the window when pressed, and you also want to write
some code that gets executed when the window is closed (maybe to stop
the window from closing in some cases), a VDE will allow you to write
small bits of code for the button and for the window closing, and maybe
it will have an event for validation, and so on. But what the VDE won't
tell you is the order in which the code executes. Do you put your code
in the button-clicking step, say to prevent it from being clicked at the
wrong time? Or should it all go in the validation step? And does the
validation step come before or after the close step?
It's not a great example, but *this* is the really hard part about VDEs
(knowing what things happen and the order in which they happen) and I
don't know of any VDE that *helps* you learn these parts, and most
compound the whole learning process by giving you a bunch of arbitraries
about an object framework that was probaly less well thought out than
the language the framework is based on.
And this, ironically, is the hard thing about IF. Knowing about all
the events and the order in which they occur. An IDE could be built
that helped with that--and I think it's a great idea, frankly--but I
don't think SUDS is that (yet), and neither are any of the other
VDEs/IDEs, as far as I can tell.
[stuff I wrote about IF improvements]
> Of course these are all wonderful things too, but why can't we reduce
the
> barrier to coding AND improve the overall programming depth with these
types
> of enhancements? I still don't understand why this is such a difficult
> concept to understand.
It's not. What SUDS and QDE and other such things may bring to the IF
world is a crop of people who are threatened by code but not (so much)
by these presentations of concepts. But they're greeted lukewarmly here
because people here have paid the dues and are looking to improve what
they can *produce* not just the superficial way that things are
produced.
It's like giving an artist a pre-made palette versus him grinding out
his own paint. The pre-made stuff is fine, right up to the point he
needs that special shade of red. If you want to impress him, you don't
just lay stuff out for him; he can do that in seconds anyway. Give him
a new shade, a new material, a new medium that allows him to express
more.
> PS: By the way, I've been working with a psychologist friend in trying
to
> build emotional modeling. It ain't even close to easy and I'm not sure
of
> the value of it in anything but a very large, complex game. But we're
> trying. You'll see the results in my WIP, whenever I finish it.
Probably 8
> years from now.
Actually, I have a couple of good emotional models, but the
combinatorial thing is the killer.
Joe cheerfully puts the book down in front of you and says "Good luck!"
Joe puts the book down. "Good luck," he says with a small smile.
Joe yawns as he puts the book down. He mumbles something and walks away.
Joe puts the book on the table. "Good luck," he says with a tone that
makes you think he really means "Drop dead".
Joe slams the book down and utters a stream of obscenities that would
make a sailor blush.
Etc. That's half the simplified scale. I think the only way to handle
it is to make the author a director, as well, so that there are a
limited number of the emotions that any character can be at any point in
the story (influenced by various events, phew!), rather than giving the
NPCs completely "free" emotional range.
okbl...@my-deja.com
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
> Or, if you don't *quite* solve any of these, you can be mildly
> well-known in certain places, scrape a bare living, and be
> Something Of A Geek for the foreseeable future...
Exactly. And who wouldn't want that?
Graham Nelson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
> BTW, I fully agree with you that we really should look primarily at
> the games produced by a system rather than at the system itself. If we
> see a lot of great games produced with SUDS we'll no doubt view it in
> a favourable light. I think that what made Inform so popular was (at
> least to start with) the fact that Curses was available as an example
> of what you could do with the language.
Yes, although it still took two years for Inform usage to take
off. TADS was clearly the dominant system in 1993-5; less
clearly thereafter, and I suppose it's been about half and half
ever since.
The point about "Curses" was not its quality (if any), but that
it demonstrated that a game of Infocom's complexity level could
be produced by Inform. TADS 2.0 could do that as well, but I
don't think any other systems of the day could do so -- even TADS
1, I think -- and the release of TADS 2.0 was about the same
time as the appearance of Inform, and the appearance of these
newsgroups, and the publication of "Lost Treasures of Infocom",
and... and I think these facts are all related.
Evin Robertson
Daniel Barkalow <iabe...@iabervon.mit.edu> wrote:
> I think that an IDE for Inform would be worthwhile, provided it was not
> restrictive, and let you just write code when you wanted to. If nothing
> else, an editor with an Inform interpreter, such that you could modify
> things in the code and have them change in the game without restarting,
> would greatly speed game development.
When I read about Microsoft's 'Edit and Continue' feature
<http://msdn.microsoft.com/library/techart/msdn_vc6ed_cont.htm>, I
thought it would be a neat thing to add to nitfol. Adam J. Thornton
disliked the idea because it would be impossible to make it work in
every circumstance, and L. Ross Raszewski thought nitfol was already
fast enough to use scripts to see the effects of his editing.
Things would mostly work if you only do your editing while at the game
prompt unless you're changing stuff deep within the library. Editing
strings and routines isn't too hard to implement. Allowing you to add
new objects and properties without restarting the game is significantly
more difficult, as I have to try to keep track of relationships, and
this is bound to fail in some circumstances. You'd have to promise
not to store at runtime objects numbers and addresses if you want
these to work after you've moved things around.
It shouldn't be too hard to hook up a M-x inform-edit-continue which
would recompile and signal nitfol to look at the changes, continuing
at the current location in the game. Then emacs would provide all
your Inform writing, source-level debugging, resuming, playing, and
Jarbification needs.
So how useful would you find this?
The obvious question (which you sort of asked) is "Since Inform's
output to the Z-machine isn't sufficiently strongly typed, could an
interpreter of Inform do better?" It could keep tag bits to know
which values refer to numbers, which to objects, strings, routines,
etc., and then map them around when the game changes. This would
mostly work until the game starts doing things like addressing pieces
of a number, which works fine under the Z-machine but doesn't let you
give meaningful tag bits in your interpreter. I think my werewolf
game does this to compact the knowledge table of the bots. There
still remains the question "which object does this old object
correspond to" after you've changed their names.
An Inform interpreter (instead of a Z-machine interpreter) would be a
lot of work, and would do a better job at some things and get lost
doing others.
Bob Newell
someone wants to create a new IF system, with or without consultation
from RAIFers, so be it.... they are most welcome to do so and they just
might make a contribution to the art.... or they might not. It's their
call as to whether to invest the time and effort, and we should respect
that and at least give them a fair evaluation.
I haven't looked at SUDS, at least not yet. The writeups do remind me
of StoryHarp (have we heard anything of that recently?) and so does the
shareware approach. That too is the authors choice. People will vote
with their wallets so these things sort themselves out in a neat
capitalistic fashion.
I was, though, a bit disappointed that the SUDS author was rather defensive
in his postings and not especially tolerant of criticism. There have been
critics of the "established" systems, some of those critics rather biting,
and still in the end a good product will have its day.
I'm all for more variety, more ideas, more development. In slight contra-
diction to what I said above, I think anything new teaches us at least
something about the art, in some form. I am sure no one is interested in
stagnation or the same thing repeated forever.
Another poster claimed that we haven't really advanced all that much over
the years. I think that is not really the case. Perhaps we haven't seen
quantum leaps in development systems, it's true (although that could even
be argued; look where Inform was say 5 years ago, or even TADS or
Hugo) but look at the quality of stories now produced! Go back to Zork
and then compare with some of, for instance, Andrew Plotkin's work.
(Not certainly that Zork was bad or primitive, but look at the advancement
in the state of the art.)
We are only enriched by new ideas and new development.
Bob Newell
cmshaw@i_should_put_my_domain_in_etc_nntp_inews_domain
>On 9 Nov 1999, Magnus Olsson wrote:
>> In article <806su7$n3h$1...@bgtnsc03.worldnet.att.net>,
>> Mike Snyder <mikes...@worldnet.att.net> wrote:
>> >Kevin Forchione <Lys...@email.msn.com> wrote in message
>> >news:OYOQnHgK$GA.249@cpmsnbbsa02...
>> >> Let's not be afraid of complexity or pander to simplicity for its own
>> >sake,
>> >> but expect more from ourselves and be pleasantly surprised.
>> >
>> >Explain this to the enthusiastic kid who thinks it'd be fun to write a game
>> >but just can't grasp these complex constructs.
>>
>> I'll stick my neck out a bit: if the "complex constructs" of TADS or
>> Inform are so difficult that you *can't* grasp them, then I don't think
>> you can write a good game.
>This is more of a point for the next generation: it would be good if even
>people who did not yet have the capacity to write a good game could write
>a lousy game they could play now, and when they're more mature, they
>would think to write a game which would turn out to be good.
Would it really do "the next generation" any good to learn lousy
programming skills now, in the hopes that they'd grow out of it later?
Kids are not, at a rule, scared by complicated logical structures. In
fact, most interesting childrens' games -- or at least, most games which
interest children who grow up scientifically-oriented -- are simply
fancy logic puzzles.
Really, if you look at it that way, coding IF and playing IF are almost
the same sort of game....
Caitlin
--
cmshaw -at- lambda -dot- net -without- any fancy signature line
*** for obvious reasons, you can't use the email in the headers
David Glasser
> I will say this though. SUDS is very well written and documented. Clearly,
> the authors knew what they were doing and had a clear vision when doing it.
> The problem is that they didn't get RAIF involved in the process and they
> failed to target the IF audience properly. Then coming out and annoucning it
> as shareware. Well, that was just naive. As everyone knows, IF folk are
> notoriously frugal.
Is that truly a problem? Something gives me the feeling that the SUDS
authors didn't says "let's write a program that the r*if people will
love"; they said "let's write this program" and later thought "well, why
don't we tell the r*if people about this because it is similar to what
they discuss?"
I don't see the lack of raifness as a flaw in the product; it just means
that they won't find too many customers here. Which doesn't really mean
anything about how good SUDS is.
(On the other hand, I probably won't add SUDS to the IF systems list in
the raif FAQ unless either it becomes popular *here* or the authors send
me a complete description so all I have to do is copy and paste. But
that's just because I'm lazy and cynical.)
--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
rec.arts.int-fiction FAQ: http://www.davidglasser.net/raiffaq/
"So what's the story with Tetris? Block meets block, block loses block,
block meets another block?" --Russ Williams
Kevin Forchione
This is an interesting observation.
I think you're right. The fascination with Inform (and TADS) is that it
gives the author the ability to create a game that has a complex interplay
of relationships. For those of us who cut our teeth on BASIC or some other
procedural language, stumbled onto AGT, and then cheered to find TADS and
Inform, we were drawn by the potential to produce works of a "commercial
quality" (I believe you even use this phrase somewhere in the Inform
Author's Manual). For many of us, Infocom set the standard.
--Kevin
Graham Nelson
Daniel Barkalow <URL:mailto:iabe...@iabervon.mit.edu> wrote:
> I think that an IDE for Inform would be worthwhile, provided it was not
> restrictive, and let you just write code when you wanted to. If nothing
> else, an editor with an Inform interpreter, such that you could modify
> things in the code and have them change in the game without restarting,
> would greatly speed game development.
Of course Inform's Infix verbs do interpret Inform code at the
"What now?" line, ... but that's not as difficult as what you're
asking for.
Neil K.
> Is that truly a problem? Something gives me the feeling that the SUDS
> authors didn't says "let's write a program that the r*if people will
> love"; they said "let's write this program" and later thought "well, why
> don't we tell the r*if people about this because it is similar to what
> they discuss?"
Indeed. I've made this observation before, but I think we have a basic
clash of cultural assumptions here.
On the one hand we have the PC user community, which sprang from bulletin
boards and online systems. This is apparently a world where shareware
still exists as a viable form of distribution, and which has no interest
at all in the notion of cross-platform compatibility. After all, PCs rule
the world - what other operating systems could there be? There's an
interest in relatively easy to use software, as most of the users tend to
be casual hobbyists who don't have the knowledge or tools to compile their
own source.
On the other, we have the UNIX/open source community, which sprang from
the academic Internet. This is a world of freeware and public domain
software, and which has a keen interest in source distribution and
cross-platform development. After all, UNIX is a vastly superior operating
system to anything else. Since this world is full of engineers, computer
science students and hackers, there isn't much interest in making software
all that easy to use. Who needs more than a makefile?
The rise of the Internet and the decline of BBSs and big standalone and
proprietary online systems means some increased contact between these
formerly disparate communities, of course.
raif very much has its origins in the latter community. The top three
development systems aren't open-sourced, but do have their source freely
distributable. Virtually all the games being produced by raif community
types are freeware. And so a development system like SUDS - apparently
simple and easy to use, but with severe limitations unless it's been
registered - is culturally alien to the traditions and requirements of
raif people. Which is fine, of course, but I really don't see the point of
judging it in a raif context if that's not what it was meant for.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Daniel Barkalow
> It shouldn't be too hard to hook up a M-x inform-edit-continue which
> would recompile and signal nitfol to look at the changes, continuing
> at the current location in the game. Then emacs would provide all
> your Inform writing, source-level debugging, resuming, playing, and
> Jarbification needs.
>
> So how useful would you find this?
I think that would be pretty cool. I think an Inform interpreter might be
a more effective way to do this, and no less powerful, since we presume
nobody modifies their Z-code midstream without using Inform.
> An Inform interpreter (instead of a Z-machine interpreter) would be a
> lot of work, and would do a better job at some things and get lost
> doing others.
An Inform interpreter could presumably do as well as a Z-machine
interpreter even with the strange things by simulating the strangeness;
that is, in the situations where the programmer has not changed anything
behind the game's back, it all still works. It could also probably be set
up with some sort of conservative estimate for situations where it may be
confused. (You removed the player's location, removed an object whose
number was stored somewhere such that it cannot just be removed
consistently, etc.) In these cases, we just fall back to making the
programmer restart, which they would have to anyway if they weren't using
this system. It's not perfect, of course, but it's strictly better than
restarting every time, including after adding trivial objects and
changing text.
David Cornelson
news:8093dk$8ne$1...@bartlet.df.lth.se...
> In article <80493u$vj8$1...@news4.svr.pol.co.uk>,
> Liz & Andy <lizn...@liznandy.freeNOSPAMTAserve.co.uk> wrote:
> >
>
> Please don't judge the entire group by one poster. David is outspoken
> and has interesting views, but they're far from always representative
> of the group as a whole.
>
I guess I was a little strong in whacking SUDS. I tried to be complimentary
about the quality of the coding. My review was still centered more on what
interactive fiction means to me. But at the same time, this _is_
rec.arts.int-fiction and despite Magnus's comment, this is a fairly closed
environment.
Neil K posted about culture clash and I think he hit the nail on the head. I
come from the commercial, profit, Microsoft world. Any knowledge of
shareware, freeware, and Unix is pretty much from here and the ifMUD. And it
has taken me a long time to accept the fact that this group generally comes
from a different background than I do. I have had to change.
Neil made a comment that Unix is a far superior OS. Why? I would question
whether engineering or productivity is more important. Clearly, people are
more productive with Windows based OS's than Unix. I won't argue that Unix
is probably more stable and up until recently blew the doors off of NT for
responsiveness. But which OS has more users doing more and accomplishing
more? It's not even close. Of course this is where I come from and I don't
try to push these views on raif anymore, because, well, it ain't popular. So
just ignore I said this. (;
Back to SUDS. My comments are very simple. SUDS presents a story in a Point
and Click fashion. This is my only gripe with the player module that they
have created. Without a parser, it's my belief that you lose a great deal of
flexibility and creativity, something fundamental to IF. The constructor was
great. If I could use that constructor to build a game with a parser and an
interface like the TADS, Hugo, and Inform interpreters, then SUDS would be
very attractive to me. Is there an IF audience for Point and Click
adventures on raif? If there is, that's news to me, because I remember only
very negative remarks about point and click adventures on raif.
Lastly. On the issue of a VDE or IDE or whatever. I simply think an Editor
specifically tailored to one of the programming languages would be a great
leap in productivity for all of us. It would just be an environment that
logically organized your code. It wouldn't _do_ anything for you outside of
that. It wouldn't limit your ability to write complex code. Can we just
assume this is a requirement?
There really are only a few requirements for an IDE.
1. It cannot limit coding ability in any way.
2. It has to make coding simpler.
3. A spell-checker (and maybe a grammar checker, thesaurus) for descriptive
text would be nice but not necessary.
4. It has to import any previously written code.
5. It has to export the code in a readable manner, albeit formatted in some
programmtic way.
6. It has to have a rich help environment that scales from beginner to
expert user.
Are any of these requirements unattainable?
Would the result not be useful?
7. Okay - Cross-Platform would be nice too, but that _would_ be difficult.
Herein lies the problem. With the user base as it is on raif, would people
welcome a Windows based IDE? Probably not. But it sure would make things
easier for newcomers that use Windows based computers.
Jarb
Graham Nelson
<URL:mailto:bne...@alum.mit.edu> wrote:
> Another poster claimed that we haven't really advanced all that much over
> the years. I think that is not really the case. Perhaps we haven't seen
> quantum leaps in development systems, it's true (although that could even
> be argued; look where Inform was say 5 years ago, or even TADS or
> Hugo)
In particular I think the world model, which as I would argue is
where the real thought comes in, has been refined considerably
in all of these systems. One of the things I've tried to do in
the new edition of the Inform manual is to document the algorithms
by which Inform decides on visibility, touchability, resolving
ambiguities in parsing and other notorious problems. This is
only partly for the benefit of Inform authors -- it's also to
make some of the lessons learned by Inform over the years available
to people who will write better systems in years to come.
Oh dear, that sounds terribly pompous. Perhaps it's also because
I like the sound of my own voice.
Joe Mason
>Neil made a comment that Unix is a far superior OS. Why? I would question
>whether engineering or productivity is more important. Clearly, people are
>more productive with Windows based OS's than Unix. I won't argue that Unix
<plug> Just wait until Comdex... </plug>
Joe
David Samuel Myers
problem you are trying to solve. Imagine doing quantum physics
calculations, but you are forced to do it with Roman numerals.
I also think a vast number of people (again not *everyone* here, but
invariably some) underestimate the gains in time that are made by letting
the IDE auto generate some code for you. The sentiment I see a lot in
scientists is that they don't need more than a Makefile because this is
what works for them. Hell, a lot don't even use a Makefile because that's
too much for them. It may be true that you *can* get by ok like this for a
very long time, but there is a lot of fear involved in a statement like
that, too. I think they vastly underestimate the amount of time they would
save if using a visual debugger, *EVEN* though none of them will ever
write a lick of code that needs a gui. Granted, no one wants to invest
time to learn a system up front if the gains are marginal, but I think
the cost-benefit analysis shows that this is not marginal.
-david
David Thornley
Daniel Barkalow <iabe...@iabervon.mit.edu> wrote:
>On 9 Nov 1999, Magnus Olsson wrote:
>
>> In article <806su7$n3h$1...@bgtnsc03.worldnet.att.net>,
>> Mike Snyder <mikes...@worldnet.att.net> wrote:
>> >Kevin Forchione <Lys...@email.msn.com> wrote in message
>> >news:OYOQnHgK$GA.249@cpmsnbbsa02...
>> >
>> >> Let's not be afraid of complexity or pander to simplicity for its own
>> >sake,
>> >
>> >but just can't grasp these complex constructs.
>>
>> I'll stick my neck out a bit: if the "complex constructs" of TADS or
>> Inform are so difficult that you *can't* grasp them, then I don't think
>> you can write a good game.
>
>This is more of a point for the next generation: it would be good if even
>people who did not yet have the capacity to write a good game could write
>a lousy game they could play now, and when they're more mature, they
>would think to write a game which would turn out to be good.
>
The first chapter of the old TADS manual showed how to write a lousy
game fairly fast. If you just read the sections on the airport
game sketch and the demo, you could copy enough to write a lousy game.
It isn't in a snazzy IDE, but I would assume that anybody interested
in writing IF would be used to typing, and it's easy to find simple
editors.
The really nice part about this is that it's extensible. If you learn
enough to write a lousy game from copying the examples and bashing
them to fit, you can write a more complicated game by simply adding
to what you already know. Further, if you want to add something
complicated, there's a fairly good chance that somebody's already done
the grunt work, so you can copy in another file.
Now, I don't know much about SUDS. I've managed to be Microsoft OS-free
for two years now, and I'm not changing that just to try out a new
IF writing system. (That's another advantage of TADS: since it runs
on most common computers, I can have meaningful interaction with people
who share my interests regardless of what platform they're on. I don't
think the IF community is so large that I want to split it by platform.)
It appears, from what I've read, that it's essentially a way to write
simple games playable on Microsoft Windows, and is not extensible.
It is shareware, and may not be translated to the Macintosh or any
flavor of Unix anytime soon. These are reasons why I probably would
not be interested even if I did have a Windows box available.
>We've already had the hard part done, but the (reletively) easy part
>remains. There's nothing inherently bad about a slick IF system; it's
>just that if you start out making the IF system slick, you'll miss the
>important parts.
>
Um, are you saying that interface design is even relatively easy?
I think that making a good programmer productivity aid, that helps
get the easy stuff done and doesn't interfere with the harder stuff,
is going to be difficult.
(Not to mention that any sort of IDE will tend to be platform-specific,
unless it's built around Tk or wxWindows or Java or something. Actually,
Java would probably be the best bet, being as platform-independent as
you can get and still have a GUI.)
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
okbl...@my-deja.com
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
> In particular I think the world model, which as I would argue is
> where the real thought comes in, has been refined considerably
> in all of these systems. One of the things I've tried to do in
> the new edition of the Inform manual is to document the algorithms
> by which Inform decides on visibility, touchability, resolving
> ambiguities in parsing and other notorious problems. This is
> only partly for the benefit of Inform authors -- it's also to
> make some of the lessons learned by Inform over the years available
> to people who will write better systems in years to come.
>
> Oh dear, that sounds terribly pompous. Perhaps it's also because
> I like the sound of my own voice.
Pompous or not, it's much needed. And, let's face it, with *that*
accent, you can't help but sound pompous to us yanks! ;-)
--
[ok]
Alex Warren
> Lastly. On the issue of a VDE or IDE or whatever. I simply think an Editor
> specifically tailored to one of the programming languages would be a great
> leap in productivity for all of us. It would just be an environment that
> logically organized your code. It wouldn't _do_ anything for you outside of
> that. It wouldn't limit your ability to write complex code. Can we just
> assume this is a requirement?
>
> There really are only a few requirements for an IDE.
>
> 1. It cannot limit coding ability in any way.
> 2. It has to make coding simpler.
> 3. A spell-checker (and maybe a grammar checker, thesaurus) for descriptive
> text would be nice but not necessary.
> 4. It has to import any previously written code.
> 5. It has to export the code in a readable manner, albeit formatted in some
> programmtic way.
> 6. It has to have a rich help environment that scales from beginner to
> expert user.
>
> Are any of these requirements unattainable?
> Would the result not be useful?
I think QDK is pretty much the closest thing to this vision that exists - it
satisfies all of the above apart from points 3 and 6 - though the help feature
shouldn't be too far off (better to concentrate on the programming of the thing
first before writing help files).
The only thing is, hardly anybody seems to be using it, and particularly I don't
think anybody on this newsgroup is using it... are they? This makes me wonder
whether an IDE for IF really *IS* such a useful thing - the concept is all well
and good but it would appear that most people are already quite well-prepared to
do a bit of coding.
The only real aspect of IF coding that I can imagine would be made substantially
easier by the use of and IDE would be creating a map - QDK doesn't support a
visual map editing feature yet, although SUDS does. Having tried the Constructor
though, all it seems to do is hinder coding by making you click a large number
of things in order to get a basic instruction out, and yet it doesn't really
seem to hide any complexity from the IF author - kind of defeating the object
really. Not that I claim QDK makes the job much easier either, which is probably
the cause of its seemingly limited appeal.
> 7. Okay - Cross-Platform would be nice too, but that _would_ be difficult.
> Herein lies the problem. With the user base as it is on raif, would people
> welcome a Windows based IDE? Probably not. But it sure would make things
> easier for newcomers that use Windows based computers.
That was certainly the idea with Quest/QDK, and I imagine it's the reasoning
behind SUDS too. The problem is that VB and Delphi are difficult to port to
other OS's, and there doesn't seem to be a language that exists that can port
interfaces (I imagine this is what GLK is supposed to do, although it would mean
recoding all of QDK - not something I really wish to contemplate).
--
Alex Warren, Axe Software · al...@axesoftware.co.uk · ICQ: 4043750
http://www.axesoftware.co.uk - including Quest, the IF system for Win95
David Thornley
>> In article <38264...@dilbert.ic.sunysb.edu>,
>> David Samuel Myers <dmy...@sparky.ic.sunysb.edu> wrote:
>> > Continuing in line with what Mike Snyder said ---
>> >
>> What I'm getting at is that you can't just shoehorn traditional
>> programming advancements into IF and expect to get the same overall
>> gains.
>
>I disagree with this statement enormously. By adding the simplicities of a
>Visual Basic like environment, you reduce the barrier to entry for whichever
>language you've chosen to simplify, which I believe was the whole point of
>Visual Basic. Beforehand, you needed to know C++ and the Windows SDK which
>for many people was a huge barrier.
>
Except that that isn't the same. I know very little about VB, but I
would assume that it's a general-purpose programming language, and
therefore that you can do pretty much anything in it that you could do
in C++ (although one language may well be easier to do any specific
thing with, and the result may be faster in one than the other).
This means that somebody going from C++ to VB would not really be losing
much expressive power, except when projects get so large that software
engineering considerations start to dominate. You can do the same
things, but easier.
This doesn't seem to be the case with SUDS. It is apparently much
more limiting than the traditional IF languages. It does not reduce
the entry barrier for writing something like a good competition entry.
>When I first started in this whole hobby three years ago, I really didn't
>understand oo programming despite being a professional and successful
>software developer. It took me three major writings in Inform before the
>lights went on and that amounted to well over two years. I still don't
>consider myself all that good of an oo programmer.
>
>Using an IDE for Inform, I believe that two years could have been reduced
>significantly.
I have real problems with this statement.
There are things an IDE can do. I like the Metrowerks and Digitool
IDEs a lot. They help me write, test, and debug code.
They do not substitute for knowing what I am doing. I didn't learn about
object-oriented programming from the IDE. I learned it from experience
in writing object-oriented code, and books like Keene's "Object-oriented
Programming in Common Lisp".
In fact, I believe it would have helped reduce many of the
>coding bugs that I released in Town Dragon as well as spelling (assuming any
>well-written IDE would have spell-checking within and possibly grammar).
Oh, it would have. I like the syntax coloring in the Metrowerks IDE.
I like Macintosh Common Lisp's little pop-up of function parameters
whenever I type a function name. I wouldn't dream of writing Lisp
without a parenthesis-matching editor, and I very much like having one
for C++.
This, of course, has nothing to do with object orientation.
(BTW, I've never seen a grammar checker that I'd trust. I've used some,
and found them very useful, but only since I knew what I was doing, and
was able to evaluate their suggestions myself.)
>An IDE could also 'guide' you into writing better IF by keeping a check list
>of objects that need to be described. It could point out that you have two
>or more similar objects and ask if you want to merge them or create a class
>for them.
This strikes me as being seriously ambitious. Does SUDS do anything like
this?
It could help you implement doors, which I believe is an
>enormously confusing task at times.
Libraries. Other people write the stuff. You use it.
It could help you build NPC code that
>works and possibly even ask you if you want to use some of the library
>contributions, such as follower or movelcass. It could help you manage the
>complexity of all of your objects by keeping tabs on all of their
>relationships. You would be able to 'see' the big pictuire. All of these
>things would reduce the barrier to building successful, well-written games
>for new programmers.
Yes, although I think you've gone beyond state of the art. It might
be worth doing, but I assure you I don't have time for the design work.
The IDE need only adhere to one simple rule. It must
>not in any way shape or form reduce the flexibility of writing ones own
>code. It must be able to import a text version of the code and export a text
>version of the code and understand it without problems. But I believe this
>is doable.
>
>And then you have...
>
>> * General parsing
>> * Dialogue parsing
>> * Artificial intelligence
>> * Handling combinatorial explosion
>> * Physics/world modelling
>> * Emotional modeling
>
>Of course these are all wonderful things too, but why can't we reduce the
>barrier to coding AND improve the overall programming depth with these types
>of enhancements? I still don't understand why this is such a difficult
>concept to understand.
>
It isn't. The problem is to do the entry barrier stuff while still
allowing the neat stuff above. The hypothetical IDE you described would
be useful to that. It looks like SUDS isn't.
>Jarb
>
>PS: By the way, I've been working with a psychologist friend in trying to
>build emotional modeling. It ain't even close to easy and I'm not sure of
>the value of it in anything but a very large, complex game. But we're
>trying. You'll see the results in my WIP, whenever I finish it. Probably 8
>years from now.
The big problem I see is translating a character's internal state to
game description. So far, I don't see anything better than partitioning
the emotional state space into regions manually and writing code and/or
descriptions individually.
Magnus Olsson
Alex Warren <S...@THE.SIG.COM> wrote:
>The problem is that VB and Delphi are difficult to port to
>other OS's, and there doesn't seem to be a language that exists that can port
>interfaces (I imagine this is what GLK is supposed to do, although it would mean
>recoding all of QDK - not something I really wish to contemplate).
If you mean a ortable language for writing GUI applications, there's
Tcl/Tk, and Python with its Tk interface, just to name two.
okbl...@my-deja.com
> The only real aspect of IF coding that I can imagine would be made
substantially
> easier by the use of and IDE would be creating a map
I don't think that map generation is *that* big a deal. Anybody can
throw together a map pretty quickly in TADS or Inform or Alan or Hugo.
I've never done much more than look at Alan or Hugo code, but I'm
reasonably sure that I could put together an elaborate map pretty dang
quickly in either of them.
I'm not saying it wouldn't help, mind you, just that it's not the main
thing people bang their heads on. If it were to be *really* useful, I
think it should allow variable sized sticks-and-balls, so that you
could, for example, easily draw an area in which certain senses could be
passed.
For example, you have a room with a big printing press in it that's
clattering away. You then have a big circle expand outward from that
room to indicate other rooms in which the printing press could be heard.
At least, I think that would be useful.
> > 7. Okay - Cross-Platform would be nice too, but that _would_ be
difficult.
> > Herein lies the problem. With the user base as it is on raif, would
people
> > welcome a Windows based IDE? Probably not. But it sure would make
things
> > easier for newcomers that use Windows based computers.
I think the resistance to a Windows-based IDE is less than the
resistance to a Windows-only player environment. I have no idea what the
actual numbers are, but I've certainly heard people say that they would
use a WIndows IDE if that didn't limit their players to Windows.
> That was certainly the idea with Quest/QDK, and I imagine it's the
reasoning
> behind SUDS too. The problem is that VB and Delphi are difficult to
port to
> other OS's, and there doesn't seem to be a language that exists that
can port
> interfaces (I imagine this is what GLK is supposed to do, although it
would mean
> recoding all of QDK - not something I really wish to contemplate).
I've heard rumors that Borland has an Alpha for Delphi for Linux. A
German company called Speedsoft has a Delphi-like Pascal environment for
OS/2, 32-bit Windows and a "pre-Alpha" for their Linux version. If you
made the player in Pascal (say avoiding most of the post-Delphi 2.0
features, which aren't that important to text programming), you could
use fPrint's Virtual Pascal to port the player between OS/2, Win32, DOS
and Linux, I think.
There are options for cross-platform stuff other than C, but you have to
work harder to find them.
Daniel Barkalow
> 7. Okay - Cross-Platform would be nice too, but that _would_ be difficult.
> Herein lies the problem. With the user base as it is on raif, would people
> welcome a Windows based IDE? Probably not. But it sure would make things
> easier for newcomers that use Windows based computers.
Glk IDE, anyone? I don't think an IDE actually involves any interface
operations that aren't used in playing text adventures, and there are
already interpreters which will be happy in the subwindows of such an
interface. Besides, we don't have to welcome *all* windows users, just
those willing to play with text. :)
Andrew Plotkin
Well, for some people, "IDE" *does* include menus, buttons, dialogue
boxes, list windows, and other widgets. At least, I'm pretty sure that's
what most people in this thread are visualizing when we talk about a TADS
or Inform IDE.
I would love to have Glk support such widgets someday, but it doesn't
right now, and it's not going to any time soon.
TCL/TK is often suggested as a cross-platform GUI toolkit. So is Java.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Daniel Barkalow
> The first chapter of the old TADS manual showed how to write a lousy
> game fairly fast. If you just read the sections on the airport
> game sketch and the demo, you could copy enough to write a lousy game.
You have a good point. When I was that age, I didn't have any IF-specific
tools, and basic just wasn't good enough. to get me far enough.
> >We've already had the hard part done, but the (reletively) easy part
> >remains. There's nothing inherently bad about a slick IF system; it's
> >just that if you start out making the IF system slick, you'll miss the
> >important parts.
> >
> Um, are you saying that interface design is even relatively easy?
> I think that making a good programmer productivity aid, that helps
> get the easy stuff done and doesn't interfere with the harder stuff,
> is going to be difficult.
Considering the number of snazzy interfaces we've seen relative to the
number of really solid systems, I would think that the interfaces require
less cleverness. What I really meant, however, is that the programmer
interface is less important.
> (Not to mention that any sort of IDE will tend to be platform-specific,
> unless it's built around Tk or wxWindows or Java or something. Actually,
> Java would probably be the best bet, being as platform-independent as
> you can get and still have a GUI.)
I'm not convinced that an IDE will need a GUI any more than a word
processor or a mail reader. You clearly need good text editing, and the
ability to look at a bunch of parts of the program at the same time, and
some rudimentary graphics might be useful for letting you lay out maps in
the IDE so they make physical sense, but I can't think of a need for more
of a GUI than that.
I think Glk can do all of that, and it already proven cross-platform.
Furthermore, it's at the right level to be cross-platform with the
interface being sensible to people used to each platform.
Fraser
>Pompous or not, it's much needed. And, let's face it, with *that*
>accent, you can't help but sound pompous to us yanks! ;-)
Not as pompous as the sound of Americans mimicing my (Australian)
accent. They assure me that I don't really sound like that, but
I wonder.
Fraser.
(it's more of a Sam Neill than a Paul Hogan accent by the way)
(in fact, I don't think I've ever met someone who talks like Paul
Hogan)
(except for this guy who's greeting was "G'day mate! How's ya father?")
okbl...@my-deja.com
blanc...@blancolioni.org (Fraser) wrote:
>
> Not as pompous as the sound of Americans mimicing my (Australian)
> accent. They assure me that I don't really sound like that, but
> I wonder.
>
> Fraser.
> (it's more of a Sam Neill than a Paul Hogan accent by the way)
> (in fact, I don't think I've ever met someone who talks like Paul
> Hogan)
> (except for this guy who's greeting was "G'day mate! How's ya
father?")
Maybe you should be grateful it's more of a Paul Hogan thing than a
Yahoo Serious thing?
Fraser
> Clearly, people are
>more productive with Windows based OS's than Unix.
I'm genuinely interested in why you think this. I don't think it's clear
at all.
I'd disagree more, but I'm not sure exactly what you mean. Does "Windows
based" refer to:
- any OS produced by Microsoft
- any OS with a GUI
- an OS produced by Microsoft or Apple
- an OS with a GUI that has office-type applications.
Does the word "people" refer to:
- programmers
- secretaries
- executives
- game players.
"Clearly" is not the word.
> But which OS has more users doing more and accomplishing
>more? It's not even close.
That's market penetration, not productivity.
>Of course this is where I come from and I don't
>try to push these views on raif anymore, because, well, it ain't popular. So
>just ignore I said this. (;
Whoops! :)
>7. Okay - Cross-Platform would be nice too, but that _would_ be difficult.
>Herein lies the problem. With the user base as it is on raif, would people
>welcome a Windows based IDE? Probably not. But it sure would make things
>easier for newcomers that use Windows based computers.
GTK runs on X and MS Windows. Unfortunately, the text widget is so buggy
as to be almost completely useless at the moment. Apparently this is
changing.
It's free software, so I could look into fixing it, but who has the time?
Tcl is cross platform, but I've never seen a good-looking Tcl application.
Fraser.
Trevor Barrie
David Cornelson <dcorn...@placet.com> wrote:
>Neil K posted about culture clash and I think he hit the nail on the head. I
>come from the commercial, profit, Microsoft world. Any knowledge of
>shareware, freeware, and Unix is pretty much from here and the ifMUD. And it
>has taken me a long time to accept the fact that this group generally comes
>from a different background than I do. I have had to change.
>
>Neil made a comment that Unix is a far superior OS. Why?
Because it makes it easier for me to get things done. Why else?
>I would question whether engineering or productivity is more important.
>Clearly, people are more productive with Windows based OS's than Unix.
This is clear how?
>I won't argue that Unix is probably more stable and up until recently blew
>the doors off of NT for responsiveness. But which OS has more users doing
>more and accomplishing more? It's not even close.
Ummm, so productivity and popularity are synonymous in your view? If one
person uses Widget-Whacker brand A and whacks 120 widgets a day, and
fifty people of equal skill use Widget-Whacker brand B and each whack 3
widgets a day, you'd say "Look, people are clearly more productive with
brand B... 150 widgets/day as opposed to 120!"?
Peter Seebach
Fraser <blanc...@blancolioni.org> wrote:
>paene lacrimavi postquam "David Cornelson" <dcorn...@placet.com> scripsit:
>>more productive with Windows based OS's than Unix.
>I'm genuinely interested in why you think this. I don't think it's clear
>at all.
Well, depends on what you mean by "productive". I don't see any evidence
that people using clumsy GUI interfaces can come within hailing distance of
the performance of the heavily tweaked shell scripts I use to process my
mail. I end up reading around 100,000 emails a year, give or take. ;-)
Word processing? Well, honestly, I'll take anything *without* all of MS
Word's "features" over MS Word any day. I used to have to write technical
docs in MS Word. It was awful; even after you turned off most of the stuff,
it kept trying to auto-number paragraphs, and it did it *wrong*, but you
couldn't override it most of the time, because the software-generated numbers
weren't selectable text.
I'd guess about 30% of my time went into fighting the editor.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Dave
>
> Ummm, so productivity and popularity are synonymous in your view? If one
> person uses Widget-Whacker brand A and whacks 120 widgets a day, and
> fifty people of equal skill use Widget-Whacker brand B and each whack 3
> widgets a day, you'd say "Look, people are clearly more productive with
> brand B... 150 widgets/day as opposed to 120!"?
Oh, puh-leez. At least do your research. There is simply no way that
anyone could whack more than 50 widgets in a day, I don't care what
brand you use.
David Cornelson
news:1999Nov10.1...@jarvis.cs.toronto.edu...
> In article <80aphj$81p$1...@bgtnsc02.worldnet.att.net>,
> David Cornelson <dcorn...@placet.com> wrote:
>
> >Neil K posted about culture clash and I think he hit the nail on the
head. I
> >come from the commercial, profit, Microsoft world. Any knowledge of
> >shareware, freeware, and Unix is pretty much from here and the ifMUD. And
it
> >has taken me a long time to accept the fact that this group generally
comes
> >from a different background than I do. I have had to change.
> >
> >Neil made a comment that Unix is a far superior OS. Why?
>
> Because it makes it easier for me to get things done. Why else?
>
> >I would question whether engineering or productivity is more important.
>
>
> >I won't argue that Unix is probably more stable and up until recently
blew
> >the doors off of NT for responsiveness. But which OS has more users doing
> >more and accomplishing more? It's not even close.
>
> person uses Widget-Whacker brand A and whacks 120 widgets a day, and
> fifty people of equal skill use Widget-Whacker brand B and each whack 3
> widgets a day, you'd say "Look, people are clearly more productive with
> brand B... 150 widgets/day as opposed to 120!"?
Um - Yes - 150 is greater than 120.
Jarb
Graham Nelson
<URL:mailto:dmy...@sparky.ic.sunysb.edu> wrote:
> I also think a vast number of people (again not *everyone* here, but
> invariably some) underestimate the gains in time that are made by letting
> the IDE auto generate some code for you.
There's something in this. My text editor has an "Inform" mode
which syntax-colours, produces clickable lists of object and
class definitions, and has nice options such as "start a game
with any given name" and "make an item". For instance, I choose
the option for "make a vehicle", type in "rickety hay wain" and
the editor inserts the following into the code:
Object -> rickety_hay_wain "rickety hay wain"
with name "rickety" "hay" "wain",
before
[; Go: ; ! Look at noun, which is a direction
! like n_obj, and return true if the
! proposed move is OK, false if not.
],
has enterable static container open;
I can then click for any extra attributes or properties.
So I think what I'm suggesting is that a lot of the labour-saving
devices are most appropriately provided at the level of text
editing, or in some other external shell, rather than as part of
the system itself?
BrenBarn
>creation process. For example, one could write an IDE for Inform, or a
>tool where you build the game map by clicking and dragging. But I
>don't think such tools would simplify the process enough for it to
>matter very much. It would, perhaps, be easy to write a very simple
>game, and *then* when you wanted to add add more complexity you'd run
>smack into the learning curve. Or, which would be much worse, you'd
>find that the nice, shiny tool wouldn't *let* you add the complexity
>you needed.
I agree. I must say it would be nice if I could just draw a map instead
of putting in bunches of "n_to"s and "e_to"s and such, but there's yet another
problem. I personally would feel let down (and have felt let down) by an IDE
which purports to make programming "easier" and "more visual", but is really
just a front end that generates code for some behind-the-scenes programming
language.
In other words, with most IDEs, the complexity that you can achieve lies in
the LANGUAGE, not the development environment, and as a result the environment
is conceived as an afterthought to the language itself. So what you have an
IDE that lets you "visually" do the easy stuff, but leaves you out in the cold
and running to your text editor when you have to do anything even remotely
complex.
What I'm trying to say is that often, with an IDE, you wind up having to do
almost as much old-fashioned coding as ever. And its hard for someone to
motivate themself to make an IDE, because they're basically just translating
the same stuff into a new medium. The ideal solution, I think, would be a
language that was CONCEIVED as a visual language, and thus was inextricably
linked with its IDE. (Of course, that means no more Inform, which puts me, at
least, back to square one. :-)
I notice I'm dizzy. Was what I wrote at all comprehensible?
From,
Brendan B. B. (Bren...@aol.com)
(Name in header has spam-blocker, use the address above instead.)
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Peter Seebach
BrenBarn <bren...@aol.comRemove> wrote:
> In other words, with most IDEs, the complexity that you can achieve lies in
>the LANGUAGE, not the development environment, and as a result the environment
>is conceived as an afterthought to the language itself.
I would go further; in most cases, the complexity that you are facing is the
complexity of the *problem* you are trying to solve, and nothing can ever
change it.
John West McKenna
>(it's more of a Sam Neill than a Paul Hogan accent by the way)
Except he's Irish, brought up in NZ. Australia has a habit of adopting
successful Kiwis.
Not Fraser Wilson, by any chance? Swanbourne High? I think he was an
ex-Kiwi (I may be wrong - it's been a long time).
John West
Evin Robertson
Andrew Plotkin <erky...@netcom.com> wrote:
> Well, for some people, "IDE" *does* include menus, buttons, dialogue
> boxes, list windows, and other widgets. At least, I'm pretty sure that's
> what most people in this thread are visualizing when we talk about a TADS
> or Inform IDE.
>
> I would love to have Glk support such widgets someday, but it doesn't
> right now, and it's not going to any time soon.
Menus, buttons, and list windows can be made in Glk through excessive
cleverness with text grid windows. If that's not enough, you can use
the rectangle drawing command to render text on graphics windows.
The difficulty is a text editor widget. A text grid won't work. You
can't use character input in it because then the user might not be
able to see the cursor. You can't use line input in it because then
you can't change lines in the middle of editing. Perhaps some vi-like
modal editor could be made, but I doubt the GUI crowd would appreciate
it. A graphics window won't work because they don't accept keyboard
input (though perhaps you could take character input from a small
window and represent it in the graphics window). At any rate, you
won't have platform-native text editing keystrokes.
For an Inform IDE, I'd just recommend emacs. Other than perhaps
clever map-dragging-editing stuff, it should be able to provide
everything people need.
Daniel Barkalow
> Neil made a comment that Unix is a far superior OS. Why? I would question
> whether engineering or productivity is more important. Clearly, people are
> more productive with Windows based OS's than Unix. I won't argue that Unix
> is probably more stable and up until recently blew the doors off of NT for
> responsiveness. But which OS has more users doing more and accomplishing
> more? It's not even close. Of course this is where I come from and I don't
> try to push these views on raif anymore, because, well, it ain't popular. So
> just ignore I said this. (;
My particular experience has been exactly the opposite. I got some stuff
done back when I was using DOS, got nothing at all done in Windows 3.1,
got very little done with any other Windows, and find Unix to be the best
thing since sliced bread.
E.g., I find it more efficient to write everything but the
preliminary notes for a problem set on the computer than on paper.
I'm using Linux (with latex, make, and jed). I don't know of anyone
having increased productivity with Windows over not having Windows. In
fact, I suspect that Windows is, to a large extent, the reason the
computer revolution has not increased overall productivity.
In any case, just an anecdote.
Daniel Barkalow
> Well, for some people, "IDE" *does* include menus, buttons, dialogue
> boxes, list windows, and other widgets. At least, I'm pretty sure that's
> what most people in this thread are visualizing when we talk about a TADS
> or Inform IDE.
When *I* think IDE, I think of Turbo Pascal 5.0 or so for DOS. That
didn't even have things as sophisticated as Glk. Glk certainly wouldn't
be sufficient for a VDE, but I'm not convinced that such a thing would
have any major advantages over an IDE with a more spartan interface.
Kevin Lighton
> "Trevor Barrie" <tba...@cs.toronto.edu> wrote in message
> news:1999Nov10.1...@jarvis.cs.toronto.edu...
>> In article <80aphj$81p$1...@bgtnsc02.worldnet.att.net>,
>> David Cornelson <dcorn...@placet.com> wrote:
>> >I won't argue that Unix is probably more stable and up until recently
> blew
>> >the doors off of NT for responsiveness. But which OS has more users doing
>> >more and accomplishing more? It's not even close.
>> Ummm, so productivity and popularity are synonymous in your view? If one
>> person uses Widget-Whacker brand A and whacks 120 widgets a day, and
>> fifty people of equal skill use Widget-Whacker brand B and each whack 3
>> widgets a day, you'd say "Look, people are clearly more productive with
>> brand B... 150 widgets/day as opposed to 120!"?
> Um - Yes - 150 is greater than 120.
Except that, if the 50 people using Widget-Whacker brand B used Widget-Whacker
brand A instead, they'd increase their productivity 40 times.
Which one produces better productivity can only reasonably be judged by how
well people of equal skill _in equal numbers_ produce, not by more being
produced using a more inefficient system because more people use it.
Ja, mata
--
Kevin Lighton lig...@bestweb.net or shin...@operamail.com
http://members.tripod.com/~shinma_kl/main.html
"Townsfolk can get downright touchy over the occasional earth-elemental in
the scullery. Can't imagine why..." Quenten _Winds of Fate_
Kevin Forchione
news:ant1022460b0M+4%@gnelson.demon.co.uk...
> So I think what I'm suggesting is that a lot of the labour-saving
> devices are most appropriately provided at the level of text
> editing, or in some other external shell, rather than as part of
> the system itself?
I would agree with this. Finding a text editor that allows for macro
handling of this sort is very useful.
--Kevin
Mike Snyder
news:Pine.LNX.3.91.99111...@iabervon.mit.edu...
> My particular experience has been exactly the opposite. I got some stuff
> done back when I was using DOS, got nothing at all done in Windows 3.1,
> got very little done with any other Windows, and find Unix to be the best
> thing since sliced bread.
> E.g., I find it more efficient to write everything but the
> preliminary notes for a problem set on the computer than on paper.
> I'm using Linux (with latex, make, and jed). I don't know of anyone
> having increased productivity with Windows over not having Windows. In
> fact, I suspect that Windows is, to a large extent, the reason the
> computer revolution has not increased overall productivity.
Oh, <laugh> this was just what I needed this morning, and it certainly puts
a new twist on "interactive fiction." I especially like the part about Unix
being the best thing since sliced bread. :) :) :) My apologies if you
weren't joking.
Mike.
Andrew Plotkin
>> Well, for some people, "IDE" *does* include menus, buttons, dialogue
>> boxes, list windows, and other widgets. At least, I'm pretty sure that's
>> what most people in this thread are visualizing when we talk about a TADS
>> or Inform IDE.
>>
>> right now, and it's not going to any time soon.
>
> Menus, buttons, and list windows can be made in Glk through excessive
> cleverness with text grid windows. If that's not enough, you can use
> the rectangle drawing command to render text on graphics windows.
Everybody knows that Evin makes my head hurt, right?
Andrew Plotkin
>> done back when I was using DOS, got nothing at all done in Windows 3.1,
>> got very little done with any other Windows, and find Unix to be the best
>> thing since sliced bread.
>
> a new twist on "interactive fiction." I especially like the part about Unix
> being the best thing since sliced bread. :) :) :)
All right, you guys, take it to one of the advocacy groups.
If RAIF turns into yet another OS flamewar group, I'm leaving.
BrenBarn
>>> person uses Widget-Whacker brand A and whacks 120 widgets a day, and
>>> fifty people of equal skill use Widget-Whacker brand B and each whack 3
>>> widgets a day, you'd say "Look, people are clearly more productive with
>>> brand B... 150 widgets/day as opposed to 120!"?
>
>> Um - Yes - 150 is greater than 120.
>
>Except that, if the 50 people using Widget-Whacker brand B used
>Widget-Whacker
>brand A instead, they'd increase their productivity 40 times.
>Which one produces better productivity can only reasonably be judged by how
>well people of equal skill _in equal numbers_ produce, not by more being
>produced using a more inefficient system because more people use it.
Perhaps even more important, people have a desire to use what they know.
There's no doubt in anyone's mind that the metic system makes way more sense
the crazy English system, but it's just so darn hard to make that change.
Likewise, if someone's been using Widget-Whacker brand B all their lives,
they'll probably be less likely to transition to Widget Whacker brand A, even
if they KNOW its more efficient.
But it seems like we're talking about a perfect world here anyway, so:
Yes, you're right. :-)
Magnus Olsson
Andrew Plotkin <erky...@netcom.com> wrote:
>>> My particular experience has been exactly the opposite. I got some stuff
>>> done back when I was using DOS, got nothing at all done in Windows 3.1,
>>> got very little done with any other Windows, and find Unix to be the best
>>> thing since sliced bread.
>>
>> Oh, <laugh> this was just what I needed this morning, and it certainly puts
>> a new twist on "interactive fiction." I especially like the part about Unix
>> being the best thing since sliced bread. :) :) :)
>
>All right, you guys, take it to one of the advocacy groups.
>
>If RAIF turns into yet another OS flamewar group, I'm leaving.
My feeling exactly. Though I'll try killfiling first. The problem is when
the religious wars invade a thread where there's still some interesting
discussion going on. (The "real millenium bug" thread, OTOH, I killfiled
after reading just one message.)
Listen, guys: Unix is one of those things in life that you either love
or hate. No amount of flaming is likely to convert anybody to the
other side, so let's just leave it at that, shall we?
okbl...@my-deja.com
Andrew Plotkin <erky...@netcom.com> wrote:
>
> All right, you guys, take it to one of the advocacy groups.
>
> If RAIF turns into yet another OS flamewar group, I'm leaving.
AMIGA RULEZZZZ!!
--
[ok]
sg
>Lastly. On the issue of a VDE or IDE or whatever. I simply think an Editor
>specifically tailored to one of the programming languages would be a great
>leap in productivity for all of us. It would just be an environment that
>logically organized your code. It wouldn't _do_ anything for you outside of
>that. It wouldn't limit your ability to write complex code. Can we just
>assume this is a requirement?
Following on from your review of SUDS, then, I'd like to see your
reviews of Informer and IMForm (in the IF Archive programming/editors
directory.)
Informer is an editor tailored to Inform. Perhaps exactly what you're
envisaging? Certainly a review of it would be topical in this thread.
IMForm is the outline (its unfinished) of an Inform programming IDE
(or maybe its a VDE -- depending on what VDE means!)
>There really are only a few requirements for an IDE.
[snipped Jarb's list - which I think is a good list, by the way]
--
SteveG.
(Remove the 'wrongbit.' from my
address if replying via email.)
Mike Snyder
news:80evil$h2u$1...@bartlet.df.lth.se...
> Listen, guys: Unix is one of those things in life that you either love
> or hate. No amount of flaming is likely to convert anybody to the
> other side, so let's just leave it at that, shall we?
I am *not* flaming Unix. I like Unix just fine and I use Unix/Linux daily
for several web-related tasks (and I've used it professionally while
developing a configuration system for AT&T.) I've used a variety of systems
(including Macintosh) and aside from feeling that I'm most productive with
Windows, I like them all. I'm not an OS advocate, I was just replying to
what I felt was an amusing insistance that one OS far surpasses the other.
Admittedly, Zarf's comment was enough for me to realize that I shouldn't
have posted that at all, but I wasn't trying to start an OS flame war.
Mike.
Fraser
>Except he's Irish, brought up in NZ. Australia has a habit of adopting
>successful Kiwis.
Well, I never said Sam was an Australian. I just said my accent was
more like his. Ha! :)
>Not Fraser Wilson, by any chance? Swanbourne High? I think he was an
>ex-Kiwi (I may be wrong - it's been a long time).
Well, golly. It's only been 13 years. Nice to see that the UCC
still operates.
Yes, I'm technically a Kiwi, but for the purposes of living in the US, I'm
an Australian.
Fraser.
--
fraser 'at' whitelion 'dot' org
David Cornelson
news:ant1022460b0M+4%@gnelson.demon.co.uk...
> <URL:mailto:dmy...@sparky.ic.sunysb.edu> wrote:
> > I also think a vast number of people (again not *everyone* here, but
> > invariably some) underestimate the gains in time that are made by
letting
> > the IDE auto generate some code for you.
>
> There's something in this. My text editor has an "Inform" mode
> which syntax-colours, produces clickable lists of object and
> class definitions, and has nice options such as "start a game
> with any given name" and "make an item". For instance, I choose
> the option for "make a vehicle", type in "rickety hay wain" and
> the editor inserts the following into the code:
>
>
> Object -> rickety_hay_wain "rickety hay wain"
> with name "rickety" "hay" "wain",
> before
> [; Go: ; ! Look at noun, which is a direction
> ! like n_obj, and return true if the
> ! proposed move is OK, false if not.
> ],
> has enterable static container open;
>
>
> I can then click for any extra attributes or properties.
>
> devices are most appropriately provided at the level of text
> editing, or in some other external shell, rather than as part of
> the system itself?
And he shall see the light. And the light will guide him to the truth. And
the truth will set him free.
An Inform IDE would not _be_ Inform. Just a shell editor with lots of really
cool time-saving features built-in.
Jarb
David Cornelson
news:80du7t$b7m$1...@nnrp1.deja.com...
> In article <80cdta$jso$2...@nntp3.atl.mindspring.net>,
> Andrew Plotkin <erky...@netcom.com> wrote:
>
> For an Inform IDE, I'd just recommend emacs. Other than perhaps
> clever map-dragging-editing stuff, it should be able to provide
> everything people need.
Here we go with Emacs again. I don't want to learn Emacs - I want to write
Interactive Fiction in an environment that supports IF programming AND
writing.
Relating to an Inform IDE:
Stop saying the following things because it's _not_ what I have been
describing:
1. I don't want some feature-rich unix founded editor to write IF in. Why?
Because it's a feature-rich _unix_ founded _editor_.
2. It doesn't need to write code for me. I can write my own code.
3. It doesn't need to map things for me. I can create my own maps.
What it _should do:
1. Open a text file with code in it.
2. Organize the classes, objects, attributes, properties, functions, grammar
definitions, and variables visually.
3. Highlight syntax where needed.
4. Correct syntax or offer to correct syntax where needed (if I want - I
should be able to turn this off).
5. Ability to click on an class, object, attribute, property, etc from a
list and be transported to the code that the selected widget describes.
I realize that some of you are familiar with Emacs but building anything on
Emacs would only be great for you. You build two barriers then, one to
Emacs, and then one to IF. I'm trying to suggest a way to _reduce_ the
barriers.
Jarb
Magnus Olsson
David Cornelson <dcorn...@placet.com> wrote:
>"Evin Robertson" <nit...@my-deja.com> wrote in message
>news:80du7t$b7m$1...@nnrp1.deja.com...
>> In article <80cdta$jso$2...@nntp3.atl.mindspring.net>,
>> Andrew Plotkin <erky...@netcom.com> wrote:
>>
>> For an Inform IDE, I'd just recommend emacs. Other than perhaps
>> clever map-dragging-editing stuff, it should be able to provide
>> everything people need.
>
>Here we go with Emacs again. I don't want to learn Emacs - I want to write
>Interactive Fiction in an environment that supports IF programming AND
>writing.
I think people are suggesting not using Emacs as it is, or even Emacs
with minor additions (such as the existing Inform mode), but using
Emacs as a platform on which to build the IDE. Of course, it may
not be the ideal platform - for example, I don't think you can write a
GUI application in Emacs.
>Relating to an Inform IDE:
>Stop saying the following things because it's _not_ what I have been
>describing:
>1. I don't want some feature-rich unix founded editor to write IF in. Why?
>Because it's a feature-rich _unix_ founded _editor_.
To some people, Emacs is much more than an editor. And I don't mean that
in some smartass "Emacs-as-religion" sense, but more literally: some people
do more or less everything from inside Emacs. But since I just use Emacs
as an editor myself I'll let the real aficionados expand on this.
And what do you mean by "unix founded"? To begin with, Emacs doesn't
come from Unix, it comes from the ITS and Multics communities which
predated Unix. If you mean that it enforces a Unix mindset, I think
you're wrong: Emacs enforces the Emacs mindset, which is something
different.
>2. It doesn't need to write code for me. I can write my own code.
Good for you. But many people have asked for such a feature. I think
it depends a lot on one's background: you and I prefer writing our own
code, but people who are new to programming seem daunted by the fact
that they have to get every little colon and comma right, or be
treated to a bunch of strange error messages. Of course, the idea of
an IDE (or whatever) that automatically writes all the code (sort of a
4GL for IF) is a pipe dream, but if it could reduce the burden of
getting the syntax right for the neophytes I think it would be a good
thing.
>3. It doesn't need to map things for me. I can create my own maps.
So can I, and I think a graphic map-making tool would have to be rather
sophisticated or we'd end up with very artificial, grid-like maps.
What *would* be nice would be a tool that, when I decide to change the
geography of the game, would automatically make all the changes implied
by, for example, letting two rooms swap places.
>What it _should do:
>1. Open a text file with code in it.
Well, Emacs can surely do that :-). (Sorry, couldn't resist it)
>2. Organize the classes, objects, attributes, properties, functions, grammar
>definitions, and variables visually.
You mean you want browsers for those things? I suppose it could be
done in Emacs, but in a rather clunky way. Something more like VB
would be nice, perhaps.
>3. Highlight syntax where needed.
>4. Correct syntax or offer to correct syntax where needed (if I want - I
>should be able to turn this off).
>5. Ability to click on an class, object, attribute, property, etc from a
>list and be transported to the code that the selected widget describes.
You can do all that in Emacs, too :-).
>I realize that some of you are familiar with Emacs but building anything on
>Emacs would only be great for you. You build two barriers then, one to
>Emacs, and then one to IF. I'm trying to suggest a way to _reduce_ the
>barriers.
Are you referring to the legendary obscurity of Emacs' UI here (lots
and lots of two-control-key combinations)? You have a point. But even
if "your" system would be much easier to learn than Emacs, and easier
to use in the sense that you wouldn't have to remember all those
strange control-alt-meta-cokebottle commands, users would still have
to learn it. You can't make things *completely* obvious.
In fact, you'd have *three* barriers: one to the IDE, one to Inform,
and one to IF. The question is whether the last two barriers would be
lowered enough for it to be worth the effort.
I think the reason you get such a lukewarm response when you suggest
things like this to the "established" IF community is not that anybody
is opposed to it in principle, or that they think it would be
unnecessary or a waste of time, but rather that they'd rather invest
the necessary energy in other areas. This could be because they think
that improvements in those other areas would benefit the IF community
as a whole more, or simply because they think it would be more fun.
My personal view is that there are some good ideas around, and yours
are among them, but *I* don't have the time or inclination to puruse
them myself.
Kevin Forchione
news:80fk5i$glj$1...@bgtnsc03.worldnet.att.net...
Oh! You mean that thingummy that Graham has apparently been using for years!
IDE, eh? Why didn't you just say "fancy-shmancy text-editor"? We could have
had that years ago...
David Cornelson
> In article <80fl60$kvh$1...@bgtnsc03.worldnet.att.net>,
> David Cornelson <dcorn...@placet.com> wrote:
> >"Evin Robertson" <nit...@my-deja.com> wrote in message
> >news:80du7t$b7m$1...@nnrp1.deja.com...
> >> In article <80cdta$jso$2...@nntp3.atl.mindspring.net>,
> >> Andrew Plotkin <erky...@netcom.com> wrote:
> >>
> I think people are suggesting not using Emacs as it is, or even Emacs
> with minor additions (such as the existing Inform mode), but using
> Emacs as a platform on which to build the IDE. Of course, it may
> not be the ideal platform - for example, I don't think you can write a
> GUI application in Emacs.
I guess my point is that my idea of an IDE would be design and build from
the ground up as a tool for writing interactive fiction. Emacs sort offers a
plethora of options that would very likely never be used, and by their
presence, confuse and intimidate many a writer/programmer.
> >2. It doesn't need to write code for me. I can write my own code.
>
> Good for you. But many people have asked for such a feature. I think
I guess what I meant is that the IDE wouldn't _have_ to write code for me. I
would
have the option of turning _off_ the wizards and code-creators to write my
own little
blobs of code and that should be okay with the IDE. You're right though, the
idea is
that the IDE would be sophisticated enough to handle many of the more basic
features
of IF, like basic room creation, mapping connections, creating things, etc.
> >3. It doesn't need to map things for me. I can create my own maps.
>
> So can I, and I think a graphic map-making tool would have to be rather
> sophisticated or we'd end up with very artificial, grid-like maps.
>
> What *would* be nice would be a tool that, when I decide to change the
> geography of the game, would automatically make all the changes implied
> by, for example, letting two rooms swap places.
I was thinking that it would just allow you to see the exits somehow and
easily be able to follow them around with a click. Sort of like a compass
rose. If you click on a direction that has no code, a dialog window asks
you what to do, connect to an existing room, or open a connection to a
new room, much the way the mud does things (only this would be mouse
oriented).
> In fact, you'd have *three* barriers: one to the IDE, one to Inform,
> and one to IF. The question is whether the last two barriers would be
> lowered enough for it to be worth the effort.
>
> My personal view is that there are some good ideas around, and yours
> are among them, but *I* don't have the time or inclination to puruse
> them myself.
No one has time. That's why I only rant about this once a year. I could
do the IDE itself, but what I would need is assistance from Graham or
Andrew (because I don't want to stray from what Inform already is and
because they _know_ the compiler). This assistance would include breaking
the compiler down into functions that could be called via a Windows DLL.
These functions might include;
function validateSyntax(string inCode, array errList()) where I send a slice
of
code to the function and receive back a syntax validation, including a list
of
errors and locations. This is just an initial pass (I'm not thinking this
all the
way though), but the idea is that I would need many of the compiler
functions
broken into pieces so that I could call them. I would eventually need a
library
function that actually tries to compile the program, but instead of
returning an
executable, it returns a list of errors and their source locations.
The trick is to have the IDE be in constant contact with the compiler
functions
so that the programmer has instant feedback about what they are coding. Add
spell-checking and you can reduce a lot of the mistakes even seasoned coders
make.
Thanks for the nice reply Magnus - I was kind of snooty in my post but that
was
just from getting all hot about using an editor to do the IDE. An IDE should
be
built from the ground up using a programming language. At least that's my
take.
Jarb
Russell Wallace
> I also think a vast number of people (again not *everyone* here, but
> invariably some) underestimate the gains in time that are made by letting
> the IDE auto generate some code for you.
I think that a lot of people who make arguments like this fail to
realize that a) it depends on exactly what you're doing, and b) *it
varies a great deal from person to person*.
I've used IDEs, and I still find myself coming back to doing most of my
work in Brief in a DOS prompt. I find it does everything I need, and
does it about as efficiently as an editor is likely to do. Occasionally
I hit a case where an IDE could save a few seconds for me, but not
enough to pay for the time it would take to load up the IDE.
Now, if *you* find that an IDE saves you a lot of time, fair enough, but
please don't assume that's necessarily going to be true for everyone.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
mano...@iol.ie
Daniel Barkalow
> The difficulty is a text editor widget. A text grid won't work. You
> can't use character input in it because then the user might not be able
> to see the cursor. You can't use line input in it because then you can't
> change lines in the middle of editing.
Why do you say the user might not be able to see the cursor? It seems to
me the cursor should be as well-behaved as anywhere else; it will wander
off the bottom of the window, but the program can check for this and move
the page accordingly.
The platform-native control keys are still a problem, I guess. Perhaps
future versions should include a ton of special keys which are just
normal other keys, but have a different meaning on that platform. E.g.,
^K might produce keycode_CutLine instead of ^K if some feature were
turned on and the system was an Emacs-like one.
Jonadab the Unsightly One
[Early z-machine]
> I bet this is answered in some "history of" text somewhere I haven't run
> into yet, but I was curious. Was it an open architecture, or did you just
> "figure out" how it worked to create Inform?
There were lots of working examples both of interpreters and games,
but the z-machine wasn't documented *as such* by Infocom, at least
not to anyone outside of Infocom, AFAIK. There was a lot of
"figuring out" that went on, which is why there was a 0.something
z-machine standards document which has since been upgraded to 1.0,
and that's also why early non-infocom interpreters (ISTR using ITF
for a while) weren't quite right until Zip came out. Infocom's
own interpreters, or so I am told, weren't always right for other
games than the one they were distributed with, presumably because
the standard was updated and adjusted as time went on or something.
I think back issues of XYZZYnews might have more info on this,
and maybe the z-machine Specifications.
Somehow I was under the impression that Graham Nelson was not
working alone to figure out the z-machine, but I was always
hazy as to who else was involved.
"Virtual Reality has nothing on Calvin." -- Susie Derkins
Jonadab the Unsightly One
> Trevor Barrie wrote:
> >
> > Ummm, so productivity and popularity are synonymous in your view? If one
> > person uses Widget-Whacker brand A and whacks 120 widgets a day, and
> > fifty people of equal skill use Widget-Whacker brand B and each whack 3
> > widgets a day, you'd say "Look, people are clearly more productive with
> > brand B... 150 widgets/day as opposed to 120!"?
>
> Oh, puh-leez. At least do your research. There is simply no way that
> anyone could whack more than 50 widgets in a day, I don't care what
> brand you use.
That's simply not true. Install raif-POOL and compile the
following:
Room Wackerry;
Class Widget-Wacker(9000)
with each_turn [; <<Whack_Widget>>; ];
[ Initialise j k;
location=Wackery;
for (j=1:j<9000:j++)
{
k = new Widget-Wacker;
move k to Wackery;
}
];
Jonadab the Unsightly One
> >I would question whether engineering or productivity is more important.
> >Clearly, people are more productive with Windows based OS's than Unix.
>
> This is clear how?
Because, there are so many popular high-graphics games for Windows,
that... oh, that's backwards. Nevermind.
I would say that more people are productive with Windows than Unix,
but I would not say that people are more productive with Windows
than Unix. That's an important distinction. A typical Unix
user accomplishes more in his spare time than a typical Windows
user accomplishes full time, but that's not fair either because
Unix users are frequently math professors and engineers and
researchers and geniuses and so forth, and if they were using
Windows they'd *still* get more done in their spare time than
the typical user gets done full time.
Talking about how productive each person would be if he
switched systems isn't interesting. If he thought he'd be
more productive in the other system, he'd switch systems (and
many people have, but many more never will).
It is interesting to note that more Unix software is ported
to Windows (and, indeed, DOS) every year. If WINE ages
a bit more, stability of the OS itself may become a major
remaining issue eventually. (Currently it's not for most
home users. Rebooting only wastes five minutes out of
maybe an hour, and you probably needed a break anyway.
If your software has decent autosave capability,
information lossage in a crash is not a major issue
on a FAT-family filesystem. You can go years without
ever losing anything significant, despite regular
crashes, particularly if you disable write cacheing.)
I'm not bashing Windows. I have Linux installed but
use Windows most of the time. I just think the difference
between more people who are productive and people who
are more productive is a substantial one.
Besides having more people who are productive than Unix does,
Windows *also* has more people who are unproductive... but
that's also not really interesting, since the same people
would also generally be unproductive with Unix.
Andrew Plotkin
> Evin Robertson said:
>
>> The difficulty is a text editor widget. A text grid won't work. You
>> can't use character input in it because then the user might not be able
>> to see the cursor. You can't use line input in it because then you can't
>> change lines in the middle of editing.
>
> Why do you say the user might not be able to see the cursor?
Because there's no guarantee that a particular implementation will *have*
a visible cursor.
> It seems to
> me the cursor should be as well-behaved as anywhere else; it will wander
> off the bottom of the window, but the program can check for this and move
> the page accordingly.
Can't do that, either, in fact. There's no way to get the cursor position.
This is a policy decision which I may change someday, but not for a
baroque hack like faking a text-editng panel.
> The platform-native control keys are still a problem, I guess. Perhaps
> future versions should include a ton of special keys which are just
> normal other keys, but have a different meaning on that platform. E.g.,
> ^K might produce keycode_CutLine instead of ^K if some feature were
> turned on and the system was an Emacs-like one.
Why, no. No.
Mike Snyder
<383104fb...@news.bright.net>...
>"Mike Snyder" <mikes...@worldnet.att.net> wrote:
>Somehow I was under the impression that Graham Nelson was not
>working alone to figure out the z-machine, but I was always
>hazy as to who else was involved.
Evidently, Infocom approved (whether at the beginning, or in retrospect)
since I seem to recall that some of the prizes from COMP#1 were donated *by*
Infocom. Thanks for the reply!
Mike.
Andrew Plotkin
The Z-machine archaeology was really done by the Previous Generation --
the people that wrote the Zip and ITF interpreters. (The latter stood for
"Infocom Task Force".) This was before Inform, and way before the first
IFComp.
I don't know if Activision knew about it, at the time. I tend to doubt it.
Paul O'Brian
> Jonadab the Unsightly One wrote in message
> <383104fb...@news.bright.net>...
> >"Mike Snyder" <mikes...@worldnet.att.net> wrote:
>
> >Somehow I was under the impression that Graham Nelson was not
> >working alone to figure out the z-machine, but I was always
> >hazy as to who else was involved.
>
> Evidently, Infocom approved (whether at the beginning, or in retrospect)
> since I seem to recall that some of the prizes from COMP#1 were donated *by*
> Infocom. Thanks for the reply!
Bzzzzt! Not quite. Infocom, in the sense we usually speak of it, had long
since blinked out of existence by the time of the 1995 comp. That comp
(whose results are recorded in SPAG #7, available for your perusal at the
SPAG website) did not have any prizes donated by any company.
However... Activision, who bought Infocom along with the rights to its
name and all its properties, was kind enough to publish the "Winners" (top
3 from each category) of that competition on the Masterpieces of Infocom
cd, and to compensate the authors. It also donated prizes to the 1996
competition and has donated prizes to every competition since.
As you suggest, Activision has been very friendly toward amateur IF, and
nobody is really worried that they are going to start getting defensive
about their rights to the z-machine.
--
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
"Sometimes even music cannot substitute for tears."
-- Paul Simon
Daryl McCullough
>
>David Samuel Myers wrote:
>> I also think a vast number of people (again not *everyone* here, but
>> invariably some) underestimate the gains in time that are made by letting
>> the IDE auto generate some code for you.
>
>I think that a lot of people who make arguments like this fail to
>realize that a) it depends on exactly what you're doing, and b) *it
>varies a great deal from person to person*.
I don't know if this was David's point, but you can't
always rely on the programmer's subjective judgement
of his productivity. You really need to do a controlled
study (which is pretty hard to do).
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
David Given
Andrew Plotkin <erky...@netcom.com> writes:
[...]
>>> The difficulty is a text editor widget. A text grid won't work. You
>>> can't use character input in it because then the user might not be able
>>> to see the cursor. You can't use line input in it because then you can't
>>> change lines in the middle of editing.
>>
>> Why do you say the user might not be able to see the cursor?
>
> Because there's no guarantee that a particular implementation will *have*
> a visible cursor.
Yup. A few months ago I went totally insane and started writing stuff in
Floo; partly to play with Glk and partly, as I said, because I was
totally insane. I managed most of a text editor, which lived in a Glk text
grid, and discovered that the cursor was only visible in the Curses Glk
implementation. XGlk didn't have one. I did think about using a flashing *
or something as a cursor but never got round to it.
I also wrote a single-stepping debugger for Floo words. Fun! (Floo's
actually not a bad language. It needs better scoping controls, but other
than that, it's flexible and powerful and not bad to write in.)
[...]
> Can't do that, either, in fact. There's no way to get the cursor position.
> This is a policy decision which I may change someday, but not for a
> baroque hack like faking a text-editng panel.
I kept track of the user's editing position, and put the cursor there
before waiting for a keypress. Of course, as the Glk cursor has no
physical existance, this only worked as a side effect of the Curses Glk
implementation.
--
+- David Given ---------------McQ-+ Q: What's the difference between the US and
| Work: d...@tao-group.com | Russia?
| Play: dgi...@iname.com | A: The US has a legal Communist party.
+- http://wired.st-and.ac.uk/~dg -+
Erik Max Francis
> As you suggest, Activision has been very friendly toward amateur IF,
> and
> nobody is really worried that they are going to start getting
> defensive
> about their rights to the z-machine.
I seem to strongly recall that the Z machine specification was
officially released into the public domain at some point. Am I
remembering correctly?
--
Erik Max Francis | icq 16063900 | whois mf303 | email m...@alcyone.com
Alcyone Systems | irc maxxon (efnet) | web http://www.alcyone.com/max/
San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
USA | 411 days and counting | &tSftDotIotE
__
/ \ I'm paranoid. But am I paranoid enough?
\__/ Louis Wu
Jake Wildstrom
Jonadab the Unsightly One <jon...@bright.net> wrote:
>"Mike Snyder" <mikes...@worldnet.att.net> wrote:
>
>There were lots of working examples both of interpreters and games,
>but the z-machine wasn't documented *as such* by Infocom, at least
>not to anyone outside of Infocom, AFAIK. There was a lot of
>"figuring out" that went on, which is why there was a 0.something
>z-machine standards document which has since been upgraded to 1.0,
But if the internal specs were never provided to the pro bono reverse
engineering team (presumably Graham Nelson & co.), how were opcodes like
piracy, art_shift, and nop incorporated into the spec?
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+
Andrew Plotkin
> In article <383104fb...@news.bright.net>,
> Jonadab the Unsightly One <jon...@bright.net> wrote:
>>"Mike Snyder" <mikes...@worldnet.att.net> wrote:
>>
>>There were lots of working examples both of interpreters and games,
>>but the z-machine wasn't documented *as such* by Infocom, at least
>>not to anyone outside of Infocom, AFAIK. There was a lot of
>>"figuring out" that went on, which is why there was a 0.something
>>z-machine standards document which has since been upgraded to 1.0,
>
> But if the internal specs were never provided to the pro bono reverse
> engineering team (presumably Graham Nelson & co.), how were opcodes like
> piracy, art_shift, and nop incorporated into the spec?
Guesswork and osmosis. Also, reverse-engineering the interpreters that
Infocom sold.
Also, I think a few non-shipped game files escaped. The German version of
Zork never shipped, but people knew enough about it to figure out the
accented-character set.
Also, sometimes they just got it wrong. I seem to recall that nop was
considered to be a break for quite some time.
Daniel Barkalow
> In article <80t4ut$dh1$1...@nntp9.atl.mindspring.net>,
> Andrew Plotkin <erky...@netcom.com> writes:
> > Because there's no guarantee that a particular implementation will *have*
> > a visible cursor.
It seems to me that having a visible cursor in text grids would be a
useful feature and not difficult to provide. Why is it not?
> I kept track of the user's editing position, and put the cursor there
> before waiting for a keypress. Of course, as the Glk cursor has no
> physical existance, this only worked as a side effect of the Curses Glk
> implementation.
Yeah, the user wouldn't be able to move the cursor around; the program
would do that in response to cursor movement keys or mouse clicks or
such. The program doesn't have to get the cursor position from Glk
because it put the cursor there.
Andrew Plotkin
> On Wed, 17 Nov 1999, David Given wrote:
>
>> In article <80t4ut$dh1$1...@nntp9.atl.mindspring.net>,
>> Andrew Plotkin <erky...@netcom.com> writes:
>> > Because there's no guarantee that a particular implementation will *have*
>> > a visible cursor.
>
> It seems to me that having a visible cursor in text grids would be a
> useful feature and not difficult to provide. Why is it not?
Because I can't specify implementation. I have no idea what the output
capability of the library will be. It may be a VT100 terminal. It may be
an HTML page being reupdated really frequently, with text grids as
<pre></pre> blocks. It may be a stream of N*M characters that gets piped
to some other program or device.
The point of this exercise is to *abstract* the UI, and a rectangular grid
of characters is as explicit as I'm willing to go (for text grids).
Russell Wallace
Well, a programmer's judgement is the best evidence we have concerning
his own productivity. If we can't rely on that, we haven't got anything
except armchair speculation. (Meaningful controlled studies for most of
these things simply aren't available.)
T Raymond
>Besides having more people who are productive than Unix does,
>Windows *also* has more people who are unproductive... but
>that's also not really interesting, since the same people
>would also generally be unproductive with Unix.
Gee, and I thought there was no chance in heck that we could put Bill
into this thread ;)
Tom
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond adk @ usa.net
"The original professional ameteur."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Daryl McCullough
>Well, a programmer's judgement is the best evidence we have concerning
>his own productivity.
Why do you think that?
>If we can't rely on that, we haven't got anything
>except armchair speculation.
Why do you think that a programmer's judgement is
any better than armchair speculation?
l...@cc.gatech.edu
> Daryl McCullough wrote:
> >
> > Russell says...
> > >
> > >David Samuel Myers wrote:
> > >> I also think a vast number of people (again not *everyone* here, but
> > >> invariably some) underestimate the gains in time that are made by letting
> > >> the IDE auto generate some code for you.
> > >
> > >I think that a lot of people who make arguments like this fail to
> > >realize that a) it depends on exactly what you're doing, and b) *it
> > >varies a great deal from person to person*.
> >
> > I don't know if this was David's point, but you can't
> > always rely on the programmer's subjective judgement
> > of his productivity. You really need to do a controlled
> > study (which is pretty hard to do).
>
> Well, a programmer's judgement is the best evidence we have concerning
> his own productivity. If we can't rely on that, we haven't got anything
> except armchair speculation. (Meaningful controlled studies for most of
> these things simply aren't available.)
>
Nah, it's possible to do much better. At the least, a programmer can
keep some sort of statistics (functionality per day, errors found
later on, whatever). And if the programmer works for someone else,
then the someone else can keep stats and even compare them to other
programmers in similar jobs.
Going by how productive someone feels is close to useless. The best a
person can do is compare how quickly the same person get tasks done in
different systems. But most people don't spend a lot of time using
anything but the system they like the most.
Lex
Matthew T. Russotto
Jake Wildstrom <wil...@mit.edu> wrote:
}In article <383104fb...@news.bright.net>,
}Jonadab the Unsightly One <jon...@bright.net> wrote:
}>"Mike Snyder" <mikes...@worldnet.att.net> wrote:
}>
}>There were lots of working examples both of interpreters and games,
}>but the z-machine wasn't documented *as such* by Infocom, at least
}>not to anyone outside of Infocom, AFAIK. There was a lot of
}>"figuring out" that went on, which is why there was a 0.something
}>z-machine standards document which has since been upgraded to 1.0,
}
}But if the internal specs were never provided to the pro bono reverse
}engineering team (presumably Graham Nelson & co.), how were opcodes like
}piracy, art_shift, and nop incorporated into the spec?
Mostly reverse-engineering of the existing interpreters. I believe some of
them had the opcode names in them.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Graham Nelson
> Somehow I was under the impression that Graham Nelson was not
> working alone to figure out the z-machine, but I was always
> hazy as to who else was involved.
People who deserve the real credit include: the InfoTaskForce,
Mike Threepoint, Mark Howells, Stefan Jokisch and lots of others.
I actually did very little except to substantially flesh out the
version-6 definition (I think I'm the last person to discover a
new opcode, although Stefan is the last person to decipher a
header bit) -- but there again some leaks from friendly Infocom
people helped me out a bit.
When Inform arrived, versions 3 and 5 were understood in theory
but only version 3 was reliably interpreted. Indeed, it wasn't
until Inform started compiling v5 games that interpreters started
taking them seriously...
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom