Good language to start out?
Ben Marlowe
I loved text adventures back in the day, but thought that no-one was
writing them any more -- until I found out about interactive fiction
from a friend, who sent me a bunch of games and told me to have a look
at ifarchive.org and this newsgroup. Wow!
It'd be absolutely great to write a piece of interactive fiction,
having seen what the medium can do. But where do I start? I know
various BASICs (Visual Basic, QBasic), a little C/C++ and a few webby
languages like HTML and PHP. IF appears to be mostly written in Inform
and Tads and then interpreted, but are there any other languages that
would be easier or quicker? Failing that, what is the best version of
those languages, and where can I learn one?
Thanks,
Ben Marlowe.
Ben Caplan
There really isn't an 'easy' language for writing IF, due to the inherently
complex nature of human language and human expectations of computer
representations of reality.
I personally recommend TADS. If you're just starting out, you probably want
to stay away from HTML TADS, simply because it's just one more thing to keep
track of. I learned TADS using the tutorial at
http://users.abac.com/MeriBird/TADS/Tutorial/index.html
Good luck.
----------------------------------------------------------------
Ben Caplan -- philosopher, linguist, and thaumaturge
Mark 'Kamikaze' Hughes
> It'd be absolutely great to write a piece of interactive fiction,
> having seen what the medium can do. But where do I start? I know
> various BASICs (Visual Basic, QBasic), a little C/C++ and a few webby
> languages like HTML and PHP. IF appears to be mostly written in Inform
> and Tads and then interpreted, but are there any other languages that
> would be easier or quicker? Failing that, what is the best version of
> those languages, and where can I learn one?
Alan is very simple (much simpler than Inform, TADS, or Hugo) and
still reasonably powerful:
<http://w1.132.telia.com/~u13207378/alan/index.html>
My own Aiee! (An Interactive Environment Engine) system is currently
in beta, but is also easy to develop with, especially if you already
understand a bit about programming and XML:
<http://kuoi.asui.uidaho.edu/~kamikaze/Aiee/>
Actors (NPCs) are not in Aiee! 0.1; I have actors working in my
development system, but they're not quite done yet. I should be able to
release 0.2 with actors this week.
However, Aiee! is different from a lot of other text adventure
systems, with a deliberately simple user interface.
Start with Alan, see how that suits you.
--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"We remain convinced that this is the best defensive posture to adopt in
order to minimize casualties when the Great Old Ones return from beyond
the stars to eat our brains." -Charlie Stross, _The Concrete Jungle_
Cedric Knight
> having seen what the medium can do. But where do I start? I know
> various BASICs (Visual Basic, QBasic), a little C/C++ and a few webby
> languages like HTML and PHP. IF appears to be mostly written in Inform
> and Tads and then interpreted, but are there any other languages that
> would be easier or quicker? Failing that, what is the best version of
> those languages, and where can I learn one?
Welcome, and here's what is perhaps the most often posted link in this
group:
http://www.firthworks.com/roger/cloak/index.html
It's a good comparison of the major languages.
As keeps getting restated here, writing IF in VB (or any general
language) would make it much harder and more time-consuming to produce
high-quality work; and the finished result would then not be as
accessible to many people in this group as something done in Inform,
TADS, Hugo or ALAN.
Other tips: carry on playing IF to get a good idea of what you want to
do, and don't get too ambitious at first - plenty of time for that once
you feel confident in your chosen language and are designing a story.
Good luck
CK
Gadget
wrote:
A good place to start is www.firthworks.com where most major IF
languages are on display. My personal preference is Inform, which
isn't that hard to code in, if you invest some time. And it is a
compiled language, by the way, not interpreted ;-)
-------------
It's a bird...
It's a plane...
No, it's... Gadget?
-------------------
To send mail remove SPAMBLOCK from adress.
British Ben
language like ADRIFT, where you set up rooms and characters in a few
clicks, then move on to ALAN to start actual scripting, then TADS. If
you are familiar with C/C++, TADS code should look very familiar.
TADS will even allow you to use the C/C++ operands, if you put in a
"#pragma C+" at the beginning of the file. I suggest learning ADRIFT
first, though, as it gives you a good basic platform to build from.
Writing IF is pretty different from writing a program, so ADRIFT will
help you figure out the interactions of objects, character relations,
etc. Unfortunatly, ADRIFT is a very limited system to work with, so
an upgrade to ALAN would probably be required not soon after. ALAN
will get you into Verbs moreso than ADRIFT, and is not too dissimilar
to TADS. Really, you could go for either TADS or Inform, but my
personal preference is TADS. It just seems like a slightly easier
language to learn, with all the power of Inform. Ideally, learn both,
but it would be better to become excellent at one than average at
both. Hope this helps you out. Use the link given in another post,
this should give you some good starting points to compare the
languages.
"Cedric Knight" <ckn...@gn.babpbc.removeallBstosend.org> wrote in message news:<0ce%9.15475$pS2.575210@stones>...
John W. Kennedy
Both Inform and TADS are good. Inform is generally thought to have a
better book to go with it. There are a couple of others (Alan, Adrift,
Hugo), which might be a little easier to start with, but which are more
likely to be unable to do something you want.
You _don't_ want to use a general programming language. The code to
produce the world model and parser in Inform is over 10,000 lines of
Inform code, and you'd have to rewrite every line of it. And C++ would
be the only one of the languages that you name in which it would be at
all easy to do -- after you wrote another few thousand lines to
reproduce Inform's built-in world-object management, word-wrapping,
screen management, and half a dozen other things.
--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
-- G. K. Chesterton, "The Man Who Was Thursday"
LoneCleric
> Both Inform and TADS are good. Inform is generally thought to have a
> better book to go with it. There are a couple of others (Alan, Adrift,
> Hugo), which might be a little easier to start with, but which are more
> likely to be unable to do something you want.
For the record, Hugo is NOT a second-tier language. Last time I checked,
the general consensus was that it's just as powerful as Inform and TADS.
(And just as hard to learn, too.) Hugo's main problem is its small user
base, due to... well, to its small user base.
Oh, and I'm ready to mud-wrestle anybody saying the opposite.
LC
Carl Gundel
You might look at CAT, an authoring tool for creating IF. An
interesting note is that it's written in Liberty BASIC. Perhaps you'd
find that interesting too. ;-)
The link for CAT is:
http://www.richmond62.freeserve.co.uk/
The link for Liberty BASIC is:
-Carl Gundel, author of Liberty BASIC
Gadget
wrote:
>My personal recommendation would be to start out in a super-easy
>language like ADRIFT, where you set up rooms and characters in a few
>clicks, then move on to ALAN to start actual scripting, then TADS. If
>you are familiar with C/C++, TADS code should look very familiar.
>TADS will even allow you to use the C/C++ operands, if you put in a
>"#pragma C+" at the beginning of the file. I suggest learning ADRIFT
>first, though, as it gives you a good basic platform to build from.
>Writing IF is pretty different from writing a program, so ADRIFT will
>help you figure out the interactions of objects, character relations,
>etc. Unfortunatly, ADRIFT is a very limited system to work with, so
>an upgrade to ALAN would probably be required not soon after. ALAN
>will get you into Verbs moreso than ADRIFT, and is not too dissimilar
>to TADS. Really, you could go for either TADS or Inform, but my
>personal preference is TADS. It just seems like a slightly easier
>language to learn, with all the power of Inform. Ideally, learn both,
>but it would be better to become excellent at one than average at
>both. Hope this helps you out. Use the link given in another post,
>this should give you some good starting points to compare the
>languages.
>
Hm.. this sounds like an unnecessary waste of time... My advice: pick
one of the 'big three' (Inform, Tads and Aiee ( oops I mean Hugo of
course ;-) ) and just stat coding. If you have prior programming
experience (even if it is 'just' BASIC) learning an IF language isn't
all that hard. And as you said, it is better to focus all of your time
on one language rather then start over and over with systems you
*know* are going to be too limited.
Cedric Knight
> > IF appears to be mostly written in Inform
> > and Tads and then interpreted, but are there any other languages
that
> > would be easier or quicker?
Another comment if I may. If the idea that IF languages compile to
something other than a Windows .EXE file is what is making you reluctant
to use such a language, then the solution is simple. Distribute one of
the freeware interpreters with your game/story so your less
computer-literate friends don't need to download anything else.
There are even ways of packaging most formats as a single executable
file for Wind32, although most people here would hope (not unreasonably)
that you'd also release the platform-independent version it was based
on.
(Hope that's clear. Someone will probably correct me.)
"John W. Kennedy" <jwk...@attglobal.net> wrote
> Both Inform and TADS are good. Inform is generally thought to have a
> better book to go with it.
Two good books, now there's the _Inform Beginner's Guide_. :)
CK
David Thornley
Cedric Knight <ckn...@gn.babpbc.removeallBstosend.org> wrote:
>> Ben Marlowe wrote:
>> > IF appears to be mostly written in Inform
>> > and Tads and then interpreted, but are there any other languages
>that
>> > would be easier or quicker?
>
and TADS are anywhere near perfect, but they're pretty close to being
the best we know how to make. There are simpler IF systems, Adrift
probably being the most popular, but these systems tend to break down
when you're doing something the system designer didn't think of. Either
they flat-out won't do it, or it's much harder than it would be in
Inform or TADS.
>Another comment if I may. If the idea that IF languages compile to
>something other than a Windows .EXE file is what is making you reluctant
>to use such a language, then the solution is simple. Distribute one of
>the freeware interpreters with your game/story so your less
>computer-literate friends don't need to download anything else.
>
>There are even ways of packaging most formats as a single executable
>file for Wind32, although most people here would hope (not unreasonably)
>that you'd also release the platform-independent version it was based
>on.
>
Or other platforms, such as MacOS. Again, people around here would
really like to see a platform-independent version for three reasons:
1. It's easier to find just one version of the game, rather than looking
for the version for the correct machine.
2. It's a shorter download, which is more important than it used to
be.
3. It avoids cluttering somebody's hard disk with endless versions of
the same interpreter, bundled into games. (Mac users might remember
the number of times TeachText would be loaded onto their machines
when installing software. I'd frequently have four or five
copies there. With TeachText, at least I could go around and remove
other copies without losing documents.)
>(Hope that's clear. Someone will probably correct me.)
>
Yup.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Mark 'Kamikaze' Hughes
> Or other platforms, such as MacOS. Again, people around here would
> really like to see a platform-independent version for three reasons:
> 1. It's easier to find just one version of the game, rather than looking
> for the version for the correct machine.
> 2. It's a shorter download, which is more important than it used to
> be.
"Less important", I think you mean. Most people now have fast
connections and many gigs of HD space.
> 3. It avoids cluttering somebody's hard disk with endless versions of
> the same interpreter, bundled into games. (Mac users might remember
> the number of times TeachText would be loaded onto their machines
> when installing software. I'd frequently have four or five
> copies there. With TeachText, at least I could go around and remove
> other copies without losing documents.)
There's another reason, which is far more vital than the "convenience"
reasons you listed: your platform will not live forever. If you tie
your software too closely to one specific platform, in 5 years people
will only be able to use it in an emulator.
Using a well-specified VM is really the best way of making sure your
software will continue to be useful. This is why I use Java; whatever
else happens in the computer industry, the JVM will probably live as
long as Unix. Inform, TADS, and most others also run on a VM which can
be adapted to new platforms. Those that can't, like Adrift, will die
eventually, played only by diehard collectors with emulators.
L. Ross Raszewski
<kami...@kuoi.asui.uidaho.edu> wrote:
>
> Using a well-specified VM is really the best way of making sure your
>software will continue to be useful. This is why I use Java; whatever
>else happens in the computer industry, the JVM will probably live as
>long as Unix. Inform, TADS, and most others also run on a VM which can
>be adapted to new platforms. Those that can't, like Adrift, will die
>eventually, played only by diehard collectors with emulators.
>
But surely this is only effective if you release the source code;
though some form of Java is liable to live on a good long time, java
has a number of elements which are are explicitly not
backward-compatable. I've had java class files a few *months* old that
wouldn't run without a recompile, so it seems that the java platform
is not in and of itself sufficient to keep your software useful
Cedric Knight
> >There are even ways of packaging most formats as a single executable
> >file for Wind32, although most people here would hope (not
unreasonably)
> >that you'd also release the platform-independent version it was based
> >on.
"David Thornley" <thor...@visi.com> wrote
> Or other platforms, such as MacOS. Again, people around here would
> really like to see a platform-independent version for three reasons:
[snip 3 good reasons]
I was trying to distinguish at least two different audiences here :
(i) computer-literate people who've played IF before or maybe read raif,
who can download from the IF Archive; and
(ii) your mates, colleagues, website visitors, fans etc. who are mostly
interested because it's something you've done, would run a mile at the
mention of words like 'emulation', and may have only just mastered
double-clicking. These people are unlikely to download from the
Archive.
E.g. Photopia is available via Adam Cadre's website in a version
packaged with Windows Glulxe, thereby increasing accessibility of
Photopia, Glulx and IF.
> 2. It's a shorter download, which is more important than it used to
> be.
This is assuming that people are downloading from the master IF Archive.
I now get everything from ifarchive.biff.org.uk unless I catch a recent
announcement on rgif. Or am I missing something?
Cheers
CK
Shadow Wolf
news:slrnb3vtc4....@kuoi.asui.uidaho.edu:
> 04 Feb 2003 14:43:55 GMT, David Thornley <thor...@visi.com>:
>> 2. It's a shorter download, which is more important than it used to
>> be.
>
> "Less important", I think you mean. Most people now have fast
> connections and many gigs of HD space.
>
More important, at least to the IF community -- the if-archive has had it's
bandwidth capped recently! Anything that saves bandwidth is good for the
archive.
--
Shadow Wolf
shado...@softhome.net
Stories at http://www.asstr.org/~Shadow_Wolf
Andrew Plotkin
> kami...@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote in
> news:slrnb3vtc4....@kuoi.asui.uidaho.edu:
>> 04 Feb 2003 14:43:55 GMT, David Thornley <thor...@visi.com>:
>>> 2. It's a shorter download, which is more important than it used to
>>> be.
>>
>> "Less important", I think you mean. Most people now have fast
>> connections and many gigs of HD space.
>>
> More important, at least to the IF community -- the if-archive has had it's
> bandwidth capped recently! Anything that saves bandwidth is good for the
> archive.
Anyone who uses a mirror is good for the Archive.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Simon Baldwin
> ... Inform, TADS, and most others also run on a VM which can
> be adapted to new platforms. Those that can't, like Adrift, will die
> eventually, played only by diehard collectors with emulators.
Ahem. There's jAsea, http://sourceforge.net/projects/jasea, which may
offer a form of life-support, if such ever becomes necessary, for Adrift.
And for that matter, http://www.geocities.com/legion_if/scare.html.
But yeah, fundamentally, portability ensures a longer life for software
than shackling something to a small range of systems. And IF games are
often much more amenable to portability than other programs -- if all you
absolutely must have are read_line and print_line, the chances of out-
lasting a given platform are reasonably good.
So, when do you forsee the death of Windows and all forms of Windows
backwards compatibility, then? :-)
--S
Fredrik Ramsberg
> software will continue to be useful. This is why I use Java; whatever
> else happens in the computer industry, the JVM will probably live as
> long as Unix. Inform, TADS, and most others also run on a VM which can
> be adapted to new platforms. Those that can't, like Adrift, will die
> eventually, played only by diehard collectors with emulators.
Then use Cobol instead. It has a more impressive track-record of
outliving operating systems and other languages. As an added benefit,
the source code won't look too much different from a game transcript...
/Fredrik
John W. Kennedy
> kami...@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote in message news:<slrnb3vtc4....@kuoi.asui.uidaho.edu>...
>
>> Using a well-specified VM is really the best way of making sure your
>>software will continue to be useful. This is why I use Java; whatever
>>else happens in the computer industry, the JVM will probably live as
>>long as Unix. Inform, TADS, and most others also run on a VM which can
>>be adapted to new platforms. Those that can't, like Adrift, will die
>>eventually, played only by diehard collectors with emulators.
>
>
> Then use Cobol instead. It has a more impressive track-record of
> outliving operating systems and other languages.
Unfortunately, it is grossly nonportable (after over 40 years, they
still haven't even standardized the semantics of the COMPUTE statement),
and grossly unstable from ANSI version to ANSI version (every decade or
so, IBM has to write a new COBOL-to-COBOL translator).
David Thornley
John W. Kennedy <jwk...@attglobal.net> wrote:
>Fredrik Ramsberg wrote:
>> kami...@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote in message news:<slrnb3vtc4....@kuoi.asui.uidaho.edu>...
>>
>>> Using a well-specified VM is really the best way of making sure your
>>>software will continue to be useful. This is why I use Java; whatever
>>
>> outliving operating systems and other languages.
>
>Unfortunately, it is grossly nonportable (after over 40 years, they
>still haven't even standardized the semantics of the COMPUTE statement),
>and grossly unstable from ANSI version to ANSI version (every decade or
>so, IBM has to write a new COBOL-to-COBOL translator).
>
an upgrade between two consecutive COBOL standards once (back when
I still had to work with the language), and it was a pain.
If you want raw portability, consider FORTRAN. I'd go with the '77
standard; it's widespread, easily available (usually for free if you've
got a C compiler), and is not likely to be subject to incompatibilities.
(Anybody who's done anything with the newer standard feel free to
correct me.) Nobody wants to make all *those* libraries obsolete.
Mark 'Kamikaze' Hughes
> kami...@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote in message news:<slrnb3vtc4....@kuoi.asui.uidaho.edu>...
>> ... Inform, TADS, and most others also run on a VM which can
>> be adapted to new platforms. Those that can't, like Adrift, will die
>> eventually, played only by diehard collectors with emulators.
> Ahem. There's jAsea, http://sourceforge.net/projects/jasea, which may
> offer a form of life-support, if such ever becomes necessary, for Adrift.
> And for that matter, http://www.geocities.com/legion_if/scare.html.
That helps some, though it would help more if the authoring system was
portable... And jAsea's not complete, is it?
> So, when do you forsee the death of Windows and all forms of Windows
> backwards compatibility, then? :-)
Oh, about the time people realize that security, stability, and
customizability are more important than a brand name.
Yeah, I know.
Mark 'Kamikaze' Hughes
> For those reasons, among others, I'd avoid COBOL. I was involved in
> an upgrade between two consecutive COBOL standards once (back when
> I still had to work with the language), and it was a pain.
I agree--I've never written COBOL, but I have had to read it and
convert it to C in one case, and Java in another. The manual for the
versions I was working with continually mentioned which variations from
the standard it was using.
It's also a vile, terrible, wretched language. Doing anything
interesting in it would be nightmarish.
> If you want raw portability, consider FORTRAN. I'd go with the '77
> standard; it's widespread, easily available (usually for free if you've
> got a C compiler), and is not likely to be subject to incompatibilities.
> (Anybody who's done anything with the newer standard feel free to
> correct me.) Nobody wants to make all *those* libraries obsolete.
I wrote a fair amount of F77 for CS classes, and played a bit with
FORTRAN 90. I actually like FORTRAN, it's a decent and very efficient
language that just gets a reputation for bad code from physicists
writing FORTRAN programs. Real programmers *can* write elegant FORTRAN
code.
Most F77 programs compile and run in F90 unmodified, unless you're
doing something really stupid. The big incompatibilities are that
whitespace is significant in F90, and some of the F66 features that were
included in most implementations of F77 are gone in F90. The compiler
spews out an endless series of complaints on some programs, and there's
probably some it's not catching and turning directly into bugs. If you
get a single error when converting, review your code line-by-line, don't
trust the compiler.
Anyone who is actually going to write new software in FORTRAN, though,
should use the new standard, it's also well-supported and is a better
language if you're not stuck with punch cards. You don't see a lot of
FORTRAN users on the Net, but they're out there, actually getting some
work done.
The big problem with both FORTRAN and COBOL is that they compile to
native binary. If you lose the source, which does happen, you're
reduced to unreliable emulation.
With languages that compile to bytecode, the VM is usually simple and
well-specified, so you can keep extending the life of the program
indefinitely, even without source (running Infocom's games on modern
Z-Machines, etc).
In Java's case, you can also decompile almost any Java program to
something very close to the original source, unless the classes were run
through an obfuscator. A FORTRAN decompiler would be useless, since it
compiles much more efficiently.
Valjean
"Mark 'Kamikaze' Hughes" <kami...@kuoi.asui.uidaho.edu> wrote in message
news:slrnb432s0.1...@kuoi.asui.uidaho.edu...
> 05 Feb 2003 17:06:38 GMT, David Thornley <thor...@visi.com>:
> > For those reasons, among others, I'd avoid COBOL. I was involved in
> > an upgrade between two consecutive COBOL standards once (back when
> > I still had to work with the language), and it was a pain.
>
> I agree--I've never written COBOL, but I have had to read it and
> convert it to C in one case, and Java in another. The manual for the
> versions I was working with continually mentioned which variations from
> the standard it was using.
>
> It's also a vile, terrible, wretched language. Doing anything
> interesting in it would be nightmarish.
>
> > If you want raw portability, consider FORTRAN. I'd go with the '77
> > standard; it's widespread, easily available (usually for free if you've
> > got a C compiler), and is not likely to be subject to incompatibilities.
> > (Anybody who's done anything with the newer standard feel free to
> > correct me.) Nobody wants to make all *those* libraries obsolete.
>
Ahhh FORTRAN - I used to be forced to write in FORTRAN IV I think
it was, and we were not allowed to use strings but had to pack them into
integer arrays (something to do with one target machine being a Harris with
a 24 bit word or something). Anyway, as one of a large team of programmers
my favourite trick was to pass an actual integer into a subroutine and
change it
which meant that integer had, for the rest of the program a new value.
so if you did a "call fred(1)" and subroutine fred changed the value of its
parameter from to 2 then statments later on which compared variable to"1"
were actually comparing them to 2- endless fun.
Val
David Thornley
Valjean <Val...@no.mail.thanks> wrote:
>Ahhh FORTRAN - I used to be forced to write in FORTRAN IV I think
>it was, and we were not allowed to use strings but had to pack them into
>integer arrays (something to do with one target machine being a Harris with
>a 24 bit word or something). Anyway, as one of a large team of programmers
>my favourite trick was to pass an actual integer into a subroutine and
>change it
>which meant that integer had, for the rest of the program a new value.
>
>so if you did a "call fred(1)" and subroutine fred changed the value of its
>parameter from to 2 then statments later on which compared variable to"1"
>were actually comparing them to 2- endless fun.
>
in computer history, and he claimed that nobody ever did that deliberately
to fix a bug. Were you doing this for some useful purpose, or just to
have fun with your colleagues?
(I liked one story of an early Microsoft Fortran user on the TRS-80.
He had something like a CALL FOO(2) statement, and in a subroutine
FOO called the parameter was changed. He just changed it to I = 2
CALL FOO(I) or something like that. He considered this a beautiful
example of the Murphy axiom "Variables don't, and constants aren't.")
John W. Kennedy
> (I liked one story of an early Microsoft Fortran user on the TRS-80.
> He had something like a CALL FOO(2) statement, and in a subroutine
> FOO called the parameter was changed. He just changed it to I = 2
> CALL FOO(I) or something like that. He considered this a beautiful
> example of the Murphy axiom "Variables don't, and constants aren't.")
One of the reasons that FORTRAN is still used by high-performance
programmers is that on this, as on several other points, the rules of
FORTRAN simply say, "Don't do that," rather than damage run-time
performance in protecting the programmer from himself.
Valjean
"John W. Kennedy" <jwk...@attglobal.net> wrote in message
news:JHW1a.243808$HG.40...@news4.srv.hcvlny.cv.net...
> David Thornley wrote:
> > (I liked one story of an early Microsoft Fortran user on the TRS-80.
> > He had something like a CALL FOO(2) statement, and in a subroutine
> > FOO called the parameter was changed. He just changed it to I = 2
> > CALL FOO(I) or something like that. He considered this a beautiful
> > example of the Murphy axiom "Variables don't, and constants aren't.")
>
> One of the reasons that FORTRAN is still used by high-performance
> programmers is that on this, as on several other points, the rules of
> FORTRAN simply say, "Don't do that," rather than damage run-time
> performance in protecting the programmer from himself.
>
of what I am told (normally just to be annoying). So rules tend to work
better for me. Generally though, even my FORTRAN was relatively
easy to read and understand, while my C++ was terse and obscure.
They tried getting us to use ADA (yeuch) but I have wandered off to use
Pascal (Delphi / Kylix) which I am pretty much sold on at the moment.
Val
Neil Cerutti
>
> "John W. Kennedy" <jwk...@attglobal.net> wrote in message
> news:JHW1a.243808$HG.40...@news4.srv.hcvlny.cv.net...
>> David Thornley wrote:
>> > (I liked one story of an early Microsoft Fortran user on the
>> > TRS-80. He had something like a CALL FOO(2) statement, and
>> > in a subroutine FOO called the parameter was changed. He
>> > just changed it to I = 2 CALL FOO(I) or something like that.
>> > He considered this a beautiful example of the Murphy axiom
>> > "Variables don't, and constants aren't.")
>>
>> One of the reasons that FORTRAN is still used by
>> high-performance programmers is that on this, as on several
>> other points, the rules of FORTRAN simply say, "Don't do
>> that," rather than damage run-time performance in protecting
>> the programmer from himself.
>>
> I, however, have always been somewhat perverse and done the
> reverse of what I am told (normally just to be annoying). So
> rules tend to work better for me. Generally though, even my
> FORTRAN was relatively easy to read and understand, while my
> C++ was terse and obscure.
So you're more of a Sir Lancelot that a King Arthur. Luckily,
they make languages for both characters. ;-)
--
Neil Cerutti <cer...@trans-video.net>
David Jackson
> of what I am told (normally just to be annoying). So rules tend to work
> better for me. Generally though, even my FORTRAN was relatively
> easy to read and understand, while my C++ was terse and obscure.
>
> They tried getting us to use ADA (yeuch) but I have wandered off to use
> Pascal (Delphi / Kylix) which I am pretty much sold on at the moment.
>
> Val
Pascal. Blech! As if Fortran didn't have enough rules!
-David
[Illegal-Operation]
wrote:
>Hi,
>
>I loved text adventures back in the day, but thought that no-one was
>writing them any more -- until I found out about interactive fiction
>from a friend, who sent me a bunch of games and told me to have a look
>at ifarchive.org and this newsgroup. Wow!
>
>It'd be absolutely great to write a piece of interactive fiction,
>having seen what the medium can do. But where do I start? I know
>various BASICs (Visual Basic, QBasic), a little C/C++ and a few webby
>languages like HTML and PHP. IF appears to be mostly written in Inform
>and Tads and then interpreted, but are there any other languages that
>would be easier or quicker? Failing that, what is the best version of
>those languages, and where can I learn one?
>
>Thanks,
>
>Ben Marlowe.
Either HTML TADS or Inform. They are both based on the C/C++ structure
and are easy to learn and compile, especially TADS.
I started out with Inform just because I wanted to make a game with
the same basic structure as INFOCOMs, who where at that time my
heroes. Just because of the "coolness" factor. Myself, I'm not an
experienced programmer: I know a litle of C (the basics, plus the if
statements and other routines) and some HTML. The Inform Designers
Manual you can find at the official Infocom page (or IF-Archive, for
that matter) is quite self-explaining, and it's easy to follow even if
it lacks somewhat. However, I would skip the entire first chapter if I
were you: it may confuse the begginers. If you get stuck with Inform I
also recommend browsing through other games source codes, you'll learn
lots of things with them.
TADS is also great, and I strongly recommend you this one. It's easily
one of the most used IF langues. I'm starting to learn how to code
with it and so far not a single problem. Quite easy and as or even
more powerful than Inform. Even better: try both and decide for
yourself which one is better for you.