IF for Non-Programmers
Ferlin Scarborough
A couple of years ago, 1987 or so I believe I purchased a program called
AGT then MAGT to create Text Adventures, the program boasted that a
Non-Programmer could create adventures using it.
Hugo, Alan, Tads and Inform all seem to get a little technical for a
Non-Programmer to use.
I have seen another package that boasts at being a Non-Programmer Text
Adventure creation tool called Adrift
My question(s) is this:
Which Authoring System do YOU feel is good for a Non-Programmer to use to
create Text Adventures and Why?
What are some of the strong points/weaknesses of this Authoring System?
How could it be improved, yet still remain easy for a Non-Programmer?
Thanks in advance for your input on this subject.
Ferlin.
Lewis Raszewski
Here is the fundamental problem.
A non-programmer *cannot* write a good text adventure. You can make the
syntax as simple as you like, but writing a text adventure is
*fundamentally* a programming exercise (it is also, lest you think I'm
leaving it out, fundamentally a writing exercise).
This is not to say that you can't write a good text adventure in a
programming-lite language; I'm sure you can (in most of them). The
relationship between bad games and use of a programming-lite language is
due to other factors:
- Non-programmers are using them
- It is so much more difficult to express programming in a
non-programming languages that anyone who becomes a sufficiently
competent programmer switches to a "fully powered" language, becuase
it's *easier* to program in it.
It may perhaps be worthwhile for a non-programmer to begin in one of the
non-programmer languages, and learn to *program* in the frieldly
provided environment, then move on to a programming-intensive language
once they gain sufficient competance, though this may well be
mis-application of effort.
I submit that if you are capable of writing a good game, you *are* a
competent programmer. The technical aspects of a language are *as
nothing* to the difficulty of thinking in a programming-mindset, and the
latter is essential to write a good game in *any* language.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"Nature provides for us a safety net; whatever we do, we can never
forget." --
Barenaked Ladies, I Live with it Every Day
Frobozz
Ferlin Scarborough wrote:
Check out the Author's Aid for AGT. It's driven using menus and produces code
for AGT. I used it before, but it just wasn't very useful for me. So I
switched to
TADS.
Jonathan Penton
news:3C7451D...@hotmail.com...
I think you overstate your case. While game design is not the same as
writing, it is not synonomous with being a good programmer, either. Good
games are written in ADRIFT, without using ADRIFT's more esoteric
programming functions. (And, of course, we recognize that most ADRIFT games
are very bad; the ADRIFT page contains several games of the designer's
house.) You can argue that everyone who uses ADRIFT becomes a programmer,
but I don't think we can call all the creators of decent ADRIFT games
*competent* programmers. And while most probably do leave ADRIFT for a more
powerful language, some stay, because ADRIFT meets their needs very
comfortably: check out the mini-games of Heal Butcher.
I know HTML and basic JavaScript. I tried to learn TADS, but found the
learning curve too steep. I knew I could learn it, but I'd burn myself out
on it first. I was about to switch to ALAN, but realized that I could make a
playable and entertaining game in ADRIFT immediately. So I figured I'd do
that, to appease my need to get something tangible accomplished, then switch
to a more flexible language.
--
Jonathan Penton
http://www.unlikelystories.org
Jim Aikin
> Here is the fundamental problem.
>
> A non-programmer *cannot* write a good text adventure. You can make the
> syntax as simple as you like, but writing a text adventure is
> *fundamentally* a programming exercise (it is also, lest you think I'm
> leaving it out, fundamentally a writing exercise).
You may take some heat for this, but you're absolutely right.
The essence of IF is interactivity. Interactivity requires the modeling
of the real world. The real world is complex and messy. Off-the-rack
generic code attempts to model the world, but does not provide enough
detail for any but generic objects.
Here's a simple example: Doors with keys have been done over and over
and over in IF. They're generic. They're boring. They suck. If you want
to program generic IF, you can certainly grab an off-the-rack door
object, hide the key in a potted palm somewhere, and congratulate
yourself on having created a puzzle. But the moment you start to think
about how to make a door that will be unique to your game -- let's say
it's an ancient Roman door, with a keyhole big enough to stick your arm
into, so you can wiggle your fingers around in there and unlock it --
you're going to have to write code.
> It may perhaps be worthwhile for a non-programmer to begin in one of the
> non-programmer languages, and learn to *program* in the frieldly
> provided environment, then move on to a programming-intensive language
> once they gain sufficient competance, though this may well be
> mis-application of effort.
Coin toss. Learning one language and then learning another is no fun,
but I can't say I'd recommend that someone learn TADS as their first
language.
--Jim Aikin
Eric Mayer
<rras...@hotmail.com> wrote:
>
>Here is the fundamental problem.
>
>A non-programmer *cannot* write a good text adventure. You can make the
>syntax as simple as you like, but writing a text adventure is
>*fundamentally* a programming exercise (it is also, lest you think I'm
>leaving it out, fundamentally a writing exercise).
>
I'm primarily a writer and I pretty much agree with this statement.
Which is why I believe that although I enjoy playing with what small
amount of programming I've learned, I'll never write a terrific game,
despite having some nonIF writing skills. Writing a very good game,
though might be possible, if it were the right sort - ie. very linear
and nonIF-like.
Actually, all writing, IF or nonIF depends more heavily on its overall
structure than the particular words and sentences. At least in my
opinion. To structure IF you need to program. So someone who will have
problems structuring a game because of lack of programming skills is
under the same handicap as a would-be novelist who can write fine
sentences but doesn't understand pacing, transitions etc.
As somone who had never seen a line of code before encountering IF I
found ALAN to be very learnable. It taught me basic concepts like
if/else statements too! If you really (like me) know nothing about
fundamental programming ALAN might serve as a good intro to, say TADS,
which has some similarties it seems. Adrift is, in its basics, even
easier than ALAN - although, surprisingly, at a more advanced level it
can become more difficult to grasp- to me.
You can, I believe, write a worthwhile, enjoyable game in ALAN or
Adrift. However, for us nonprogramming writers, the sad truth is
that you can't just somehow stick some simple code into the text of a
short story or novel and have a game. They are very different things.
--
Eric Mayer
Web Site: <http://home.epix.net/~maywrite>
"The map is not the territory." -- Alfred Korzybski
Kodrik
I don't know if it will answer your need, but you can take a look.
Adam Thornton
Jim Aikin <kill_spammers@kill_spammers.org> wrote:
>Lewis Raszewski wrote:
>> Here is the fundamental problem.
>> A non-programmer *cannot* write a good text adventure. You can make the
>> syntax as simple as you like, but writing a text adventure is
>> *fundamentally* a programming exercise (it is also, lest you think I'm
>> leaving it out, fundamentally a writing exercise).
>You may take some heat for this, but you're absolutely right.
However, it doesn't necessarily mean you have to be a *good* programmer
to write a good game.
The reason for this is, as long as the code *works*, it doesn't really
matter how efficient or well-thought-out or elegant it is, because the
player won't see it and, except in pathological cases (like my old Psion
3a) the player will never notice a factor of two or five in the speed of
the computer's response. (Obviously, this doesn't really apply to
abuses like Silicon Castles, but those things are almost by definition
exercises in programming--rather than writing--virtuosity.)
My favorite example of this is Adam Cadre's _I-0_ (and, for the record,
his coding has improved greatly since then--the Gull examples are clear
and useful to work with. I have some problems with Gull in that it is
not an OO framework and so doesn't fit my programming style, but it's
not that it's not clearly written). The code is clearly the code of a
novice programmer. Stuff that could easily be put into a subroutine is
duplicated. There are clumsy ways of doing things that could have been
done much more cleanly if he'd understood how to use Inform better.
But none of that matters, because the code works *well enough* that the
player simply sees the text that was intended. As a player, I don't
know that I'm reading a description that was included a second time in
the source code when it could have been encapsulated as a single
routine. Nor do I care. _I-0_ is a very fun game, and the coding is
adequate to maintain mimesis, which is all that's really necessary.
This does not apply to the writing of the text in a game. That's why
I prefer playing, for example, one of Adam's games to, say, _The Plant_;
Mike Roberts is one of the best programmers we have working in IF
(although I find the TADS 2 source almost impossible to digest; most of
that, though, is its heritage as something that had to live with DOS's
shortcomings. Well, that and his bizarre and perverse fondness for
macros. But I digress) but I find his prose--although certainly
competent and coherent--not nearly as gripping as Adam Cadre's.
(Of course, take this with a grain of salt: even though Robb Sherwin's
early work crashes and burns the first time you take a step off of his
prescribed walkthrough, his dialogue is powerful enough that I'm willing
to forgive almost any technical shortcomings. Thankfully, _Fallacy of
Dawn_ is far less buggy than any of his earlier work, while maintaining
that bizarre, amphetamine-addled, Sherwinnian dialogue stream. Oh crap,
I digressed again.)
>The essence of IF is interactivity. Interactivity requires the modeling
>of the real world. The real world is complex and messy. Off-the-rack
>generic code attempts to model the world, but does not provide enough
>detail for any but generic objects.
Right; as Robb famously put it via the persona of Johnny Dapper, "You
can't make an omlette without killing some eggs."
From where I sit (where that is: among my hats are both "published
author" and "professional programmer," but I certainly self-identify as
much more of a technical geek than a writer), I'd say that to write a
great game, you need to be a very good writer, but you can get away with
being a mediocre programmer. Nevertheless, you will need some
programming skills to achieve enough mimesis that your game is actually
fun to play.
Adam
Jim Aikin
> "The map is not the territory." -- Alfred Korzybski
"Who needs a map?" -- Zippy the Pinhead
Peter Seebach
>However, it doesn't necessarily mean you have to be a *good* programmer
>to write a good game.
Sure. That said, being a good programmer always helps. A *lot*. Figure that,
if nothing else, familiarity with coding can make a factor of five or more difference
in debugging time. :)
>From where I sit (where that is: among my hats are both "published
>author" and "professional programmer," but I certainly self-identify as
>much more of a technical geek than a writer), I'd say that to write a
>great game, you need to be a very good writer, but you can get away with
>being a mediocre programmer. Nevertheless, you will need some
>programming skills to achieve enough mimesis that your game is actually
>fun to play.
Yup. You need to be able to tell a story. Language needs to be interesting to
you, because the player is going to see a lot of your language. The advantages
of good code will be felt more in the polish and mimesis.
(ARGH! I was never going to use that word, but I guess I'm stuck now.)
-s
--
Copyright 2002, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
David A. Cornelson
news:6MWc8.150082$TI5.7...@e3500-atl2.usenetserver.com...
> Hello All, (Warning Long Winded Post Ahead)
>
This is inherently a moot question since Interactive Fiction _requires_ the
ability to program and it _requires_ the ability to write something
resembling legible language. Sure, you can do it the hard way (look at the
source of IO (sorry Adam)), or you can do it the harder way (see the source
of Ruins (kudos Graham)), but no matter what, you're best bet is to just
bite the bullet and muddle through TADS, Inform, Hugo, or one of the other
IF languages and learn. It may take a few weeks, a few months, or as in my
case, a few years, but eventually the lights will come on and you'll be much
happier.
Wait. You'll be miserable. Why? Because after learning an IF language you
will also learn that a good IF game takes an enormous amount of time and
effort.
Oh, you have to write something readable too.
And test it. Pleeeeease test it.
And throw away the game designed on your Aunt's house. We have enough attics
in IF.
Good Luck!
Jarb
Barney Gumble
> Coin toss. Learning one language and then learning another is no fun,
> but I can't say I'd recommend that someone learn TADS as their first
> language.
But I'd certainly recommend it before Inform. It's just as powerful,
but more intuitive for the first time programmer.
Ashley Price
Anyone who has seen my name in the from column probably knows what I am
about to say:
Learn HUGO.
To write a decent IF you are going to have to learn to program. I would
assume that any "no programming to learn" IF creator would have to be some
sort of menu driven or similar device, which simply because of the infinite
possibilities cannot cover everything a writer will need.
However, I am sure that TADS, INFORM, ALAN or *HUGO* will be of great
benefit and will not take that long to learn.
Let me give you an example. I downloaded HUGO one wet Saturday. By the end
of the afternoon I had produced my first mini game. Okay, it was nothing
special, you were locked in a four room house and had to find the key (which
was in the pocket of a coat, hanging on a coat hook in the hall) to unlock
the exit door. It didn't have other characters, timed events, or anything
like that. But it was still a game and it took me hardly any time at all.
But, Kent Tessman (the creator of HUGO) has really thought about the
construction of adventures and how to make HUGO as easy to use as possible.
If you would like any more info, do not hesitate to e-mail me at
ashle...@DELETE-THISbtinternet.com (remove the DELETE-THIS).
Ashley
--
Do you use or want to learn HUGO? If so and would like a regular newsletter
e-mail me at ashle...@DELETE-THISbtinternet.com (obviously removing the
DELETE-THIS part) and include the word HUGO in the subject line.
*First Issue out now!*
Jason Etheridge
>But I'd certainly recommend it before Inform. It's just as powerful,
>but more intuitive for the first time programmer.
Would I be crazy to try to program the same game in both Tads and
Inform simultaneously? (hrmm)
How different are the world models?
Magnus Olsson
Eric Mayer <emay...@epix.net> wrote:
>On Wed, 20 Feb 2002 20:48:01 -0500, Lewis Raszewski
><rras...@hotmail.com> wrote:
>
>
>>
>>Here is the fundamental problem.
>>
>>A non-programmer *cannot* write a good text adventure. You can make the
>>syntax as simple as you like, but writing a text adventure is
>>*fundamentally* a programming exercise (it is also, lest you think I'm
>>leaving it out, fundamentally a writing exercise).
>>
>
>I'm primarily a writer and I pretty much agree with this statement.
>Which is why I believe that although I enjoy playing with what small
>amount of programming I've learned, I'll never write a terrific game,
>despite having some nonIF writing skills.
I think you're overly pessimistic. Or perhaps you're setting your
goals too high.
To me, programming skills are a lot like writing skills. You can't
expect somebody who's never written any fiction before to write a
novel and succeed at the first try. Similarly, you can't expect a
non-programmer to write a complex, well-polished adventuer at first
try, even with one of the programming-light languages such as AGT
or ADRIFT.
But these are skills that can be learned and improved.
Granted, there's such a thing as talent, in both writing and
programming. And not everybody can become a great programmer, anymore
than everybody can become a great writer.
But I do think that most people can learn enough programming skills
to write good adventure games.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Barrier, Guy
I tried to send you an e-mail at ashle...@DELETE-THISbtinternet.com, but
it came back that the address didn't exist??
Just kidding!
"Ashley Price" <ashle...@DELETE-THISbtinternet.com> wrote in message
news:a52cqd$nrt$1...@knossos.btinternet.com...
Ashley Price
"Barrier, Guy" <guyba...@hotmail.com> wrote in message
news:a52pmr$c67$1...@eskinews.eskimo.com...
> Ashley,
>
> I tried to send you an e-mail at ashle...@DELETE-THISbtinternet.com,
but
> it came back that the address didn't exist??
Hi Guy
You need to remove the words DELETE-THIS from the address.
Ashley
Stephen Granade
> Barney Gumble <barney...@subdimension.com> wrote:
> >But I'd certainly recommend it before Inform. It's just as powerful,
> >but more intuitive for the first time programmer.
That depends. Inform has a number of constructs which mimic English,
and I've spoken to a number of people who tried TADS, went "Bleah!"
and then tried Inform, finding it much more to their liking.
> Would I be crazy to try to program the same game in both Tads and
> Inform simultaneously? (hrmm)
>
> How different are the world models?
You wouldn't be crazy, though you'd be letting yourself in for a lot
of work. The world models are very similar -- not surprising given
that they're both languages meant to create text adventures and were
first created back in the late 80s-early 90s. What I think you'll find
is that, even if the two games behave in exactly the same manner,
they'll feel different due to differences in the default library
messages, &c.
Stephen
--
Stephen Granade
sgra...@phy.duke.edu
Duke University, Physics Dept
D. R. Porterfield
I'm brand-new here, but this seemed like a good thread to jump in on.
"Ferlin Scarborough" <Bill...@microsoft.com> wrote in message news:<6MWc8.150082$TI5.7...@e3500-atl2.usenetserver.com>...
> Hello All, (Warning Long Winded Post Ahead)
>
> A couple of years ago, 1987 or so I believe I purchased a program called
> AGT then MAGT to create Text Adventures, the program boasted that a
> Non-Programmer could create adventures using it.
My experience with most "non-programmer" adventure creation programs
is that although they technically do produce adventure games, the
games tend to be very simplistic and unsatisfying. Like you, perhaps,
I wanted to create more complex "Infocom-style" text adventures, and I
found such so-called "easy" programs to be inadequate (and ultimately
frustrating) for this task.
>
> Hugo, Alan, Tads and Inform all seem to get a little technical for a
> Non-Programmer to use.
Powerful tools involve a somewhat steeper learning curve, but pay off
with great rewards. Don't limit yourself by calling yourself a
non-programmer. You're only a non-programmer until you're not. (I'm
not trying to be a wise guy by saying that. Please read on, and bear
with me.)
>
> I have seen another package that boasts at being a Non-Programmer Text
> Adventure creation tool called Adrift
Sorry, I'm not familiar with that one.
>
> My question(s) is this:
>
> Which Authoring System do YOU feel is good for a Non-Programmer to use to
> create Text Adventures and Why?
I recommend the Inform language, and I'll tell you why.
Two months ago, I was a non-programmer. I was a writer who'd played a
lot of text games and wanted to write one of my own, but didn't know
how. I knew basic html, but other than that, I had no coding
experience, not even JavaScript. I'd tried to learn programming in the
past, but every book I read on the subject seemed full of dry, arcane
gobbletygook that just didn't seem to click.
Then, in early January of this year, I discovered the Inform
Designer's Manual by Graham Nelson, and suddenly the light came in.
This has got to be the most lucid, cogent, readable guide to a
programming language that I've ever seen, ever. I finally understood,
and it was like learning to read all over again. I'm completely
serious. It was almost a religious experience, a type of intellectual
ecstasy. Six weeks later, and I'm busily coding the IF adventure I've
always wanted to play. I'm an Inform programmer now (albeit a novice
one), and it's one of the most satisfying and empowering experiences
of my life.
>
> What are some of the strong points/weaknesses of this Authoring System?
The strong points of the Inform language are that it's very powerful,
has wide cross-platform compatibility, and is accompanied by a superb
and highly understandable Designer's Manual as noted above. The only
weak point would be the learning curve (which really isn't that bad
considering the capabilities of the language), but the effort is well
worth it, and if you're really interested in writing a quality work of
IF, you'll be driven to learn more and more so you can get the game to
do what you want it to do.
>
> How could it be improved, yet still remain easy for a Non-Programmer?
I don't think any system capable of producing a complex, satisfying
text game could be called "easy", simply because the system itself has
to be advanced enough to produce a realistic and believable model
world. However, as someone with absolutely no previous experience in
programming, I've found the Inform language to be very logical and
learnable. I'm still coming to grips with some of the more advanced
concepts such as parsing and arrays, but the more familiar I become
with the language, the more things fall into place. I'm also highly
motivated to continue to learn and advance my programming skills,
because I know what I want the game to do and I'm compelled to figure
out how to implement the features I want. I think intense motivation
may be a key to successfully learning to program IF (or to learn
anything new, for that matter).
I would recommend that you obtain the Inform Designer's Manual (it's
free online), read through the first few chapters to get a general
idea of how the language operates, and work through the first part of
the Ruins tutorial. Make sure you understand each lesson before moving
on. After that, try a little coding of your own, perhaps studying the
following chapters on elements of the model world. Experiment a little
and see what things do. Go back and review some of the earlier
chapters -- they're even more clear after you've done some of your own
coding. Then proceed further with the more advanced sections of the
tutorial. If you follow it through, you'll have completed a small
adventure game, and in the process you'll have learned how to
implement many useful features in your own games.
And oh yeah -- I'm not some teenage whiz kid, either. I'm 42 years
old, and I've never been particularly good at math. If I can learn to
program in Inform, you can too. I think it's well worth the effort.
>
> Thanks in advance for your input on this subject.
>
> Ferlin.
You're welcome. Hope this helps. Best of luck!
Gary Shannon
"Ashley Price" <ashle...@DELETE-THISbtinternet.com> wrote in message
news:a52cqd$nrt$1...@knossos.btinternet.com...
>
> Anyone who has seen my name in the from column probably knows what I am
> about to say:
>
> Learn HUGO.
I started with ALAN and within days moved on to TADS. I made my choice
between TADS, HUGO and Inform based as much on the run time interpretors as
on the coding style. The three appear quite similar, at least
superficially. However, of the the three I decided that TADS had the nicest
looking interpretor package (under Windoze). Hugo text is always jammed up
tight against the left border of the window with no margin and it feels very
crowded and unpleasantly cluttered. Hugo programmers tend to choose weird
colors for text and background, and when you re-size a HUGO window most, if
not all, of the text simply gets chopped off or in some cases vanishes
completely. The Inform/Z-machine interpretor had a real DOS/Commodore
64/retro feel to it. (gray text on blue screen with fixed font went out in
the 80's) It didn't feel like a "modern" user interface to me.
That left TADS with it's clean Windows-style user interface that provides
HTML support and observes such nice touches as an actual margin on the left
and right borders of the screen.
Don't forget. Not only do you have to code the game, but players have to
play it.
(The forgoing are only the opinions of a newly returning to newbie who
hasn't played IF since the Apple II/Commodore 64 days. I simply found TADS
interpretor games more visually pleasant to play.)
--gary
Lewis Raszewski
>
> In article <3C746F9E.1000002@kill_spammers.org>,
> Jim Aikin <kill_spammers@kill_spammers.org> wrote:
> >Lewis Raszewski wrote:
> >> Here is the fundamental problem.
> >> A non-programmer *cannot* write a good text adventure. You can make the
> >> syntax as simple as you like, but writing a text adventure is
> >> *fundamentally* a programming exercise (it is also, lest you think I'm
> >> leaving it out, fundamentally a writing exercise).
> >You may take some heat for this, but you're absolutely right.
>
> However, it doesn't necessarily mean you have to be a *good* programmer
> to write a good game.
>
> The reason for this is, as long as the code *works*, it doesn't really
> matter how efficient or well-thought-out or elegant it is, because the
> player won't see it and, except in pathological cases (like my old Psion
> 3a) the player will never notice a factor of two or five in the speed of
> the computer's response. (Obviously, this doesn't really apply to
> abuses like Silicon Castles, but those things are almost by definition
> exercises in programming--rather than writing--virtuosity.)
>
Well, this is true, and yet.
There's a *reason* that well-thought out or "elegant" code is a hallmark
of a good programmer. There is a certain level of complexity beyond
which it is not feasable (mind you, I didn't say not *possible*) to
kludge your way through it.
> From where I sit (where that is: among my hats are both "published
> author" and "professional programmer," but I certainly self-identify as
> much more of a technical geek than a writer), I'd say that to write a
> great game, you need to be a very good writer, but you can get away with
> being a mediocre programmer. Nevertheless, you will need some
> programming skills to achieve enough mimesis that your game is actually
> fun to play.
>
> Adam
I am unsure that I can buy the divide being as great as you suggest.
And, of course, most people will *never* write great IF. TO write *good*
IF, you need to be a good writer, and a fairly good programmer. (I also
object to the surruptitious sneaking in of the word 'mimesis' :-)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
Soylent Green: It's made from the best stuff on Earth!
Lewis Raszewski
Hm. I've never found TADS particularly intuitive, and inform was the
first Serious programming language I ever learned.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"I'll live as I choose, or I will not live at all." -- Cranberries,
Free to
Decide
Lewis Raszewski
> >
> > I have seen another package that boasts at being a Non-Programmer Text
> > Adventure creation tool called Adrift
>
> Sorry, I'm not familiar with that one.
Sort of amazing to have missed it. Adrift is a recent, windows-only
language, which has a very vocal advocacy group (only a very few of whom
could be described as raving lunatics), but which has, so far, failed to
produce a substantial number of non-bad games.
>
> I recommend the Inform language, and I'll tell you why.
>
> Two months ago, I was a non-programmer. I was a writer who'd played a
> lot of text games and wanted to write one of my own, but didn't know
> how. I knew basic html, but other than that, I had no coding
> experience, not even JavaScript. I'd tried to learn programming in the
> past, but every book I read on the subject seemed full of dry, arcane
> gobbletygook that just didn't seem to click.
>
> Then, in early January of this year, I discovered the Inform
> Designer's Manual by Graham Nelson, and suddenly the light came in.
> This has got to be the most lucid, cogent, readable guide to a
> programming language that I've ever seen, ever. I finally understood,
> and it was like learning to read all over again. I'm completely
> serious. It was almost a religious experience, a type of intellectual
> ecstasy. Six weeks later, and I'm busily coding the IF adventure I've
> always wanted to play. I'm an Inform programmer now (albeit a novice
> one), and it's one of the most satisfying and empowering experiences
> of my life.
Yay. This sounds almost exactly like what happened to me in 1996. I,
having no programming experience beyond a few lines of BASIC, struggled
with AGT for a while, and decided it mightn't be a bad idea to try out
inform, struggled with a total lack of success for a few days, then
printed out the Designer's Manual (version 2, for Inform 5), and, on a
three-hour car trip, with no computer in the area, read it. Cover to
cover. Came home, and was an inform programmer.
About a year later, I decided to go into computer science and not
physics after all. Inform seems to have triggered a fairly major
track-jump in the direction my life has taken.
Yeah. That's pretty sad.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"The Daleks will stop at anything to stop us!" -- The Doctor, Doctor
Who: The
Daleks' Masterplan
Ferlin Scarborough
> syntax as simple as you like, but writing a text adventure is
> *fundamentally* a programming exercise (it is also, lest you think I'm
> leaving it out, fundamentally a writing exercise).
>
> This is not to say that you can't write a good text adventure in a
> programming-lite language; I'm sure you can (in most of them). The
> relationship between bad games and use of a programming-lite language is
> due to other factors:
> - Non-programmers are using them
> - It is so much more difficult to express programming in a
> non-programming languages that anyone who becomes a sufficiently
> competent programmer switches to a "fully powered" language, becuase
> it's *easier* to program in it.
>
Very valid point Lewis, thanks for pointing it out.
Ferlin.
Ferlin Scarborough
"Jonathan Penton" <unli...@flash.net> wrote in message
news:QAZc8.8296$gh4.124...@newssvr17.news.prodigy.com...
>
> I think you overstate your case. While game design is not the same as
> writing, it is not synonomous with being a good programmer, either. Good
> games are written in ADRIFT, without using ADRIFT's more esoteric
> programming functions. (And, of course, we recognize that most ADRIFT
games
> are very bad; the ADRIFT page contains several games of the designer's
> house.) You can argue that everyone who uses ADRIFT becomes a programmer,
> but I don't think we can call all the creators of decent ADRIFT games
> *competent* programmers. And while most probably do leave ADRIFT for a
more
> powerful language, some stay, because ADRIFT meets their needs very
> comfortably: check out the mini-games of Heal Butcher.
>
Jonathan,
I did not mean to give the impression that I was putting ADRIFT down in
any way. I downloaded ADRIFT and a Tutorial on it, and went through it.
Very simple to use. Perhaps I should give a little more details on where I
was trying to go with my post.
Ferlin.
Ferlin Scarborough
"Kodrik" <kod...@zc8.net> wrote in message
news:u78us29...@corp.supernews.com...
take a look??????
Are you talking about the Author's Aid for AGT?
Ferlin.
Ferlin Scarborough
"D. R. Porterfield" <drpf...@measinc.com> wrote in message
news:a0425cbf.02022...@posting.google.com...
>
> I would recommend that you obtain the Inform Designer's Manual (it's
> free online), read through the first few chapters to get a general
>
Thanks D. R. for the input, although I have on my computer HUGO, TADS 2.5,
HTML TADS, INFORM 6.2, ALAN, ADRIFT, AGT, MAGT,GLULX and who knows what
else. Also any and all resources I could find on those.
I'll try to explain a little better my in my next post to every one. What I
was trying to get at, maybe that will clear it up a bit.
Ferlin.
Adam Thornton
Lewis Raszewski <rras...@hotmail.com> wrote:
>Adam Thornton wrote:
>There's a *reason* that well-thought out or "elegant" code is a hallmark
>of a good programmer. There is a certain level of complexity beyond
>which it is not feasable (mind you, I didn't say not *possible*) to
>kludge your way through it.
Further, I suspect that the people who like writing IF, and are
naturally good enough at it to write good games without much training,
and who find it reasonably easy, are precisely the sort of people who
pick up good coding habits along the way.
However, IF that is IF for the story's sake will rarely require all
*that* much complexity. Fundamentally, most IF is all about
computationally-pretty-simple stuff. About as bad as it gets is NPC
design, and, for the most part, this is simply (take that with a grain
of salt) several (perhaps as many as FORTY-ONE!) internal state
variables, whose values influence the response of the NPC. Even in this
case, I'd argue the prose is generally much more visible and hence
important to the player than the fine gradations of NPC state.
>I am unsure that I can buy the divide being as great as you suggest.
>And, of course, most people will *never* write great IF. TO write *good*
>IF, you need to be a good writer, and a fairly good programmer. (I also
>object to the surruptitious sneaking in of the word 'mimesis' :-)
My houseplants were feeling neglected. We may simply disagree on our
definitions of "fairly good."
Adam
Ferlin Scarborough
Sorry if I didn't make things very clear, when I posted the message it was
after a LOOOONG work day. Here is what I was actually trying to get at.
First of all, I used the terminology Non-Programmers because that was the
term used in the AGT Manual. I guess I should have said Begginers instead.
What I was driving at was this:
My first taste of an Authoring System for Text Adventures had been AGT, but
there were some things that you had to go around the world to implement in
it. Especially if it went against the design of AGT.
On the other hand AGT was EASY to learn and one could easily create a mini
non complex IF game in it, with hardly any extra command coding.
When I looked at ADRIFT it looked like a nice tool to create IF, but there
is only so much you can do with a Menu driving system. (Only so many choices
can be on a menu), not much room for the Author to add his own coding.
When I looked at HUGO, ALAN, TADS and INFORM they looked like they would be
a little OVERWHELMING to a Begginer?
With all that said I wanted to Inquire as to What Authoring System you
people would consider as being a good one for a Begginer to start learning
with, and why?
To which I have seen some of the reply's concerning ALAN, INFORM, TADS, HUGO
and ADRIFT.
My next inquiry was as to How these systems could be improved, yet still
remain a good Authoring System for a Beginner to start learning with.
I hope this clears things up a little.
I have never written my own IF game for public consumption, although I did
write a couple for friends and family a few years ago. (Very Amateur, I
might Add). But I'm hoping some day to maybe write one, if I ever get some
of these Iron's out of the fire. :)
I am a Computer Programmer and have been for about 15 years now, so these IF
languages don't intimidate me much. Although I did have a couple of friends
(Non-Programmers) inquire about where to begin, if they wanted to write
their own IF.
Also the reason for the Why and how to improve, was as a Hobby, I'm working
on an Authoring System for Beginners (Programming-Lite for now any way),
just to see if I can do it.
Thanks for the input so far I have thoroughly enjoyed this thread so far.
Ferlin. (I apologize (apologise) for the long babble).
Kodrik
>
> Are you talking about the Author's Aid for AGT?
I'm developing an engine and you can already create complex adventure with
it. I don't want it public until a few completed adventures are out so I
don't post about it publicly.
I'm curious about your reaction, why you will find it good for your needs
or why you wouldn't find it adequate.
Email me, I'll send you what you need to check it out. It's quite
different, quite easy and quite powerful. I would have emailed you like I
did others but your email is obviously fake.
Jacqueline A. Lott
> When I looked at HUGO, ALAN, TADS and INFORM they looked like they would
be
> a little OVERWHELMING to a Begginer?
Well, Ferlin, I may receive some flack for this, but here goes:
I am a twenty-year veteran when it comes to playing IF, but I am,
admittedly, a beginner when it comes to writing. I went with Inform because
I'm a shameless slave to fashion and everyone else seemed to be doing it. I
downloaded the DM4 and dove in, and while it was a wee bit overwhelming at
first, I've learned how to cope. I ask for help every once in a while, but
my story seems to be coming along just fine - and it's not even set in my
apartment! ; )
My previous programming experience? None. I wrote games in BASIC when I
was ten, and I can put together some very nice web pages, occasionally for
profit, but I don't consider either of these ventures even close to
"programming."
So, while I haven't any experience with the other popular platforms from a
programming perspective, I am willing to speak up for Inform and the DM4 and
say to the world, "It's not as bad as all that - sit down, read it through,
concentrate, play with the language a bit, and it'll start to make sense for
you." Trust me.
Jacqueline
Lewis Raszewski
Hm... I think the answer lies less in providing better "introductory
languages" and more in providing better tools. (This is a break from my
traditional standpoint). For instance, a tool which provided some kind
of menu-driven interface for assembling the basic components of a game,
but which output human-modifyable code for a "real" development system
(say, inform), might be a pretty good system for "putting off" the
problems of actual programming until the user actually needs them.
Unfortunately, I suspect that any such tool would be hard pressed to
both provide sufficiently useful features and generate code that was
not... well... not human-editable (I mean, technically, if you wanted to
do something in AGT that was difficult to express in the AGT language,
you could write something close in AGT, then go in wiht a hex editor and
muck about with the AGT bytecode untill you got what you really wanted,
but it's not really feasable.)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"She's a lot like you, but she don't look like you... Okay, she's not
you, but
she'll do find." -- Barenaked Ladies, Intermittently
D. R. Porterfield
> "D. R. Porterfield" wrote:
>
> > >
> > > I have seen another package that boasts at being a Non-Programmer Text
> > > Adventure creation tool called Adrift
> >
> > Sorry, I'm not familiar with that one.
>
> Sort of amazing to have missed it. Adrift is a recent, windows-only
> language, which has a very vocal advocacy group (only a very few of whom
> could be described as raving lunatics), but which has, so far, failed to
> produce a substantial number of non-bad games.
>
If it's windows-only, I probably ignored it for that reason. I use
windows at work because I have to, but I have a Macintosh at home, and
that's what I'm programming on.
Philipp Lenssen
>..
> Which Authoring System do YOU feel is good for a Non-Programmer to use to
> create Text Adventures and Why?
QML-Edit is a freeware tool to create Choose-Your-Own-Adventure games, and
it doesn't necessarily require programming (it does support it in "source"
mode):
http://questml.com
Carl Muckenhoupt
Adrift could manage with a codeless, menu-based system. And that's still
true; Adrift goes well beyond what I had expected, and I advise anyone
who's trying to make a new "easy" adventure system to give it a look.
However, Adrift also has some serious problems. The most serious of
these is that the default error messages pretend to understand things
that they do not. This may not sound like a serious problem, but it is.
For example, in one recent game, many players missed a vital clue because
they tried to "examine robot" rather than "examine robot guard"; the
response "Nothing special." gave no indication that the command they had
entered was not successfully interpreted.
Sean T Barrett
>From where I sit (where that is: among my hats are both "published
>author" and "professional programmer," but I certainly self-identify as
>much more of a technical geek than a writer), I'd say that to write a
>great game, you need to be a very good writer, but you can get away with
>being a mediocre programmer. Nevertheless, you will need some
>programming skills to achieve enough mimesis that your game is actually
>fun to play.
I totally concur. As an, umm, extremely talented programmer (I am, as
far as I can tell, at the top of my profession in my industry), I observe
two phenomena: one, I will never write an IF game as good as some games
out there written by authors who are great writers and I'm fairly certain
are not as good at programming as I--*according* to the current definition
of "good IF game"--and two, because I know that a lot of the IF code
I write is fairly crappy, because IF coding is mostly just a pile of
exceptions.
I mainly followed up because I wanted to post the following URL, which
somebody sent me last week, which actually attempts to address WHY
programming is important. (Not IF specific, but close enough, you'll see.)
http://home.netcom.com/~apstern/interactivestory.net/papers/deeperconversations.html
[evil long URLs, sigh]
However, it is not a particularly unbiased piece; it is written by
a programmer, and indeed by a programmer who I would say (although
he would disagree) works in the game industry (that is, the mass-market
interactive entertainment industry), and by an author who (IMO)
denigrates games in an attempt to reach out to academia.
SeanB
Sean T Barrett
>My previous programming experience? None. I wrote games in BASIC when I
>"programming."
Hmm well. The important part of programming is really the "design"
component, expressing what you want to have happen and breaking
that into component pieces. Expressing it in a concrete language
and working around an existing library isn't really the hard part,
once you have the first skill. I would tend to expect that anything
really resembling a game (even 'pick a number from 1 to 100', if
you coded the program from scratch) even in BASIC would require
achieving that skill on some level; not sufficient to go
out and write DOOM, but plenty for most IF purposes.
This is not to say that I can't code circles around the me that
wrote BASIC twenty years ago--but rather that the process of being
confronted by a new problem and working out how to move forward on
it hasn't really changed.
SeanB
Adam Thornton
Sean T Barrett <buz...@TheWorld.com> wrote:
>Hmm well. The important part of programming is really the "design"
>component, expressing what you want to have happen and breaking
>that into component pieces. Expressing it in a concrete language
>and working around an existing library isn't really the hard part,
>once you have the first skill. I would tend to expect that anything
>really resembling a game (even 'pick a number from 1 to 100', if
>you coded the program from scratch) even in BASIC would require
>achieving that skill on some level; not sufficient to go
>out and write DOOM, but plenty for most IF purposes.
It is only a slight exaggeration on the part of K&R to say that "Hello,
world" is the hardest program you will ever write.
As with human languages, computer languages get easier the more you
learn, because at some deep level they're pretty much equivalent.
Although I'd be tempted to break that into procedural, functional, and
declarative languages, but you get the idea.
Just to illustrate--I'm working on a project for a very small system
(you will be able to see part of it in the IntroComp). Among the things
I wanted to do today was to change the behavior of the GIVE verb a
little; usually, in this system, it destroys the object given, but for
one particular object in my game, I want the player to retain possession
(the idea being that the recipient uses it and gives it back).
The system is written in a variant of 6502 assembly code. I found the
Give subroutine, added in my check (there was already a bne, so I
figured that beq was its inverse, so all I had to do was load the
constant representing this object into the accumulator, compare it with
the value at the address referred to as temp, and skip the
destroy-object code if they were equal), and damned if it didn't work
the second time out (forgot to reload the accumulator with the old value
the first time). This despite the fact that I haven't looked at 6502
assembly code in 15 years.
>This is not to say that I can't code circles around the me that
>wrote BASIC twenty years ago--but rather that the process of being
>confronted by a new problem and working out how to move forward on
>it hasn't really changed.
Although your toolbox of stuff with which to attack that problem has
grown. How many of us invented quicksort or something similar (IOW: a
divide-and-conquer, pivot-based, recursive sort), before ever knowing
that such a thing had a name and was described and analyzed in the
literature? Indeed, before even knowing there *was* a literature?
Adam
Jim Aikin
>>>Coin toss. Learning one language and then learning another is no fun,
>>>but I can't say I'd recommend that someone learn TADS as their first
>>>language.
>>>
>>But I'd certainly recommend it before Inform. It's just as powerful,
>>but more intuitive for the first time programmer.
>>
> Hm. I've never found TADS particularly intuitive, and inform was the
> first Serious programming language I ever learned.
I learned Inform 3 years ago, and found it pretty easy to get my brains
around (but then, I already knew a little C++). TADS 2 has some
counter-intuitive features. For instance, a logic test can't be used on
a variable with a numeric value:
var := 1;
if (var) {"blah blah blah";}
This generates a runtime error, which it doesn't in C or Inform. The
problem is partly that the compiler doesn't know ahead of time that var
won't be set to true. If variables were typed, the compiler could 'see'
the problem.
Also, the compiler DOES NOT FLAG AN ERROR if you declare a verb handling
method in an object and forget to include the parameters (actor, dobj,
etc.) in the method declaration. Yet at runtime you'll get hash
characters on the screen. (I make this mistake at least once a day.)
I personally like Inform's parse_name functionality a LOT. That's the
one big thing I wish I could do in TADS. It allows one to disambiguate
gracefully when objects have complex names.
--Jim Aikin
Jim Aikin
>
> Then, in early January of this year, I discovered the Inform
> Designer's Manual by Graham Nelson, and suddenly the light came in.
> This has got to be the most lucid, cogent, readable guide to a
> programming language that I've ever seen, ever.
Right on. The manual was why I picked Inform for my first game in 1999.
I've now switched to TADS principally because the multimedia support
includes mp3 playback, which I need for my new project. But with all due
respect to Mike Roberts, who is a genius, the TADS manual is not as good
as it ought to be. The index is out of date, the links in the TOC are
not all valid, it could use more real-world examples, and some technical
points are not explained with as much clarity as I need.
A lot more could be said on the pros and cons of the two languages, but
if I tried, I'd surely put my foot in my mouth.
--Jim Aikin
Kodrik
> component, expressing what you want to have happen and breaking
> that into component pieces. Expressing it in a concrete language
> and working around an existing library isn't really the hard part,
> once you have the first skill.
Exactly, there is a saying that says "what is conceive well is enunciated
well".
If you conceive your story well and can lay out well all the relations
between all the objects in your game, you will be able to find an engine
with fits you in its way of implementing your design and for which the
coding comes naturally.
Then, as you gain experience in manipulating these objects in more and more
complex ways, you will understand the questions and answers posted here
with other languges and you might find one that better suits your needs and
give you more power.
Georgina Bensley
> Although your toolbox of stuff with which to attack that problem has
> grown. How many of us invented quicksort or something similar (IOW: a
> divide-and-conquer, pivot-based, recursive sort), before ever knowing
> that such a thing had a name and was described and analyzed in the
> literature? Indeed, before even knowing there *was* a literature?
You know you're a geek when you find yourself using quicksort on physical
objects in your non-programming job...
(Library. Journal alphabetising... sorry, 'magazines' for the
non-library-people.)
> Adam
__________________________________________________________________
Duke University Role-playing And Gaming Organization
http://www.duke.edu/web/DRAGO/
Gary Shannon
<snip>
> Right on. The manual was why I picked Inform for my first game in 1999.
> I've now switched to TADS principally because the multimedia support
> includes mp3 playback, which I need for my new project. But with all due
> respect to Mike Roberts, who is a genius, the TADS manual is not as good
> as it ought to be. The index is out of date, the links in the TOC are
> not all valid, it could use more real-world examples, and some technical
> points are not explained with as much clarity as I need.
>
> A lot more could be said on the pros and cons of the two languages, but
> if I tried, I'd surely put my foot in my mouth.
>
> --Jim Aikin
My biggest complaint with the TADS manual, as with so many other manuals
I've seen (Microsoft is a major offender here) is that you can't look up the
answer to a question unless you know the answer to the question already. In
essence the manual is indexed by answers instead of being indexed by
questions.
Trivial example. I wondered how to embed images in the .gam file. A lot of
helpful people on this group pointed out to me to look under "resources" in
the manual. Now that I know that the answer is "resources" I can find it.
Before I knew that the answer was "resources" all I knew to look under was
"embedding", "images", "pictures", etc.
I guess what I'm really looking for is a comprehensively indexed "how to"
guide rather than a manual. Maybe, if I get energetic, I'll start
collecting all the cool tips from this NG and create an index for them and
put an indexed how to on my web site. :-)
I was thinking I could use a "key word in title" index to a collection of
how to articles. Something that would look like this, with multiple entries
for each article based on key words:
.....
actor. -- Give an object to an [15]
actor. -- Show an object to an [6]
Actor refuses to accept an object. -- [12]
Actor refuses to give back an object. -- [17]
bright light. -- Seeing in dim vs. [41]
concealing an object until some action is performed. -- Hiding or [21]
container and supporter -- Making an object which is both [31]
container or suporter. -- Listing contents of [3]
container or surface between adjacent rooms. -- Pass-through or sharing a
single [22]
contents of a container or suporter. -- Listing [3]
Darkness and light sources. -- [40]
dim light vs. bright light. -- Seeing in [41]
Embedding image and sound files in the .gam file. -- [14]
enter <name> to enter a location -- Using [8]
Give an object to an actor. -- [15]
.....
--gary
Dana Clarke
<fiz...@starband.net> wrote:
>My biggest complaint with the TADS manual, as with so many other manuals
>I've seen (Microsoft is a major offender here) is that you can't look up the
>answer to a question unless you know the answer to the question already. In
>essence the manual is indexed by answers instead of being indexed by
>questions.
As a newbie IF programmer, I have to agree. I find myself spending
inordinate amounts of time just trying to find answers to what I
consider to be "root" issues with any programming language - answers
that with "normal" programming languages I have used were immediate
and obvious in the manuals. As you said, many times the answers are
in the manual provided, but can truly only be found by someone who
already has an in depth understanding of the programming language (and
then, that person is likely to not need it).
There are many components of code that virtually programmer will need
in most games (if not all). For example, I have been banging my head
trying to find how to ask a variety of "initialization" type questions
of the player before actually beginning the game (such as what sex is
desired for the PC, what age, etc.) - and so far have failed. This
example of getting input from the player is such a fundamental that it
should just leap out at me - but it hasn't.
Unfortunately, to generate such a comprehensive and easy to use manual
require in depth programming understanding - so I cannot do it <g>.
Dana
Ferlin Scarborough
"Adam Thornton" <ad...@fsf.net> wrote in message
news:a54g8g$53j$1...@news.fsf.net...
(snip)
> Give subroutine, added in my check (there was already a bne, so I
> figured that beq was its inverse, so all I had to do was load the
>
bne, beg, mov ....
Brings back some old memories, been awhile since I've seen those commands.
Ahhh, those where the days pushing registers on the stack so you could use
them for some thing else, then 'FORGETTING' to set them back. :)
he he he...
Ferlin
Kodrik
> guide rather than a manual. Maybe, if I get energetic, I'll start
> collecting all the cool tips from this NG and create an index for them and
> put an indexed how to on my web site. :-)
I've been tinkering on how to make documentation for my engine beyound the
tutorial, but it's not easy at all.
Personally, I've learned most of my language with two tools, reference and
sample codes.
The sample code shows me how to do something and the reference is for the
definitions of the functions.
Kind of like reading a book in a foreign language you are learning with a
dictionary. It helps you to learn the language.
I'm planning to make a system where authors can explain how they did
different part of their games. So if you see spray can in a game and you
would like to do something similar, you can search the database for "spray
can" in "game title" or "game engine" and if the author made an entry,
you can read about it.
I could make this system open to all authors and all engines.
I'm not good at guessing the opinions of people here so I would like to
know what you think. If the community doesn't see a need for it, I'll just
do it for my own needs.
David Thornley
Ferlin Scarborough <Bill...@microsoft.com> wrote:
>Hello All,
>
>My first taste of an Authoring System for Text Adventures had been AGT, but
>there were some things that you had to go around the world to implement in
>it. Especially if it went against the design of AGT.
>
>On the other hand AGT was EASY to learn and one could easily create a mini
>non complex IF game in it, with hardly any extra command coding.
>
sample code.
Creating something is basically a three-step process.
1. Find something similar in the sample code.
2. Where it says "festering corpse", you write "bowl of petunias".
Repeat as needed.
3. Try it out. If it works, great. If not, see if you can figure
it out. See if the manual suggests anything to you. If not,
post to r.a.i-f.
In order to do this, you have to be able to edit the source code,
run the compiler, and run the interpreter.
Eventually, you will learn to do routine things, and large parts of
the manual will begin making sense.
I've been a great believer in this approach since my wife taught
herself to program by modifying games in BASIC on the old TRS-80.
>When I looked at HUGO, ALAN, TADS and INFORM they looked like they would be
>a little OVERWHELMING to a Begginer?
>
I'm not familiar with Hugo or Alan. In TADS and Inform, you can usually
puzzle out what a given construct does, or if all else fails find it
in the manual. Once you can do that, you can probably change it.
>With all that said I wanted to Inquire as to What Authoring System you
>people would consider as being a good one for a Begginer to start learning
>with, and why?
>
Any that is powerful enough to support what you're going to want to do.
Since the ones I'm halfway familiar with can be learned largely by
hack-and-error, you can do so. It's usually easier to learn one
language and use it than to learn another language as preparation,
as long as you aren't planning to become a serious programmer (in
which case you should learn more languages to be exposed to different
ways of doing things).
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Alan DeNiro
> As somone who had never seen a line of code before encountering IF I
> found ALAN to be very learnable. It taught me basic concepts like
> if/else statements too! If you really (like me) know nothing about
> fundamental programming ALAN might serve as a good intro to, say TADS,
> which has some similarties it seems. Adrift is, in its basics, even
> easier than ALAN - although, surprisingly, at a more advanced level it
> can become more difficult to grasp- to me.
>
> You can, I believe, write a worthwhile, enjoyable game in ALAN or
> Adrift. However, for us nonprogramming writers, the sad truth is
> that you can't just somehow stick some simple code into the text of a
> short story or novel and have a game. They are very different things.
Eric wrote at length on this subject at:
http://www.brasslantern.org/writers/iftheory/easyif.html
I thought it was a very balanced, useful essay when I was starting out.
Alan
------
Alan DeNiro
http://www.taverners-koans.com/ratbastards/alan.html
30otsix
I would like to point out that both of these issues are a fault of the
game author. ADRIFT allows the author to designate their own default
messages. The fact that you received a default message at all is also
the fault of the author and could have been avoided with a simple "*"
(wildcard).
I have read many of posts concerning ADRIFT and it seems to me the
majority of the problems are on the part of the authors. The obvious
reason is that the learning curve is so low that anyone (and I do mean
anyone) can create a game within a matter of hours. Just because you
can make a game doesn't mean you should. I have played around with
ADRIFT for almost a year now and have yet to find something I could
not do. That's not to say that it couldn't be done easier or faster
in another language. I am convinced that in the hands of a capable
author, ADRIFT can produce games like any out there.
It is unfortunate that none of the better writers in this community
have not done so.
As for which language is simpler, I do not know. I tried my hand at
TADS for about a day before I discovered ADRIFT and quickly gave up.
I do know that ADRIFT can be as simple or as complicated as the author
wishes.
And finally, as for needing to be a programmer to write a good game.
If you mean by programmer, able to understand logic flows and if/then
statements, then I would agree. If you mean coder;I would not.
30otsix
Lewis Raszewski
>
> > Although your toolbox of stuff with which to attack that problem has
> > grown. How many of us invented quicksort or something similar (IOW: a
> > divide-and-conquer, pivot-based, recursive sort), before ever knowing
> > that such a thing had a name and was described and analyzed in the
> > literature? Indeed, before even knowing there *was* a literature?
>
> You know you're a geek when you find yourself using quicksort on physical
> objects in your non-programming job...
>
> (Library. Journal alphabetising... sorry, 'magazines' for the
> non-library-people.)
>
> > Adam
>
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"If I had a million dollars, I'd buy you a monkey (Haven't you always
wanted a
monkey?)" -- Barenaked Ladies, If I had $1000000
TheCycoONE
"Ferlin Scarborough" <Bill...@microsoft.com> wrote in message
news:6MWc8.150082$TI5.7...@e3500-atl2.usenetserver.com...
>
> A couple of years ago, 1987 or so I believe I purchased a program called
> AGT then MAGT to create Text Adventures, the program boasted that a
> Non-Programmer could create adventures using it.
>
> Hugo, Alan, Tads and Inform all seem to get a little technical for a
> Non-Programmer to use.
>
> I have seen another package that boasts at being a Non-Programmer Text
> Adventure creation tool called Adrift
>
>
> Which Authoring System do YOU feel is good for a Non-Programmer to use to
> create Text Adventures and Why?
>
>
> How could it be improved, yet still remain easy for a Non-Programmer?
>
> Thanks in advance for your input on this subject.
>
> Ferlin.
>
Seems to be a fair bit of 'sensible debate' over this matter. I would
suggest that ADRIFT is a *very* powerful programming tool, but even CW
doesn't know the extent of what it can do, and in reaching that stage you
end up with the worse looking pile of... well it becomes very tedious to
look through anyone else's code, or even come back you ones own after a few
weeks.
I suggest that nearly anything someone can do in the programmable languages
I could mimic in ADRIFT. I would also like to take this moment to say that
it is actually MUCH EASIER to program then to try to tweak features out of
ADRIFT.
(If I could actually write, I'd show you all!) :-)
TheCycoONE
nils barth
>Georgina Bensley wrote:
>> You know you're a geek when you find yourself using quicksort on physical
>> objects in your non-programming job...
>>
>> (Library. Journal alphabetising... sorry, 'magazines' for the
>> non-library-people.)
>>
I prefer doing merge sorts - I find they work quite well with physical
objects, like stacks of tests etc.
Dan Shiovitz
Jim Aikin <kill_spammers@kill_spammers.org> wrote:
[..]
>
>I learned Inform 3 years ago, and found it pretty easy to get my brains
>around (but then, I already knew a little C++). TADS 2 has some
>counter-intuitive features. For instance, a logic test can't be used on
>a variable with a numeric value:
>
>var := 1;
>if (var) {"blah blah blah";}
>
>This generates a runtime error, which it doesn't in C or Inform. The
>problem is partly that the compiler doesn't know ahead of time that var
>won't be set to true. If variables were typed, the compiler could 'see'
>the problem.
Actually, any type of value is valid as a logical test in TADS. 0 and
nil test as false; everything else tests as true. If this code didn't
work for you, I suspect you had an error in your code elsewhere.
>Also, the compiler DOES NOT FLAG AN ERROR if you declare a verb handling
>method in an object and forget to include the parameters (actor, dobj,
>etc.) in the method declaration. Yet at runtime you'll get hash
>characters on the screen. (I make this mistake at least once a day.)
Hash characters? I guess this is interpreter-specific. It's annoying
that the compiler doesn't do formal argument-count checking, yeah, but
it's somewhat unavoidable in a language as loose as TADS is. (And, of
course, you want to be able to support some verbs being like
"verDoTake(actor)" and some like "verDoPutIn(actor, iobj)"). On the
other hand, all verbs of a specific type take exactly the same
arguments, so once you learn it you'll be set.
>I personally like Inform's parse_name functionality a LOT. That's the
>one big thing I wish I could do in TADS. It allows one to disambiguate
>gracefully when objects have complex names.
Yeah, this is an unfortunate lack in TADS 2. It's partly compensated for
by the more advanced default noun-phrase-parsing, and you can
generally work something up with parseNounPhrase() (see section 6 of
the manual), but it's not as convenient for more complex NP parsing as
Inform.
T3's noun-phrasing parsing, of course, is slightly more complex to use
but superior to either of the previous.
>--Jim Aikin
--
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
Georgina Bensley
> >> (Library. Journal alphabetising... sorry, 'magazines' for the
> >> non-library-people.)
> >>
> >Um... You *do* know that radix sort is order N if you're a human?
>
> I prefer doing merge sorts - I find they work quite well with physical
> objects, like stacks of tests etc.
Okay, I admit I was only a computer science minor and not a major (which
would therefore be why I"m working in a library and not a programmer) and
the words "radix sort" aren't actually meaning a damned thing to me. We
Must Not Have Done That One.
The thing with the unbound journals is that absolute alphabetising isn't
necessary. Unbound stacks don't take up that much shelf space and
therefore many titles are in the same physically-reachable area. It's very
quick to go through a stack of titles and split them up into "title before
j", "title starts with j" (There's a lot of Journal Of Somethings, you
see), and "title after j". And unless one of those piles is still
unmanageably large to be carrying around by hand, that's more or less
enough - and that very rapid sort saves a large amount of shelving time.
Organising books on a shelving cart, on the other hand, requires complete
sorting.
Andrew Plotkin
> I would like to point out that both of these issues are a fault of the
> game author. ADRIFT allows the author to designate their own default
> messages. The fact that you received a default message at all is also
> the fault of the author and could have been avoided with a simple "*"
> (wildcard).
> I have read many of posts concerning ADRIFT and it seems to me the
> majority of the problems are on the part of the authors. The obvious
> reason is that the learning curve is so low that anyone (and I do mean
> anyone) can create a game within a matter of hours.
You can't evaluate an IF development system without evaluating how it
handles "easy" cases. If the defaults are bad by default, well,
they're bad. They should be fixed.
When I created my first one-room-one-object Inform game, which was
about twenty lines of code (mostly copied out of the DM), it was a
pretty good room and a pretty good object. Boring, with a one-line
description for each, but not *bad*. The defaults out of the box were
solid.
I could then spend my time *improving* the room and the object,
instead of trying to sort through the system making my starting point
acceptable.
(And I know that TADS has the same property, because even the simplest
TADS games have equally solid responses to the standard IF interaction
range.)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
SteveG
<Bill...@microsoft.com> wrote:
>Hello All,
>
>Sorry if I didn't make things very clear, when I posted the message it was
>after a LOOOONG work day. Here is what I was actually trying to get at.
>
>First of all, I used the terminology Non-Programmers because that was the
>term used in the AGT Manual. I guess I should have said Begginers instead.
>
>What I was driving at was this:
>
>there were some things that you had to go around the world to implement in
>it. Especially if it went against the design of AGT.
This is a common characteristic of the 'easy' IF authoring system and
the reason why many people here suggest that beginners start learning
with one of the big-three fully-capable languages. This may be good
advice for some beginners. A possible drawback though is that some
beginners may be so overwhelmed that they never reach the point where
they benefit from the programming flexibility of those systems.
>On the other hand AGT was EASY to learn and one could easily create a mini
>non complex IF game in it, with hardly any extra command coding.
I don't think AGT is all that easy for the true programming beginner.
I would argue that AGT is as hard as any authoring system for the
first hour or two as a non-programmer tries to master the fundamental
concepts of programming. You still have to master the concepts of
editing source-code in a text-editing program, then compiling it with
a commandline utility and playing the resulting game with a third
program. And on top of that you have to learn the concepts and syntax
of the AGT language.
The AGT programming language may be easier to grasp than some other
languages. I can't really say whether it is easier as I saw AGT after
I'd already learnt Turbo Basic and a little Pascal.
>When I looked at ADRIFT it looked like a nice tool to create IF, but there
>is only so much you can do with a Menu driving system. (Only so many choices
>can be on a menu), not much room for the Author to add his own coding.
>
>When I looked at HUGO, ALAN, TADS and INFORM they looked like they would be
>a little OVERWHELMING to a Begginer?
I interested that you place ALAN in the same category as Hugo, TADS
and Inform. Contrarily, I advocate ALAN as the solution to beginners
overwhelmed by one of the other three! I would be interested to hear
why you think it is as overwhelming as the others. I think ALAN has a
much simpler syntax than the other three because it takes a
descriptive approach to building an IF 'world.' In this respect ALAN
is much like AGT but ALAN is a better beginner's system because its
modern style is a better introduction to concepts common in other
programming languages.
>With all that said I wanted to Inquire as to What Authoring System you
>people would consider as being a good one for a Begginer to start learning
>with, and why?
>
>To which I have seen some of the reply's concerning ALAN, INFORM, TADS, HUGO
>and ADRIFT.
Well, as I've said, I'd advocate ALAN.
And if that's too much for a beginner, then ADRIFT.
I would also mention Quest. The Quest system has both a programming
language, giving power and flexibility, and a forms-based authoring
interface similar to ADRIFT. The best of both worlds perhaps? I don't
know as I haven't spent enough time experimenting with it. (Quest,
like ADRIFT, is a MS Windows system. Its homepage is at
<http://www.axeuk.com/quest/index.htm>.)
Another suggestion would be to experiment with a slightly different
form of interactive fiction rather than the parser-based games usually
discussed here on raif. The menu-based 'choose-your-own-adventure'
game requires less programming skill to write (but atleast as much
writing skill.) There's a CYOA utility by, I think, Jon Ingold (can't
find the URL right now--I've got 103 links in the "IF Languages"
folder in my Internet Explorer "favourites". Good grief, no wonder its
confusing choosing an IF authoring system!)
SUDS is another Windows-only system programmed entirely via a
forms-based interface. <http://www.sudslore.com/>
>My next inquiry was as to How these systems could be improved, yet still
>remain a good Authoring System for a Beginner to start learning with.
I don't think the languages themselves should be changed. It would be
a tragedy to dumb down Inform, for example, so its easier for
beginning programmers. Instead, I think the emphasis should be placed
on the learning environment and programming interface -- tutorials,
"integrated development environments", sample games, "wizards" and
templates etc. In fact a lot of work has been done in these areas for
many of the authoring systems.
A problem for beginners remains in tracking down and installing all
this stuff. One of the advantages of Adrift and SUDS is their easy
self-installing Windows setup programs to help the beginner get
started. There are Windows packages for some of the conventional
compiler-based authoring systems too. TADS has a Windows Authoring Kit
which sets all the TADS components up correctly and presents them to
the author in an integrated "TADS Workbench" interface. My own efforts
in this area is the ADE/w package and interface for ALAN. The
advantage of such all-in-one packages is that they get aspiring
authors over the first hump in the learning curve with enough energy
left to tackle the next new concept they face - programming! :-)
[snip]
-- SteveG
remove _X_ from my address to send me email
Eric Mayer
wrote:
>This is a common characteristic of the 'easy' IF authoring system and
>the reason why many people here suggest that beginners start learning
>with one of the big-three fully-capable languages. This may be good
>advice for some beginners. A possible drawback though is that some
>beginners may be so overwhelmed that they never reach the point where
>they benefit from the programming flexibility of those systems.
>
This is true. Judging from discussions here I think that some folks
underestimate just how ignorant some others (like me) can be when it
comes to programming. I realize there are those who have said they
started totally cold, with no knowledge at all or programming, and are
happily writing away in Inform or TADS -- and my hat's off to them (or
would be if I wore a hat - >take off hat, > remove hat, >doff hat etc
etc --but Isuspect not everyone will take to programming quite so
readily.
I used computers, mostly for word processing, at work and home for
fifteen years without the slightest idea of how it was people got them
to do what they did, at any level. "Write code" What's "code"?
"Compile?" Come again? The idea that one could write some stuff in a
word processor and then run it through something called a compiler and
then the "program" thus created would tell the computer to perform
certain actions - well, that was surprising to me! Maybe that shows my
age. (No comments about intelligence please!)
So being able to learn enough in ALAN to create simple programs was
not only a thrill for me but also gave me some rudimentary
understanding of some of what goes into all the software that's become
so much a part of my life. I don't understand much, but more than I do
about how my tv works.
As much as I like and an impressed by ADRIFT I would recommend a total
newcomer to start with ALAN and at least take the opportunity to get a
taste of programming. In fact, I expect ADRIFT would not have been all
that easy for me to figure out if I hadn't learned the basic
programming concepts involved (however well disguised) via ALAN. But
if you are not interested in toying around with the programming --
which is what I admit I find most amusing about writing IF -- one will
probably prefer Adrift.
--
Eric Mayer
Web Site: <http://home.epix.net/~maywrite>
"The map is not the territory." -- Alfred Korzybski
John W. Kennedy
> > >> (Library. Journal alphabetising... sorry, 'magazines' for the
> > >> non-library-people.)
> > >Um... You *do* know that radix sort is order N if you're a human?
> > I prefer doing merge sorts - I find they work quite well with physical
> > objects, like stacks of tests etc.
> Okay, I admit I was only a computer science minor and not a major (which
> would therefore be why I"m working in a library and not a programmer) and
> the words "radix sort" aren't actually meaning a damned thing to me. We
> Must Not Have Done That One.
The oldest mechanical sort of all. For simplicity, assume that we are
sorting by decimal numbers only, on a four-digit field. This is how we
did it with punched cards back in the old days:
Divide the cards into ten groups by the ones digit. (This is the
original meaning of the word "sort", and this procedure is the
reason that it evolved to mean "put into collating sequence".)
Stack the ten groups in order, and divide them again by the tens
digit. Each group will already be in order by the ones digit
from the previous step.
Stack them again, which will put them into order by the tens and
ones digit, and divide by the hundreds digit.
Stack, and divide by the thousands digit.
The time involved is proportional to N*L, where L is the length of the
field. (Note that, in the general case, L will be roughly proportional
to log N, so, while radix sort has linear time in a sense, it's not a
magic escape from the N*log N rule.)
When doing a radix sort in RAM, or when a human is doing a radix sort
with physical objects, it is more efficient to go left-to-right, instead
of right-to-left. First divide everything into A, B, C, D, E.... Then
divide the A's into AA, AB, AC, the B's into BA, BB, BC, and so on.
When a group reaches a certain upper limit, finish it with some other
sort. In a version I wrote for mainframes in the 80's, I used shell
sort* when a group reached less than 1536 members (shell sort times jump
upward at every N=3*2^n), unless it was less than three, in which case I
used bubble sort. A human would normally put the limit somewhere
between three and ten, and use the "just do it" sort at that point.
* Quicksort is very inefficient in pure IBM mainframe assembler, because
neither the operating system nor the hardware supplies a stack, so each
recursion requires two expensive operating-system calls; compiler
run-times supply a stack, but, until the 90's or so, every compiler had
its own incompatible run-time, and only one of them was documented.
--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html
John W. Kennedy
> I prefer doing merge sorts - I find they work quite well with physical
> objects, like stacks of tests etc.
...which is why merge sorts are used in mainframe sort programs, which
often have to deal with quantities of data larger than available RAM by
many orders of magnitude. (Another mainframe trick: if you're only
interested in counts or totals, merge sorts let you replace two records
by one record containing their sum, so that the number of records being
sorted continually drops during the process; depending on the data, this
can be much faster than quicksort.)
Lewis Raszewski
Coding is a trivial task compared to the ability to think in a
programatical sense. All "easy" systems have attempted to simplify the
syntax.
You insist that the flaws in adrift games result from the fact that poor
authors are using it. Perhaps you should contemplate why this is the
case.
As the saying goes, If you build a system that any idiot can use, any
idiot will.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"You are in a maze of twisty passages, all alike." -- Crowther and Woods
Lewis Raszewski
>
> > >> (Library. Journal alphabetising... sorry, 'magazines' for the
> > >> non-library-people.)
> > >>
> > >Um... You *do* know that radix sort is order N if you're a human?
> >
> > I prefer doing merge sorts - I find they work quite well with physical
> > objects, like stacks of tests etc.
>
> Okay, I admit I was only a computer science minor and not a major (which
> would therefore be why I"m working in a library and not a programmer) and
> the words "radix sort" aren't actually meaning a damned thing to me. We
> Must Not Have Done That One.
>
> The thing with the unbound journals is that absolute alphabetising isn't
> necessary. Unbound stacks don't take up that much shelf space and
> therefore many titles are in the same physically-reachable area. It's very
> quick to go through a stack of titles and split them up into "title before
> j", "title starts with j" (There's a lot of Journal Of Somethings, you
> see), and "title after j". And unless one of those piles is still
> unmanageably large to be carrying around by hand, that's more or less
> enough - and that very rapid sort saves a large amount of shelving time.
>
> Organising books on a shelving cart, on the other hand, requires complete
> sorting.
>
Radix sort was the first sort whose name came to be from a family of
sorts based on the principle of "The fastest way to sort a group of
things is to look at each thing, just Know Where It Goes, and put it
there" It's (or rather, sorts from this family) are actually a lot
closer to what people actually do when sorting things like books. You
look at the first book, see that its title begins with 'j', and put it
10/26 of the way through (more or less, depending on what you know about
the distribution of titles. Radix sort itself, IIRC, would first pull
out all the 'J's, and sort them, then stick the whole pack where the Js
go. Works especially good in real life situations like ordering library
books, because there's marks on the shelves to tell you where the Js
go.).
There's a bunch of sorts that are faster than quicksort, but they're not
as popular because they either require extra memory, or require that you
know something about the distribution of the data (which is hardly ever
worth collecting)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"She's a lot like you, but she don't look like you... Okay, she's not
you, but
she'll do find." -- Barenaked Ladies, Intermittently
Eric Mayer
<rras...@hotmail.com> wrote:
>
>You insist that the flaws in adrift games result from the fact that poor
>authors are using it. Perhaps you should contemplate why this is the
>case.
>
>As the saying goes, If you build a system that any idiot can use, any
>idiot will.
>
Much as I admire the abilities, foreign to me, of people in this group
to do programming, the ability to program, or even the ability to
think in programming terms, isn't the only measure of intelligence,
or, conversely, idiocy. :)
David Glasser
> My biggest complaint with the TADS manual, as with so many other manuals
> I've seen (Microsoft is a major offender here) is that you can't look up the
> answer to a question unless you know the answer to the question already. In
> essence the manual is indexed by answers instead of being indexed by
> questions.
Well, the manual is a set of files on your computer. You can search it
with grep or your text editor's multi-file search or whatever. Indices
are great but on the computer, you can work around that.
--
David Glasser
ne...@davidglasser.net http://www.davidglasser.net/
Dana Clarke
Glasser) wrote:
>Gary Shannon <fiz...@starband.net> wrote:
>
>> My biggest complaint with the TADS manual, as with so many other manuals
>> I've seen (Microsoft is a major offender here) is that you can't look up the
>> answer to a question unless you know the answer to the question already. In
>> essence the manual is indexed by answers instead of being indexed by
>> questions.
>
>Well, the manual is a set of files on your computer. You can search it
>with grep or your text editor's multi-file search or whatever. Indices
>are great but on the computer, you can work around that.
However, the search function of the computer still won't help if you
don't know what to search for! That is the point (at least for me).
If you don't already know that you need a function known to
programmers as "glop_fleinng_toomuchnomenclature", then you are VERY
unlikely to ever find it. All the computer search function will do
for you is to help you not find stuff faster <g>.
In fact, in many cases (speaking again for novices such as myself) the
major problem is not even knowing the question! Further, most manuals
(I will include the HUGO and TADS manuals in this group) use technical
lingo (jargon, whatever) that communicates absolutely wonderfully to
someone proficient in that programming environment and successfully
communicates virtually nothing to someone who is not. Again, if you
know it already the manual helps a great deal - if you don't then you
won't.
If you don't already know Russian, you are NOT going to learn it from
a book written in Russian <g>.
Dana
Gary Shannon
"Dana Clarke" <joey...@bellsouth.net> wrote in message
news:d05j7uoroqpi97nn4...@4ax.com...
Kinda reminds me of the time I tried to learn Linux! As a long time
DOS/Windows programmer the Linux manuals were written in some strange
language I simply couldn't grok at all.
Fortunately there are a lot of good TADS sample games to look at. These are
usually a better way to learn how to do some specific thing anyway.
--gary
>
Magnus Olsson
Dana Clarke <joey...@bellsouth.net> wrote:
>However, the search function of the computer still won't help if you
>don't know what to search for! That is the point (at least for me).
This is true for most manuals, unfortunately. A good index is worth
its weight in gold, and about as hard to find as well.
>Further, most manuals
>(I will include the HUGO and TADS manuals in this group) use technical
>lingo (jargon, whatever) that communicates absolutely wonderfully to
>someone proficient in that programming environment and successfully
>communicates virtually nothing to someone who is not. Again, if you
>know it already the manual helps a great deal - if you don't then you
>won't.
The Inform manual isn't like that, IMO. The TADS manual (at least the
old printed copy that I have) does sort of assume that you're familiar
with some C-like programming language.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Magnus Olsson
Andrew Plotkin <erky...@eblong.com> wrote:
>30otsix <30o...@tsconnects.com> wrote:
>
>> I would like to point out that both of these issues are a fault of the
>> game author. ADRIFT allows the author to designate their own default
>> messages. The fact that you received a default message at all is also
>> the fault of the author and could have been avoided with a simple "*"
>> (wildcard).
>
>handles "easy" cases. If the defaults are bad by default, well,
>they're bad. They should be fixed.
>
>When I created my first one-room-one-object Inform game, which was
>about twenty lines of code (mostly copied out of the DM), it was a
>pretty good room and a pretty good object. Boring, with a one-line
>description for each, but not *bad*. The defaults out of the box were
>solid.
>
>I could then spend my time *improving* the room and the object,
>instead of trying to sort through the system making my starting point
>acceptable.
To elaborate on that a bit, I think the users of a system have a right
to demand good default responses from the system. Not default responses
that fit every situation, of course - they wouldn't be defaults in that
case. But if the default responses are so bad that *every* author has
to change them, then I'd say there's something wrong with the system
providing those defaults.
Or, to take it to extremes, "By default, system Y does the wrong thing,
but the author can easily make it do the right thing, so there's
nothing wrong with Y."
Magnus Olsson
>Or, to take it to extremes, "By default, system Y does the wrong thing,
>but the author can easily make it do the right thing, so there's
>nothing wrong with Y."
Hmmm - that came out a bit wrong, didn't it? I meant, of course, that
the extreme position above is *not* the way one should think of things.
Sean T Barrett
>Georgina Bensley wrote:
>> > >Um... You *do* know that radix sort is order N if you're a human?
>> > I prefer doing merge sorts - I find they work quite well with physical
>> > objects, like stacks of tests etc.
>> Okay, I admit I was only a computer science minor and not a major (which
>> would therefore be why I"m working in a library and not a programmer) and
>> the words "radix sort" aren't actually meaning a damned thing to me.
>
You know, this is the exact sort of thread that is basically ENTIRELY
IRRELEVANT to IF, and should be taken to email, not just tacked with
an "OT".
I'm pretty sure you have email, given that I emailed BOTH you
and Georgina a single mail, addressing the previous post in
this thread *and* attempting to define what radix sort was,
to spare us further posts on the subject...
and you responded to that email by email.
For the love of Gorf, people, just say no to off-topic posts.
Sean "grumpy" B
Magnus Olsson
Sean T Barrett <buz...@TheWorld.com> wrote:
>>Radix sort was the first sort whose name came to be from a family of
>>sorts based on the principle...
>
>You know, this is the exact sort of thread that is basically ENTIRELY
>IRRELEVANT to IF, and should be taken to email, not just tacked with
>an "OT".
Sean, you're way out of line here. Nobody died and made you the
moderator.
And IMAO I think off-topic threads on sorting algorithms are the
*least* of our troubles right now.
Off-topic *flamewars* are a problem, but - again IMAO - it's the flaming
that's the problem, not the OT-ness. A thread on radix sorting has little
risk of developing into one of _those_ threads. Now, if the thread
had been veering towards copyright or abandonware or feminism, or even
Harry Potter, I could have understood you...
In case you feel I must defend this position: I think it's the ability
to chat about anything, the gentle topic drift that takes us to explore
all kinds of strange subjects, that helps maintain the sense of community
in groups like this.
Our enemy is the general grumpiness and the tendency to bring out the
flamethrower at the slightest provocation. Trolls, drive-by flamers and
resident flamers are also our enemies.
Topic drift is not the enemy.
DarrenH
Cheers,
D
"Lewis Raszewski" <rras...@hotmail.com> wrote in message
news:3C7451D...@hotmail.com...
> Ferlin Scarborough wrote:
> >
> > Hello All, (Warning Long Winded Post Ahead)
> >
> > A couple of years ago, 1987 or so I believe I purchased a program
called
> > AGT then MAGT to create Text Adventures, the program boasted that a
> > Non-Programmer could create adventures using it.
> >
> > Hugo, Alan, Tads and Inform all seem to get a little technical for a
> > Non-Programmer to use.
> >
> > I have seen another package that boasts at being a Non-Programmer Text
> > Adventure creation tool called Adrift
> >
> > My question(s) is this:
> >
> > Which Authoring System do YOU feel is good for a Non-Programmer to use
to
> > create Text Adventures and Why?
> >
> > What are some of the strong points/weaknesses of this Authoring System?
> >
> > How could it be improved, yet still remain easy for a Non-Programmer?
> >
>
> Here is the fundamental problem.
>
> A non-programmer *cannot* write a good text adventure. You can make the
> syntax as simple as you like, but writing a text adventure is
> *fundamentally* a programming exercise (it is also, lest you think I'm
> leaving it out, fundamentally a writing exercise).
>
> This is not to say that you can't write a good text adventure in a
> programming-lite language; I'm sure you can (in most of them). The
> relationship between bad games and use of a programming-lite language is
> due to other factors:
> - Non-programmers are using them
> - It is so much more difficult to express programming in a
> non-programming languages that anyone who becomes a sufficiently
> competent programmer switches to a "fully powered" language, becuase
> it's *easier* to program in it.
>
> It may perhaps be worthwhile for a non-programmer to begin in one of the
> non-programmer languages, and learn to *program* in the frieldly
> provided environment, then move on to a programming-intensive language
> once they gain sufficient competance, though this may well be
> mis-application of effort.
>
> I submit that if you are capable of writing a good game, you *are* a
> competent programmer. The technical aspects of a language are *as
> nothing* to the difficulty of thinking in a programming-mindset, and the
> latter is essential to write a good game in *any* language.
>
>
> --
> L. Ross Raszewski
> The Johns Hopkins University
> Wyman Park 407
>
> "Nature provides for us a safety net; whatever we do, we can never
> forget." --
> Barenaked Ladies, I Live with it Every Day
David Thornley
30otsix <30o...@tsconnects.com> wrote:
>
>I have read many of posts concerning ADRIFT and it seems to me the
>majority of the problems are on the part of the authors.
This can be equally said of any computer system anywhere for
doing anything. The majority of problems are on the part of the
authors. The exact same thing would be true if you were writing
IF in Visual Basic, Inform, TADS, or x86 assembler.
The difference between two different computer languages is normally
that one will make things easier to do than another, not that they
have different abilities. If ADRIFT games tend to have certain
errors, then obviously it isn't as easy as it should be to avoid
these errors.
>in another language. I am convinced that in the hands of a capable
>author, ADRIFT can produce games like any out there.
>
>It is unfortunate that none of the better writers in this community
>have not done so.
>
There are reasons for this, some inherent and some cultural. People
who are good at IF generally choose their tools in order to write
good IF, and not to provide free demonstration for another tool.
ADRIFT also suffers from being MS Windows-specific, so writing in
ADRIFT rather than TADS or Inform or Hugo would cut down on the
potential audience.
To put this another way, if you want one of the better writers to
write an ADRIFT game, you are going to have to make it worth that
writer's while, somehow or other. These authors generally write
things for reasons that do not include showcasing somebody else's
systems.
By far the most likely way to have a good ADRIFT game written is for
some ADRIFT fan to write one. This is how Hugo became more visible
(with Guilty Bastards).
>And finally, as for needing to be a programmer to write a good game.
>If you mean by programmer, able to understand logic flows and if/then
>statements, then I would agree. If you mean coder;I would not.
>
If you are a programmer in the first sense, then you will learn to
use what tools are available, and will find that learning TADS or
Inform isn't all that difficult. If you find TADS and Inform
incomprehensible after study, then you're unlikely to be a good
enough programmer to write innovative games, and might want to see
if you can collaborate with a good programmer.
Sean T Barrett
>Sean, you're way out of line here. Nobody died and made you the
>moderator.
This is not true. All the participants in the forum
are responsible for policing it; there is nobody else
who will do so. Just because it isn't moderated doesn't
mean it's not supposed to have a charter and attempt to
stick to it. It can be done by email or it can be
done out loud. In this case I'm doing it out loud because
(a) I did it by email on this specific thread and was
ignored and (b) because it gives other posters to the
group, like you, the chance to see that I'm griping about
it and gives you the chance to voice your opinion that
it's a perfectly acceptable thread.
>And IMAO I think off-topic threads on sorting algorithms are the
>*least* of our troubles right now.
I wouldn't have mentioned it if it hadn't (a) seemed of
little interest to most readers and (b) had a reasonable
attempt made to move it to email which was ignored.
>I think it's the ability
>to chat about anything, the gentle topic drift that takes us to explore
>all kinds of strange subjects, that helps maintain the sense of community
>in groups like this.
As I've mentioned previously, it is this trend towards community
away from topicality that has turned much of Usenet from a useful tool
for communicating about specifics into yet another generic Internet chat
forum. There are newsgroups which have essentially entirely abandoned
their topic and are just chatty about nothing specific. (I mean this
literally; all the regulars just chat with each other and the 1%
of people posting on topic are ignored by the regulars, and should
they complain that the regulars are posting off-topic, are flamed
soundly for 'not understanding what the group is all about'.)
>Our enemy is the general grumpiness and the tendency to bring out the
>flamethrower at the slightest provocation. Trolls, drive-by flamers and
>resident flamers are also our enemies.
>
>Topic drift is not the enemy.
I consider both equal long-term dangers. If raif retreats to its
previous volume of posts, I won't be concerned about the off-topic
ones.
This really is the last I have to say on the subject. If others
feel the same they can take their turn policing the newsgroup; if
not, so be it.
SeanB
OKB -- not okblacke
>In article <Gs3DF...@world.std.com>,
>Sean T Barrett <buz...@TheWorld.com> wrote:
>>>Radix sort was the first sort whose name came to be from a family of
>>>sorts based on the principle...
>>
>>You know, this is the exact sort of thread that is basically ENTIRELY
>>IRRELEVANT to IF, and should be taken to email, not just tacked with
>>an "OT".
>
>Sean, you're way out of line here. Nobody died and made you the
>moderator.
I'm not particularly concerned with the issue of what is and isn't on
topic, but I don't see how telling Sean that he's out of line is any less out
of line than his telling someone else that they're out of line. (And no, I'm
not saying either of you is out of line.)
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Magnus Olsson
OKB -- not okblacke <bren...@aol.comRemove> wrote:
>m...@df.lth.se (Magnus Olsson) wrote:
>>In article <Gs3DF...@world.std.com>,
>>Sean T Barrett <buz...@TheWorld.com> wrote:
>>>>Radix sort was the first sort whose name came to be from a family of
>>>>sorts based on the principle...
>>>
>>>You know, this is the exact sort of thread that is basically ENTIRELY
>>>IRRELEVANT to IF, and should be taken to email, not just tacked with
>>>an "OT".
>>
>>Sean, you're way out of line here. Nobody died and made you the
>>moderator.
>
> I'm not particularly concerned with the issue of what is and isn't on
>topic, but I don't see how telling Sean that he's out of line is any less out
>of line than his telling someone else that they're out of line. (And no, I'm
>not saying either of you is out of line.)
And your point was?
I could, of course, have formulated myself a bit more diplomatically;
"I disagree with Sean" or something like that - but that doesn't change
very much.
Sean writes that it's the duty of every group member to police the
group; I think that that way leads to something very undesirable: a
group where nobody dare say anything the least provocative, lest some
self-appointed net.cop slams them. Instead of a moderated group with
one moderator who follows a well-defined moderation policy, we get a
group full of "moderators" who follow their own ideas of what is
appropriate or not.
It is the duty of every group member to keep the group on-topic
and polite by exercising restraint in their own postings, and to
repect the integrity of other posters, *even* if that means
letting the occasional off-topic thread exist.
Besides, a discussion of sorting algorithm is at least partially
on-topic for a group dedicated (partly) to programming. *That* kind
of off-topic discussion has *never* been a problem before; I can't
see why it should be a problem now.
Of course, I may be totally out of line here. Perhaps the consensus is
that the group should not be explicitly moderated, but rather
self-censored by a of, if not net.cops, then at least net.vigilantes.
My experience from other groups where this has been tried is that it
leads to a very oppressed atmosphere, but this may be what is desired,
and, in that case, so be it; I'd probably follow the lead of Adam
Cadre and Emily Short, since I have no desire to take part in a
discussion where you're likely to be reprimanded as soon as you
deviate from someone's notion of what is proper.
Dana Clarke
anything to come out? I sense some severely constricted orifices here
<g>.
Dana
Magnus Olsson
David Thornley <thor...@visi.com> wrote:
>In article <508c727b.02022...@posting.google.com>,
>30otsix <30o...@tsconnects.com> wrote:
>>in another language. I am convinced that in the hands of a capable
>>author, ADRIFT can produce games like any out there.
>>
>>It is unfortunate that none of the better writers in this community
>>have not done so.
>>
>There are reasons for this, some inherent and some cultural. People
>who are good at IF generally choose their tools in order to write
>good IF, and not to provide free demonstration for another tool.
(..)
>To put this another way, if you want one of the better writers to
>write an ADRIFT game, you are going to have to make it worth that
>writer's while, somehow or other. These authors generally write
>things for reasons that do not include showcasing somebody else's
>systems.
I'm not sure that I can or should consider myself "one of the better
writers" (at least not considering the abundance of extraordinary
talent we've seen the last few years), but let me comment anyway:
For a new game, I would only choose a new system over Inform or TADS
if
a) I was convinced that I could do everything in the new system that I
could do in the old one, and at least as easily
and
b) the new system offered some big advantage over the old one (note
that that advantage could simply be fun, or what is known as "hack
value" - that's why I learned Inform, after all).
Yes, those are egotistical reasons. But I feel that writing a
decently-sized piece of IF is so much work that I can't be persuaded
to do so just to showcase somebody else's system. Sorry.
Magnus Olsson
>Sean writes that it's the duty of every group member to police the
>group; I think that that way leads to something very undesirable: a
>group where nobody dare say anything the least provocative, lest some
>self-appointed net.cop slams them. Instead of a moderated group with
>one moderator who follows a well-defined moderation policy, we get a
>group full of "moderators" who follow their own ideas of what is
>appropriate or not.
There's (at least) one exception to this: if a newbie blunders in with
a post that's obviously to the wrong group (such as a programming
question on rec.games.int-fiction), I think it's OK to point this out;
this is more helping the newbie than policing the group, though.
Peter Seebach
Sean T Barrett <buz...@TheWorld.com> wrote:
>>Sean, you're way out of line here. Nobody died and made you the
>>moderator.
>This is not true.
Well, it's literally true, to the best of my knowledge, that nobody died and
made you the moderator.
>All the participants in the forum
>are responsible for policing it; there is nobody else
>who will do so.
Exactly! And I, for one, appreciate the intent.
>As I've mentioned previously, it is this trend towards community
>away from topicality that has turned much of Usenet from a useful tool
>for communicating about specifics into yet another generic Internet chat
>forum.
This is somewhat true, although I think that the sorting thread wasn't one
of the most off-topic. Still, you're right; it *was* off-topic, and it's not
as though there's a shortage of general purpose programming groups.
-s
--
Copyright 2002, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
Lucian P. Smith
: To put this another way, if you want one of the better writers to
: write an ADRIFT game, you are going to have to make it worth that
: writer's while, somehow or other. These authors generally write
: things for reasons that do not include showcasing somebody else's
: systems.
I actually disagree with this. Nobody should expect that a writer of any
caliber is going to change authoring systems. Once an author gets
comfortable with TADS or Inform, you rarely see them jump ship to the
other (not that it doesn't happen).
Instead, what a system needs to do is *culture* great writers. This means
both a) attracting the right type of person from the get-go, and b) making
sure they stay. Attracting people to a system usually means writing a
great game in that system that makes people say "I want to write a game
like that." Making sure they stay involves giving them the tools they
need along the way as they progress as an author.
Barring that, you could always pay someone to write a game in your system
to advertise it ;-)
-Lucian
Magnus Olsson
Dana Clarke <joey...@bellsouth.net> wrote:
>Jeez, are you folks actually able to sit on the toilet and get
>anything to come out? I sense some severely constricted orifices here
><g>.
>
>Dana
>
>
>On 25 Feb 2002 20:21:24 GMT, m...@df.lth.se (Magnus Olsson) wrote:
OK, that oes it.
Goodbye. It's been nice talking to you.
Keep "policing" your newsgroup as you see fit.
David Thornley
Lucian P. Smith <lps...@rice.edu> wrote:
>David Thornley <thor...@visi.com> wrote in <z5we8.3527$N7.9...@ruti.visi.com>:
>
>: To put this another way, if you want one of the better writers to
>: write an ADRIFT game, you are going to have to make it worth that
>: writer's while, somehow or other. These authors generally write
>: things for reasons that do not include showcasing somebody else's
>: systems.
>
>I actually disagree with this. Nobody should expect that a writer of any
>caliber is going to change authoring systems. Once an author gets
>comfortable with TADS or Inform, you rarely see them jump ship to the
>other (not that it doesn't happen).
>
(OK, let's translate that: I agree with what you said, and if you
thought I didn't you misunderstood me, and if you misunderstood
me it was probably my fault.) My point is that people select
authoring systems for their own reasons, familiarity being a biggie,
and that they're probably not going to use a new system for the
sake of showcasing it. (In the case of Adrift, this also means
cutting into the potential audience, since some people do not
play games on MS Windows. I suspect that most authors would prefer
their work to reach as many people as possible.)
>Instead, what a system needs to do is *culture* great writers. This means
>both a) attracting the right type of person from the get-go, and b) making
>sure they stay. Attracting people to a system usually means writing a
>great game in that system that makes people say "I want to write a game
>like that." Making sure they stay involves giving them the tools they
>need along the way as they progress as an author.
>
Yup. If this doesn't happen, it means that (a) the system doesn't
support the development of good IF writers, or (b) it was unlucky.
TADS was neat because it was better than everything else I could find
at the time. Inform was neat because it compiled to zcode and had
produced Curses. Hugo has become neat mostly because of Guilty
Bastards. There are doubtless systems that are as good that didn't
make it because they came later and nobody wrote a really good game
in them.
>Barring that, you could always pay someone to write a game in your system
>to advertise it ;-)
>
Yup. Figure $10,000 on up, I'd say. (That's 200 hours of work at the
minimum price I'd consider charging, if I were in the market.) *Never*
underestimate the value of what we receive for free by the likes of
Andrew Plotkin, Mike Roberts, Kent Tessman, Emily Short, and many,
many others.
OKB -- not okblacke
>Sean writes that it's the duty of every group member to police the
>group; I think that that way leads to something very undesirable: a
>group where nobody dare say anything the least provocative, lest some
>self-appointed net.cop slams them.
Since it appears Magnus has once again left us, this is moot as it regards
him, but just for the record: I was not suggesting that newsgroup policing is
what I want. I was trying to point out that Magnus was just as much policing
Sean as Sean was policing the radix sort posters.
I feel that every time someone leaves the group, that's a loss for all of
us, and I'm sorry that Magnus has gone.
wo...@one.net
Hi Magnus,
>My experience from other groups where this has been tried is that it
>leads to a very oppressed atmosphere, but this may be what is desired,
>and, in that case, so be it; I'd probably follow the lead of Adam
>Cadre and Emily Short, since I have no desire to take part in a
>discussion where you're likely to be reprimanded as soon as you
>deviate from someone's notion of what is proper.
Then again, you could just ignore the over-zelous... :) You've always
been a moderate voice and I for one would hate to lose your insights.
Nothing is better for controlling would-be moderators/vigilantes/net
cops than being ignored. After all, they have no real power. I think
we forget that here nobody can bully us unless we allow it.
As for the radix-sort thread you could argue it had value. I even
found value in the discussion about temperature scales! :)
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
Magnus Olsson
>In article <te8l7usr46q61ve64...@4ax.com>,
>Dana Clarke <joey...@bellsouth.net> wrote:
>>Jeez, are you folks actually able to sit on the toilet and get
>>anything to come out? I sense some severely constricted orifices here
>><g>.
>
>
>Goodbye. It's been nice talking to you.
Since this looks a lot like a temper tantrum, stomping off
in a huff because somebody used toilet humour, perhaps I should
just explain that this isn't really the case. And I don't really
feel driven off by any particular poster.
It's just that it's simpliy not very rewarding to post here when every
thread has the potential to turn into a flamewar, and when, in
addition, people have started "policing" the group to suppress
off-topic discussion. The occasional drive-by flamer or resident
loonie doesn't help either.
Historically, the IF community has been like a large family.
Right now, the family seems rather dysfunctional.
And I'm not doing this to make a point or anything - I've left a
couple of times before, though for quite different reasons, so I don't
really have any credibility left to make a point this way anymore.
I'll continue to check the group for announcements and for the
interesting discussions that do remain, but I'll refrain from posting
for a while.
Michael Iachini
> I'll continue to check the group for announcements and for the
> interesting discussions that do remain, but I'll refrain from posting
> for a while.
That's a bit of a relief. I'm a relative newbie to raif -- I've only
been around since November or December -- but I've become a regular
reader and occasional poster. I've seen Magnus's name on a lot of
well-written posts, and I'd miss that voice if it left the community
for good. But hey, we all need a break from time to time; I can
respect that.
Michael Iachini
30otsix
> 30otsix <30o...@tsconnects.com> wrote:
>
> > I would like to point out that both of these issues are a fault of the
> > game author. ADRIFT allows the author to designate their own default
> > messages. The fact that you received a default message at all is also
> > the fault of the author and could have been avoided with a simple "*"
> > (wildcard).
>
> > reason is that the learning curve is so low that anyone (and I do mean
> > anyone) can create a game within a matter of hours.
> You can't evaluate an IF development system without evaluating how it
> handles "easy" cases. If the defaults are bad by default, well,
> they're bad. They should be fixed.
>
> When I created my first one-room-one-object Inform game, which was
> about twenty lines of code (mostly copied out of the DM), it was a
> pretty good room and a pretty good object. Boring, with a one-line
> description for each, but not *bad*. The defaults out of the box were
> solid.
>
> I could then spend my time *improving* the room and the object,
> instead of trying to sort through the system making my starting point
> acceptable.
>
> TADS games have equally solid responses to the standard IF interaction
> range.)
>
> --Z
I agree that the standard of *Nothing special.* is a poor choice for a
default message. My point was that it is unfortunate that the authors
involved didn't change it when the system ADRIFT asks the author to
define the default (among other things) whenever he or she gives their
game a title:
Line one: Game Title
Line two: Game Author
Line three: Default message
It amazes me that the authors will always name their game and give
themselves credit but fail to take the time to hit the tab button and
type *I do not understand what you mean.* or some such verbiage. If
this is not completed the *nothing special* default is used. This is
just plain lazy. Something as easy to fix as this should have been
discovered and fixed during beta testing. This to me is an *easy*
case.
-30otsix
30otsix
> You insist that the flaws in adrift games result from the fact that poor
> authors are using it. Perhaps you should contemplate why this is the
> case.
>
> As the saying goes, If you build a system that any idiot can use, any
> idiot will.
I agree with you 100 percent. That is why I stated in my original
post *Just because you can make a game doesn't mean you should.* It
is true that the Adrift games available are of very low quality,
unfortunately this probably means that when (not if) a gem is finally
produced it will be lost among the piles of coal.
30otsix
Campbell
> these is that the default error messages pretend to understand things
> that they do not. This may not sound like a serious problem, but it is.
> For example, in one recent game, many players missed a vital clue because
> they tried to "examine robot" rather than "examine robot guard"; the
> response "Nothing special." gave no indication that the command they had
> entered was not successfully interpreted.
The "Nothing special" comment for examining all objects without a
description has been fixed in version 4, due out very soon.
Kevin Forchione
> On Sat, 23 Feb 2002 19:31:53 GMT, stev_...@actrix.gen.nz (SteveG)
> wrote:
>
> >This is a common characteristic of the 'easy' IF authoring system and
> >the reason why many people here suggest that beginners start learning
> >with one of the big-three fully-capable languages. This may be good
> >advice for some beginners. A possible drawback though is that some
> >beginners may be so overwhelmed that they never reach the point where
> >they benefit from the programming flexibility of those systems.
> >
> This is true. Judging from discussions here I think that some folks
> underestimate just how ignorant some others (like me) can be when it
> comes to programming. I realize there are those who have said they
> started totally cold, with no knowledge at all or programming, and are
> happily writing away in Inform or TADS -- and my hat's off to them (or
> would be if I wore a hat - >take off hat, > remove hat, >doff hat etc
> etc --but Isuspect not everyone will take to programming quite so
> readily.
Interestingly, part of the criteria for enrollment in the computer
training I underwent some 14+ years ago involved aptitude testing. The
idea was that not everyone had the aptitude to become a computer
programmer. This idea seems to have been swept under the rug in
today's digital age, yet few people would dismiss this argument in the
case of a mathematician or engineer.
An author of IF has to possess writing skills, first and foremost,
because this is the medium of expression, but they must be able to
work within the framework of an interactive simulation. The more
control one wants in the crafting of the story, the more one needs to
understand programming fundamentals.
Systems differ in the levels of conceptual sophistication of the
parser, model world, and command execution process, as well as the
presentation level.
Languages differ in the manner and degree in which they facilitate the
implemention of abstract datatypes and in the level of support they
provide an author regarding the inspection and manipulation of these
datatypes.
--Kevin
Kevin Forchione
> On Sun, 24 Feb 2002 16:55:15 -0500, Lewis Raszewski
> <rras...@hotmail.com> wrote:
>
> >
> >You insist that the flaws in adrift games result from the fact that poor
> >authors are using it. Perhaps you should contemplate why this is the
> >case.
> >
> >As the saying goes, If you build a system that any idiot can use, any
> >idiot will.
> >
>
> to do programming, the ability to program, or even the ability to
> think in programming terms, isn't the only measure of intelligence,
> or, conversely, idiocy. :)
It is, however, essential to writing a computer program, which is what
a work of Interactive Fiction is. No matter how we might disguise it
by calling it a story or a game, it is nothing more than a collection
of instructions that the computer processes sequentially. Therefore,
the successful construction of an Interactive Fiction *requires* one
to think programmatically. The more one deviates from the custom-built
library, the more these skills will be called into play.
The process need not be foreign. If you simply list the steps required
to rise from your desk and answer the doorbell you are thinking
programmatically. Coding in a specific language is not the critical
issue here, but the ability to break apart processes into a series of
steps is the essential beginning.
Intelligence probably doesn't correlate highly in programmatic
thinking. Less than a handful of logical structures, methodically
applied, can be used to break down any complex process into a series
of sequentially processed statements that the computer can then
execute. Aptitude helps, certainly, much as it does in accounting or
mathematics or music, but the consistent application of principles
will allow any tenacious author to produce a game/story. Whether that
game/story is a brilliant gem or merely mediocre is the art of the
craft.
--Kevin
Kevin Forchione
> On Sun, 24 Feb 2002 20:09:25 -0500, ne...@davidglasser.net (David
> Glasser) wrote:
>
> In fact, in many cases (speaking again for novices such as myself) the
> major problem is not even knowing the question! Further, most manuals
> (I will include the HUGO and TADS manuals in this group) use technical
> lingo (jargon, whatever) that communicates absolutely wonderfully to
> someone proficient in that programming environment and successfully
> communicates virtually nothing to someone who is not. Again, if you
> know it already the manual helps a great deal - if you don't then you
> won't.
Of course. But then most applications have tutorials that provide a
basic foundation from which to build. TADS has tutorials available
that provide a basic understanding of language features and game
construction.
There is also the community, a pool of experience, that can be tapped.
--Kevin
Plugh!
[snip]
> My next inquiry was as to How these systems could be improved, yet still
> remain a good Authoring System for a Beginner to start learning with.
Well, rather than demand/expect/hope that the author/owner of each
system implement it, I took the way of providing an add on tool to do
so (see http://plugh.cjb.net, I'm just putting the finishing touches
to it at the moment).
The beginner can use a GUI to define all of his rooms and connect them
to make a map, then add items and NCPs and have the TADS code
generated (Inform too in a later version).
What is produced, however, is rather boring. A series of
interconnected rooms, containing items & NCPs for which the beginning
author must provide textual descriptions, free of puzzles and
interactions, beyond the default, with items & NCPs as these must be
programmed.
Programming just can't be avoided. I can simplify things but, as has
been stated here, some coding must be done, or you don't have any i-f
(fortunately, my system gives you 100% control over code, so the
system is just as usable by an advanced author).
I do think that we should be looking at add-ons, front-ends, etc, but
am not sure how these can be used to help the beginner.
Pissing Bandit
>In article <Gs3DF...@world.std.com>,
>Sean T Barrett <buz...@TheWorld.com> wrote:
>>You know, this is the exact sort of thread that is basically ENTIRELY
>>IRRELEVANT to IF, and should be taken to email, not just tacked with
>>an "OT".
>Sean, you're way out of line here. Nobody died and made you the
>moderator.
*ahem*
You, Sirrah, are Beginning To Encroach Upon My Territory.
>Our enemy is the general grumpiness and the tendency to bring out the
>flamethrower at the slightest provocation. Trolls, drive-by flamers and
>resident flamers are also our enemies.
Hear, hear.
Lest there Be any Confusion on this Point: I am, Even As We Speak,
Quaffing Anheuser-Busch Product (Straight From the Clydesdales, As It
Were), preparatory to Unleashing a Torrent of Peevishness.
Yrs.,
The Pissing Bandit