IF Should Not Be Spaghetti Code
Mike Smith
***In the interest of protecting my email address from being scanned and
put on a Yellow Pages CDROM, please remove SPAM and click here
(mailto://shortc...@ntwrks.com) or use this newsgroup to reply.***
There is no need for IF to be spaghetti code like it has been with its
series of nested goto, if/then, or select/case type statements. IF
developers should shoot for realistic and dynamic designs, yet strive for
object-oriented, tight code.
Here's some techniques I'm using in my latest IF project. If you have an
additional one, please do tell.
1. Instead of coding the program logic into an application with hard to
follow code, my project consists of a script document of a world with all
its rooms laid out in an *.INI fashion. The world files contain Name, Time,
Description, Routes, Stationary Objects, Removable Objects, Creatures,
Acceptable Commands and their Effects, and Acceptable Triggers and their
Effects.
2. The properties of my character (the "you" in the game) are stored in
another *.INI file. This has a default set of values, but gets updated as
the game goes along and gets reset upon starting the game.
3. My parser is very simple. Instead of using explicit tree language
parsing like you commonly see, I use implicit tree language parsing. My
parser strips the phrase down into 2-3 words before allowing to be
processed. Next, I take the verb and either look for a direct match or a
match from a word in a mini-thesaurus I wrote. If this passes, then I
branch to looking for an object match and then I give an effect for that
action if I want one. I also use a small core set of commonly acceptable
verbs. The thesaurus file I wrote translates this to one of 15 verbs if
possible.
4. Avoid globals for properties because these can become hard to follow and
debug. Instead, use objects, collections, and local variables.
5. Use objects and collections, and routinely write these objects to an INI
file so that you can copy it as another name very quickly when one wants to
do a save operation.
Mike McKee
Steven Howard
In <01bd3469$8f33f7c0$074c9ac0@station>, on 02/08/98
>There is no need for IF to be spaghetti code like it has been with its
>series of nested goto, if/then, or select/case type statements. IF
>developers should shoot for realistic and dynamic designs, yet strive for
>object-oriented, tight code.
I've been a COBOL programmer for ten years. Trust me, you don't know what
spaghetti code is. Oh, and you can't actually nest GOTOs.
>Here's some techniques I'm using in my latest IF project. If you have an
>additional one, please do tell.
>1. Instead of coding the program logic into an application with hard to
>follow code, my project consists of a script document of a world with all
>its rooms laid out in an *.INI fashion. The world files contain Name,
>Time, Description, Routes, Stationary Objects, Removable Objects,
>Creatures, Acceptable Commands and their Effects, and Acceptable Triggers
>and their Effects.
Yuck. Icky. Blah. Why not code the program logic into an
application with easy to follow code? Having this forest of
.INI files hanging around is just begging for trouble. You'll notice that
current Windows programming style is to avoid the use of .INI files.
>2. The properties of my character (the "you" in the game) are stored in
>another *.INI file. This has a default set of values, but gets updated as
>the game goes along and gets reset upon starting the game.
So why not store in in memory? The only reason to keep it in an external
file is if you DON'T want to reset it upon starting the program.
>3. My parser is very simple. Instead of using explicit tree language
>parsing like you commonly see, I use implicit tree language parsing. My
>parser strips the phrase down into 2-3 words before allowing to be
>processed. Next, I take the verb and either look for a direct match or a
>match from a word in a mini-thesaurus I wrote. If this passes, then I
>branch to looking for an object match and then I give an effect for that
>action if I want one. I also use a small core set of commonly acceptable
>verbs. The thesaurus file I wrote translates this to one of 15 verbs if
>possible.
Somebody who knows parsing theory better than I do can take a look at this
and say if it's any different from what TADS and Inform do.
>4. Avoid globals for properties because these can become hard to follow
>and debug. Instead, use objects, collections, and local variables.
Standard OO procedure, it seems to me.
>5. Use
>objects and collections, and routinely write these objects to an INI file
>so that you can copy it as another name very quickly when one wants to do
>a save operation.
Yeesh, what's with the .INI fetish? .INI files are supposed to store the
INItial state of a program. The program should read its .INI file once,
at startup time, to get the default values for user preferences and things
like that. .INI files are not meant to be a substitute for RAM. And what
makes you think saving the current game state to one file and then copying
it to another file is faster than just saving the current game state to a
file?
========
Steven Howard
bl...@ibm.net
"Are you a COBOL programmer?" "No, but people tell me I look like one."
David Glasser
Mike Smith <sup...@remedy.com> wrote:
> ***In the interest of protecting my email address from being scanned and
> put on a Yellow Pages CDROM, please remove SPAM and click here
> (mailto://shortc...@ntwrks.com) or use this newsgroup to reply.***
>
> 1. Instead of coding the program logic into an application with hard to
> follow code, my project consists of a script document of a world with all
> its rooms laid out in an *.INI fashion. The world files contain Name, Time,
> Description, Routes, Stationary Objects, Removable Objects, Creatures,
> Acceptable Commands and their Effects, and Acceptable Triggers and their
> Effects.
OK, call me a MacAddict, but what the **ll is a *.INI file?
--David Glasser
gla...@NOSPAMuscom.com
Stephen Griffiths
"Mike Smith" <sup...@remedy.com> wrote:
>1. Instead of coding the program logic into an application with hard to
>follow code, my project consists of a script document of a world with all
>its rooms laid out in an *.INI fashion. The world files contain Name, Time,
>Description, Routes, Stationary Objects, Removable Objects, Creatures,
>Acceptable Commands and their Effects, and Acceptable Triggers and their
>Effects.
This descriptive rather than 'computer programming language' way of
defining an i.f. world reminds me of the way AGT (The Adventure Game
Toolkit) works.
It is certainly a workable alternative that may be more immediately
understood by i.f. authors without a traditional programming
background.
No matter what technique is used, the i.f. author is going to have to
think _really_ hard about how to get the computer to do what the
author wants it do - and that's 'programming' in anybody's language!
(Um. I know what you're thinking and no, there isn't really any point
to this post but seeing as I've written this much, I'm going to click
'send' anyway. :-)
--
SteveG.
(Please remove the typo from my address
if you want to send me mail.)
Mike Smith
> >1. Instead of coding the program logic into an application with hard to
> >follow code, my project consists of a script document of a world with
all
> >its rooms laid out in an *.INI fashion. The world files contain Name,
> >Time, Description, Routes, Stationary Objects, Removable Objects,
> >Creatures, Acceptable Commands and their Effects, and Acceptable
Triggers
> >and their Effects.
>
> application with easy to follow code? Having this forest of
> .INI files hanging around is just begging for trouble. You'll notice
that
> current Windows programming style is to avoid the use of .INI files.
> Steven Howard
> bl...@ibm.net
> "Are you a COBOL programmer?" "No, but people tell me I look like one."
Steven,
There are two ways to look at INI files. One is that they are an ilk that
should go away ever since the registry of Win 95/NT 4. If it is used for
program settings, then yes, I think that would be very good to use the
registry. However, I found that I needed a database file for my programs
that could be written/read from quickly. Often times, these database file
programs require many other supporting libraries and are hard to interact
with. I thought to myself one day, since the INI file size limitation went
away in NT 4 and Win 95, why not use INI file APIs, which are much more
simpler than writing to/from a database and are actually quite fast. Plus,
no support libraries are necessary. I found this to be acceptable, and so I
use INI files as scripts or databases too. I also rename the extension to
something else, like *.WORLD or *.CHAR. Yes, I would like to use something
else besides INI files, but in the Win 32 platform, ANSI Unix-like database
APIs are not a common part of it as of yet in Visual Basic, which I use for
reading/writing my world and character script files.
Mike McKee
Darin Johnson
stephen....@moc.govt.typo.nz (Stephen Griffiths) writes:
> No matter what technique is used, the i.f. author is going to have to
> think _really_ hard about how to get the computer to do what the
> author wants it do - and that's 'programming' in anybody's language!
This is very true. And this is one reason I feel that simplifying an
IF programming language can be a drawback. If all you can do in an IF
system is what the designers thought of, the games written with it can
end up looking very similar.
But with a real programming language underneath, you can start adding
"special effects". You can have rooms that don't quite work like
normal rooms (ie, moving automobiles), smarter NPC's, change the way
inventory is printed, even add combat. When you have a solid
underpinning, nothing gets in the way of your imagination!
Of course, not everyone is a programmer. For non-programmers that
absolutely must write some IF, then most systems *do* provide an easy
to use base. Even TADS and Inform are not difficult for
non-programmers to use, but they also won't restrict you when you want
to start doing some magic.
I look at non-programmers trying to write an IF game as
non-programmers trying to write a good sequel to Doom; that is, if you
really want to do it right, you're going to *have* to learn the
programming no matter how much you fight against it. Not doing the
programming would be like trying to write good IF when you can't write
good prose.
--
Darin Johnson
da...@usa.net.removethis
Mike Smith
Hello, I am Mike McKee out of Raleigh, NC, USA. (an aside--I use Mike Smith
as my alias to foil direct marketing systems.)
I need to temper my original post for this thread. I am the creator of this
thread. I think I disagree with a few of the ideas that I posted in the
initial start of this thread. Thank you, folks, for pointing out my rather
myopic vision on how I wished to solve the spaghetti code problem. I wish
to thank those folks personally. They say they are:
Ian Finley
Steven Howard
Gene Tang
Russell Mirabelli
They have opened my eyes to understanding a world of diversity, and, heh,
man, I think that's cool. I jive. I grok. I comprehend. Peace to all. I
will work on my tone. I will keep my eyes open for when I mention something
that may be platform-specific. I think it shameful now that I even
mentioned VB. I love the language--I develop with it at my job, I think it
has evolved, it is powerful enough for me to make a lot of money with it.
However, it was foolish for me to propose that using VB to solve the
spaghetti code problem of IF is the answer. I have since thought of better
ways.
However, I want to say that I will be around here for awhile. I like your
ideas. I like when people "set me straight" when they think I have been
blinded by a lack of diversity. I don't want you to stop when you feel what
you have to say is right. I thank you for your patience--I am a "newbie"
here in this newsgroup.
However, it is my opinion that the world could benefit from an IF standard
similar to FTP, HTML, etc., but be much more cleaner and easier, and not
use 70's like tags like <BR> and <FORM>. And this standard could solve what
I sense is a spaghetti code problem when writing IF. We could then submit
this standard to IETF and get it approved, then when it's in the public
domain, the world could adhere to it and it would explode just as hypertext
grew out of being a proprietary thing into a world wide thing called WWW.
If you are truly worried about IF diminishing into a shrinking audience,
you might consider a standard. Instead of requiring authors to be
developers, or having to partner with developers, they could merely be
authors and could follow this standard similar to one typing in essay
answers to sections of a questionnaire. We could have multi-platform player
programs of this standard definition format, and the players could be
inside a web browser like a downloadable plug-in, or could be a single
executable with the definition format file stored like a resource inside
it, or could be an application separate from the definition format file. It
could integrate sound, or have sound turned off, or allow it as an option
(of course). However, I think most of the people I read from in RAIF speak
of nothing but text adventures, not graphical IF, so the standard I propose
would not support graphics.
Mike McKee
Peace to All
Mike Smith
Yes. Actually, INI files are a bad idea. Forget I mentioned it. I use INI
files like one would use a database for storing information about rooms,
objects, characters, scenes, conditions, etc. If I found a database format
that didn't require support files on the Win32 platform, I suppose I would
use that instead of INI files.
David Glasser <gla...@NOSPAMuscom.com> wrote in article
<1d44zeq.oh...@usol-phl-pa-070.uscom.com>...
> Mike Smith <sup...@remedy.com> wrote:
>
> > ***In the interest of protecting my email address from being scanned
and
> > put on a Yellow Pages CDROM, please remove SPAM and click here
> > (mailto://shortc...@ntwrks.com) or use this newsgroup to reply.***
> >
> > 1. Instead of coding the program logic into an application with hard to
> > follow code, my project consists of a script document of a world with
all
> > its rooms laid out in an *.INI fashion. The world files contain Name,
Time,
> > Description, Routes, Stationary Objects, Removable Objects, Creatures,
> > Acceptable Commands and their Effects, and Acceptable Triggers and
their
> > Effects.
>
Mike Smith
I think I have an idea to the spaghetti code problem that could be not
platform specific, non-proprietary, and no one person dying could bring it
down. (I think if the author of Inform decided to stop making Inform for
some reason, one would realize that's not a non-proprietary platform after
all.) Plus, it would work over the Internet or alone, disconnected. It
could work in systems as small as a PDA. It would support not too many
features beyond a text adventure, but perhaps optional music or room sounds
would be a nice touch.
Watch the newsgroup soon for a post with the tag [Proposal].
Stay tuned, and watch out for grues.
Mike McKee
Kenneth Fair
In article <1d44zeq.oh...@usol-phl-pa-070.uscom.com>,
gla...@NOSPAMuscom.com (David Glasser) wrote:
>OK, call me a MacAddict, but what the **ll is a *.INI file?
Roughly (very roughly!) the equivalent of a preference file on the Mac.
Except they don't have their own special little folder.
--
KEN FAIR - U. Chicago Law | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?
"Any smoothly functioning technology will be
indistinguishable from a rigged demo." Isaac Asimov
Brock Kevin Nambo
Mike Smith wrote in message <01bd351a$9b9818a0$0f4c9ac0@station>...
>(I think if the author of Inform decided to stop making Inform for
>some reason, one would realize that's not a non-proprietary platform after
>all.)
The Z-machine was born as a proprietary platform. Infocom invented it and
sold their famous text adventures for it. But I'm sure we know enough about
it now that some programming wizard could recreate or continue the Inform
format after Graham.. After all, there is published already a Zmachine
standards document, and an Inform designer's manual, detailing the machine's
format and the language's format, respectively.
>>BKNambo
--
http://come.to/brocks.place
Allen Garvin
In article <01bd3469$8f33f7c0$074c9ac0@station>,
Mike Smith <sup...@remedy.com> wrote:
***In the interest of protecting my email address from being scanned
and put on a Yellow Pages CDROM, please remove SPAM and click here
(mailto://shortc...@ntwrks.com) or use this newsgroup to reply.***
I've been using USENET since 1987, and have posted thousands of messages
over the years without ever disguising my address, and I get no more than
2 or 3 "spam" advertisements by email a week.
There is no need for IF to be spaghetti code like it has been with
its series of nested goto, if/then, or select/case type statements. IF
developers should shoot for realistic and dynamic designs, yet strive
for object-oriented, tight code.
What does it matter? Tight, well-written, elegant code is important when
working as part of a project with many programmers, or writing something
that other people will use and update over the years. Most IF authors
write a game, drop it off at the IF archive and except for a few bug fixes
rarely touch it again. Most in fact never distribute their code, so it
doesn't matter a bit how ugly the code is.
1. Instead of coding the program logic into an application with
hard to follow code, my project consists of a script document of
a world with all its rooms laid out in an *.INI fashion. The world
files contain Name, Time, Description, Routes, Stationary Objects,
Removable Objects, Creatures, Acceptable Commands and their Effects,
and Acceptable Triggers and their Effects.
Blah! There's no way this can provide for everything. If you want to
do something different or something sophisticated, there has to be some
mechanism in place for laying out straight code. Can you really imagine
something that like "So Far" could have been written in a language designed
solely like this?
2. The properties of my character (the "you" in the game) are stored
in another *.INI file. This has a default set of values, but gets
updated as the game goes along and gets reset upon starting the game.
I know you repudiated this in a later post, so I won't comment on it.
3. My parser is very simple. Instead of using explicit tree language
parsing like you commonly see, I use implicit tree language
parsing. My parser strips the phrase down into 2-3 words before
allowing to be processed. Next, I take the verb and either look for a
direct match or a match from a word in a mini-thesaurus I wrote. If
this passes, then I branch to looking for an object match and then
I give an effect for that action if I want one. I also use a small
core set of commonly acceptable verbs. The thesaurus file I wrote
translates this to one of 15 verbs if possible.
When it can parse text and handle disambiguation as well as Inform, I'd
like to see how simple it is then.
4. Avoid globals for properties because these can become hard to
follow and debug. Instead, use objects, collections, and local
variables.
They're so just so darned useful! Unless I'm forced to avoid them (like
in Smalltalk), I find many places where they're indispensible for clarity
or ease.
5. Use objects and collections, and routinely write these objects
to an INI file so that you can copy it as another name very quickly
when one wants to do a save operation.
Same reply as to 2.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Den of Iniquity
On Sun, 8 Feb 1998, Steven Howard wrote:
> at 07:59 AM, "Mike Smith" <sup...@remedy.com> said:
>
>>There is no need for IF to be spaghetti code
>
>I've been a COBOL programmer for ten years. Trust me, you don't know what
>spaghetti code is.
I've been programming in PASTA for twelve years and.... no, no, I can't
bring myself to do it. (Darn, think I did already.)
On an almost _completely_ unrelated note I thought people might be
interested in the following: I read in New Scientist recently that the
folks at MIT had been helping Lego to create new 'programmable' bricks.
So - how long before we see Dungeon ported to Lego?
--
Den
Gareth Rees
Mike McKee <shor...@ntwrks.com> wrote:
> There is no need for IF to be spaghetti code like it has been with its
> series of nested goto, if/then, or select/case type statements.
Is this "structured programming gone mad" or what? If you outlaw goto,
if/then and select/case statements, how do you express flow of control?
Should one implement all flow-of-control using method dispatch and
continuation passing, something like this?
function if-then-else(p, t, f, c) {
p.t = t;
p.f = f;
c(p.branch()); /* The lambda way is the only way! */
}
--
Gareth Rees
Neil Brown
At 15:58:48 on Mon, 9 Feb 1998, Allen Garvin wrote:
>In article <01bd3469$8f33f7c0$074c9ac0@station>,
>Mike Smith <sup...@remedy.com> wrote:
> ***In the interest of protecting my email address from being scanned
> and put on a Yellow Pages CDROM, please remove SPAM and click here
> (mailto://shortc...@ntwrks.com) or use this newsgroup to reply.***
>
>I've been using USENET since 1987, and have posted thousands of messages
>over the years without ever disguising my address, and I get no more than
>2 or 3 "spam" advertisements by email a week.
You're exceptionally lucky then. Ever since I started disguising my
email address, my spam levels have dropped by a half. Even so, that
still makes three or four emails a week. Grrrrr.
> There is no need for IF to be spaghetti code like it has been with
> its series of nested goto, if/then, or select/case type statements. IF
> developers should shoot for realistic and dynamic designs, yet strive
> for object-oriented, tight code.
>
>What does it matter? Tight, well-written, elegant code is important when
>working as part of a project with many programmers, or writing something
>that other people will use and update over the years. Most IF authors
>write a game, drop it off at the IF archive and except for a few bug fixes
>rarely touch it again. Most in fact never distribute their code, so it
>doesn't matter a bit how ugly the code is.
I agree. And it is not as if speed is an issue in most cases, although
messy code makes debugging a serious problem. (Erm, as opposed to a
funny one, I suppose.)
- NJB
Neil Brown
At 05:06:35 on Mon, 9 Feb 1998, Mike Smith wrote:
>I think I have an idea to the spaghetti code problem that could be not
>platform specific, non-proprietary, and no one person dying could bring it
>some reason, one would realize that's not a non-proprietary platform after
>could work in systems as small as a PDA. It would support not too many
>features beyond a text adventure, but perhaps optional music or room sounds
>would be a nice touch.
>
>Watch the newsgroup soon for a post with the tag [Proposal].
Aha, but would it work on my 2Mb Acorn? (Or for that matter, my 32k BBC?
I suppose it would be pushing it to mention my ZX81 at this point, so I
won't.) Generally, systems that are designed to work with all possible
platforms eat up huge amounts of memory and only work on high-end
machines. Look at web browsers.
- NJB
Trevor Barrie
In article <01bd351a$9b9818a0$0f4c9ac0@station>,
Mike Smith <sup...@remedy.com> wrote:
>I think I have an idea to the spaghetti code problem that could be not
>platform specific, non-proprietary, and no one person dying could bring it
>down. (I think if the author of Inform decided to stop making Inform for
>some reason, one would realize that's not a non-proprietary platform after
>all.)
Huh? I could shoot Graham Nelson stone-cold dead right now, and it wouldn't
stop anybody from creating new Inform games. It might mean there wouldn't
be any new versions of Inform, but then, I don't know if he was planning on
producing new versions anyway.
Trevor Barrie
In article <01bd3469$8f33f7c0$074c9ac0@station>,
Mike Smith <sup...@remedy.com> wrote:
>There is no need for IF to be spaghetti code like it has been with its
>series of nested goto, if/then, or select/case type statements.
Nested goto? Do the major IF languages even have gotos? (Probably they do,
but I doubt anybody uses them.) OTOH, structures like if/then and
select/case are the very opposite of "spaghetti code".
>3. My parser is very simple. Instead of using explicit tree language
>parsing like you commonly see, I use implicit tree language parsing. My
>parser strips the phrase down into 2-3 words before allowing to be
>processed. Next, I take the verb and either look for a direct match or a
>match from a word in a mini-thesaurus I wrote. If this passes, then I
>branch to looking for an object match and then I give an effect for that
>action if I want one. I also use a small core set of commonly acceptable
>verbs. The thesaurus file I wrote translates this to one of 15 verbs if
>possible.
It sounds like your parser only allows for two-word commands, without
allowing for prepositions and indirect objects... if so, it won't fly
with the '90's text adventure audience.
Jeff Hatch
Allen Garvin wrote:
> What does it matter? Tight, well-written, elegant code is important when
> working as part of a project with many programmers, or writing something
> that other people will use and update over the years. Most IF authors
> write a game, drop it off at the IF archive and except for a few bug fixes
> rarely touch it again. Most in fact never distribute their code, so it
> doesn't matter a bit how ugly the code is.
It also matters on large, complicated projects, even when you're the
only one working on them. My authoring system is several thousand lines
long now, and I spend more than half my programming time just cleaning
code. If I tried to spend all my time adding new features without doing
this, it would actually take me longer to finish my system, since it's
far more difficult to modify "spaghetti code" without producing bugs.
IF games are simpler than authoring systems, but complex games could
still be written more quickly without spaghetti.
-Rúmil
Jeff Hatch
Trevor Barrie wrote:
> Huh? I could shoot Graham Nelson stone-cold dead right now, and it wouldn't
> stop anybody from creating new Inform games. It might mean there wouldn't
> be any new versions of Inform, but then, I don't know if he was planning on
> producing new versions anyway.
Inform has improved a lot since the first release. If Graham Nelson
died, Inform wouldn't get any worse, but it would probably improve more
slowly, and a better-supported system like Hugo might replace it as #1.
I don't see how a hypothetical standard by consensus would be any better
than the current de facto Inform standard, though. If the standard were
agreed upon by many people, it would probably take a lot of effort to
change the standard, so it wouldn't be able to improve any more quickly.
-Rúmil
The Glassers
Mike Smith <sup...@remedy.com> wrote:
> (I think if the author of Inform decided to stop making Inform for
> some reason, one would realize that's not a non-proprietary platform after
> all.)
Ah, but you are looking at this backwards. Infocom died and Graham came
and saved it.
--David Glasser
gla...@NOSPAMuscom.com
The Glassers
Mike Smith <sup...@remedy.com> wrote:
> We could then submit
> this standard to IETF and get it approved, then when it's in the public
> domain, the world could adhere to it and it would explode just as hypertext
> grew out of being a proprietary thing into a world wide thing called WWW.
I hate to say it, but HTML has gotten more and more proprietary, not
less.
Oh, and I'd also like to mention that though I have made several posts
to raif that may seem detrimental to you, it is (a) nothing personal and
(b) the sarcasm was not in a mean way. If you come out with the next
IF, great!
--David Glasser, unless it doesn't work on Macs, then you die
gla...@NOSPAMuscom.com
Neil K.
tba...@ibm.net (Trevor Barrie) wrote:
> Nested goto? Do the major IF languages even have gotos? (Probably they do,
> but I doubt anybody uses them.) [...]
TADS does. To quote Mike Roberts, from the manual:
> The goto statement is widely considered among civilized computer
> scientists to be an evil and malevolent feature of ancient and unusable
> languages, and the esteem of TADS within serious computer language
> design circles has undoubtedly been fatally injured by the inclusion of
> this construct. So, you may wish to use this statement sparingly, if at
> all, especially if you're hoping to impress a civilized computer
> scientist with your coding efforts. However, many software engineers
> look upon goto as a highly useful statement when in the hands of a
> seasoned professional, and scoff at the blanket indictment by the
> more-elegant-than-thou academic establishment, most of whom probably
> haven't written a line of code since their TA's were chastising them for
> using goto in their Pascal programs, excepting perhaps some algorithms
> written in pseudo-code that always end in "the rest is left as an
> exercise for the reader" anyway. The author of TADS doesn't wish to take
> sides in this heated controversy, but hopes that both camps will be
> pleased, by gaining either the utility of using goto with wild abandon
> or the sense of virtue of knowing they could have used it but overcame
> the unclean temptation. With TADS, the choice is yours.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Darin Johnson
Neil Brown <ne...@this.address.is.fake> writes:
> You're exceptionally lucky then. Ever since I started disguising my
> email address, my spam levels have dropped by a half. Even so, that
> still makes three or four emails a week. Grrrrr.
Someone said that you can reduce even more by never replying "remove"
to a spam. By doing so, you authenticate that your email address is
valid.
> I agree. And it is not as if speed is an issue in most cases, although
> messy code makes debugging a serious problem. (Erm, as opposed to a
> funny one, I suppose.)
However, nice well written code makes it very easy for people to read
the code and learn from it. This is especially true for the
non-programmer or new programmer who is trying to figure out how to
take advantage of TADS or Inform. It's very enlightening to play
through an interesting bit of a game, then actually look at the code
to see how they did it.
--
Darin Johnson
da...@usa.net.removethis
Joe Mason
In article <6bn6id$ke$1...@drollsden.ibm.net>,
Trevor Barrie <tba...@ibm.net> wrote:
>In article <01bd3469$8f33f7c0$074c9ac0@station>,
>Mike Smith <sup...@remedy.com> wrote:
>
>>There is no need for IF to be spaghetti code like it has been with its
>>series of nested goto, if/then, or select/case type statements.
>
The Inform libraries use goto in some of the longer routines, like
PlayTheGame() (the main program loop). I've never used it in my own code,
except for a couple of cases where I've had to edit library routines which
use it.
Joe
Paul F. Snively
In article <si1zxc3...@cre.canon.co.uk>, Gareth Rees
<gar...@cre.canon.co.uk> wrote:
> Is this "structured programming gone mad" or what? If you outlaw goto,
> if/then and select/case statements, how do you express flow of control?
>
> Should one implement all flow-of-control using method dispatch and
> continuation passing, something like this?
>
> function if-then-else(p, t, f, c) {
> p.t = t;
> p.f = f;
> c(p.branch()); /* The lambda way is the only way! */
> }
Well, Guy Steele *did* write that little MIT AI Lab Memo, "Lambda: The
Ultimate Goto," but I'm pretty sure that his point was that tail-recursion
optimization is a Good Thing(tm). Not even sure whether to put a smiley
here or not.
I already posted a rather lengthy diatribe on this subject that I suppose I
could summarize as "people who want to do away with programming in IF
authoring understand neither programming nor IF authoring," in retrospect.
Geez, I'm in a nasty mood over this. I wonder why?
> --
> Gareth Rees
Paul Snively
<mailto:ch...@mcione.com>
Brock Kevin Nambo
Neil Brown wrote in message ...
>At 15:58:48 on Mon, 9 Feb 1998, Allen Garvin wrote:
>>In article <01bd3469$8f33f7c0$074c9ac0@station>,
>>Mike Smith <sup...@remedy.com> wrote:
>> and put on a Yellow Pages CDROM, please remove SPAM and click here
>> (mailto://shortc...@ntwrks.com) or use this newsgroup to reply.***
>>
>>I've been using USENET since 1987, and have posted thousands of messages
>>over the years without ever disguising my address, and I get no more than
>>2 or 3 "spam" advertisements by email a week.
>
>email address, my spam levels have dropped by a half. Even so, that
>still makes three or four emails a week. Grrrrr.
You're both exceptionally lucky then. By some unknown law of the Internet,
I get at least one spam every time I check my mail (which is several times a
day...)
>>BKNambo (even *with* a "newsmaster" email address)
--
http://come.to/brocks.place
Chris Marriott
In article <816rIEAC...@highmount.demon.co.uk>, Neil Brown
<ne...@this.address.is.fake> writes
>Aha, but would it work on my 2Mb Acorn? (Or for that matter, my 32k BBC?
>I suppose it would be pushing it to mention my ZX81 at this point, so I
>won't.) Generally, systems that are designed to work with all possible
>platforms eat up huge amounts of memory and only work on high-end
>machines. Look at web browsers.
With current prices of memory and disks, is that really an issue?
Seriously, should new IF engines really have to bother about supporting
machines which are out of production and have been so for years?
I realise that old machines like the Amiga still have a few users out
there, but should the restrictions imposed by these obsolete platforms
affect the future development of *new* IF systems for modern computers?
Chris
----------------------------------------------------------------
Chris Marriott, SkyMap Software, UK (ch...@skymap.com).
Visit our web site at: http://www.skymap.com
Astronomy software written by astronomers, for astronomers.
Iain Merrick
Chris Marriott wrote:
> In article <816rIEAC...@highmount.demon.co.uk>, Neil Brown
> <ne...@this.address.is.fake> writes
> >Aha, but would it work on my 2Mb Acorn? (Or for that matter, my 32k BBC?
> >I suppose it would be pushing it to mention my ZX81 at this point, so I
> >won't.) Generally, systems that are designed to work with all possible
> >platforms eat up huge amounts of memory and only work on high-end
> >machines. Look at web browsers.
>
> With current prices of memory and disks, is that really an issue?
>
> Seriously, should new IF engines really have to bother about supporting
> machines which are out of production and have been so for years?
>
> I realise that old machines like the Amiga still have a few users out
> there, but should the restrictions imposed by these obsolete platforms
> affect the future development of *new* IF systems for modern computers?
It's an issue if you're using a palmtop - even with a decent one you
only have, I don't know, 2 megs RAM and no hard disk?
I don't have one, but I'm always tempted to buy a Newton just so that I
can play IF on the train. :)
--
Iain Merrick
Benjamin Kenward
someone whos name i accidentally wiped and cant get back cos im clueless with
emacs really wrote:
: It's an issue if you're using a palmtop - even with a decent one you
: only have, I don't know, 2 megs RAM and no hard disk?
: I don't have one, but I'm always tempted to buy a Newton just so that I
: can play IF on the train. :)
i hate to boast but my psion 5's got 8 megs and runs frotz nicely. keyboard
is very nice... dont buy a newton ;)
ben
--
--------------------------------------------
FREE THE GANDALF 3! 3 YEARS FOR "CONSPIRACY TO INCITE
PERSONS UNKNOWN TO COMMIT ARSON" IS OUTRAGEOUS.
(All they did was write a newspaper and prepare press releases)
Don't be scared off by the thought police. Make all your e-mails
illegal by putting in reports of your favourite actions...
* Oct 31- Opencast quarry in Derbyshire trashed in raid- sorted!
* Nov 1- Street Party in Oxford, highway obstructed and illegal rave- fair
play!
* Nov 23- Action at Hillgrove Farm, Witney, kittens for vivisection
breeders,
fence trashed- nice one!
>@>Disobey! Their power comes from our obedience<@<
Kenneth Fair
In article <CFG5NIA5$G40...@chrism.demon.co.uk>, Chris Marriott
<ch...@chrism.demon.co.uk> wrote:
>Seriously, should new IF engines really have to bother about supporting
>machines which are out of production and have been so for years?
>
>I realise that old machines like the Amiga still have a few users out
>there, but should the restrictions imposed by these obsolete platforms
>affect the future development of *new* IF systems for modern computers?
And why not? The nice thing about text adventures is that they require
neither the speed nor the storage space of "advanced" programs. They are
not ever going to require the resources that a Riven requires. So why
not make them available to as many platforms as possible?
Neil Brown
At 11:12:12 on Mon, 9 Feb 1998, Trevor Barrie wrote:
>Huh? I could shoot Graham Nelson stone-cold dead right now, and it wouldn't
>stop anybody from creating new Inform games.
(PANICKING) No! You can't shoot Graham! He's a national treasure!
- NJB
Neil Brown
At 00:05:11 on Tue, 10 Feb 1998, Darin Johnson wrote:
>However, nice well written code makes it very easy for people to read
>the code and learn from it. This is especially true for the
>non-programmer or new programmer who is trying to figure out how to
>take advantage of TADS or Inform. It's very enlightening to play
>through an interesting bit of a game, then actually look at the code
>to see how they did it.
Well, that's not a problem for me. All my recent games use library
hacks, so I can't release the the code, and I can be as messy as I like.
:)
- NJB
Neil Brown
At 15:19:21 on Tue, 10 Feb 1998, Chris Marriott wrote:
>In article <816rIEAC...@highmount.demon.co.uk>, Neil Brown
><ne...@this.address.is.fake> writes
>>Aha, but would it work on my 2Mb Acorn? (Or for that matter, my 32k BBC?
>>I suppose it would be pushing it to mention my ZX81 at this point, so I
>>won't.) Generally, systems that are designed to work with all possible
>>platforms eat up huge amounts of memory and only work on high-end
>>machines. Look at web browsers.
>
>With current prices of memory and disks, is that really an issue?
>
>machines which are out of production and have been so for years?
Hey, I know you'd love to see nothing better than the entire world ruled
by Microsoft, but let us poor souls out here enjoy our last few years of
freedom!
>I realise that old machines like the Amiga still have a few users out
>there, but should the restrictions imposed by these obsolete platforms
>affect the future development of *new* IF systems for modern computers?
I can't help thinking that you're basically saying "Why on earth isn't
everyone using Windows 95 machines here?" A very frightening prospect.
(Sorry, I must stop winding you up. I will resist temptation in future.
:)
- NJB
Patrick Kellum
In article <ui3pvPi...@upnetnews02.moswest.msn.net>, Brock Kevin Nambo was talking about:
>You're both exceptionally lucky then. By some unknown law of the Internet,
>I get at least one spam every time I check my mail (which is several times a
>day...)
How's this, I get three copies of each spam. This is due to me having my
web site addresses being different then my real one but it forwards my
email to the real one :-(
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry
Patrick Kellum
In article <CFG5NIA5$G40...@chrism.demon.co.uk>, Chris Marriott was talking about:
>Seriously, should new IF engines really have to bother about supporting
>machines which are out of production and have been so for years?
>
>I realise that old machines like the Amiga still have a few users out
>there, but should the restrictions imposed by these obsolete platforms
>affect the future development of *new* IF systems for modern computers?
First, Amiga's are far from obsolete (ok, they need a few upgrades, I'll
admit th