Relative difficulty of Inform, Tads, Hugo?
Eric Mayer
languages for Stephen Granade's About.com site I've had some comments
from readers about the relative difficulty of "non-easy" systems. So
of course that made me curious. Putting aside the different
capabilities, just looking at authoring standard IF without media, how
would folks rank the big three of Inform, Tads and Hugo as to ease? My
impression, having not used them, from reading comments and looking at
manuals, is that Inform may be considered somewhat harder than Tads,
although, to me, Tads actually looks more mind-bending. Does it just
come down to personal taste? And how about Hugo? Would that be easier
to to learn than Tads or Inform? Just interested in whether there's
any consensus.
I have to say I find it hard to judge because manuals and
tutorials, by starting out with chapters on constructing basic rooms
and objects, which seems pretty easy in any system, remind me of a
comic strip feature that used to run in some magazine or other a long
time ago. Every week you'd be instructed how to draw something. So,
for example, one week you'd get to "Draw Lassie." And the first panel
would be a couple of circles. (Hey, see anybody can do it) and next
panel a couple stick legs would be added, then two dots for eyes in
the next (see how easy it is). So by the penultimate panel you'd have
this crude stick figure creature, laboriously built up, and then
suddenly, the last panel it'd be miraculously transformed into a
beautifully rendered collie with every hair expertly detailed. Which,
anyway, is how IF strikes me, in that there's this huge leap from the
simple tasks of creating a crude sketch to doing what's necessary to
author a decent game.
--
Eric Mayer
Web Site: <http://home.epix.net/~maywrite>
"The map is not the territory." -- Alfred Korzybski
Dan Schmidt
| Since writing about my experiences with a couple of easy IF
| languages for Stephen Granade's About.com site I've had some comments
| from readers about the relative difficulty of "non-easy" systems. So
| of course that made me curious. Putting aside the different
| capabilities, just looking at authoring standard IF without media, how
| would folks rank the big three of Inform, Tads and Hugo as to ease? My
| impression, having not used them, from reading comments and looking at
| manuals, is that Inform may be considered somewhat harder than Tads,
| although, to me, Tads actually looks more mind-bending. Does it just
| come down to personal taste? And how about Hugo? Would that be easier
| to to learn than Tads or Inform? Just interested in whether there's
| any consensus.
OK, I am going to generalize wildly here. Stand back so that no one
gets hurt.
TADS is more of a general-purpose language. How you get things done
is very consistent: you send messages to objects, e.g.:
soap.moveInto (firetruck);
which moves the soap into the firetruck, by telling the soap,
"moveInto the firetruck".
Inform has a lot more syntactic nooks and crannies. This is
partially because it has to deal with some idiosyncrasies of the
z-machine (particularly with respect to strings, and I believe
the property/attribute distinction also exists because it's a
natural fit for the z-machine), and partially because much of its
syntax is specialised to map to IF concepts, e.g.:
move soap to firetruck;
The effect of this difference in style seems to be that (_in general_)
TADS makes somewhat more sense to programmers than Inform does, because
of its regular syntax and semantics, while Inform makes somewhat more
sense to non-programmers than TADS does, because of the way it provides
'syntactic sugar' for standard IF concepts. Both languages have fine
manuals at this point.
I'm not familiar with Hugo.
Gunther Schmidl
> The effect of this difference in style seems to be that (_in general_)
> TADS makes somewhat more sense to programmers than Inform does, because
> of its regular syntax and semantics, while Inform makes somewhat more
> sense to non-programmers than TADS does, because of the way it provides
> 'syntactic sugar' for standard IF concepts. Both languages have fine
> manuals at this point.
That's funny - I'm most definitely a programmer and I prefer the way Inform
does it a lot. The verDo and verIo and so on of TADS have me hopelessly
confused, but that's due to the inavailability of a tutorial-like manual
(like the DM) for TADS.
Hugo syntax, to add something useful, is very similar to Inform's, the most
striking difference being that you don't put semicola at the end of lines.
If you're used to Inform, this and other subtle differences will cause lots
of errors in the beginning, but since the original poster hadn't...
-- Gunther
Mark Musante - Sun Microsystems
> That's funny - I'm most definitely a programmer and I prefer the way Inform
> does it a lot. The verDo and verIo and so on of TADS have me hopelessly
> confused, but that's due to the inavailability of a tutorial-like manual
> (like the DM) for TADS.
I wonder if Graham would object to someone 'porting' the Inform DM to
TADS.
-markm
Dan Schmidt
| Dan Schmidt wrote:
| > The effect of this difference in style seems to be that (_in general_)
| > TADS makes somewhat more sense to programmers than Inform does, because
| > of its regular syntax and semantics, while Inform makes somewhat more
| > sense to non-programmers than TADS does, because of the way it provides
| > 'syntactic sugar' for standard IF concepts. Both languages have fine
| > manuals at this point.
|
| That's funny - I'm most definitely a programmer and I prefer the way Inform
| does it a lot. The verDo and verIo and so on of TADS have me hopelessly
| confused, but that's due to the inavailability of a tutorial-like manual
| (like the DM) for TADS.
When you say 'inavailability of a tutorial-like manual for TADS', what
did you find lacking in
- the introductory tutorial
(http://www.tela.bc.ca/tela/tads-manual/overview.html)
- the tiny sample game
(http://www.tela.bc.ca/tela/tads-manual/tads-1.html)
- the introduction to the language itself
(http://www.tela.bc.ca/tela/tads-manual/tads-3.html)
- the second, larger, sample game
(http://www.tela.bc.ca/tela/tads-manual/tads-9.html), and
- the discussion of 21 other topics (new verbs, doors, vehicles,
NPCs, daemons, etc.)
(http://www.tela.bc.ca/tela/tads-manual/tads-10.html)?
I do think that putting chapters 4-7 (about grody parser hacking) in
the middle of the manual rather than an appendix is a mistake.
In the middle, they're scary, and fool people into thinking they have
to read them (you don't have to read chapter 4 for a while, and most
people have no need to read chapters 5-7 at all). And chapter 8
(language reference) should probably come at the end, after the worked
examples of chapter 10.
But overall, I think the difference in tutorialness between the two
manuals is a difference of degree, not of kind.
Robotboy8
obscure functions built in, and these seem ( to me anyway, this could be argued
otherwise) to bog down the code quite a bit. On the other hand, it had a good
number of nice graphics functions.
Tads has a different feel to graphics functions - this feel has a distinctly
HTML flavor. It was easy to get started with, but quickly got prickly.
Again, I prefer Inform. While it has severely limited graphics capabilities,
there's always Glulx. I like the feel of its code, and besides: it compiles to
Inform-ish files, and is therefore nostalgic for someone who hacked his way
through Zorks I-III in a matter of panicked months.
T Raymond
[snippage]
>| That's funny - I'm most definitely a programmer and I prefer the
>| way Inform does it a lot. The verDo and verIo and so on of TADS
>| have me hopelessly confused, but that's due to the
>| inavailability of a tutorial-like manual (like the DM) for TADS.
>
>When you say 'inavailability of a tutorial-like manual for TADS',
>what did you find lacking in
[chapter snippage]
How about consistant and complete examples? Which had something to do
with my own tutorial site's creation. (Not that it is complete, but
it is an attempt at a consistant tutorial that builds on an initial
theme.)
>I do think that putting chapters 4-7 (about grody parser hacking)
>in the middle of the manual rather than an appendix is a mistake.
>In the middle, they're scary, and fool people into thinking they
>have to read them (you don't have to read chapter 4 for a while,
>and most people have no need to read chapters 5-7 at all). And
>chapter 8 (language reference) should probably come at the end,
>after the worked examples of chapter 10.
I agree with most of this, although I think the language reference
should come at the beginning, with more explanations. It should come
before working examples so that a new user should (hopefully) be
somewhat familiar with various objects before beginning to implement
them. But that's just my opinion.
Tom
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond adk AT usaDOTnet
"The original professional ameteur."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
David A. Cornelson
news:3ae85fdc...@newsserver.epix.net...
> Since writing about my experiences with a couple of easy IF
> languages for Stephen Granade's About.com site I've had some comments
> from readers about the relative difficulty of "non-easy" systems. So
> of course that made me curious. Putting aside the different
> capabilities, just looking at authoring standard IF without media, how
> would folks rank the big three of Inform, Tads and Hugo as to ease?
I have never completed much in Tads or Hugo and have used Inform
extensively.
To me, Tads is more of a 'traditional' OO language in that a C++ programmer
would see Tads and say 'ah-ha'! The same C++ programmer might see Inform and
recoil. In looking at Hugo they'd say, "well, this is better than Inform,
but this Tads thing is my style..."
Inform is yucky looking, has some very weird syntax characteristics, but
seems to lend itself to being hacked at as if it were a top-down language,
much like Basic. You still have to build objects, but you don't necessarily
need to do anything OO related to make a fair game. I think you can far more
easily avoid OO (object-oriented) knowledge in writing Inform than any of
the other two.
Hugo, to me, is Inform on steroids. It removes some of the weirdness of the
syntax and adds a lot of things that the z-machine is missing, but from my
own experience, it just isn't enough to make me want to switch from Inform.
There are other languages/compilers - but nothing has grabbed the IF
audience attention of Tads and Inform. Hugo seems destined to be Inform's
prettier, but dateless sister. (Sorry Kent). Tads has been arround forever
(I actually paid for a copy back in 1993) and therefore has a solid base of
users to support it. Inform has the whole Infocom/Z-Code/Nostalgia thing to
support it along with some of the better writers using it.
I still think someone could blow away these platforms with a client-server
multi-PC system, but that's just me.
No matter what, IF is hard stuff. Your analogy of the drawing commercial is
probably accurate. But once you make that leap, it's funny, it gets even
harder because then you have no excuse in writing a bad game. ;)
The coding is hard. The writing is hard. The coding and the writing is even
harder. No matter which system you pick, you're still learning a skill that
very few seem able to master, while most of us toy with mediocrity.
Jarb
Adam J. Thornton
David A. Cornelson <dcorn...@placet.com> wrote:
>I still think someone could blow away these platforms with a client-server
>multi-PC system, but that's just me.
It's hard and I'm busy. But yeah.
Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Alex Warren
> In article <DI4G6.917$R2.4...@newsrump.sjc.telocity.net>,
> David A. Cornelson <dcorn...@placet.com> wrote:
> >I still think someone could blow away these platforms with a client-server
> >multi-PC system, but that's just me.
>
> It's hard and I'm busy. But yeah.
Yeah well www.axeuk.com/qx to you, I say.
--
Alex Warren
al...@axeuk.com
Quest - Make adventure games easily - http://www.axeuk.com/quest/
Acius
> Adam J. Thornton wrote:
>
>
>> In article <DI4G6.917$R2.4...@newsrump.sjc.telocity.net>,
>> David A. Cornelson <dcorn...@placet.com> wrote:
>>
>>> I still think someone could blow away these platforms with a client-server
>>> multi-PC system, but that's just me.
>>
>> It's hard and I'm busy. But yeah.
>
> Yeah well www.axeuk.com/qx to you, I say.
What is the difference between this QX3 thing and a MUD? (I'm a MUD
coder generally, and have been lurking here to see if anyone has
anything interesting to say about NPC design...)
-- Acius
Alex Warren
> >>> I still think someone could blow away these platforms with a client-server
> >>> multi-PC system, but that's just me.
> >>
> >> It's hard and I'm busy. But yeah.
> >
> > Yeah well www.axeuk.com/qx to you, I say.
>
> What is the difference between this QX3 thing and a MUD? (I'm a MUD
> coder generally, and have been lurking here to see if anyone has
> anything interesting to say about NPC design...)
To be honest I'm not entirely sure what a MUD actually involves, but "this QX3
thing" gives you all the power of my IF language Quest, but with multiple
players. So you can set up a game world much like a standard IF game world, and
have multiple players walk around in it and interact with it (and each other) at
once. You connect to a QX3 server using the Quest software, so the players have
the same user interface as with a single-player game (buttons for quickly moving
around, taking objects etc.).
Iain
[...]
> Tads has a different feel to graphics functions - this feel has a distinctly
> HTML flavor.
You do realise you were using HTML-TADS, right?
I totally agree with Dan Schmidt's point elsewhere in the thread -- TADS
can look fearsome to non-programmers but is pretty logical and consistent
when you understand it, while Inform is, well, not quite so logical or
consistent but has lots of nifty IF-specific features. However, I think to
some extent the tables are turned when it comes to multimedia.
TADS uses HTML, which means it's fairly easy to get into; it has definite
limitations, but as long as you work within them it's usually pretty
straightforward to get the effect you want.
Glulx, on the other hand -- or rather, the Glk I/O model -- takes a
programmatic approach. To do fancy multimedia stuff, you have to call all
sorts of weird and wondeful functions. It's very powerful, but (I think)
bloody difficult to use.
I think the HTML-TADS approach scores over Glulx/Glk in that the TADS
library doesn't get in your way; all you have to worry about is one HTML
'banner' for the status bar. In Glulx you've got to explicitly keep track
of what all your windows are doing, and it strikes me as being a lot more
fiddly.
Hugo is also strong on multimedia, but I don't know much about it. Anyone
care to tell us how easy-to-use and powerful it is? (Yes, I'm talking to
you, Sherwin.)
But I'm not going to mention the Z-machine. If you want to do Z-machine
multimedia, you are insane.
--
Iain Merrick
i...@spod-central.org
Neil Cerutti
>Robotboy8 wrote:
>[...]
>> Tads has a different feel to graphics functions - this feel
>> has a distinctly HTML flavor.
>
>You do realise you were using HTML-TADS, right?
>
>I totally agree with Dan Schmidt's point elsewhere in the thread
>-- TADS can look fearsome to non-programmers but is pretty
>logical and consistent when you understand it, while Inform is,
>well, not quite so logical or consistent but has lots of nifty
>IF-specific features.
I think Inform is very easy to read and my guess is that it was
designed that way even at the expense of being easy to write. As
has been oft suggested, for the syntax, look at Roger Firth's
Cloak of Darkness pages, which includes sample code for
indentical games in each system.
http://homepages.tesco.net/~roger.firth/cloak/index.html
Hugo and Inform only really (in my opinion) trounce TADS in the
syntax arena with the excellent grammar declaration style
invented by Graham Nelson, which Hugo wisely stole.
But this discussion is going nowhere if it focuses only on syntax
differences. The standard libraries for each is where the
differences really reside, and you have to use them for
non-trivial things before you know if they are for you.
At first sight, all the systems support basically the same things
in the standard library: doors, containers, vehicles, switching
PCs, etc... Hugo has an excellent skeleton for NPC actions in
place. Inform (and TADS?) assume that only the PC ever perform
actions, so much more manual coding may be required.
The tone of each library's default responses differ, with
Inform's being the most serious, succinct and... snooty; Hugo's
being in the more vernacular end of the spectrum, and TADS' being
somewhere in the middle of it. TADS seems to be closest to the
tone of the typical early Infocom game, to me.
Serious parser changes can be accomplished in Inform without
hacking the library. TADS 2 isn't as configurable (but TADS 3 is
on the way). I don't know much about Hugo in this area.
All of the systems seem to provide the same basic facilities for
coding responses to special cases in your game (Graham Nelson has
called IF programming a series of special cases). For example,
using Inform you can change the default behavior before anything
happens (an opportunity to do anything, conceivably) or after
everything has happened; in this latter case you can only change
the default response, or cause side effects. If you want
significantly more granularity of special casing, you have to use
non-standard libraries, like Platypus, or write very large before
routines. Inform could use a stronger ability for causing
side-effects; you can't really do it easily unless an action is a
"type 3" action, and it succeeds.
So don't just read the syntax. Download the manuals and read
them, and find out what you think of the standard libraries.
--
Neil Cerutti <cer...@together.net>
*** Your mule was judged "best built" at the colony fair. You
won $200. ***
Tina
Dan Schmidt <df...@harmonixmusic.com> wrote:
>emay...@epix.net (Eric Mayer) writes:
>
>| Since writing about my experiences with a couple of easy IF
>| although, to me, Tads actually looks more mind-bending. Does it just
>| come down to personal taste?
Yes. That is the answer. Why do I think that? Because, among other
things...
>The effect of this difference in style seems to be that (_in general_)
>TADS makes somewhat more sense to programmers than Inform does, because
>of its regular syntax and semantics, while Inform makes somewhat more
>sense to non-programmers than TADS does, because of the way it provides
>'syntactic sugar' for standard IF concepts. Both languages have fine
>manuals at this point.
...I can't agree with this, as someone with a programming background.
I think it is /mostly/ dependent on just what your programming background
is. I suspect most people who find TADS more intuitive have a C++ or Java
background. I have a perl (and C, and Pascal -- eek!) background. I find
Inform more intuitive. I suspect most straight C coders would, as well.
I certainly don't dislike TADS, but it doesn't fit what I'm most used to.
What's more, I think Inform's syntax is just as regular as TADS', which
speaks of a different experience than Dan has had.
As to which one would be easier to a non-programmer, personally, I feel the
answer is still "it depends on the person". I actually think it takes
the same kinds of skills to succesfully make a plot as it does to
succesfully write a program (though I bet that opinion could easily lead to
loads of arguments in itself), so it's just going to be a matter of
which structure works better with the author's approach.
For instance, I suspect that people who approach their game-writing in an
outline fashion could easily find TADS works better for them, whereas
folks who write stuff out in story-like form probably -would- think "move
foo to bar" was more intuitive.
I have no real experience with Hugo, so can't really speak to that.
Stephen Granade
> In article <wkae53i...@turangalila.harmonixmusic.com>,
> Dan Schmidt <df...@harmonixmusic.com> wrote:
> >emay...@epix.net (Eric Mayer) writes:
> >
> >| Since writing about my experiences with a couple of easy IF
> ...
> >| although, to me, Tads actually looks more mind-bending. Does it just
> >| come down to personal taste?
>
> Yes. That is the answer. Why do I think that? Because, among other
> things...
>
> >The effect of this difference in style seems to be that (_in general_)
> >TADS makes somewhat more sense to programmers than Inform does, because
> >of its regular syntax and semantics, while Inform makes somewhat more
> >sense to non-programmers than TADS does, because of the way it provides
> >'syntactic sugar' for standard IF concepts. Both languages have fine
> >manuals at this point.
>
> ...I can't agree with this, as someone with a programming background.
>
> I think it is /mostly/ dependent on just what your programming background
> is. I suspect most people who find TADS more intuitive have a C++ or Java
> background. I have a perl (and C, and Pascal -- eek!) background. I find
> Inform more intuitive. I suspect most straight C coders would, as well.
> I certainly don't dislike TADS, but it doesn't fit what I'm most used to.
To add another data point more on Dan's side, I prefer TADS to
Inform, and my programming background is entirely C, with a smattering
of perl.
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit About Interactive Fiction
Duke University, Physics Dept | http://interactfiction.about.com
Dennis G. Jerz
news:jd66fqn...@login2.phy.duke.edu...
FWIW, I am fairly competent in Perl, and learned C++ and Java for older
projects I'm no longer maintaining. I was thoroughly charmed by the Inform
manual the third or fourth time I sat down with it, but overwhemed and
frustrated with it initially (e.g. why does "Getting started" come in
chapter 7?). I went with Inform in part because of Zplet. Great for dallyers
and newbies, whose difficulties with downloading and installing programs in
this mouse-clicky world are not trivial. (See the "What, no exe's?" thread a
while back.)
Inform does have a steep learning curve, but as I recall much of what caused
me frustration was figuring out how to run the compiler; figuring out I had
to add ".h" to the end of some file names; finding a text editor that
doesn't add ".txt" to every file I save, and assorted silliness like that --
from which I tried as much as possible to shield my students.
This year the 3 students who chose Inform projects have picked up the
language very quickly. Just a few weeks into the course, we had a 50-minute
speed quiz, in which they were supposed to slap together a game with certain
features, much like a SpeedComp. All 3 did the exercise just fine -- far
better than I could possibly have done months after I first peeked at
Inform.
--
Dennis G. Jerz, Ph.D.; (715)836-2431
Dept. of English; U Wisc.-Eau Claire
419 Hibbard, Eau Claire, WI 54702
------------------------------------
Literacy Weblog: www.uwec.edu/jerzdg
Dan Schmidt
| In article <wkae53i...@turangalila.harmonixmusic.com>,
| Dan Schmidt <df...@harmonixmusic.com> wrote:
|
| >The effect of this difference in style seems to be that (_in general_)
| >TADS makes somewhat more sense to programmers than Inform does, because
| >of its regular syntax and semantics, while Inform makes somewhat more
| >sense to non-programmers than TADS does, because of the way it provides
| >'syntactic sugar' for standard IF concepts. Both languages have fine
| >manuals at this point.
|
| ...I can't agree with this, as someone with a programming background.
|
| I think it is /mostly/ dependent on just what your programming background
| is. I suspect most people who find TADS more intuitive have a C++ or Java
| background. I have a perl (and C, and Pascal -- eek!) background. I find
| Inform more intuitive. I suspect most straight C coders would, as well.
| I certainly don't dislike TADS, but it doesn't fit what I'm most used to.
Fair enough. Interestingly (maybe), I think of Inform as the Perl of
IF languages, and of TADS as the Python.
| What's more, I think Inform's syntax is just as regular as TADS', which
| speaks of a different experience than Dan has had.
That's surprising to me. Here are some things I find a bit irregular
about Inform's syntax:
- -> to mean 'child of previous object'
- move x to y
- with <properties>
- has <attributes>
- obj in obj2
- give obj attribute, give obj ~attribute
- obj has attribute, obj hasnt attribute
- function definitions: [ variables; code; ]
- the alternate function-calling syntax, e.g., print (The) obj,
- <additional command>
- <<redirected command>>
- Object object_name "name" location
- implicit switch on action
- different implicit return values depending on what name your
function has (I guess this is semantics, not syntax, though)
- ##Verb
- the special syntax for defining/extending verbs
- special directives such as Release, Replace
Mind you, I'm not complaining about any of these irregularities; as in
Perl, they all exist in order to make the programmer's job easier, and
to bring the code closer to the concepts in the programmer's mind.
But there are a bunch of them, and I don't see any overall regularity
binding them together.
On the other hand, TADS has a few idiosyncrasies, but from a syntactic
point of view it seems an order of magnitude simpler to me. The only odd
syntactic things that occurs to me off the top of my head are the lack of
separators between properties, and "<<embedded code>> in strings". Other
than that, you pretty much just call functions to accomplish almost all
of the things I put in the above list.
For better or worse, it appears that TADS 3 will have a more interesting
syntax if you want to use it. For example, it will have a (general and
programmer-modifiable) object template facility for writing things like
Inform's 'Object object_name "name" location', and an equivalent to
Inform's '->'.
Dan Schmidt
| Serious parser changes can be accomplished in Inform without
| hacking the library. TADS 2 isn't as configurable (but TADS 3 is
| on the way). I don't know much about Hugo in this area.
Interestingly, I first started using TADS seriously when I needed to
do some serious parser hacking, and I couldn't do it easily in
Inform. While Inform's parser is written in Inform and thus available
for modification, it's some seriously gnarly code. TADS' isn't as
close to the surface, but it does expose around sixty zillion hooks
that so far have proved sufficient for all of my needs.
I hasten to add, in case it wasn't clear from previous messages, that I
like both languages a great deal and program in both of them regularly,
depending on the needs of my project.
Iain Merrick
>ti...@eniac.stanford.edu (Tina) writes:
[...]
>> I suspect most people who find TADS more intuitive have a C++ or Java
>> background. I have a perl (and C, and Pascal -- eek!) background. I find
>> Inform more intuitive. I suspect most straight C coders would, as well.
>> I certainly don't dislike TADS, but it doesn't fit what I'm most used to.
>
>To add another data point more on Dan's side, I prefer TADS to
>Inform, and my programming background is entirely C, with a smattering
>of perl.
Right. I like C and C++ about equally, and I prefer TADS to Inform.
I really don't think that TADS is C++ to Inform's C.
For me, the main difference is that TADS is much more C-like, at least
syntactically. Inform uses different symbols from C for almost everything
-- different block delimiters, different comparison operators, that sort
of thing.
Semantically, TADS isn't much like C; but as far as I can see, neither is
Inform. It doesn't have pointers; it doesn't even have a standard 'malloc'
function.
When it comes to OO, neither TADS nor Inform is much like C++, so I don't
think there's a big difference there.
Possibly TADS appeals to people with previous experience of more
high-level, dynamic languages, where it's taken for granted that you can
create and manipulate strings and lists and things on the fly.
I'm not sure where that leaves Inform, but it obviously appeals to many
people. Maybe people who've used small computers tend to like it, since it
produces tight compact code and you generally know what it's doing at a
low level. The use of Z-code assembly, in particular, strikes me as very
reminiscent of hobbyist hacking back in the halcyon days when home
computers had 32KB of RAM and built-in BASIC.
--
Iain Merrick
i...@spod-central.org
Michael Sousa
Tina wrote:
>
> I think it is /mostly/ dependent on just what your programming background
> is. I suspect most people who find TADS more intuitive have a C++ or Java
> background. I have a perl (and C, and Pascal -- eek!) background. I find
> Inform more intuitive. I suspect most straight C coders would, as well.
> I certainly don't dislike TADS, but it doesn't fit what I'm most used to.
My background is C and Pascal and prefer the style of TADS over Inform. I
guess it's just a matter of preference.
-- Mike
Robb Sherwin
>Hugo is also strong on multimedia, but I don't know much about it. Anyone
>care to tell us how easy-to-use and powerful it is? (Yes, I'm talking to
>you, Sherwin.)
It was pretty easy to just get graphics up there, initially -- the
source code to Guilty Bastards provides a working example of how to
split the screen, (with graphics and text each getting a
programmer-definable chunk) and I pretty much just experimented with
that.
Since Comp2K, I've realized that you can set the display to either
take a portion of the screen no matter the resolution (for instance,
graphics at 30% and text at 70% no matter if the user is at 640x480 or
1280x800 -- and the could graphics shrink if necessary) or to make it
absolute (the graphics will be displayed x-many pixels in size, and
the larger resolution the user happens to have, the more room for game
text).
Manipulating the screen, on the whole, seems pretty flexible -- I've
got the screen split into four independent "windows" for the thing I'm
working on right now, and have it divided up so that two of them will
show graphics, one will show inventory, and one is the main-game text
display. Additionally, you could probably duplicate the interface used
in any of The Bard's Tale games with Hugo, and implement something
that the IBM PC Magnetic Scrolls games had, where the user can select
the amount of screen utilized for pictures on the fly without too much
trouble.
The way I've done music, previously, is to just play a new song when
the player enters a particular area and then just set a flag so it's
not played every time that location is entered. If I had to do it
again, I'd probably write a new routine that would accept input from
the player (well, volume level, and on/off), allow for some songs
(like ambient music) to be repeated in certain sections, and allow it
to possibly pull songs randomly from the resource file. I don't think
there's any source code out there that effectively duplicates the kind
of cool stuff done in (say) the first Unreal, but writing such a thing
would be more along the lines of "interesting craft project" than
"excruciating chore programming that elicits foul obscenities."
You can also configure your Hugo .hex story file to not run if the
multimedia resource file(s) aren't present, if you wish that behavior
as an author.
A note: I don't really have anything to compare my experiences to, as
I have not attempted to use graphics and sound in HTML-TADS or Glulx.
It could very well be that one system puts the others to shame in
terms of ease of use. But on the whole though, multimedia in Hugo has
been a pleasant, intuitive endeavor for me.
Robb
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robb Sherwin, Fort Collins CO
Reviews From Trotting Krips: http://ifiction.tsx.org
Knight Orc Home Page: www.geocities.com/~knightorc
OKB -- not okblacke
I have experimented briefly with C and C++ and found them insufferable.
Despite the stigma, I'm fond of QBasic, but recently I've come to be enamored
of Haskell.
The first IF language I looked at was TADS. This was back in the day,
before HTML-TADS, and when I paid for internet access by the hour, so I
downloaded the manuals in plaintext form and then couldn't understand them.
Inform, by contrast, was much easier to get started with. I haven't looked
much at Hugo.
I've found that in most cases the weaknesses of Inform lie more with the
standard library or the Z-machine than with the language itself. I've gotten
around the former by hacking the library like a maniac (and I've started to
look at Platypus), and the latter by moving to Glulx.
--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
Sean T Barrett
>That's surprising to me. Here are some things I find a bit irregular
>about Inform's syntax:
Shortcuts are no big deal--you don't have to learn or use them:
> - the alternate function-calling syntax, e.g., print (The) obj,
> - -> to mean 'child of previous object'
several of the things you listed are just infix operators like "+":
> - obj in obj2
> - obj has attribute, obj hasnt attribute
(although I admit "hasnt" is a bit silly.)
several of them are the only definition syntax provided at all,
so I'm not sure what it's supposed to be irregular with respect to:
> - function definitions: [ variables; code; ]
> - with <properties>
> - has <attributes>
> - Object object_name "name" location
> - the special syntax for defining/extending verbs
> - special directives such as Release, Replace
(I mean, would you complain that C's syntax is irregular because
you use [] in some cases, {} in some cases, and () in others? I
guess a LISP programmer would.)
and many of them are irregularities:
> - move x to y
> - give obj attribute, give obj ~attribute
> - <additional command>
> - <<redirected command>>
> - implicit switch on action
> - ##Verb
> - different implicit return values depending on what name your
> function has (I guess this is semantics, not syntax, though)
One major issue is that these are not just syntactic irregularities;
you can override the behavior of any function call, but you can't
override "move x to y" or "give obj attribute"--that this is a
problem is obvious from the number of times newbies make the mistake
of trying "move player to y" instead of calling PlayerTo(y) or whatever
exactly it's called.
Since the point of this thread was supposed to be about the issues
of the "harder" languages vs. the easy languages, in my opinion
the issue is really that if you're using the harder languages, it's
because you want to do advanced things. The problem with Inform
for doing advanced things is the semantic irregularities--and the
hackiness of much of the standard libraries.
SeanB
Kevin Forchione
news:20010428002438...@ng-da1.aol.com...
> Just throwing my opinion in. . .
>
the
> standard library or the Z-machine than with the language itself. I've
gotten
> around the former by hacking the library like a maniac (and I've started
to
> look at Platypus), and the latter by moving to Glulx.
The future of Inform does seem to lie in Platypus and Glulx. Platypus
library looks like a brilliant solution to many of the problems present in
the standard library. It may be, however, that the Inform library could use
a thorough rewrite from the ground up, based on the collective experience of
its authors over the past 8 or so years.
In comparing TADS and Inform one looks not only at the syntax of the
language, but the methodology presented by the two libraries, the
implementation of its command processing, and the sophistication of its
model world. My general feelings run something like this:
The Inform library is largely procedural in nature, implementing an object's
default behavior through an examination of the object's attributes.
Exceptional behavior is implemented largely through two object methods that
allow an author to modify the behavior / display either before or after the
default mechanism has been called. The drawback to this approach is that the
library has to be aware of the kinds of behaviors allowable for various
classes. The perceived advantage is that one has only to look in a specific
routine to determine how each class of object will be treated by the
library.
TADS library has increasingly evolved to a more object-oriented approach
that is easiest described by example: A listing in Inform would begin with
an object, assess its attributes, list it, get the object's contents, assess
their attributes, and list them, etc. TADS, increasingly, would request the
object to "list itself", in which case the object would produce the
appropriate list based on its attributes. It would then pass this request to
each of its contents, allowing them to "list themselves". Default behavioral
overrides may occur in any of the objects by simply overriding the method
directly actioned. This same kind of pattern is adopted in other situations,
though it is not cleanly implemented in the standard library. The advantages
are that the library does not have to be aware of the behaviors of its
classes. The perceived drawback, of course, is that in order to determine
how an object is going to behave you have to examine the object and its
derivations.
I won't go into an examination of the command execution process or the model
world at this point in time. But I believe that these other elements are
also equally important in determinations of relative difficulty between the
two systems. On a general note, however, it is *generally* agreed that
object-oriented applications are easier to maintain and modify, but far more
difficult to conceive and design than are procedural applications. Grasping
the overall library processes behind TADS *is* more difficult than for
Inform, but no one will argue that the Inform library is less sophisticated
than the standard TADS library. Rather it is more difficult to visualize the
way in which the classes/objects in TADS interact to perform the action of
the command.
--Kevin
Tina
Dan Schmidt <df...@harmonixmusic.com> wrote:
>ti...@eniac.stanford.edu (Tina) writes:
>| I think it is /mostly/ dependent on just what your programming background
>| is. I suspect most people who find TADS more intuitive have a C++ or Java
>| background. I have a perl (and C, and Pascal -- eek!) background. I find
>| Inform more intuitive. I suspect most straight C coders would, as well.
>| I certainly don't dislike TADS, but it doesn't fit what I'm most used to.
>
>Fair enough. Interestingly (maybe), I think of Inform as the Perl of
>IF languages, and of TADS as the Python.
Not having ever done more than glance at Python, I have no idea how
accurate this is. Obviously, however, given other responses in this thread,
my characterization is as inaccurate as any other generalization tends to
be, but I can hardly say I'm surprised. :) It's based totally on my
experience, which is, well, limited to a small sample size.
In fact, reading through the rest of your note, it occurs to me one thing I
left off my list of experience in coding was tinyMUSH softcoding, which
actually may have more to do with why I find Inform intuitive than perl did.
>| What's more, I think Inform's syntax is just as regular as TADS', which
>| speaks of a different experience than Dan has had.
>
>That's surprising to me. Here are some things I find a bit irregular
>about Inform's syntax:
>
> - -> to mean 'child of previous object'
Hmm, this makes sense to me on a purely logical level. It's ... like
threading in TRN.
> - move x to y
> - with <properties>
> - has <attributes>
> - obj in obj2
> - give obj attribute, give obj ~attribute
> - obj has attribute, obj hasnt attribute
...
> - Object object_name "name" location
Here's where the tinyMUSH experience fits, I think. It seems perfectly
logical to me to define things in this manner. You have object foo. You
define it via the properties/attributes it has. When you test for things,
you classify those properties and attributes as the important test factors.
Everything is an object, so you move things around as if you were handing
them off to other things (including rooms and players).
[more examples deleted]
I honestly think the rest of the things you find odd are purely stylistic
in nature; that is to say, they logically work out to the same thing as
some other syntax would give you, but they're simply notationally
different. I suppose that might qualify as 'irregular' given a specific set
of experiences but to me, it seems to fit as a whole.
OKB -- not okblacke
>It may be, however, that the Inform library could use
>a thorough rewrite from the ground up, based on the collective experience of
>its authors over the past 8 or so years.
I agree. The real kicker would be if some way could be found to meld the
two, so that old libraries would still work without modification, but new games
and libraries could make use of the new features of the library.
John W. Kennedy
>
> "Kevin Forchione" Ke...@lysseus.com wrote:
> >It may be, however, that the Inform library could use
> >a thorough rewrite from the ground up, based on the collective experience of
> >its authors over the past 8 or so years.
>
> I agree. The real kicker would be if some way could be found to meld the
> two, so that old libraries would still work without modification, but new games
> and libraries could make use of the new features of the library.
Errr.... That's how it is. The Inform library is compiled and/or
linked into the Z-machine game file. Old is old and new is new, and
there's no conflict.
--
John W. Kennedy
(Working from my laptop)
Neil Cerutti
>That's surprising to me. Here are some things I find a bit
>irregular about Inform's syntax:
>
> - -> to mean 'child of previous object'
>
> - move x to y
>
> - with <properties>
- with property, property, property
>
> - has <attributes>
- has attribute attribute attribute
I don't like it.
> - obj in obj2
>
> - give obj attribute, give obj ~attribute
>
> - obj has attribute, obj hasnt attribute
This one bites even experienced Inform programmers after a long
abstinence.
> - different implicit return values depending on what name your
> function has (I guess this is semantics, not syntax, though)
Yes, embedded routines return false, and non-embedded(?) routines
return true. I would like it if they returned neither and
printed a compiler error.
> - ##Verb
This is one of the last few remaining # warts. There used to be a
lot of them.
>Mind you, I'm not complaining about any of these irregularities;
>as in Perl, they all exist in order to make the programmer's job
>easier, and to bring the code closer to the concepts in the
>programmer's mind. But there are a bunch of them, and I don't
>see any overall regularity binding them together.
>
>On the other hand, TADS has a few idiosyncrasies, but from a
>syntactic point of view it seems an order of magnitude simpler
>to me. The only odd syntactic things that occurs to me off the
>top of my head are the lack of separators between properties,
>and "<<embedded code>> in strings". Other than that, you pretty
>much just call functions to accomplish almost all of the things
>I put in the above list.
>
>For better or worse, it appears that TADS 3 will have a more
>interesting syntax if you want to use it. For example, it will
>have a (general and programmer-modifiable) object template
>facility for writing things like Inform's 'Object object_name
>"name" location', and an equivalent to Inform's '->'.
Here's the "original Inform criticism" by Dave Baggett, author of
WorldClass and several great games.
Now that Google's back up, Just search for "Specific Inform
criticism" to find the messages.
It's detailed and has a response from the designer.
--
Neil Cerutti <cer...@together.net>
Greg Ewing
>
> Dan Schmidt <df...@harmonixmusic.com> wrote:
> >I think of Inform as the Perl of
> >IF languages, and of TADS as the Python.
>
> Not having ever done more than glance at Python, I have no idea how
> accurate this is.
As far as the Python comparison goes, it's very accurate. TADS
and Python are remarkably similar, both in syntax and underlying
models of data and execution.
Inform and Perl aren't really much alike at all, except insofar
as they both have a lot of quirky syntax.
> I honestly think the rest of the things you find odd are purely stylistic
> in nature; that is to say, they logically work out to the same thing as
> some other syntax would give you, but they're simply notationally
> different.
Many things in Inform seem irregular, not so much with respect to
other parts of Inform, but to corresponding things in other programming
languages. Special syntax is justifiable for things which are unique
to IF, e.g. for specifying the command grammar. But I fail to see
why IF needs an entirely new syntax for defining functions or
indexing arrays.
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
OKB -- not okblacke
I said old libraries, not old games. Certainly, compiled game files will
still work as long as there isn't a change in the basic structure of the
compiled format. The problem is that library extensions written for an old
standard library may not work with a new standard library. This means game
authors have to: A) write a new library; B) hack the old library to fit the new
standard lib; C) wait for a new library to be written; or D) go back to the old
standard lib.
LoneCleric
Robb Sherwin wrote:
> A note: I don't really have anything to compare my experiences to, as
> I have not attempted to use graphics and sound in HTML-TADS or Glulx.
> It could very well be that one system puts the others to shame in
> terms of ease of use. But on the whole though, multimedia in Hugo has
> been a pleasant, intuitive endeavor for me.
Same here. Hugo was the first and only "new" IF language I tried. (I looked at
AGT back in '95, but that hardly counts.)
Why did I choose it? Well, almost everyone "back then" (read that as "a year
and a half ago"), everyone seemed to agree that the "big three" was made of
Inform, TADS and Hugo. However, on the GMD itself, Hugo clearly appeared to be
the "neglected brother", with only a few games. So basically, I decided to "go
for the underdog". Of course, the fact that it supported multimedia and that
Kent was frequently available on ifMUD were a definite plus.
How easy was it? Well, I should probably mention that I'm a professional C++
developer, and that I've been programming in one form or another for a while.
I picked up the manual expecting a language that would make it easy for me to
created simple IF stuff, while at the same time giving me the power to do
whatever I'd like in the end. That's exactly what I got.
Did I enjoy it? I sure did. Kent was prompt to respond to questions & bug
reports. I also got some help from fellows Hugo coders (er, hmm, well, from
Jason Dyer actually - there just aren't that many Hugo guys... yet). Since
January, I wrote two SpeedIF entries, my first "official" game, plus another
smallish game I intend to turn into a Hugo tutorial. At this point in time, I
see no reason to try anything else, especially with Kent working on a Palm
interpreter. (Right, Kent, right?? :-) )
In conclusion:
You go, I go, we all go for Hugo! (I know, it's cheezy, but I like it.)
LC
Andrew Plotkin
> "John W. Kennedy" jwke...@bellatlantic.net wrote:
>>OKB -- not okblacke wrote:
>>>
>>> "Kevin Forchione" Ke...@lysseus.com wrote:
>>> >It may be, however, that the Inform library could use
>>> >a thorough rewrite from the ground up, based on the collective experience
>>> >of its authors over the past 8 or so years.
>>>
>>> I agree. The real kicker would be if some way could be found to
>>> meld the two, so that old libraries would still work without
>>> modification, but new games
>>> and libraries could make use of the new features of the library.
>>
>>Errr.... That's how it is. The Inform library is compiled and/or
>>linked into the Z-machine game file. Old is old and new is new, and
>>there's no conflict.
>
> I said old libraries, not old games. Certainly, compiled game files
> will still work as long as there isn't a change in the basic
> structure of the compiled format. The problem is that library
> extensions written for an old standard library may not work with a
> new standard library.
Honestly, library extensions are a tiny part of the problem. Being
compatible with old game code is a much larger task[*].
If a game author has to throw away his existing code when upgrading to
a new standard library, the lack of library extensions isn't even
going to surface as an issue. It's back to square one no matter what.
Anyway, a new library is going to address many of the concerns that
existing library extensions were built for.
[* And maybe not even a possible task at all. I would go so far as to
say "probably not possible".]
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* George W. Bush was elected with just five votes.
Matthew T. Russotto
Greg Ewing <s...@my.signature> wrote:
}
}Many things in Inform seem irregular, not so much with respect to
}other parts of Inform, but to corresponding things in other programming
}languages. Special syntax is justifiable for things which are unique
}to IF, e.g. for specifying the command grammar. But I fail to see
}why IF needs an entirely new syntax for defining functions or
}indexing arrays.
Inform, being typeless, can't use the C or Pascal system for indexing
arrays. I believe the Inform system was taken from some other obscure
language. The function syntax is derived another Z-machine quirk,
probably.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Dan Schmidt
| Tina wrote:
| >
| > Dan Schmidt <df...@harmonixmusic.com> wrote:
| > >I think of Inform as the Perl of
| > >IF languages, and of TADS as the Python.
| >
| > Not having ever done more than glance at Python, I have no idea
| > how accurate this is.
|
| As far as the Python comparison goes, it's very accurate. TADS
| and Python are remarkably similar, both in syntax and underlying
| models of data and execution.
|
| Inform and Perl aren't really much alike at all, except insofar
| as they both have a lot of quirky syntax.
Yes, that's what I mean; plus the fact that they both have a lot of
hacks in them that are really useful but would give Niklaus Wirth a
heart attack. I mean 'hack' in a good way, really; I like Perl too.
| Many things in Inform seem irregular, not so much with respect to
| other parts of Inform, but to corresponding things in other
| programming languages.
Yes again.
OKB -- not okblacke
>Honestly, library extensions are a tiny part of the problem. Being
>compatible with old game code is a much larger task[*].
>
>If a game author has to throw away his existing code when upgrading to
>a new standard library, the lack of library extensions isn't even
>going to surface as an issue. It's back to square one no matter what.
>
>Anyway, a new library is going to address many of the concerns that
>existing library extensions were built for.
How often do game authors make this kind of a switch mid-game anyway,
though? I mean, if I'm in the middle of coding a game, I'm not likely to
switch to a new standard lib -- even if it advertises that old code will still
work. I may use the new lib for later games, but not for works-in-progress.