any need for tads-like languages?
Gu
don't understand a thing and i need some answer.
i'm fairly new to if as a player and as a author. i'm not new to
programming (i've been programming for 15 years, so far) and the
"technical" side of if really intrigues me so that i'm programming my
own if language not to become famous or to make it mainstrem but
solely to delight myself.
said that, i'm looking through most of the languages out there to
understand exacly what a language should be able to, to see how they
works etc.
i think alan is a great and powerful language, so easy one could start
coding an adventure in a couple of hours after getting the manual.
adrift is proving to be mature and solid and i like the way adventures
are constructed with it.
inform and tads seem to be the most used languages and i don't
understand why. as far as i've seen they (together with hugo) are (or
are getting) so huge and complicated and full of options that they're
turning, imho, completely useless. i've seen a tetris programmed in
inform, and this in terrible.
what i don't understand is why one should "invest" (learning or
developing) in one of those languages. a tads file looks as
complicated as a c one. why should i learn tads while learning c /
java / delphi / python would take the same time? why should i work an
a library for inform rather that on a dll for c?
i mean, of course there's an "advantage" of years of programming and
codes, but i think libraries dedicated to if for other major languages
would be much better. an if language is useful when it is easy and
streight forward, inform and tads and hugo are not. if tads'd be a
library for c, for example, i'd have:
- a equally complex language (not that this a good thing)
- a lots more documentation and community to ask help (the tads
specific one plus the whole c community for what concerns the
language)
- the same things (in the form of c objects and functions)
- more flexibily (libraries can be adapted and be used server-side for
web-based if, included in the .net framework, adapted to be
multi-platform and be compiled under all the systems running c, or
virtually anyone, imported into a customized gui and so on)
- a easier / faster development as tads developers should only
concentrate on the "functions" not on the "language". while the c
community works on a better "if" statement (for example), they'd
concentrate on a better parser able to understand adverbs (see
previous posts)
- all the rest (the game looking online for a new version of the
adventure and upgrade to it would be a matter of an include and a call
to a server. just a rough example).
the same, of course, for any other complicated if language and any
other major language (inform as a java library, hugo as a python
include and so on..)
really, why do spend years programming testing a debugging an if
language to announce the groundbreaking news it's gone completely
object-oriented while in the same time one could have been simply
developing a library and a user interface for a stable object oriented
programming language?!
my personal experience: my "language" runs indeed within php. in the
first 5 days of developement i had my own adaptation of cloak of
darkness running on my pc. if i had started everything from scretch
(or started creating something already created 1000 times), i'd be
still stuck on the "if x==y" statement.
just my opinion, of course..
---
that said, i'll add that developing libraries for a language like c is
not the way to go, in my opinion of course. i know this may sound in
clear contrast with what i wrote previously.
c is not easy, and almost any major language out there is too tough to
write if. i underline "to write if". the problem is that in a big
softwarehouse (pick one at your choice) no one pretends that a coder
have to be a graphician, no one wants a musician to be a system admin.
in the if word all the figures that generally rotate around the
creation of a game are concentrated into one single person: the game
designer, the writer, the coder..
there are very few exceptions where one author is equally good in the
three things i've mentioned and this results in games with great
concepts poorly developed, great pieces of writing hidden by
inappropriate code.
the real question is whether we want to play and enjoy and like and
talk about text adventures or interactive fiction. i don't want to go
into a theoretical analysis of the terms, just bear with me and the
different use i'll do of the definitions in this single post.
a text adventure is an _adventure_ played in a "textual way".
a piece of if is a _fiction_ that is interactive.
it seems that the wider spread use of "if" over "ta" makes it more
relevent the fiction side over the adventure one. of course a piece of
fiction can be very "adventurous".
if i'm playing an adventure, a description like "you're in a big room.
there are three bottons on a wall" is ok because my attention will be
on the eventual puzzle, on the search for the "you win" text to
appear.
if i'm reading an interactive fiction, that description of a room is
totally inappropriate.
what i want to say is that for writing adventure you have to be a
better coder, for writing if you need to be a good writer. (i know,
you need all the things gathered into one person, but i'm keeping the
two things distincted and i'm talking for people much better at a
thing that at the other).
now, while no one can teach you getting the idea for the if of the
century, no one can give you the wit, the sensibility, the
intelligence to become a good writer, one can teach you to program.
the problem is that complicated languages to write if ends up to keep
away from the creation pocess the pure writers, while they are not a
problem for the coders. but a coder is not necessarely a good writer
and while it is fairly easy to to pretend to be a writer (as we all
suppose anyone can at least read and write), one cannot pretend to be
a coder and start coding even a basic "hello word" program without
cetain knowledge. but writing if is not like writing a christmas
postcard to aunt victoria, knowing the 26 letters is not enough.
complicated authoring systems doom the if community to be
self-alimenting and close, hard to get into. it will be dominated more
and more by self-pretending writers that are coders and will lack of
writers and creative. it is actually full of people great enough to
program magnificent games and write good stories (i love you all!!),
but a look into the future is to be taken. most people that are now in
the if community were once little kids with a commodore, a spectrum
machine, computers where "using" and "programming" were almost the
same thing. the average computer user is now less expert and
completely uneware of what a boolean operation is. unfortunately (or
fortunately) this "average computer user" can have the best ideas,
can be a fantastic writer whose stories we'll never know, we'll never
play.
easier languages such as adrift or alan are giant steps forward a
"people republic of interactive fiction". william b.yeats shouldn't
need to know what an include or a main{} function is to express
himself.
i'm sure you all are cleaver enough to know that every single word
i've written is just my opinion and my point of view, i'd hate to read
a single "inform is perfect and you're a dumbass" commment.
gustavo
cub...@aol.com
> what i don't understand is why one should "invest" (learning or
> developing) in one of those languages. a tads file looks as
> complicated as a c one. why should i learn tads while learning c /
> java / delphi / python would take the same time? why should i work an
> a library for inform rather that on a dll for c?
"invest" in any other language whatsoever?
IF is about issuing commands that alter the behavior of a
world-model. The creation of such a world-model is not a trivial task.
Basically, your complaint is that nobody has yet managed to shoehorn
the complexity of said task into any kind of language or system or
*something* which is transparently accessible to even the greenest
newbie; while your complaint does happen to be true -- nobody *has* yet
managed to shoehorn, etc -- it also ignores the fact that creating a
world-model just plain *is* Highly Complex, end of discussion. It's not
clear that that sort of shoehorning is even *possible*, nor is it clear
that, even were it possible in the first place, that sort of
shoehorning is *desirable*. An analogy: Would you *want to* design a
control panel that would allow a 4-year-old to run a nuclear power
plant?
Gu
>Gu wrote:
>> what i don't understand is why one should "invest" (learning or
>> developing) in one of those languages. a tads file looks as
>> complicated as a c one. why should i learn tads while learning c /
>> java / delphi / python would take the same time? why should i work an
>> a library for inform rather that on a dll for c?
> You can write *any* kind of program in assembly. Why should one
>"invest" in any other language whatsoever?
>
roughly any language is easier than assembly, not every language is
harder than tads.
> IF is about issuing commands that alter the behavior of a
>world-model. The creation of such a world-model is not a trivial task.
>Basically, your complaint is that nobody has yet managed to shoehorn
>the complexity of said task into any kind of language or system or
>*something* which is transparently accessible to even the greenest
>newbie; while your complaint does happen to be true -- nobody *has* yet
>managed to shoehorn, etc -- it also ignores the fact that creating a
>world-model just plain *is* Highly Complex, end of discussion.
first of all, the hard task is to create a system that *manages* the
world model, and this task should be accoplished by programmers.
creative prople should be able to focus on the *world-model* solely,
and i don't see any current language makes it, not, most of all, i see
that the direction is towards easier system, but toward more complex
ones.
> It's not
>clear that that sort of shoehorning is even *possible*, nor is it clear
>that, even were it possible in the first place, that sort of
>shoehorning is *desirable*. An analogy: Would you *want to* design a
>control panel that would allow a 4-year-old to run a nuclear power
>plant?
i hope you're aware it is clearly an iappropriate analogy, aren't you?
a poorly written / programmed if won't harm a thing, you'll just end
up don't playing it.
Eric Eve
news:av0u71thm1t0b9b5p...@4ax.com...
> this post might attract flames. this is not my intention, but i
> really
> don't understand a thing and i need some answer.
> i'm fairly new to if as a player and as a author. i'm not new to
> programming (i've been programming for 15 years, so far) and the
> "technical" side of if really intrigues me so that i'm programming
> my
> own if language not to become famous or to make it mainstrem but
> solely to delight myself.
> said that, i'm looking through most of the languages out there to
> understand exacly what a language should be able to, to see how
> they
> works etc.
> i think alan is a great and powerful language, so easy one could
> start
> coding an adventure in a couple of hours after getting the manual.
> adrift is proving to be mature and solid and i like the way
> adventures
> are constructed with it.
> inform and tads seem to be the most used languages and i don't
> understand why.
[snip remainder of post]
There's really no point in getting into yet another "system X is
better than system Y because Z" discussion here. At the end of the
day most people end up programming in the IF language that best
suits them. I've looked at both Alan and Adrift and neither of them
would suit me; Inform, TADS 2 and Hugo are languages that would suit
me pretty well, but I'm happiest working in TADS 3. Other IF authors
make other choices. But overall the very fact that there are plenty
of IF authors using TADS, Inform and Hugo is surely sufficient to
demonstrate the need for these languages - they meet a certain
demand. Other people may prefer to use Adrift or Alan, or to invent
their own language, and that's fine too if that's what they want to
do.
Many people are who are attracted to IF as a hobby since it combines
two activities they enjoy - programming and creative story-telling.
Since most people who write IF are doing it for their own enjoyment
as much as anything else, the fact that not all of them are both
expert coders and literary geniuses hardly matters. Over the years a
very good number of good IF works have been produced using languages
like Inform, TADS and Hugo, so these systems are clearly not acting
as barriers to the production of decent IF. The fact that these
systems can be also be used (and have been used) to produce not so
good games is hardly an agument against the systems (particularly
since we're only talking about a hobby here).
That said, there are reasons why many of us prefer to use languages
such as Inform, TADS or Hugo. These are all languages that are
specifically designed for the specialist task of writing IF. They
thus make coding the common IF tasks (like defining rooms and
objects) easy, while providing support for common interface tasks, a
reasonably robust world-model and parsing.user input. At the same
time they provide enough flexibility and power to enable IF authors
to achieve most of what they want with reasonable ease. This does
not mean that it's not possible to provide the same quality of
interface and world model with other systems, but many of us would
find it significantly more difficult.
A penultimate point is that languages such as Inform, TADS and Hugo
produce games with a parser and world model to the standard that
most players of modern IF have come to expect. The majority of games
produced with home-brewed systems or general-purpose programming
languages have failed to meet these standards, and are generally
given quite a rough ride by reviewers for this failure. In the hands
of a skilled practioner like David Whyld a system like Adrift can
certainly be used to produce decent games, but I'm not convinced
that the skill required to master Adrift to that level is any less
than it would be to master Inform, Tads or Hugo. I've only ever
taken a very quick look at Alan, and frankly I was not all that
impressed; to me its somewhat minimalistic approach seemed to leave
the IF author more work to do with less powerful tools (but perhaps
that's being partially adressed by the provision of an Alan
library). But others may take a different view and in the end it
partly comes down to taste and what you're used to.
The final point is that TADS, Inform and (to a lesser extent) Hugo
are widely used because, being widely used, they have proven track
records, so that new authors can be reasonably confident that the
time and effort invested in learning one of these systems will be
time and effort well spent. You can call this success breeding
success if you like, but taking note of the experience of those who
have gone before is usually a good idea.
-- Eric
Fredrik Ramsberg
What if IF isn't simply another way of story telling? Who says IF can't
require other skills than what's required for writing poetry? Who says
Yeats could have become a great IF author?
To create something, you may need tools. If I give a person a hammer, a
saw and all the building material he wants, he may be able to build a
simple car, but he will never build a great car using just a hammer and
a saw. He'll have to accept the limitations of the tools at hand and
work from that. If I hand him the keys to a complete workshop for
building cars, he may actually be able to build a great car. Of course
he will also need knowledge and skill to succeed. And knowledge about
building stuff in general may not be enough, but it may help. Same
thing with IF.
I think simple (from the user's POV) IF systems are a good way to start
for non-programmers who don't have the patience or see the need to
learn Inform, TADS or Hugo. After writing a game or two in a simple
system, I also think many of them will have found enough limitations
that they'll feel motivated to learn a more complicated system.
The most important reason to use one of the big three is that almost
everything about a game's behaviour can be changed. If you know exactly
how you want the game to behave, you can make it behave that way. This
involves programming and sometimes a lot of it, and there's no way
around that.
I'm in the process of setting up an Inform programming environment for
Windows, including compiler, library, documentation, a text editor with
syntax highlighting for Inform, menu options and keyboard shortcuts to
compile and start games, and of course an installer tying it all
together. I think figuring out how to use the command shell, installing
Inform and its library into some well-chosen locations, figuring out
the essential commandline options for the compiler etc are completely
unnecessary obstacles for newbies. There should also be a small
template source code file, so you don't have to start from just an
empty file when there are a dozen lines or so that you'll almost
certainly need to write to get your first little embryo of a game to
compile.
I should also add that there's already a program called JIF which does
a lot of this and then some more, but the problem is that it's written
in Java. Someone will ask me to explain why this is a problem, so here
goes: Even for me, who is a professional programmer, it took a while to
figure out why the process started but no window appeared when I
launched the program. It turned out I did in fact have the required
version of the JVM installed, but it had put itself at the tail of the
PATH variable, which meant an older version of the JVM was used
instead. Most users today wouldn't have a clue as to what a PATH
variable is, and there's no reason they should have to.
/Fredrik
cub...@aol.com
> On 9 May 2005 01:10:34 -0700, cub...@aol.com wrote:
>
> >Gu wrote:
> >> what i don't understand is why one should "invest" (learning or
> >> developing) in one of those languages. a tads file looks as
> >> complicated as a c one. why should i learn tads while learning c /
> >> java / delphi / python would take the same time? why should i work
an
> >> a library for inform rather that on a dll for c?
> > You can write *any* kind of program in assembly. Why should one
> >"invest" in any other language whatsoever?
>
> roughly any language is easier than assembly, not every language is
> harder than tads.
the expression. So let's try this again: You can write *any* kind of
program in BASIC. Why should one "invest" in any other language
whatsoever? (hint: "the right tool for the right job" is a *highly*
relevant concept here)
> > IF is about issuing commands that alter the behavior of a
> >world-model. The creation of such a world-model is not a trivial
task.
> >Basically, your complaint is that nobody has yet managed to shoehorn
> >the complexity of said task into any kind of language or system or
> >*something* which is transparently accessible to even the greenest
> >newbie; while your complaint does happen to be true -- nobody *has*
yet
> >managed to shoehorn, etc -- it also ignores the fact that creating a
> >world-model just plain *is* Highly Complex, end of discussion.
>
> first of all, the hard task is to create a system that *manages* the
> world model...
[shrug] You say "toMAYto", I say "toMAHto".
> ...and this task should be accoplished by programmers.
> creative prople should be able to focus on the *world-model*
solely...
Yes, and *I* should be independently wealthy. What's your point?
Just because something "should" happen, doesn't make that thing real
and/or doable. If you have some solution in mind for the problem you
describe, I'm all ears; but if all you want to do is kvetch about how
horrible it is that *nobody else* has solved the problem for you...
well, that's nice.
> ...and i don't see any current language makes it, not, most of all, i
see
> that the direction is towards easier system, but toward more complex
> ones.
SFW? Why does this *matter* worth a damn? Okay, complex tools mean
there aren't many newbies attracted to IF-writing. What of it? Do you
honestly think there are hordes and hordes of people out there who
yearn with all their heart to create IF, but the complexity of the
current toolset(s) bars them from doing so? I doubt it. In point of
fact, I strongly suspect that the vast majority of computer users are
barely even *aware* of IF, let alone chomping at the bit to *create*
the stuff.
> > It's not
> >clear that that sort of shoehorning is even *possible*, nor is it
clear
> >that, even were it possible in the first place, that sort of
> >shoehorning is *desirable*. An analogy: Would you *want to* design a
> >control panel that would allow a 4-year-old to run a nuclear power
> >plant?
>
> i hope you're aware it is clearly an iappropriate analogy, aren't
you?
> a poorly written / programmed if won't harm a thing, you'll just end
> up don't playing it.
You miss the point of the analogy. A 4-year-old is clearly not a
suitable candidate for running a nuclear power plant in the first
place, so designing a control panel that would allow one to do so is
just stoopid. That is to say, this is a specific example in which
Making It *Real* Simple Is *Not* A Good Thing. In a similar vein, I
would like to suggest that "shoehorning the complexity of world-model
creation into system which is transparently accessible to even the
greenest newbie" is Not A Good Thing, either. You have implicitly
asserted that this sort of shoehorning *is* a good thing, but that
assertion is not one you have supported, as of yet. Perhaps you might
care to try supporting this assertion?
Gu
<eric...@NOSPAMhmc.ox.ac.uk> wrote:
>[snip remainder of post]
>
>There's really no point in getting into yet another "system X is
>better than system Y because Z" discussion here. [..]
of course that's not what i want and i'd hate it. teh best tool is the
one that meets your needs at best.
>Many people are who are attracted to IF as a hobby since it combines
>two activities they enjoy - programming and creative story-telling. [..]
again, i agree with you. but i think there are 3 categories of people
who'd like to work on if:
programmers*
the creative programmer
the creative one
*of course a curious progammer interested in this kind of game
(better, who likes the idea of programming a text-based game possibly
because there's not a gfx artist at hand) whose average room building
method is "ok, i'll put a couple of trolls in this room cause i like
trolls".
i just think one of the 3 classes (clearly the creative) is taken away
from creating if because of language toughness.
>That said, there are reasons why many of us prefer to use languages
>such as Inform, TADS or Hugo. These are all languages that are
>specifically designed for the specialist task of writing IF. They
>thus make coding the common IF tasks (like defining rooms and
>objects) easy, [..]
this is not answering my point, indeed. it is "easier" to use inform
that to start something from scretch, of course. it is also easier
caouse there are no specialized libraries for other languages. my
questions were just from a curious. why aren't there if tools for
general purpouse languages as there are for other things? and again, i
don't see any advantage of using a dedicated language that a dedicated
library, only disvantages. there are hundreds of libraries to handle
3d graphics written in any language for any language and wrappers to
any language, libraries for menaging thousands of data-base systems
and so on, so that you can turn your delphi ide (just to say) into the
perfect platform to develop the next level doom clone or a program to
store your granny's recipes or a bank's data. why do you feel IF is
different from the rest of the world's software development and need
dedicated languages?! i know there are _some_ dedicated languaes for
the most strnage things, but always beside other development systems.
if seems to use only if languages.
>A penultimate point is that languages such as Inform, TADS and Hugo
>produce games with a parser and world model to the standard that
>most players of modern IF have come to expect.[..]
i don't think this is a point. what you write is true, but not because
only if languages can manage given things (the text world-model), only
because there's not a developed counterpart (again, dlls etc). and i'm
just asking why.
>The final point is that TADS, Inform and (to a lesser extent) Hugo
>are widely used because, being widely used, they have proven track
>records, so that new authors can be reasonably confident that the
>time and effort invested in learning one of these systems will be
>time and effort well spent. You can call this success breeding
>success if you like, but taking note of the experience of those who
>have gone before is usually a good idea.
you're right, and this is why they'll keep in being the mainstream if
languages.
gustavo
Fredrik Ramsberg
The things that IF authors need to do all the time are easy to do in
the specialized languages, and usually not easy to do in other
languages. So, do you want to do a lot of tedious repetitive work while
building your game, or would you rather get on with the interesting
parts?
I've written applications using a lot of SQL in Visual Basic, Perl and
PHP, and seen such source code in C, C++ etc. I've also written a lot
of SQL-intensive code in PL/SQL. I'd say I'm at least twice as
productive using PL/SQL as a general-purpose language, for that kind of
application. But I'd rather not write an IF game in PL/SQL.
And then, there's the portability. When I see that my game compiles in
Inform on my PC and plays fine on whatever interpreter I'm using, I
upload it to if-archive and I'm done. I can start writing my next game
or go out and play ball with my son instead of starting to port it to
Palm, WinCE, Mac OS 9, Max OS X, Linux etc. And if some old geek has an
Apple II, an Amiga, Atari or whatever, he/she can play my game too. No
sane developer on earth, commercial or hobbyist, would port a game to a
dozen different platforms.
Another thing is trust. Would you run a file called MyNewGame.exe which
someone you barely know sends you a link to, or even includes in an
email? In these days of viruses and trojans, you think twice before
opening an executable. With a game running in a virtual machine, you're
a lot safer. I'm nearly 100% confident that I can trust the Zcode terp
I download from if-archive, and that means I also firmly believe no
game running in that terp can delete files, overwrite files, mess upp
my registry or my boot sector, hijack my modem etc.
You're not wrong to want to write IF in some general-purpose language,
but there's a reason why few people try it and even fewer succeed in
writing a good game in such a language and getting many people to play
it.
Actually, it would be interesting to see the Cloak of Darkness as C or
C++ source code, even if it called an imaginary library which is yet to
be written.
/Fredrik
Gu
>Gu wrote:
>> On 9 May 2005 01:10:34 -0700, cub...@aol.com wrote:
>>
>> >Gu wrote:
>> >> what i don't understand is why one should "invest" (learning or
>> >> developing) in one of those languages. a tads file looks as
>> >> complicated as a c one. why should i learn tads while learning c /
>> >> java / delphi / python would take the same time? why should i work
>an
>> >> a library for inform rather that on a dll for c?
>> > You can write *any* kind of program in assembly. Why should one
>> >"invest" in any other language whatsoever?
>>
>> roughly any language is easier than assembly, not every language is
>> harder than tads.
> Okay, fine. You miss the point for the pincushion, if you'll pardon
>the expression. So let's try this again: You can write *any* kind of
>program in BASIC. Why should one "invest" in any other language
>whatsoever? (hint: "the right tool for the right job" is a *highly*
>relevant concept here)
seems like i'm missing your points and you're missing mine. what i
don't understand is why "the right tool" has to be:
1. a dedicated language
2. a hard-to-learn language.
as i pointed out in the first post, whatever "add on" (libraries etc)
for a simpler language will give you *easier access* to the same
*right tool* plus the whole *flexibilty* provided by a general purpose
language in the case you need it. where's the hard part?
>> ...and this task should be accoplished by programmers.
>> creative prople should be able to focus on the *world-model*
>solely...
> Yes, and *I* should be independently wealthy. What's your point?
>Just because something "should" happen, doesn't make that thing real
>and/or doable. If you have some solution in mind for the problem you
>describe, I'm all ears; but if all you want to do is kvetch about how
>horrible it is that *nobody else* has solved the problem for you...
>well, that's nice.
if you read carefully throughout my message, i'll see how i'm not
stuck in any problem, i'm programming by myself a tool i need to do
something i like. if you've read somewhere a "please do this for me
couse i can't but i'd like", please, report it and help me find it as
it would mean something strange is happening in my mind and i'm
writing things i don't mean to write.
that said, generally any improvement is done when someone feels that
something should be in a way it's not. you'd be living under a tree if
people before us didn't feel that dwellings *should* be more
confortable and with a roof without saying "this should happen but
it's not doable. now pass me that rock that i need to take a seat".
i'm not claming for anything, i'm just expressing what i think and
asking what other people opinions are as, being inform tads etc so
widespread, i think they're different from mine. it is called
converation and exchange of opinions and everyone had the same ideas,
usenet, established in 1980, would consist of 3 messages.
>> ...and i don't see any current language makes it, not, most of all, i
>see
>> that the direction is towards easier system, but toward more complex
>> ones.
> SFW? Why does this *matter* worth a damn? Okay, complex tools mean
>there aren't many newbies attracted to IF-writing. What of it? Do you
>honestly think there are hordes and hordes of people out there who
>yearn with all their heart to create IF, but the complexity of the
>current toolset(s) bars them from doing so? I doubt it. In point of
>fact, I strongly suspect that the vast majority of computer users are
>barely even *aware* of IF, let alone chomping at the bit to *create*
>the stuff.
again, i think that not, hordes of people don't yearn to create if.
and yes, i think more people *could* yearn to create and much more
people *could* like IF if they knew what if is. more people would know
IF if less people thought "i don't think there are hordes and hordes
of people out there who yearn with all their heart to create IF and
that's why i'll make my hobby even more elitist and i won't do a thing
to make it more accessible".
>> > It's not
>> >clear that that sort of shoehorning is even *possible*, nor is it
>clear
>> >that, even were it possible in the first place, that sort of
>> >shoehorning is *desirable*. An analogy: Would you *want to* design a
>> >control panel that would allow a 4-year-old to run a nuclear power
>> >plant?
>>
>> i hope you're aware it is clearly an iappropriate analogy, aren't
>you?
>> a poorly written / programmed if won't harm a thing, you'll just end
>> up don't playing it.
> You miss the point of the analogy. A 4-year-old is clearly not a
>suitable candidate for running a nuclear power plant in the first
>place, so designing a control panel that would allow one to do so is
>just stoopid.
thanks for explaining.
>That is to say, this is a specific example in which
>Making It *Real* Simple Is *Not* A Good Thing.
cause a nuclear power plant can be dengerous if managed by a 4 year
old kid (ring a bell?). the point in your example is:
a. make it hard to prevent something from happen (and i don't really
understand why do you see a bad adventure so dangerous)
b.[and i think and hope this is what you meant] it is *useless* to
make a very simple nuclear power plant control panel as no
4-year-old-kid will ever use it. this is true, but i'm trying to say
that while that's no need for a kid to run a power plant, there is a
strong need (better: i think there is) of writers to write if, and
being a writed doesn't mean to be a computer scientist.
computer scientist have produced the pod race in star wars episode 1,
writers," in perhaps one of the most memorable scenes in cinema
history" (c), have produced the "luke i'm your father" scene in
episode v and i think the latter is undoubtly more impressive. hope
i've been able to make my point clear.
> In a similar vein, I
>would like to suggest that "shoehorning the complexity of world-model
>creation into system which is transparently accessible to even the
>greenest newbie" is Not A Good Thing, either. You have implicitly
>asserted that this sort of shoehorning *is* a good thing, but that
>assertion is not one you have supported, as of yet. Perhaps you might
>care to try supporting this assertion?
nor you're explaining why it is not. read what i've just written
before.
Gu
>On the use of a general-purpose language vs a specialized language:
>
>The things that IF authors need to do all the time are easy to do in
>the specialized languages, and usually not easy to do in other
>languages. So, do you want to do a lot of tedious repetitive work while
>building your game, or would you rather get on with the interesting
>parts?
of course, but i'm not talking about programming, starting from 0, an
adventure. but beginning with "include parser" and "include common
verbs and common objects" (you know what i mean) will do the trick.
that part of my post is not to be taken from the point of view of the
if developer, but from the if-system point of view.
>And then, there's the portability. When I see that my game compiles in
>Inform on my PC and plays fine on whatever interpreter I'm using, I
>upload it to if-archive and I'm done. I can start writing my next game
>or go out and play ball with my son instead of starting to port it to
>Palm, WinCE, Mac OS 9, Max OS X, Linux etc. And if some old geek has an
>Apple II, an Amiga, Atari or whatever, he/she can play my game too. No
>sane developer on earth, commercial or hobbyist, would port a game to a
>dozen different platforms.
portabily *is* actually an important issue. i'm working on a web-based
if system. you can visit an early alpha (
http://www.amoeba.it/public/pif/accesso.php ). it is the cloak of
darkness, but the whole site, system and adventure is in italian, so i
don't think you'll be very interested. something that runs withing a
browser can run in a lot places.
>Another thing is trust. Would you run a file called MyNewGame.exe which
>someone you barely know sends you a link to, or even includes in an
>email? In these days of viruses and trojans, you think twice before
>opening an executable.
i 100% agree with you. again, thinking about it i started my project.
samwyse
[...]
> i think alan is a great and powerful language, so easy one could start
> coding an adventure in a couple of hours after getting the manual.
> adrift is proving to be mature and solid and i like the way adventures
> are constructed with it.
> inform and tads seem to be the most used languages and i don't
> understand why. as far as i've seen they (together with hugo) are (or
> are getting) so huge and complicated and full of options that they're
> turning, imho, completely useless. i've seen a tetris programmed in
> inform, and this in terrible.
Alan and Adrift are, in a way, the BASICs of I-F languages. They have a
very low learning curve, so newbies love them, but then you reach a
point where you want to do something that isn't supported by the
language. At that point, it takes more work to get things done than it
does in an more advanced language, like Inform or the TADS family. (And
I'm not sure why Tetris in Inform is terrible. It's just a
demonstration of some of the little-used capabilities of the language.
If I were writing Tetris for some other reason, Inform certainly
wouldn't be my first choice, but if I were writng I-F that needed timed
input or character-mode animation, I'd first read the source for that
version of Tetris.)
> what i don't understand is why one should "invest" (learning or
> developing) in one of those languages. a tads file looks as
> complicated as a c one. why should i learn tads while learning c /
> java / delphi / python would take the same time? why should i work an
> a library for inform rather that on a dll for c?
Because the user community has demostrated repeatedly that it doesn't
want I-F that's programmed in main-stream languages. If you want to
know why, Fredrik Ramsberg goes into it elsewhere in this thread, or you
can use Google Groups to look that the recent discussion of using .NET
for I-F. In summary, you can work on a DLL, but don't expect anyone to
use it.
[...]
> c is not easy, and almost any major language out there is too tough to
> write if. i underline "to write if". the problem is that in a big
> softwarehouse (pick one at your choice) no one pretends that a coder
> have to be a graphician, no one wants a musician to be a system admin.
> in the if word all the figures that generally rotate around the
> creation of a game are concentrated into one single person: the game
> designer, the writer, the coder..
There is a known need for better tools that address this point. I am
working on a Perl toolkit that allows a large portion of a game be
written in pseudo-languages that a specialized for particular tasks.
The biggest difficulty with all of the I-F languages that I've seen is
shared with "mainstream" ones: you have to declare an object in just
one place. To that end, I'd like to see standard way to represent
Inform in XML that would make tools easier to write and objects easier
to combine. My desire is for a scene editor that just handles
descriptions of rooms and objects, a dialog editor for talking to NPCs,
a puzzle editor for building everything from a locked door to the
bablefish puzzle, and finally a merge tool that combines the outputs to
produce source code and compiles it. At that level, the language for
the source that's being produced is largely irrelevant, although I'm
sure that the portability of Inform and TADS would make them logical
targets.
Fredrik Ramsberg
Gu wrote:
> of course, but i'm not talking about programming, starting from 0, an
> adventure. but beginning with "include parser" and "include common
> verbs and common objects" (you know what i mean) will do the trick.
> that part of my post is not to be taken from the point of view of the
> if developer, but from the if-system point of view.
That's what I meant as well.
Try to rewrite the Cloak of Darkness using C++ (or some other language
of your choice), using a library which you can assume has already been
written. It's possible, but it's pretty clunky. There are also a lot
more situations where a specialized IF system simplifies life for you
than what's covered by the simple game Cloak of Darkness. Many of these
things are about hiding details which you shouldn't need to worry
about, and so they don't show in the code - they will however become
apparent if you try to rewrite the code in a general-purpose language.
Actually, I'm pretty sure your web-based IF system will turn out better
if you first take the time to learn a good, specialized IF authoring
system.
> portabily *is* actually an important issue. i'm working on a
web-based
> if system. you can visit an early alpha (
> http://www.amoeba.it/public/pif/accesso.php ). it is the cloak of
> darkness, but the whole site, system and adventure is in italian, so
i
> don't think you'll be very interested. something that runs withing a
> browser can run in a lot places.
True. But it's still fewer places than where Zcode interpreters will
run (Also, a Zcode interpreter could be made to run with such an
interface, even though it hasn't been done yet AFAIK).
There's also the issue of paying - there are still a lot of people
having to pay per minute or per megabyte for a connection to the
Internet, especially on mobile devices. Will they be just as interested
to play your game if they have to pay for it?
On the other hand, running something in a browser with a pure HTML
interface means the player doesn't have to install anything at all and
will not be faced with any security warnings by his browser, which is
good.
All in all, I can see the point in building a system that plays in a
web browser with a pure HTML interface, but I'm sure it would make more
sense modifying a terp for an existing IF system to use a browser as UI
than to write a new system.
/Fredrik
Libby
>>Many people are who are attracted to IF as a hobby since it combines
>>two activities they enjoy - programming and creative story-telling. [..]
>
> again, i agree with you. but i think there are 3 categories of people
> who'd like to work on if:
> programmers*
> the creative programmer
> the creative one
> *of course a curious progammer interested in this kind of game
> (better, who likes the idea of programming a text-based game possibly
> because there's not a gfx artist at hand) whose average room building
> method is "ok, i'll put a couple of trolls in this room cause i like
> trolls".
> i just think one of the 3 classes (clearly the creative) is taken away
> from creating if because of language toughness.
>
Not really. I'm crap at programming (big fat F in C++ last semester..
>_<*) and much more into graphic arts, writing, drawing. (So, a
"creative one" ^_^) But I'm already pretty far into my first z-code
game, just by reading all the way through the beginner's manual, and
then using the main manual whenever I get stuck or want to do something
complicated. I copy-and-paste a LOT. ^_^ It's probably really hard to
learn EVERYTHING about the language, but there's no reason why anyone
would have to. Why not just learn as you go along? It's actually
really fun, like learning a foreign language or doing a puzzle book, and
I don't see why other "creative types" would have any problem with it.
Libby
Agnes Heyer
"Libby" <li...@rexandhazel.com> skrev i melding
news:117us2h...@corp.supernews.com...
I think I also fall into Libby's category. I had never programmed anything
before I started learning Inform, but it only took me a weekend to get
started on my first game. If you just start with the very basics, I don't
see why it would be that difficult as long as you're motivated. I saw the
process of learning this language as necessary if I wanted to write IF. Now
I find myself running into situations where I want to do this and that, and
I'm always delighted to find that there is a way to do it, even if it makes
the language as a whole more complex.
Mark J. Tilford
Advantages to using Inform or TADS instead of Alan or ADRIFT:
Well, try to do handle the geography of Mars (Photopia) or the caves
(Hunter in Darkness), or parse the cubes (Balances) or the various magic
items as handled in Beyond Zork (I was able to do this in under 100 lines
of Inform), or handle the gadgets (Spider & Web) in one of those
languages.
Yes, Inform & TADS are more complicated than Alan or ADRIFT, but the
advantages are well worth it.
Advantages to using Inform or TADS or a general purpose language:
- (Technically advantages to the VM architecture which would be also open
to a C compiler that targeted ZCODE or TADS instead of machine language)
Automatic support of SAVE, RESTORE, UNDO, portability, and users can be
sure of the safety of the game.
- Plenty of shorthand for the most common tasks. (Pretend you had a set
of C libraries equivalent to the Inform or TADS libraries, and work out
what the equivalent code would be for some game whose source is available
(like Balances), then compare the two.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
JohnnyMrNinja
cub...@aol.com wrote:
> Yes, and *I* should be independently wealthy. What's your point?
> Just because something "should" happen, doesn't make that thing real
> and/or doable. If you have some solution in mind for the problem you
> describe, I'm all ears; but if all you want to do is kvetch about how
> horrible it is that *nobody else* has solved the problem for you...
> well, that's nice.
I'm sorry, but what is the point of posting this? Isn't the point of
this forum the discussion of ideas? I am new to IF, but even I realize
that Graham Nelson didn't jot Inform down in a weekend; there were
years of public discussion on the subject.
> SFW? Why does this *matter* worth a damn? Okay, complex tools mean
> there aren't many newbies attracted to IF-writing. What of it? Do you
> honestly think there are hordes and hordes of people out there who
> yearn with all their heart to create IF, but the complexity of the
> current toolset(s) bars them from doing so? I doubt it. In point of
> fact, I strongly suspect that the vast majority of computer users are
> barely even *aware* of IF, let alone chomping at the bit to *create*
> the stuff.
This is a disturblingly elitist attitude, and one that I hope is not
terribly common. I'm terribly sorry if some people don't like the idea
of your secret treehouse boys-club view of IF, but just because someone
might have a problem learning a complicated code just to tell a story
doesn't mean they have "coodies".
> You miss the point of the analogy. A 4-year-old is clearly not a
> suitable candidate for running a nuclear power plant in the first
> place, so designing a control panel that would allow one to do so is
> just stoopid. That is to say, this is a specific example in which
> Making It *Real* Simple Is *Not* A Good Thing. In a similar vein, I
> would like to suggest that "shoehorning the complexity of world-model
> creation into system which is transparently accessible to even the
> greenest newbie" is Not A Good Thing, either. You have implicitly
> asserted that this sort of shoehorning *is* a good thing, but that
> assertion is not one you have supported, as of yet. Perhaps you might
> care to try supporting this assertion?
So in your analogy, Steve Meretzky would be a nuclear technician, and
Douglas Adams would be a preschooler on "Take your kid to work day"?
Again, elitist crap. I find it quite unlikely that an inexperienced
game author would accidently kill millions of people.
People who don't know how to program aren't always idiots. And some who
do quite clearly are.
Eizua
programming, I asked that too, even if I'm barely familiar with C or
C++.
I think the deciding factor for me was the support I would need in
accomplishing the programming task itself. I've found the folks around
R.A.I-F to be a lot helpful in this regard, which might not be possible
(correct me if I'm wrong) if I used something as "general-purpose" as C
or C++. Here, there are several people knowledgeable in the different
levels of either of the 3 languages, though I certainly don't discount
the support provided by the people subscribing to the ADRIFT and ALAN
forums.
I agree with Fredrik that there would be a humongous load taken off if
I used one of the three IF languages, not just for game design but also
for portability. In addition, there's really not a lot of games written
in these general-purpose languages that have really succeeded in the
way most of the modern IF games have succeeded. I mean, several entries
like these have been entered in IF Comps before but none have really
been voted among the top.
As for your point about separating the creative from the technical
tasks of writing IF, well, there are willing collaborators, and some of
these have produced remarkable results (No Time to Squeal, for example,
by Robb Sherwin and Mike Sousa). But if you're worried the seemingly
insurmountable task of learning an IF language is going to prevent
future users from writing more IF, I don't think it will.
~eizua
Kevin Forchione
news:d5ns1n$ai8$1...@orkan.itea.ntnu.no...
> I think I also fall into Libby's category. I had never programmed anything
> before I started learning Inform, but it only took me a weekend to get
> started on my first game. If you just start with the very basics, I don't
> see why it would be that difficult as long as you're motivated. I saw the
> process of learning this language as necessary if I wanted to write IF.
> Now I find myself running into situations where I want to do this and
> that, and I'm always delighted to find that there is a way to do it, even
> if it makes the language as a whole more complex.
Simply spoken. More people would find success if they only paid heed to such
a simple, practical outlook. Desire is the motivating force, and passion is
the fire that prevails against all seeming obstacles. But it's reverence for
the art and for one's self, that the road becomes a journey, and each
gesture on the way an act of creativity and self-discovery.
--Kevin
Signwriter
> developing) in one of those languages. a tads file looks as
> complicated as a c one. why should i learn tads while learning c /
> java / delphi / python would take the same time? why should i work an
> a library for inform rather that on a dll for c?
Speaking as a hobbyist programmer, I don't see much difference between
learning a specialist IF language and learning the interface to a dll or
library which enables me to write IF in a more general-purpose language.
If I'm deciding whether to learn a specialist language, or an IF dialect
of an existing one, the important question is "Which is easier?" By
which I mean: which makes me write least code to produce a particular
room or behaviour? Which, in short, is most *expressive* for the task of
writing IF?
The answer's nearly always - I'm tempted to say invariably - the
specialist language.
> i mean, of course there's an "advantage" of years of programming and
> codes
I can't see how that's anything but a blessing :)
-Sgnwrtr
Kevin Forchione
> [E]asier languages such as adrift or alan are giant steps forward a
> "people republic of interactive fiction". william b.yeats shouldn't
> need to know what an include or a main{} function is to express
> himself.
Would William B. Yeats write a brilliant piece of Interactive Fiction,
granted that he need know nothing about and include or a main()? He might,
but he would have to become a skilled practitioner in the art of
interactivity. What would he have to know to achieve that?
One would think that he would have to know as much about the techniques of
interactivity as he would of writing. The techniques of interactivity
culminate in shaping the response of the game to a player command; just as
the techniques of writing culminate in shaping the response of the reader to
the intentions of the writer. To achieve those ends in writing requires an
understanding and proficiency of an array of dramatic and grammatical tools
and structures. A writer doesn't merely express himself, he sculpts his
intention through the multilayered discipline of craft.
Yeats could, had he been presented with a word processor, have railed,
"Grammar? Why should I have to concern myself with grammar! Let Microsoft
Word sort it out!" And I daresay that in most cases, arguably, he would be
satisfied with the results. That wouldn't mitigate his need to understand
grammar, or why the program was complaining about a particular sentence, or
what was required to fix it, or whether in this instance the "error" could
be ignored.
This isn't to suggest that Yeats wouldn't be better off abandoning the word
processor and going back to pen and paper. The word processor comes with an
implicit trade-off: the prospect of increased productivity at the price of
increased complexity. The complexity comes in the form of a series of
learning curves: how to use the keyboard, how to use a computer, how to use
the word processing program, how best to take advantage of those features of
the word processing program to make his life simpler. In the end Yeats may
decide he was better off with pen and ink.
But he might also decide that, with discipline and practice, in time the
trade-off pays off and he's a more productive poet. Not only is he able to
produce more poems, but that the whole process has become second nature to
him and he wonders how he ever managed without it. Oh, for the simpler days
of notepad? He wouldn't dream of it. Besides, all of his friends are now
using the very latest version of X, and they don't appreciate having to
scroll through his drivel in ascii, and wouldn't it be neat to try out some
of the new features?
For all of that, is he a better writer? Perhaps not. After all, pen and ink
*were* sufficient tools for translating ideas onto the page, and we would
argue that the true craft of his art lies not in the mastery of the word
processor, but in the art of writing itself. How then do we stretch this
analogy across the chasm of Interactive Fiction?
Well, in a sense, the various development systems, such as Inform and TADS
are somewhat like the word processor. But the art of Interactive Fiction is
more akin to the art of making music. A simple jew's harp may provide an
afternoon's entertainment, but no one would begrudge the awe and majesty of
a symphony orchestra, or the complex rhythms of electronically synthesized
rock & roll. And while it's not necessary to be able to read notes, or the
benefit of classical training, in order to create music, those who possess
these additional skills and background may bring a subtle richness and
fullness to the tapestry of their art.
I do suspect that if he were to write Interactive Fiction, William B. Yeats
would know what an include and a main() function was, if that knowledge was
in the service of his art. Though I'm sure he'd probably be far more excited
having you play his latest game.
--Kevin
John Prevost
> between learning a specialist IF language and learning the
> interface to a dll or library which enables me to write IF in
> a more general-purpose language.
Not much difference at all, really. The key things that IF
domain-specific languages have going for them is that they typically
have a number of constructs that make IF tasks simpler. For example,
in TADS 3:
VerbRule(TurnOff)
('deactivate' | ('turn' | 'switch') 'off') dobjList
| ('turn' | 'switch') dobjList 'off'
: TurnOffAction
verbPhrase = 'turn/turning off (what)'
;
This requires some syntax knowledge, of course, to understand exactly
what each part means--but the overall meaning is pretty clear, and it
expresses the task of defining verb phrases for a lexical entry
"TurnOff" pretty simply. Compare this to the following pseudo-code for
a Java-like language that hasn't been designed with IF in mind at all,
assuming someone has defined a library for doing IF work:
/* Keyword, SyntaxOr are subclasses of SyntaxRule */
/* dobjList is a pre-defined instance of SyntaxRule */
/* Assuming Java 1.5's varargs support so we can have a variable */
/* length arg list for the SyntaxOr and SyntaxPhrase constructors. */
Keyword deactivate = Keyword.createOrFind("deactivate");
Keyword turn = Keyword.createOrFind("turn");
Keyword switch = Keyword.createOrFind("switch");
SyntaxOr turnOrSwitch = new SyntaxOr(turn, switch);
Keyword off = Keyword.createOrFind("off");
VerbRule turnOff = new VerbRule
(new SyntaxOr
(new SyntaxPhrase(deactivate, dobjList),
new SyntaxPhrase(turnOrSwitch, off, dobjList),
new SyntaxPhrase(turnOrSwitch, dobjList, off)),
new VerbPhrase("turn/turning off (what)"));
/* ... and probably even more stuff here to associate the turnOff */
/* verb rule with a VerbAction class */
So this is one example of why a domain specific language is preferable
to any old programming language. Note that you could get some portion
of this by having a program that pre-processes something more like the
TADS definition into Java, but then, you're really extending Java with
new syntax--making a new Java-based DSL for IF.
Now, on the other side of the picture, the reason that TADS and Inform
are full-powered programming languages is that when an author wants to
hook into the core functionality of the system (for example, to add
support for fluids or other measured substances), it's much easier when
the core functionality is written in the same language as the rest of
the game. Otherwise, an author might have to do something like
distribute a game as a game source file *plus* a patch to the compiler.
In essence, if the language is too weak, an author might have to write
a portion of the game in C (or whatever language), and another portion
in the game definition language. Which is, if anything, *worse* than
having to write the entire game in a language like Java which has no
explicit support for IF.
In short, the reason Inform and TADS are so popular is that they make
the easy things easy (by providing IF-friendly syntax for the most
common tasks) and hard things possible (by providing access to most if
not all of the internal workings of the standard system's parser,
output routines, etc., and a fully featured programming language to
implement the standard parser, etc. and any needed extensions.)
John.
jameshcunningham
> [...] In a similar vein, I
> would like to suggest that "shoehorning the complexity of world-model
> creation into system which is transparently accessible to even the
> greenest newbie" is Not A Good Thing, either. You have implicitly
> asserted that this sort of shoehorning *is* a good thing, but that
> assertion is not one you have supported, as of yet. Perhaps you might
> care to try supporting this assertion?
Let us assume that I have everything planned out for a piece of IF: text
descriptions, puzzles, NPC movements and reactions, scoring, the way I'm
going to do hints, whatever. Everything about my little adventure has
been typed out and organized.
Then let us say that I can translate this into a finished work of IF in
- say - one day. This finished work will have world management and a
parser on par with what might be achieved through - screw adrift! - TADS3.
Would having this ability be detrimental to something? If so, what?
best,
james cunningham
Gu
wrote:
i thank you for this example, john. i'll comment on it in a very short
way caouse i'm in a hurry, but it is really interesting. first of all,
the java example is much simplier and understandable and linear (for
me, at least, a non-tads expert and a java-hater).
that said, an eventual keyword-creator-on-the-fly function that
accepts multiple arguments or a single argument to parse or an array
of arguments, written in the virtual class we're using for our
purpose, will make the code look like (bear with me, i haven't been
useing java for ages!)
VerbsForTurnOrSwitch =
VerbsForTurnOrSwitch.createOrFind("deactivate","turn","switch","off");
SyntaxOr turnOrSwitch = new SyntaxOr(turn, switch);
VerbRule turnOff = new VerbRule
(new SyntaxOr
(new SyntaxPhrase(deactivate, dobjList),
new SyntaxPhrase(turnOrSwitch, off, dobjList),
new SyntaxPhrase(turnOrSwitch, dobjList, off)),
new VerbPhrase("turn/turning off (what)"));
the eventual createOrFind turns any argument into a keyword object
with the same name. actually, i'm using a very similar function in php
for the same purpose. of course, i don't know if tads code actually
creates the keywords you're declaring or it supposes it already knows
"turn" "switch" etc. if so, well, our class will also already know
them, so get rid of the first line of the code and the whole
createOrFind thing.
then, the CreateSyntaxPhrases class could accept dynamic input in the
creation phase, a single variable to parse and eval would work (again,
i'm doing it. i don't really know if java lets you do this, but i
suppose so) and this will result in a single statement that creates
SyntaxPhrase objects in a very similar way the first code does. so:
[VerbsForTurnOrSwitch =
VerbsForTurnOrSwitch.createOrFind("deactivate","turn","switch","off");]
SyntaxOr turnOrSwitch = new SyntaxOr(turn, switch);
VerbRule turnOff = new VerbRule
(new SyntaxOr
(new CreateSyntaxPhrases("deactivate dobjList | turnOrSwitch
off dobjList | turnOrSwitch dobjList off")
new VerbPhrase("turn/turning off (what)"));
and so on. classes or functions can be as specific as you want to
match your needs.
Rikard Peterson
jameshcunningham wrote in
news:1115695953.836e82d96429317929eb232717f649b3@teranews:
> Let us assume that I have everything planned out for a piece of
> IF: text descriptions, puzzles, NPC movements and reactions,
> scoring, the way I'm going to do hints, whatever. Everything
> about my little adventure has been typed out and organized.
>
> Then let us say that I can translate this into a finished work of
> IF in - say - one day. This finished work will have world
> management and a parser on par with what might be achieved through
> - screw adrift! - TADS3.
>
> Would having this ability be detrimental to something? If so,
> what?
>
> best,
> james cunningham
If you have everything planned out _in_that_detail_, it could also be
translated into a finished work with TADS/Inform/Hugo in - say - one
day.
Rikard
Andrew Cowper
> Let us assume that I have everything planned out for a piece of IF:
> text descriptions, puzzles, NPC movements and reactions, scoring, the
> way I'm going to do hints, whatever. Everything about my little
> adventure has been typed out and organized.
>
> Then let us say that I can translate this into a finished work of IF
> in - say - one day.
If it is that well specified then I suspect that the notation system
you have used to write down your adventure is as powerful and well
defined as TADS or Inform, and could be translated into a finished
work of IF in one minute by a suitable compiler.
If on the other hand is is written down in some natural language you
still have a lot of work to do to make a finished program.
--
Andrew Cowper
Pick a different user name to email me.
ChicagoDave
I think your post is carefully written and instead of jumping to
conclusions, you've clearly done enough research to understand some of
the basic issues. Many of us have follow a similar path.
I think the general answer to your question is, there is no real reason
any of the languages you presented couldn't be used to develop IF and
IF libraries.
The missing part is the parsing and world model aspects of how IF is
developed. These are not found in any general programming language
libraries, so you'd be pressed into the service of building these items
on your own.
This is where the major difference between writing IF in Inform and
writing IF in C or Basic becomes painfully obvious. Just try to sit
down and work out the logic for how an abstract world model would
function. Here are some of the questions you face:
* Do you start with a turn-based loop?
* What is in the loop?
* What events are exposed in the loop that the author can trap and
impose game-specific rules?
* How are objects managed?
* How is text managed with objects and events?
* How is inventory handled?
* How is parsing handled in relation to the loop?
* How do I build grammatically complex reactions into the game and
still have a way to corral the loose ends into default responses?
* How do objects relate to each other and how can the parser understand
these relations inherently within the world model?
In a way, IF is a database of states managed by an engine that
understands IF. So you can use any language you want, but in order to
have a flexible and reusable platform, you also need to have that
database and IF management piece.
Now here's the fun part. Many many smart people have _tried_ to build
the database and IF management piece and have simply walked away from
it because it's very complex. It's like juggling three hundred bananas
covered in vegatable oil, peanut butter, and/or thumbtacks. Sure, you
can get a few dozen in the air, but when you hit one with thumbtacks,
that hurts, and it's just easier to use Inform instead.
And a lot less bloody.
David C.
John Prevost
> i thank you for this example, john. i'll comment on it in a very
> short way caouse i'm in a hurry, but it is really interesting.
> first of all, the java example is much simplier and understandable
> and linear (for me, at least, a non-tads expert and a java-hater).
> that said, an eventual keyword-creator-on-the-fly function that
> accepts multiple arguments or a single argument to parse or an array
> of arguments, written in the virtual class we're using for our
> purpose, will make the code look like (bear with me, i haven't been
> useing java for ages!)
{ ... code elided ... }
Well, part of what's going on here is that what you suggest isn't even
vaguely possible in Java--that's a bit of what I meant when I said that
you'd have to write some sort of extension to Java to make things
easier. (In short: you cannot, in Java, have any variables be defined
by a function you call. You're suggesting that I could, say, call
something with a list of the keywords I want to be available in my
current function, and those keywords would suddenly be in scope. In
Java, this is not something you can do.)
Of course, in other languages, it may very well be something you can
do. But I think this still supports my suggestion that different
languages will be better or worse for the task of writing IF. In this
case, Java's pretty far down on the list of languages with helpful
features. About the only thing it has going for it is that the program
it eventually produces will run in a lot of different places. (But
z-code will run in every place Java runs and then some.)
Your second suggested piece of code brings up a different and also
interesting point:
{ edited slightly to be easier to read in the quote, and fit Java
better }
> VerbRule turnOff = new VerbRule
> (new SyntaxPhrases("deactivate dobjList | " +
> "(turn | switch) off dobjList | " +
> "(turn | switch) dobjList off"),
> new VerbPhrase("turn/turning off (what)"));
Here, we've gotten around the problem of having all of this extra
boilerplate code to create objects and hook them together by having a
simple call "new SyntaxPhrase". The thing here, is that this new
SyntaxPhrase call is essentially escaping into another language: We're
not really writing Java any more, we're writing a hybrid of Java and
something else--it's just that we're not doing it quite as nicely as we
might like, because we're trying to avoid extending Java. So, instead
of having someone able to write:
// This isn't real Java, but would be a reasonable Java-friendly syntax
// for an extension of Java to make IF easier
public syntax TurnOffSyn extends VerbSyn {
("deactivate" | ("turn" | "switch") "off") dobjList |
("turn" | "switch") dobjList "off"
};
we have to pass a string in to a special call. Of course, the
complexity of learning how to write a syntax phrase is the same either
way.
Note, of course, that the syntax of the version you provided, the TADS
version, and the Java-IF version I made up, are all *really* about the
same. See, that's one of the great things here: once you know a few
programming languages (preferably at least one imperative and one
functional language in the mix), there's not a lot of difference
between languages: you have your loops, your includes or imports, etc.
They all work pretty much the same way. There are a handful of
paradigms that most people won't have worked with before--and learning
to use those well moves you from "adequate" to "good" in the given
language.
It's only when you have to define large structures in some
domain-specific way that this starts to break down. For example, I
think the core features that the IF domain has are (with some
implications):
1) IF contains extremely large amounts of text
a) Text must be as easy as possible to include in source code.
b) It should be easy to mix code into text.
2) IF represents structures with many complicated interrelationships
a) Common relationships should be easy to express.
3) IF requires complicated parsing tools
a) It must be easy to define and manipulate parsing rules.
4) New games provide new verbs which have serious impact on
any standard world model.
a) It must be easy to replace and augment pieces of the model.
I'm sure there are other things that I'm missing (for example, the
desirability of having properties defined as expressions that are
evaluated dynamically.)
Notice that I didn't define #2 as "containment hierarchies". Both
Inform and TADS have similar containment notions--mainly, I think,
because it simplifies the problem a bit without introducing *too* many
extra problems.
Anyway, these needs have some pretty significant impact on the
languages. For example, both Inform and TADS have much more convenient
ways to write multi-line strings than most languages, including syntax
specifically designed to let you call out to code, or expand certain
keywords in the text. (Like: '"{The dobj/he} looks too heavy to
lift."' from TADS 3, for example, or 'print (The) noun, "looks too
heavy to lift."' from Inform.)
And both provide really simple ways to define one object contained
inside another. And ways to create objects inside other objects.
The last thing, #4, is actually one of the things that makes a more
dynamic language than Java a better choice for things: in a language
like Java, it's very hard to build a framework for augmenting and
replacing portions of a standard library. You have to do a lot of work
to look up which dynamic thing to use rather than simply writing
(static, unchangeable) code to call directly. In Python, to pick a
random example, it would be markedly easier to do this.
Anyway, I think what it comes down to at the end is: you could in fact
write all of these things in a non-IF language. And people do--but
because Inform and TADS are already out there and have these desirable
features, it's generally easier to learn them than it is to write an
entire library and world model from scratch. And I think that the
authors of TADS and Inform designed their languages partially in order
to satisfy the above requirements: because finding an already existing
language that supports more than one or two of the above constraints is
much more difficult than writing a new language. Especially when the
world model will (probably) involve a lot more code.
Okay, I'm talking too much now. I think I will return to lurking. :)
John.
David Fisher
> start coding an adventure in a couple of hours after getting the
> way adventures are constructed with it.
>
> don't understand why. As far as I've seen they (together with
> Hugo) are (or are getting) so huge and complicated and full of
> options that they're turning, imho, completely useless.
> What I don't understand is why one should "invest" (learning
> or developing) in one of those languages. A TADS file looks
> as complicated as a C one. Why should I learn TADS while
> learning C / Java / Delphi / Python would take the same time?
> Why should I work on a library for Inform rather that on a
> dll for C?
Have you discovered some answers to these questions yet ?
I was just wondering what you thought of people's answers so far.
Your main point seems to be that IF-creation tools should be simple to use
for writers (in particular, ones without a knowledge of programming), and
you see languages such as TADS and Inform to be too complex for them - and
so they may be discouraged from writing IF. You also object to the idea of a
dedicated IF language, and would prefer to see a set of libraries written in
a general purpose language like C. Does this represent you correctly ?
Here are some more thoughts ...
Others have mentioned the advantages of portability to many existing
platforms (where Z Code & other interpreters have already been ported), and
the safety of running IF on an intepreter - as opposed to an executable
which could potentially harm your computer. Another advantage is that people
get to run their own preferred intepreter, configured just the way they like
it on their own system.
These advantages could be retained by having a C compiler that targets a
virtual machine like Glulx (a successor of Z Code), for which intepreters
have already been written. Another benefit is that "save" and "undo" would
already be implemented for you. It wouldn't be able to link to existing C
libraries, though (eg. graphics) - unless they happened to be in Glulx as
well ...
But even if it included a complete library for parsing & world model
handling, etc. what would be missing is all of the useful syntax of existing
IF languages. Other posts have mentioned some examples of this already.
With regard to simple & complex IF languages - do you accept the idea that
you can only do so much with a simple language ? I haven't used Alan or
Adrift, but I believe it when people say that there are some things which
are harder to do in these languages than in TADS or Inform ... I think it is
just about impossible to make a *simple* system for handling a *complex*
problem that is completely flexible and configurable in every way. Here is a
quote about a mythical language called "RAIF-POOL":
I'm worried about my current WIP. I'm using the RAIF-POOL
Inform library, and I'm having trouble with my all_creation object.
(The intended effect is to provide a backdrop that emulates the
entire universe, so that the player can "go anywhere and do
anything", in the tradition of Zork, taken many steps further.)
Here's the relevant code snippet:
Location all_creation "all creation"
with name 'all' 'creation' 'universe ' 'cosmos',
physics_ruleset [;
SetPhysicalConstants(PHYS_CONST_NORMAL);
AllowAnomolies(ANOMOLIES_HARDCODED_ONLY);
Newton_Physics(ON);
Einstein_Pysics(PARTIAL);
]
has metaphysical scenery durable extant;
(by Jonadab the Unsightly One (Who Is Probably Not As Unsightly As He
Thinks)
- complete thread at
http://groups-beta.google.com/group/rec.arts.int-fiction/browse_frm/thread/76223b3aa3fa74/8910b8c6750b15c2?q=RAIF+pool&rnum=3&hl=en#8910b8c6750b15c2)
- the point being, that if you have a very simple way of saying something
like "create an NPC who is friendly but cautious", it will probably be very
hard to modify the default behaviour of that NPC in a particular situation -
almost certainly more difficult than customizing an NPC in TADS or Inform
(though there is still the (huge) problem of creating the default NPC
behaviour in the first place).
Maybe that wasn't the best example. But the general idea is that you need
access to certain nuts and bolts of the underlying controlling thingy of the
IF system, and TADS and Inform (and Hugo ?) allow this - Adrift and others
don't seem to make this easy at all.
There is a lot of inherent complexity in IF, and letting the authoring
system automatically handle most of it for you means that you don't get
nearly as much control over particular situations as you might end up
wanting.
There, I think I said what I was trying to express now ...
David Fisher
David Fisher
>> or developing) in one of those languages. A TADS file looks
>> as complicated as a C one. Why should I learn TADS while
>> learning C / Java / Delphi / Python would take the same time?
>> Why should I work on a library for Inform rather that on a
>> dll for C?
I forgot to mention ... if you are interested in some more research on what
is involved in developing your own IF system (either in a general
programming language or an IF-specific one), there is collection of related
discussions from this newsgroup at:
(and the sections following that follow).
David Fisher
David Fisher
news:FLhge.11704$Le2....@nasal.pacific.net.au...
>
> (and the sections following that follow).
Wow, that was grammatical ! :-)
Law of email proofreading: You will be unable to see mistakes in your own
email until at least five seconds after you send it.
David Fisher
Sands...@yahoo.com
David Fisher wrote:
<< With regard to simple & complex IF languages - do you
accept the idea that you can only do so much with a simple
language ? I haven't used Alan or Adrift, but I believe it
when people say that there are some things which are harder
to do in these languages than in TADS or Inform ... >>
I don't think there's any argument about whether languages
like TADS, Inform, or Hugo allow the user to do more things
than languages like ALAN or systems like Adrift. They do.
I think, however, that the notion that an IF language _needs_
to allow the user to, say, program Tetris, in order to be
worthwhile is a little extreme.
ALAN and Adrift allow people who are not acquainted with
programming to write text-adventure games, if they wish to.
They even allow these people to write good ones. That seems
worthwhile to me.
The original poster, if I remember correctly, was asking
whether languages like TADS, Inform and Hugo are redundant,
given that using them requires a user to spend as much time
learning them as he would have spent learning a general-purpose
language, but they offer no more flexibility than a
general-purpose language. If we pretend that a set of code
libraries that included a parser and a world model had already
be written for a general-purpose language, then he would have
a pretty good point. The only real advantage left would be the
fact that TADS, Inform and Hugo compile to a VM that has already
been ported to many machines. And that's a significant advantage.
But there's also an advantage to ALAN and Adrift. They allow
people who might be good game designers, but have had no exposure
to programming, to write a game without having to spend inordinate
amounts of time trying to learn the peculiarities of the modern
programming languages that TADS, Inform and Hugo are based on.
Don't get me wrong. I'm currently using Hugo, and I can't really
complain, but I also recognize that some aspects of it could be
a real problem for people who aren't familiar with current
general-purpose programming languages, and I'm glad there are
systems around that don't pose those problems.
cub...@aol.com
Wrong. It's a *realistic* attitude. An *elitist* attitude would be
more like, "wow, I am *so* happy that the vast majority of all computer
users are ignorant of IF!" I merely observe that IF *is* fairly obscure
outside the boundaries of the "IF ghetto". Whether or not IF *should
be* unknown to computer users in general is a question open to
discussion, but I honestly don't see how anyone can justify claiming
that IF *isn't* unknown to computer users in general.
My opinion is that, as a practical matter, the creation of IF just
plain *requires* a certain combination of mindset and skills which
simply is not very common. I do not claim that this is a desirable
state of affairs; I do not claim that it is an *un*desirable state of
affairs; I do, however, claim that is a *real* state of affairs, and
that any discussion of "wouldn't it be nice if there were more
IF-creators?" which pretends that this state of affairs is *not* real,
is basically pointless.
> ...and one that I hope is not
> terribly common. I'm terribly sorry if some people don't like the
idea
> of your secret treehouse boys-club view of IF, but just because
someone
> might have a problem learning a complicated code just to tell a story
> doesn't mean they have "coodies".
You're absolutely right: People who have a problem learning a
complicated code just to tell a story *do not* have "coodies". I do not
claim that such people are inferior; I merely claim that such people
simply will not create IF. If you have any concrete ideas about how to
change this state of affairs, I'm willing to listen; but if all you're
going to do is complain that I've called a spade a spade... that's
nice.
> > You miss the point of the analogy. A 4-year-old is clearly not a
> > suitable candidate for running a nuclear power plant in the first
> > place, so designing a control panel that would allow one to do so
is
> > just stoopid. That is to say, this is a specific example in which
> > Making It *Real* Simple Is *Not* A Good Thing. In a similar vein, I
> > would like to suggest that "shoehorning the complexity of
world-model
> > creation into system which is transparently accessible to even the
> > greenest newbie" is Not A Good Thing, either. You have implicitly
> > asserted that this sort of shoehorning *is* a good thing, but that
> > assertion is not one you have supported, as of yet. Perhaps you
might
> > care to try supporting this assertion?
>
> So in your analogy, Steve Meretzky would be a nuclear technician, and
> Douglas Adams would be a preschooler on "Take your kid to work day"?
No, I think the relationship between Meretsky and Adams, in the case
of the HHGTTG game, would be more appropriately characterized as
"technician and apprentice".
> Again, elitist crap. I find it quite unlikely that an inexperienced
> game author would accidently kill millions of people.
Again with the "elitist crap" crap. Do you recognize the difference
between an "is" claim (i.e., a statement of fact), and an "ought" claim
(i.e., a statement of opinion)?
> People who don't know how to program aren't always idiots.
I'm not sure what this is a reply to, because *I* certainly didn't
make any claim about the intelligence level of people who are unable or
unwilling to program. Perhaps you should direct this reply to whoever
it was that actually *did* say that non-programmers are idiots.
> And some who do quite clearly are.
And some people clearly do not comprehend the difference between an
"is" claim and an "ought" claim.
cub...@aol.com
> On 9 May 2005 04:01:01 -0700, cub...@aol.com wrote:
> >Gu wrote:
> >> On 9 May 2005 01:10:34 -0700, cub...@aol.com wrote:
> >> >Gu wrote:
[a certain amount of snippage]
> >> >> what i don't understand is why one should "invest" (learning or
> >> >> developing) in one of those languages. a tads file looks as
> >> >> complicated as a c one. why should i learn tads while learning
c /
> >> >> java / delphi / python would take the same time? why should i
work
> >an
> >> >> a library for inform rather that on a dll for c?
> >> > You can write *any* kind of program in assembly. Why should
one
> >> >"invest" in any other language whatsoever?
> >>
> >> roughly any language is easier than assembly, not every language
is
> >> harder than tads.
> > Okay, fine. You miss the point for the pincushion, if you'll
pardon
> >the expression. So let's try this again: You can write *any* kind of
> >program in BASIC. Why should one "invest" in any other language
> >whatsoever? (hint: "the right tool for the right job" is a *highly*
> >relevant concept here)
>
> seems like i'm missing your points and you're missing mine. what i
> don't understand is why "the right tool" has to be:
> 1. a dedicated language
Because writing IF is a specialized task which is best approached
with specialized tools. When you *need* a left-handed three-ply grommet
wrench, you *need* a left-handed three-ply grommet wrench, end of
discussion, and there's no point in complaining about how difficult it
is to adjust the knurl flanges on the damn thing.
> 2. a hard-to-learn language.
Because writing IF is *intrinsically difficult*. You can argue about
whether it *should be* intrinsically difficult, but you simply *cannot*
dispute that it *is* intrinsically difficult.
> as i pointed out in the first post, whatever "add on" (libraries etc)
> for a simpler language will give you *easier access* to the same
> *right tool* plus the whole *flexibilty* provided by a general
purpose
> language in the case you need it. where's the hard part?
Serious comment, not intended as dismissive nor derogatory: The fact
that you can ask "where's the hard part?" in the first place, indicates
that you have not given the problem much thought. You are approaching a
*hard problem*. A *very* hard problem.
> >> ...and this task should be accoplished by programmers.
> >> creative prople should be able to focus on the *world-model*
> >solely...
> > Yes, and *I* should be independently wealthy. What's your point?
> >Just because something "should" happen, doesn't make that thing real
> >and/or doable. If you have some solution in mind for the problem you
> >describe, I'm all ears; but if all you want to do is kvetch about
how
> >horrible it is that *nobody else* has solved the problem for you...
> >well, that's nice.
>
> if you read carefully throughout my message, i'll see how i'm not
> stuck in any problem, i'm programming by myself a tool i need to do
> something i like. if you've read somewhere a "please do this for me
> couse i can't but i'd like", please, report it and help me find it as
> it would mean something strange is happening in my mind and i'm
> writing things i don't mean to write.
> that said, generally any improvement is done when someone feels that
> something should be in a way it's not. you'd be living under a tree
if
> people before us didn't feel that dwellings *should* be more
> confortable and with a roof without saying "this should happen but
> it's not doable. now pass me that rock that i need to take a seat".
I said it before, and I'm going to repeat it now, and I mean it
sincerely: If you have some solution in mind for the problem you
describe, I'm all ears. But if all you're going to do *is* describe
it... well, "who will bell the cat?", you know?
You seem to be under the impression that I *want* IF to be
ignored/unknown by the vast majority of computer users. I don't. I
merely observe that IF *is* ignored/unknown by the vast majority of
computer users.
If your point is that emotional involvement makes for better
storytelling than mere technological virtuosity, you made it very
clear. And I fully agree with that point. But while I agree that the
"writer" aspect of IF *is* important, I just don't see how you *can*
eliminate (or even significantly reduce...) the "computer scientist"
aspect of IF.
> > In a similar vein, I
> >would like to suggest that "shoehorning the complexity of
world-model
> >creation into system which is transparently accessible to even the
> >greenest newbie" is Not A Good Thing, either. You have implicitly
> >asserted that this sort of shoehorning *is* a good thing, but that
> >assertion is not one you have supported, as of yet. Perhaps you
might
> >care to try supporting this assertion?
>
> nor you're explaining why it is not. read what i've just written
> before.
I've addressed this point elsewhere, so I'll summarize here: The
historical record of HyperCard suggests that if you make a toolset any
idiot *can* use, any idiot *will* use it -- and the GOOD stuff which is
made with that toolset, will sink without a trace in the sea of crap
produced by idiots.
Sophie Fruehling
>I don't think there's any argument about whether languages
>like TADS, Inform, or Hugo allow the user to do more things
>than languages like ALAN or systems like Adrift. They do.
>I think, however, that the notion that an IF language _needs_
>to allow the user to, say, program Tetris, in order to be
>worthwhile is a little extreme.
Yeah, sure, but I don't think anybody ever really said that. In
Inform, that's just a side-effect of having real-time capabilities
on the one hand and fixed-grid windows where you can arbitrarily
put characters, like you use for a statusline, on the other hand.
Or so I think. And in Hugo too, I guess.
>The original poster, if I remember correctly, was asking
>whether languages like TADS, Inform and Hugo are redundant,
>given that using them requires a user to spend as much time
>learning them as he would have spent learning a general-purpose
>language, but they offer no more flexibility than a
>general-purpose language.
I learned Inform before I learned a general-purpose programming
language. I started learning it, because I could make text
adventures with it, and not because I wanted to learn to program.
Only after having used Inform for a while, I said to myself, hey,
programming is fun, why not learn a "real" programming language, too.
The would-be IF-writers-but-not-programmers the OP is talking about
probably won't come to that conclusion. They won't care about knowing
a general-purpose language, if all they want to do is write IF.
If you start out with an IF language, you can put together some simple
scenario pretty quickly, and have fun playing around in the world
you've created almost instantly. That was a huge incentive for me. If
you start out learning C, for example, you have to do easy programming
exercises at the beginning, like reading in numbers and printing out
stuff, and do easy calculations, etc, and if you aren't into
programming, this is probably boring. But:
>If we pretend that a set of code
>libraries that included a parser and a world model had already
>be written for a general-purpose language, then he would have
>a pretty good point.
In this case, you don't really learn the standard language, but
something based on the standard language, but heavily extended,
and probably pretty different. So if you wanted to use the language
for something else, you'd have to find out what the standard parts
are, and I guess, learning C after having learned Inform or Tads
won't be that much more work. You do learn some general programming
concepts even if you start out learning an IF language, after all.
>But there's also an advantage to ALAN and Adrift. They allow
>people who might be good game designers, but have had no exposure
>to programming, to write a game without having to spend inordinate
>amounts of time trying to learn the peculiarities of the modern
>programming languages that TADS, Inform and Hugo are based on.
And then you can write IF without doing any programming at all; you
just need to find someone to do the programming for you. This is
something that's hardly ever mentioned in these discussions. I mean,
I think it is, but somehow people don't really take it into account.
I've never tried it, but I'm pretty sure if you are a writer, and
you're looking for a programmer for your game, you're going to find
someone here.
--
Sophie Frühling
"El arte no viste pantalones."
-- Rubén Darío
cub...@aol.com
Your question presupposes that this ability is achievable in the
first place. I don't think it *is* achievable; I think that by the very
nature of IF, what you're asking for just isn't *possible*, and I think
that any toolset which attempts to implement this ability *must
necessarily* be limited in Highly Significant ways.
Of course, I could be wrong. So let's say that some genius releases
a toolset which allows *anybody* to create IF. Would this be a Good
Thing? I doubt it. Why? HyperCard.
For those of you who aren't familiar with obscure bits of
Macintosh-related arcana, HyperCard was a kind of "software Erector
set" which brought honest-to-god *programming* within the reach of damn
near *any* person with two functioning brain cells to rub together, and
which still has its committed devotees even today, more than 10 years
after its last upgrade. The best HyperCard-made products were absolute
works of art, every bit as good as the finest software written in any
other language/environment, but the *worst* HyperCard stuff sucked
great green rocks with a Dixie straw... and crappy HyperCard stuff
outnumbered the good stuff by a depressingly large margin. As a result,
HyperCard gained a rather poor reputation which handicapped *all*
HyperCard users, *including the good ones*, because a lot of people
figured that HyperCard was *only* good for making crap, and therefore
*wouldn't even LOOK at ANY HyperCard product*.
Bluntly: Sturgeon's Law applies to people, too! If you make a tool
which any idiot *can* use, any idiot *will* use it -- and there's a lot
more idiots than you want to think about. Yes, some people will use a
wonderful "IF for everybody" toolset to create wonderful stuff -- but
*those* guys will be grossly outnumbered by the kind of doofus who
whips out "Conan Kill Everything" in 2.4 minutes *and thinks it's
wonderful*.
If anyone wants to dismiss what I've written as blatant elitism or
"sekret clubhouse"ism or whatever, they are entitled to their opinion.
But I would suggest that they do some research on the history of
HyperCard, and see whether they can find any reason to believe that
what I've written here is *inaccurate*.
Bertrand Augereau
> descriptions, puzzles, NPC movements and reactions, scoring, the way I'm
> going to do hints, whatever. Everything about my little adventure has
> been typed out and organized.
>
> Then let us say that I can translate this into a finished work of IF in
> - say - one day. This finished work will have world management and a
> parser on par with what might be achieved through - screw adrift! - TADS3.
But have you ever programmed an human language parser?
Or an IF world metamodel?
In what generic language would you do such things?
I honestly (don't take it as a provocation) think that if you knew how
to do those thing properly, you would understand the interest of
existing development systems. These tasks are not trivial.
Bertrand
JohnnyMrNinja
>make any claim about the intelligence level of people who are unable
or
>unwilling to program. Perhaps you should direct this reply to whoever
>it was that actually *did* say that non-programmers are idiots.
I apologize for any misinterpretation on my part, but I hope how you
could see, what with my being in the process of learning Inform myself,
that being compared to a toddler with a trigger-finger a little
offensive. I would quite like to be able to very cool things very
simply, as "effort" has never been my strong point. Also, while the
idea that IF languages be complicated for the sake of a filter is a
valid viewpoint, I was simply disturbed by the assumption that it
didn't need introduction, or was the standard. But, moving on...
cub...@aol.com also wrote:
> The best HyperCard-made products were absolute
> works of art, every bit as good as the finest software written in any
> other language/environment, but the *worst* HyperCard stuff sucked
> great green rocks with a Dixie straw... and crappy HyperCard stuff
> outnumbered the good stuff by a depressingly large margin. As a
result,
> HyperCard gained a rather poor reputation which handicapped *all*
> HyperCard users, *including the good ones*, because a lot of people
> figured that HyperCard was *only* good for making crap, and therefore
> *wouldn't even LOOK at ANY HyperCard product*.
> Bluntly: Sturgeon's Law applies to people, too! If you make a tool
> which any idiot *can* use, any idiot *will* use it -- and there's a
lot
> more idiots than you want to think about. Yes, some people will use a
> wonderful "IF for everybody" toolset to create wonderful stuff -- but
> *those* guys will be grossly outnumbered by the kind of doofus who
> whips out "Conan Kill Everything" in 2.4 minutes *and thinks it's
> wonderful*.
I don't know anything about HyperCard, but this is the exact same case
with Game Maker, although Game Maker is currently being maintained. See
http://www.caiman.us/ for examples. They've lowered the bar so far that
people have been known to make Super Mario clones while trying to check
their mail. The internet is so flooded with crappy Game Maker games
that nobody pays them any notice any more, which is a shame because
there are some cool ones.
One solution, since I was asked, is not to keep people out by some
code-ridden hazing, but simply by more support of games that don't
suck. How about more people that really have a grasp of IF
(automatically excluding me) helping to review and update on Baf's
Guide? Or on IFiction.org, which hasn't updated since '01? And then,
promoting sites like these as definitive, as the places for the
uninformed (no pun intended) to gain exposure to the magic of IF.
And (knowing that I have already said this, and that I am very green)
it would be very nice if an Adrift or ALAN-like language compiled to a
pre-existing VM. I don't mean to pull a "popularity contest" thing, but
it's the same idea that most up-and-comers release software for PC
rather than Mac, or PS2 rather than GC, or Game Boy rather than NGage,
etc.
But, this is all far, far off-topic. The question was, why have a TADS
language rather than a TADS library, which I certainly wouldn't begin
to know how to answer. I do think they idea of a VM-specific
language/compiler is very clean, and the VM concept is (and has been)
very vital to IF. Could this be done the same in a library?
Andrew Plotkin
>
> David Fisher wrote:
> << With regard to simple & complex IF languages - do you
> accept the idea that you can only do so much with a simple
> language ? I haven't used Alan or Adrift, but I believe it
> when people say that there are some things which are harder
> to do in these languages than in TADS or Inform ... >>
>
> I don't think there's any argument about whether languages
> like TADS, Inform, or Hugo allow the user to do more things
> than languages like ALAN or systems like Adrift. They do.
> I think, however, that the notion that an IF language _needs_
> to allow the user to, say, program Tetris, in order to be
> worthwhile is a little extreme.
The Tetris demo is really a bad example in this argument. (And I'm not
just saying that because I wrote it. :) It is an abuse of the
*display* capabilities of the Z-machine, not the programming language.
Furthermore, the display capabilities are exactly those that Infocom
invented for Seastalker (an ASCII-art canvas window) and Border Zone
(timed input).
The *programming* capacities needed for Tetris are numeric loops,
arithmetic, and numeric arrays. I am comfortable in saying that any
worthwhile IF development system needs those features.
But it's also true that you can write a working Inform game without
ever using the "for" statement, a numeric variable assignment, or an
array operator. If your game doesn't have that kind of puzzle, your
source code doesn't need those capabilities. If your game *does* have
that kind of puzzle, you will need those capabilities only in the
objects or room associated with that puzzle.
In other words, Inform properly segregates the basic IF concepts --
objects, actions, printing messages -- from the "advanced"
general-purpose programming language. It's not perfect at this; in
particular, the OO notation is a moderately large chunk to swallow,
and there are several extra chunks to learn. (Such as the grammar
notation and the switch-case notation.) But I do not agree that
learning Inform is *as much work* as learning Java or C.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
Agnes Heyer
<cub...@aol.com> skrev i melding
news:1115808213.6...@f14g2000cwb.googlegroups.com...
>
> You're absolutely right: People who have a problem learning a
> complicated code just to tell a story *do not* have "coodies". I do not
> claim that such people are inferior; I merely claim that such people
> simply will not create IF. If you have any concrete ideas about how to
> change this state of affairs, I'm willing to listen; but if all you're
> going to do is complain that I've called a spade a spade... that's
> nice.
Well, they could collaborate with someone who masters the programming aspect
of IF. I'm sure there are programmers who find their story-writing skills
somewhat lacking.
(We should also consider the poor programmers who are discouraged from
writing IF by the complexity of the English language. Perhaps we could
create a simpler language for them as well?)
cub...@aol.com
JohnnyMrNinja wrote:
> > I'm not sure what this is a reply to, because *I* certainly didn't
> >make any claim about the intelligence level of people who are unable
> or
> >unwilling to program. Perhaps you should direct this reply to
whoever
> >it was that actually *did* say that non-programmers are idiots.
>
> I apologize for any misinterpretation on my part, but I hope how you
> could see, what with my being in the process of learning Inform
myself,
> that being compared to a toddler with a trigger-finger a little
> offensive.
newbie with respect to Inform...
> I would quite like to be able to very cool things very
> simply, as "effort" has never been my strong point. Also, while the
> idea that IF languages be complicated for the sake of a filter is a
> valid viewpoint, I was simply disturbed by the assumption that it
> didn't need introduction, or was the standard.
It isn't so much that the complexity of IF serves as a filter (which
it does, of course), but, rather, that IF's complexity is *intrinsic to
IF*. IF's complexity is *not* something that can be worked around or
evaded. You just *can't* simplify IF; at best, you may be able to
*conceal* it, by delegating however-much of the complexity to the
toolset's code rather than forcing the would-be IF author to confront
that complexity head-on. This is fine as long as the author only wants
to do standard stuff that's built into the code... but what if the
author wants to do something *more*, or even *different*, than is built
into the code? In that case, the author is screwed. Thus, my assertion
that you *can't* make IF newbie-friendly without side-effects that are
sufficiently bad that you might as well not have bothered.
All of which said, there are programs like Photoshop, which offer
the user an immensely wide and versatile toolset, but which don't
*force* the user to deal with *all* of that toolset up front. Even the
veriest novice can open up Photoshop and *do stuff* with less than 2
minutes' instruction... but the more you play with Photoshop, the more
tools and options it reveals to you. I'm not sure what the jargon term
for this is -- "progressive revelation", perhaps? -- but it may be that
"progressive revelation" is a principle around which IF tools can be
built.
[nods] There you go...
> One solution, since I was asked, is not to keep people out by some
> code-ridden hazing, but simply by more support of games that don't
> suck. How about more people that really have a grasp of IF
> (automatically excluding me) helping to review and update on Baf's
> Guide? Or on IFiction.org, which hasn't updated since '01? And then,
> promoting sites like these as definitive, as the places for the
> uninformed (no pun intended) to gain exposure to the magic of IF.
Alright, but keep in mind that IF is just one more field of
interest, which is not necessarily any better or worse than any other
field of interest. Some people like to collect stamps; some people
follow particular rock bands; some people solve cryptarithm puzzles;
some people write and/or play IF. Try not to be disappointed if it
turns out that IF (a) obstinately defies all efforts to proselytize it,
and therefore (b) continues to enjoy pretty much the same level of
general popularity as bocci or morris dancing.
> And (knowing that I have already said this, and that I am very green)
> it would be very nice if an Adrift or ALAN-like language compiled to
a
> pre-existing VM. I don't mean to pull a "popularity contest" thing,
but
> it's the same idea that most up-and-comers release software for PC
> rather than Mac, or PS2 rather than GC, or Game Boy rather than
NGage,
> etc.
Hmmm... not sure if I agree with this idea... I shall have to ponder
it...
> But, this is all far, far off-topic. The question was, why have a
TADS
> language rather than a TADS library, which I certainly wouldn't begin
> to know how to answer. I do think they idea of a VM-specific
> language/compiler is very clean, and the VM concept is (and has been)
> very vital to IF. Could this be done the same in a library?
In principle, yes. In practice, a library is a programmer's tool
which is basically an add-on to a language (i.e., the moral equivalent
of an attachment for a vacuum cleaner), and how the heck many people
even *have* a computer language installed on their machine? Who in
their right might would download and install a whole general-purpose
language, *and* a whole IF-specialized library for that language, when
they can just grab Inform (or ADRIFT, or whatever) and be done with it?
There is definitely such a thing as "far more tool than you really
need"...
Adam Thornton
jameshcunningham <jameshcu...@yahoo.com> wrote:
>Let us assume that I have everything planned out for a piece of IF: text
>descriptions, puzzles, NPC movements and reactions, scoring, the way I'm
>going to do hints, whatever. Everything about my little adventure has
>been typed out and organized.
>
>Then let us say that I can translate this into a finished work of IF in
>- say - one day. This finished work will have world management and a
>parser on par with what might be achieved through - screw adrift! - TADS3.
>
>Would having this ability be detrimental to something? If so, what?
No. In fact it'd be very neat.
Here's the question:
How hard would it be to create the piece that makes the "Then let us
say..." paragraph happen? How much time would it take?
Now, how many people are ever going to use the system, given what we
know of the current world-wide pool of IF authors? How much time will
they save, collectively, if they use it rather than writing the
old-fashioned way?
And finally, the rub: it's my bet that the time to create that piece is
at least an order of magnitude greater than the time saved by writing in
it.
Adam
Jon
> No. In fact it'd be very neat.
>
> Here's the question:
>
> How hard would it be to create the piece that makes the "Then let us
> say..." paragraph happen? How much time would it take?
>
> Now, how many people are ever going to use the system, given what we
> know of the current world-wide pool of IF authors? How much time will
> they save, collectively, if they use it rather than writing the
> old-fashioned way?
>
> And finally, the rub: it's my bet that the time to create that piece is
> at least an order of magnitude greater than the time saved by writing in
> it.
>
> Adam
I happen to know that RAIF-POOL can easily be extended to support this
functionality, provided that drivers for the requisite neural interface
are available
Adam Thornton
Jon <jros...@gustavus.edu> wrote:
>I happen to know that RAIF-POOL can easily be extended to support this
>functionality, provided that drivers for the requisite neural interface
>are available
You should have picked them up at that big party at MIT. I did, or will
have done.
Adam
Mike Roberts
> Let us assume that I have everything planned out for a piece of IF: text
> descriptions, puzzles, NPC movements and reactions, scoring, the way I'm
> going to do hints, whatever. Everything about my little adventure has
> been typed out and organized.
The thing is, that's *precisely* what a tads/inform/etc program is -
everything about an adventure typed out and organized. So in a sense, your
wish has already come true.
But you mean in English, not a computer language, right? And you're
thinking that because it's in English, it'd easier to write than it would be
in a formal language. It seems common-sensical enough that writing in
English (or in one's own native language, anyway) would be easier than
writing in a programming language. But the thing is, my experience with
programming in general (never mind IF) is that it's actually harder to
specify an algorithm in English than in a formal language. If you look at
the way people write design documents for software systems, for example,
they tend to have a certain amount of plain English narrative framing the
big picture, but they quickly go to some suitable formal language -
object-relation diagrams, pseudo-code, etc - as they descend into the
details.
It's not because they're bad at writing English; it's because it's just a
lot easier to convey the information using a formal language. Natural
languages are vague and ambiguous and ill-equipped at handling references;
those problems can be solved with formal languages. Read a legal contract
some time if you want to see what English looks like when it's made all
precise and unambiguous.
I suspect if you really, truly tried to map out *every detail* of an IF game
in plain English, you'd quickly find that English just isn't a great
specification language, and you'd want to adopt some kind of formalism. If
you didn't have a pre-made formalism to bring to bear, you'd end up spending
all of your time, and many pages of your design document, defining your
roll-your-own formalism.
I'm not saying that tads/inform/etc are the perfect IF formalism. It's
probably possible to come up with something better that would make authors
more productive. I'm not sure what it would be; people have been dreaming
about some kind of "visual" tool around here for years, and there have been
some limited success there, but I'm not convinced it's the most profitable
direction. We seem to conceive of visual tools mostly as GUI wrappers for
the existing languages, but I think maybe what people really want is some
kind of new formalism that's a better fit to the problem domain, the way UML
is a more useful formalism than C++ for some kinds of application
development. But for the moment, procedural/OOP seems to be the best we've
come up with.
The other thing I have to point out about your "let us assume" is that it's
basically an impossible assumption as stated, because there's no plausible
way to incorporate testing into the design phase with this scheme. It's
pretty much impossible to map out everything about a piece of IF until you
start testing it, because there will be interactions that you can't
reasonably anticipate. No one has enough brain power to think of every
possible contingency in an IF work of more than trivial size. So unless
your typed-out English can actually be converted, more or less instantly -
i.e., compiled - into a running game, such that you can test it and feed
changes back into the typed-out English, you'll never be able to write a
complete enough description. Your notion of one-day conversion is too
slow - with that kind of delay, it would be impractical to feed changes from
testing back into the English description, so at some point you'd have to
declare the English version finished, convert to program format, and then
start testing and making your fixes and changes to the program version.
That makes life hard for the author because they did all their work up until
testing in a completely different language. This is one more reason that
the input has to be in *some* formal language. When computers develop
sufficient artificial intelligence to treat plain English as a compilable
language, I'll withdraw this caveat.
--Mike
mjr underscore at hotmail dot com
Bertrand Augereau
Or non native-speakers who have to cope with their own language (in my
case, French) whose grammar is much more difficult to parse in IF :)
So these people (hum) have the non-choice of making nicely-written
French games that almost nobody will play or write English games with
their crappy english writing craft :)
Gu
43 follow-ups so far, and I just can't reply to alla of them, so what
is going to follow is a sum-up trying to catch various aspects of the
problem that emerged in this 3d in these days. I won't use any
particular order and replies given to specific people I'll quote also
refer, obviously, to people who wrote similar things. So my use of
"you" is not referred to the single person i'm answring but to a wider
audience.
-1- cub...@aol.com
I find your writing arrogant and irritating, the sort of flasmish "In
this newsgroup I'm the Only One who knows everything about any
argument and don't even try to have opinions that I don't share couase
they'll surely fall miserably into the darkness because everyone is
ignorant but me". I'm not a biologist, but I can presum you dwell
somewhere deep in the heart of the Earth or deep in some forest and
you belong to the the specis commonly known as "trollus comunis". That
said, I'd easily and better skip all your posts, but i'll write a
generalyanswer. Don't expect me to write again if you will.
>> 1. a dedicated language
> Because writing IF is a specialized task which is best approached
>with specialized tools. When you *need* a left-handed three-ply grommet
>wrench, you *need* a left-handed three-ply grommet wrench, end of
>iscussion, and there's no point in complaining about how difficult it
>is to adjust the knurl flanges on the damn thing.
(by the way, good example of what I meant by "arrogant and
irritanting"). Considering IF a specialized task is right. On the
other hand, general languages are not meant for "general tasks" simply
because there are no general tasks. I don't thing "extracting orders
for my china shop from a database" is a general task, but there's no
"Ultmate china shop programming language". Writing a Doom clone or
Pakman 2, writing Microsoft Word 2006 or the latest Mp3 player for
Linux are specialized tasks done with pretty much the same means using
extentios like graphic libraries, multimedia libraries, gui libraries.
Again, IF seems to be on another world: people have been programming
all the programs you're running at the moment, including Agent
newsreader you're writing it, emule in the background, the firewall
you're using, Firefox and Eudora, the MSN you're chatting with and
Winamp you're using to listen to your CDs with the same languages but
*obviously* they arre all easy and straight forward to program, while
IF needs *obviously* a dedicated language.
But I think I've been confusing. My first post was strongly split in 2
parts. In the first part I write against dedicated languages for IF,
the same thing I'm doing now. People replied saying that writing IF
with general purpose languages would have been harder and so on. I
disagree. A good library for Python will make programming IF a lot
easier and funnier. There's a project here in Italy going this way and
the results seems to be stunning. The code is very clear and you
understand what's going on the game just reading it. The programmer is
using the Inform manual as a referece, to see what he has to include
in the language. This is just an example, maybe you hate Python and
you'd hate programming with it. It's ok, but I like and that's why I'm
using it as an example. well..
* * * * BUT * * * *
A lot of you concentrated on this dedicated language vs general
purpose language thing ignoring the second part of my post. If I'm
curious about the affirmation of those languages as TADS or Inform and
what has been done so far could have been with "normal" languages plus
dedicated libraries, the developement of those libraries IS NOT a
thing I hope is going to happen. Programming IF in C would be a pain
much more that programming in Inform, libraries or not. Why? Because C
is hard.
>> 2. a hard-to-learn language.
> Because writing IF is *intrinsically difficult*. You can argue about
>whether it *should be* intrinsically difficult, but you simply *cannot*
>dispute that it *is* intrinsically difficult.
I disagree. Trol.. ehm, cubist has been accused of being elitist.
Affirming that writing IF is a hard task and you can approach it only
if you're a computer scientist is possibly the worst way of acting and
keeping people away from IF. Writing *certain* IF is hard, and those
*hard to code IF* are not automatically the best IF. As an example
I'll pick Bad Machine. I doubt writing it is a easy task at all. It's
a great piece of IF, I think. Recently I've played Conan Kill
Everything. You mention it in one of your posts with a very
unrispectful way. I had a lot of fun playing it. It's not deep and no
one will ever remember it for its dialogs and those so well shaped
NPCs. On the other hand there are hundreds or reasons why one loads a
game into its Z-machine of choice. Reading a well written text,
feeling emotions, descovering something about Latin America (see
Bolivia By Night) or have 20 minutes of pure fun. In the latest case,
CKE accomplishes completely its aim and it's perfect in this.
Now, it happens that i have Conan's code because I needed something
simple and funny to translate to my own code for a project (no use to
talk about it right now) and it seems perfect for the task, so the
author (thanks again!) provided me with code. In this case the use of
Inform is completely useless. Everything in the game is variable
assignements (descripton=x), simple operations (damages of table ++)
and evaluations (if the cat is dead, then put the spider in game).
Now, I'm sure that most of the games are something in between a
complex game with 1000 different endings and a one-room game you can
finish with 20 moves. But, from a "code" point of view, I think, no
matter how complex the puzzles or the world is, 98% of the code is
more like Conan (work on variables and if conditions) than like Bad
Machine.
I'm back to your point (the right tool for the task). Now, I have this
simple code at hand. It could have been simply written in virtually
any IF language currently avaible, including ALAN and Adrift but the
author went for the widest spread one, and this is a respectable
choice. In a way, a semi-obligated choice.
-1.a- A breaf degression before getting back to the main "1" part
(samwyse)
ALAN and Adrift, as samwyse noted, are basic and easy but limitated.
Still I'm conviced they are ENOUGH to write most of the IF one could
be willing to write, but people do not even try to give them a run
"just in case" (keep on reading for the 'just in case' part) they'll
end up finding something the language doesn't allow you to do. Doesn't
matter than 95% of the times you'll never get to such a point. Anyway,
just a matter of choices.
Let's split the IF programmers in two cathegories:
1-Those who actually write IF games
2-Those who write IF tools
I'll refer to the secod class for what follows.
Now, ALAN is open source. This means everyone could develop it and
work for improving it. I read here and there announcements for "Hey,
I've done a new class for Inform that allows to realistically manage
16-wheeled trucks with and without load" but no "I've implemented
containers for ALAN" (there are actually cointainers for ALAN, just a
quick example to express something basic that can make a language
limitated). So, a 'limitated' (though I don't personally think so)
easy language will keep on being isolated and complex languages will
keep on growing even more complex. This does not represent a problem
for programmers or code-geeks, but for beginners.
The advantage of developing easier languages is that a newbie won't
get descouraged in his first attemp and will end up with his first
little adventure within a week. The same adventure could have been
developed by the expert in a day. But with a very simple and
streightforward language maybe the expert could have done the same in
three ours. Advantages for all. Anyway, move on (or move back)
-1- back to the main "1" part!
To keep on explainng myself. Say I have to write a "Hello world"
program that runs under DOS. Don't ask me why should I ever, but pick
it as an example. Everyone told me that Java is very used, it can run
in a virtual machine so, once my wonderful Hello World program is
written, they can run it on Linux and Mac and Sun machines and this
seems to me great. Plus i've read somewhere it is a very powerful
language and it can let me do a lot of nice staff. I start learning
java and after a while i have my program:
---
public class Hello {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
---
done. Question: have I used the right tool because everyone says Java
is great and looking for a job in the computer industry it is still
very popular?
I don't think so. I don't think that learning the types of classes
(public etc), and the way to declare them, learning the meaning of
"public", "static", "void", "main" and "Strings[] args" and the {}
syntax, the object System and what out is (pant, pant ..) is necessary
to dirt a black screen with the eleven white letters "Hello World!".
Is that the right tool because *just in case* with the same language i
can connect to a remote server, load a variable and print out
something different from Hello World" in 3D rotating letters? What if
I'd used BASIC?
---
PRINT "Hello World!"
---
What do you think will attract the more someone who just wants to get
satisfied by filling a black screen with a white "Hello World!" text?
How many people do you think will get discouraged if i tell them that
writing Hello World is a hard task you can only accomplish if you know
what classes are, what object oriented programming is, the meaning of
a void clausole? Basic is not multi-platform. Right. Let's write the
same program in Python.
---
PRINT "Hello World!"
---
Oh yes, the same neat stuff. What if I DO need object oriented
programming, or I'm used to it or non-OOP is lame?
---
class HelloWorld:
def greet(self):
print 'Hello World'
h = HelloWorld()
h.greet()
---
and so on. But maybe you're convinced that Python is a so-so language
just able to do some scripting in, say, 3d programs used in the film
industry and to help server-side in some minor web application like
Google (yes, they use it) but IF is the most specific type of
programming ever seen in 30 years of computer history so that it
needs languages on its own. Just point of views.
But, before moving on, I want to make it clear before dozens of "you
cannot use python to write IF because.." messages appear:
I DON'T WANT TO USE PYTHON FOR WRITING IF *NOR* I THINK IT WOULD /
SHOULD BE THE BEST PROGRAMMING LANGUAGE FOR IF
My simple point is that I don't trust "just in case" languages. I
don't feel like declaring and including complex things for writing my
"Hello World"-like IF using this complex language "just in case" I end
up wanting a puzzle based on the current temperature on the CPU of the
computer running the game and Inform grants me access to the system
internal thermometer because I'm sure I'll never use it. 98% of IF
don't use the most obscure aspects of tough languages that justifies
their toughness because most of IF programming is about changing
variables, printing things and using if statements. Now, don't start
firing with "In this adventure I've written this nuclear fusion
simulator" or "I'm just playing this game where the NPC artificial
intelligence has being developed in secret MIT labs". I'm aware of the
fact that some hard-to-code staff appear here and then, they make
games memorable and add deepness to them and that having an idea and
not being able to develop it the way you like because of tool-limits
is frustrating.
But the ideal language I'm talking about is much like Python. It lets
you create a thermodynamic-aware puzzle importing things and making
use of strange language charactersistics, importing hidden classes,
assembler chunks and internally evocating the Astral Dark Lord Of
Thermodynamics as well as "a gift for my girlfriend, a short IF
written in a week set in our room where at the end she descovers a
hidden ring under the bed and I give her a real ring as she finishes
the game" (I know, I'm a sweetheart by nature :P ) writing lines like
"print 'hello world'" and not caring about the rest. It's like
Microsoft Word: in its menues there are features only the programmers
know are there. I've been using Word for my homework, writing novels
and letters and flyers and for the university for ages, and I've
nevere used its visual-basic capabilites. Maybe one day I'll face a
problem that requires it, but it has not happened in the last 10
years. What if Micorsoft pretended you to know that language before
writing a simple 10 rows letter to a friend?
> I've addressed this point elsewhere, so I'll summarize here: The
>historical record of HyperCard suggests that if you make a toolset any
>idiot *can* use, any idiot *will* use it -- and the GOOD stuff which is
>made with that toolset, will sink without a trace in the sea of crap
>produced by idiots.
The IF world is already full of crap which exists in the form of
unknown staff in ftp archives and that get that last place and a mark
of 1 out of 10 when enter competions. But there's still people quoting
Bad Machine (like me in this post) and playing Zork after almost 30
years from its first appearance. As you said, is not that there are
hordes of people willing to write IF, but I think it's unjust to keep
them out of the game because you've decided that things are hard, have
to be hard and no one can do a thing to make them easier. If you turn
on the radio you'll hear the last princess of pop screaming her stupid
lyrics because the music industry has decided that a couple of rounded
buttocks are more worthy an investment than a good voice, but still
Dark Side of the Moon is considered one of the best albums ever made
and people keep on listening to it and buying it. And, even if I play
keyboards and thecnology game me powerful yet easy to use
home-recording programs and virtual machine, I won't be able to
compose another Tubular Bells (Mike Oldfield) or Vangelis album.
Provided with the same tool, no matter what, an artist will ever do a
better job than the wanna-be, but this does not mean in any sense that
the tools have to be different and /or most of all complicated and
unaccesible and obscure.
-2- the medium stuff (mainly Fredrik Ramsberg)
I'll skip the "use a general purpose language with appropriate
specific libraries" as, as I pointed out before, it is just the first
part of a post and not a part I support. An idealistic language, as
you made clear, have to be multiplatform and generally multiplatform
languages run within virtual machine. This is the case of Inform,
inform, but also Python (java, ruby...). I'm not saying that Inform
fails from this point of view and I'm all for multi-platform programs
and virtual machines provide a level of safety that i greatly
appriciate. I totally agree with you. My little suggestion, or idea or
simple proposal of exploiting the web has its faults (paying etc),
but again, it's just a simple one-moment idea. And using *browsers*
can still be a valid thing to think about. Playing a game online, if
you can, or have this mini-IF server running on your machine to play
the game *offline* within your browser of choice. Just 2 cents.
-3- Libby
>> i just think one of the 3 classes (clearly the creative) is taken away
>> from creating if because of language toughness.
>Not really. I'm crap at programming (big fat F in C++ last semester..
>>_<*) and much more into graphic arts, writing, drawing. (So, a
>"creative one" ^_^) But I'm already pretty far into my first z-code
>game, just by reading all the way through the beginner's manual, and
>then using the main manual whenever I get stuck or want to do something
>complicated. I copy-and-paste a LOT. ^_^ It's probably really hard to
>learn EVERYTHING about the language, but there's no reason why anyone
>would have to. Why not just learn as you go along? It's actually
>really fun, like learning a foreign language or doing a puzzle book, and
>I don't see why other "creative types" would have any problem with it.
This is the way to go! He he. But the fact that you took a "big fat F
in C++ last semester" proves that you *study* programming. Your
starting point is the knowledge (well or no) of terms like functions,
objects and classes, the difference between == and = . Not that you
can actually program completely ignoring those things, but, for
example, I appriciated a lot the "CHECK" statement of ALAN. Check this
and eventyally DO this. Simplier than simple, and this is the way to
go, I think. Anyway, I've already written something you agree with me
about. " It's probably really hard to learn EVERYTHING about the
language, but there's no reason why anyone would have to". This
multi-entry level is exacly what I'm thinking of. The problem is that
certain languages forces you to learn or get used to things that could
easily avoided as unnecessary to get to the simplest point. Remember
the Java Hello World program before? Of course you can program without
knowing, for example, the obscure java.util.regex package (for regular
expressions that are really not something so simple), but it forces
you to write 12 (TWELVE) words (count them) before getting to the
point where you can finally write "Hello World" which is where you
were aiming to accomplish the simplier of the tasks.
-4- Something I liked (Kevin Forchione)
I liked your post as much as I disliked the tone of cubist's ones. I
think you come across various interesting and well exposed ideas and I
must say I agree with you. The only perplexity rises when you affirm
that learning what a main() is acceptable for the purpose of the art.
If this is in a way true (you must learn how to master your tools to
express your art, being them brushes, pens, harps or computers) but on
the other hand also tools evolve. Leonardo da Vinci had to make his
colors on his own mixing herbs with eggs and similar things. Edward
Hopper just bought his own readly made colors. Now, with an obvious
abstraction from the century and what it brings such as themes and
styles, Hopper would have done the same paintings in the '300,
Leonardo the same Mona Lisa nowadays, with the difference that using
readly made colors is much easier and time saving and lets you
concentrate on the smile of the Mona Lisa getting of problems like
"have i used the right herb? Will this color turn lighter if exposed
to a string light? Have i used enought egg yolk?".
-5- David Fisher
Again, another clever post. I'll skip the first part as it deals about
*my* first part that, as i think and hope i've made finally clear is
meant to express that i see no real definitive advantages in using
specific languges for writing IF, BUT this doesn not mean I'm willing
for a conversion to those general purpose languages. I'm aware this
may sound non-sense, but i think I've made my point clear with this
long post. I think the need is for easier languages, being them
adaptations of generic languages or other IF only not important. Just,
don't exclude a-priori the possibily of using, say, Python (I'll
repeat again, just a language I like and I find pretty easy and
adaptable to different users, tasks and types of programming, I don't
mean to suggest it in any way).
Back to you post, you write:
>With regard to simple & complex IF languages - do you accept the idea that
>you can only do so much with a simple language ? I haven't used Alan or
>Adrift, but I believe it when people say that there are some things which
>are harder to do in these languages than in TADS or Inform ... I think it is
>just about impossible to make a *simple* system for handling a *complex*
>problem that is completely flexible and configurable in every way.
I don't agree with you. I don't know a thing about you, how old are
you and so on. But I remember the first word-like program I used. The
computer was a 8086, a black and green monitor and this program whose
name I can't remeber. The idea beyoind the program (and the machine)
was obviously the "using computer is hard, so is using software" and
tasks like making bold or italic letters were achieved by complex
commands given via keyboard. No help involved and you had to learn and
remeber all of them. Oh, well, good old times :P Now, any idiot can
turn on Windows move the mouse here and there and write a letter so
professional it would have been impossible to write 15 years ago. The
point is always the multi-entrylevel. You talk about the legendary
RAIF-POOL. It is obviously a joke and i had fun reading it. But
imagine a newbie writing a game set in Russia. He needs Stalin as NPC
and enters the command:
--
create Stalin
--
The language does it. Now, the point is that this Stalin would be ok
and enough for nearly the 98% of the cases. But, if for some unnamable
reason you have to make this Stalin the same Stalin but good, gentle
and not responsible for 26 million victims, I'll open the stalin.class
file to modify some parameters and make it a sort of cosy slavic
little red riding hood. But again, how many times will you run into
this case? Is it worth forcing you to write a 100 rows Stalin object
shaping all the things the way you like to give you the power of
changing something you'll probably never gonna change? Isn't it better
to have the simpliest, almost always sufficient "create Stalin"
command WITH the ability of EVENTUALLY change it according to your
needs?
And thanks for the link, I'm still reading all the matherial, it's
agreat source of ideas and infos.
Well, that's enough for now, I'll go back to my studies after having
written a while. See you after other 40 posts :P
Take care
gustavo
PS: See, Rekard Peterson? I've Used Capital Letters ^__-
Quintin Stone
program IF in a general-purpose language using specialized libraries is
better because then you're learning a general-purpose language at the same
time, which could be useful to you in other situations. I have two issues
with this assertion. First, it's my belief that most people who approach
an IF language as their first programming language aren't people likely to
do development in other areas anyway. It's the game style and
storytelling that appeal to them. So learning Python or C or Java in the
process of creating their game won't mean much because they never do
anything with that knowledge *except* write IF games. They may as well
have learned TADS/Inform, which are streamlined for writing IF anyway.
Secondly, and more importantly, as someone who's coded in a dozen
different languages, I can tell you that the most important aspect of
being a programmer is learning the concepts and ideas that vary little
from one language to another. Syntax and standard function names take a
back seat to understanding basic things like program flow, loops,
pointers, algorithms, inheritence, garbage collection, etc. So I don't
think that learning to code IF in a general-purpose language using
specialized IF libraries holds all that much value over using something
like TADS/Inform, as most of what the person would be learning, besides
the general syntax of the language, is mainly the API to this hypothetical
IF library. This would be fairly useless in any other circumstances
outside of developing an IF game. So even if a person does go from
learning TADS/Inform as a first language to experimenting with
general-purpose languages, the knowledge that was gained from coding in an
IF language is not wasted, because it taught many basic programming
concepts that will be useful no matter which general-purpose language is
used next. And as an added bonus, that IF language probably had an easier
learning curve.
==--- --=--=-- ---==
Quintin Stone "You speak of necessary evil? One of those necessities
st...@rps.net is that if innocents must suffer, the guilty must suffer
www.rps.net more." - Mackenzie Calhoun, "Once Burned" by Peter David
Rikard Peterson
Gu wrote in news:hpb68191ubdvcthkl...@4ax.com:
> PS: See, Rekard Peterson? I've Used Capital Letters ^__-
Thanks. :) It's appreciated.
Rikard
Gu
>>As far as I can tell, your main argument seems to be that learning to
>>program IF in a general-purpose language using specialized libraries is
>>better [SNIP]
Replying to my post:
>* * * * BUT * * * *
>A lot of you concentrated on this dedicated language vs general
>purpose language thing ignoring the second part of my post. If I'm
>curious about the affirmation of those languages as TADS or Inform and
>what has been done so far could have been with "normal" languages plus
>dedicated libraries, the developement of those libraries IS NOT a
>thing I hope is going to happen. Programming IF in C would be a pain
>much more that programming in Inform, libraries or not. Why? Because C
>is hard.
[..]
>I think the need is for easier languages, being them
>adaptations of generic languages or other IF only not important
How on Earth can i underline this?! Can I use colored text and font
size 20 in usenet?! :D
Quintin Stone
> How on Earth can i underline this?! Can I use colored text and font size
> 20 in usenet?! :D
So, what, your only point is that programming is too hard?
Jon
> How on Earth can i underline this?! Can I use colored text and font
> size 20 in usenet?! :D
You could start by writing shorter posts, with shorter paragraphs.
Unless your writing is especially good, the more your post looks like
large clumps of text, the harder it is to read. You needn't stick with
the one topic, one paragraph style you learned in school.
Quintin Stone
Also, if you don't want to continually defend an assertion, don't assert
it to begin with. If general-purpose IF development wasn't the point you
wanted to make, then you shouldn't have included it in your original
message. People are posting so much about it because they find it
particularly wrong and are happy to say so. Your posts are so long and
monolithic that I can't help but skim them, so not all of your points may
be coming across.
Eric Eve
> On Mon, 09 May 2005 06:33:19 GMT, Gu <pista...@gmail.com> wrote:
>
> -1.a- A breaf degression before getting back to the main "1" part
> (samwyse)
> ALAN and Adrift, as samwyse noted, are basic and easy but
> limitated.
> Still I'm conviced they are ENOUGH to write most of the IF one
> could
> be willing to write, but people do not even try to give them a run
> "just in case" (keep on reading for the 'just in case' part)
> they'll
> end up finding something the language doesn't allow you to do.
> Doesn't
> matter than 95% of the times you'll never get to such a point.
> Anyway,
> just a matter of choices.
I'm sorry, but I'm getting genuinely confused about what point
you're actually trying to make. If your point is that it's
legitimate for people to write IF in ALAN or Adrift if that's what
suits them, then that's fine.But you seem to be going beyond this to
suggest that therefore TADS, Inform and Hugo are otiose. From the
paragraph quoted above this seems to be based on a false premise,
namely that it's easier to code the basic tasks of IF in ALAN than
in one of the more powerful languages. That may be so for some
people, but I doubt it's true for all.
As an experiment, last night I tried porting the simple Heidi game
from the Inform Beginners' Guide first to ALAN 3 and then to TADS 3.
To be sure, this was not an entirely fair test, since I'm pretty
familiar with TADS 3 and not at all familiar with ALAN (and I've
already written a tutorial TADS 3 game based on Heidi). That said, I
found it *much* harder to get the game to work in ALAN than in TADS
3, not least because ALAN 3 lacks any library, so I was forced to
code basic commands like QUIT, LOOK, TAKE, DROP and EXAMINE (except
that I short-circuited this by copying the code for these commands
from the sample game supplied).
Nonetheless, the job took me about 90 minutes or more in ALAN 3 and
10 - 15 minutes in TADS 3. The resultant TADS 3 code was also much
more compact, while the resultant implementation was much fuller.
For example, here's the first location in ALAN 3:
The outsideCottage IsA location name 'Outside the Cottage'
Description
"You stand outside a small cottage. The forest lies to the east.
"
Exit east to forest.
Exit into to outsideCottage
Check "But you've only just come out, and it's such a lovely day
for a walk!"
End exit.
End The outsideCottage.
The cottage IsA object At outsideCottage
name small cottage
description
verb examine does
"It's small, but pretty and comfortable, and you're happy
there."
end verb.
verb enter does
"But it's such a lovely day for a walk! "
end verb.
end the cottage.
Now here's the TADS 3 version:
startRoom: OutdoorRoom 'Outside a Cottage' 'outside the cottage'
"You stand outside a tiny cottage. The forest lies to the east.
"
in : NoTravelMessage { "But it's such a lovely day for a walk!
" }
east = forest
;
+ Enterable -> (startRoom.in) 'small tiny simple
cottage/home/house/shed/hovel/building' 'small cottage'
"It's small and simple, but you're very happy here. "
;
It may look slightly more cryptic to the unitiated, but it's a good
deal less typing, and it's hard to see how the coding effort could
be optimised much further. I found it not only easier, but *much*
easier to do it this way.
You also seem to be assuming that the more complex parts of a
language like TADS or Inform are only needed for a small minority
of games that do particularly clever things. I'm not so sure. To
date I've released two full-length games, both written in TADS 3. I
think I would have found it considerably harder to produce the same
games in Inform, and I would have been totally defeated by the
attempt to produce them in ALAN: I'm not saying it couldn't be done,
but I am saying that *I* could not have done it, so there's at least
one IF-author (me) who would have been severely hampered by the lack
of a TADS-like language in which to work. I very much doubt that I'm
alone. That's in no way intended as a criticism of authors who
prefer to work in ALAN or Adrift, it's just to affirm from my own
practical experience of writing IF that a TADS-like language (be it
TADS, Inform or Hugo) is a godsend. I strongly suspect I am not
alone among IF authors in thinking so.
In other words, there is a need for TADS-like languages because
(unless I'm much mistaken), there are a sizeable number of IF
authors who would rather work with them than with anything else;
these languages meet a felt need. That in no way excludes the
possibility that someone might come up with something simpler and
easier but even more powerful in the future, but unless and until
that wonder language actually becomes available, there will continue
to be a need for TADS-like languages, since they will continue to be
the tool of choice for many (though not all) authors of IF.
-- Eric
Ian Haberkorn
> some people will use a
> wonderful "IF for everybody" toolset to create wonderful stuff -- but
> *those* guys will be grossly outnumbered by the kind of doofus who
> whips out "Conan Kill Everything" in 2.4 minutes *and thinks it's
> wonderful*.
Hey cubist,
Wrote my first IF and got a handful of mails from people who said they
liked playing Conan. I think, it's wonderful.
So join in, spend a few minutes (imagine what you could do in 4.8 or
even 9.6 minutes!) and create a game. If that's no challenge, do it in
a foreign language. Or, if Inform is too easy, do it in Fortran.
If you are to busy at the moment I'd accept a catalog of your earlier
IF works instead.
Ian
Adrien Beau
>
> *those* guys will be grossly outnumbered by the kind of doofus
> who whips out "Conan Kill Everything" in 2.4 minutes *and thinks
> it's wonderful*.
I somewhat agree with the rest of your posts (so far), but here.
You are so wrong (and insulting). Conan is a short, fun and good
game. Made two of my commutes vanish in a puff of smoke (or
something). Not all games do that.
--
spam....@free.fr
You have my name and my hostname: you can mail me.
(Put a period between my first and last names).
cub...@aol.com
> cub...@aol.com schrieb:
> > some people will use a
> > wonderful "IF for everybody" toolset to create wonderful stuff --
but
> > *those* guys will be grossly outnumbered by the kind of doofus who
> > whips out "Conan Kill Everything" in 2.4 minutes *and thinks it's
> > wonderful*.
>
> Hey cubist,
> Wrote my first IF and got a handful of mails from people who said
they
> liked playing Conan. I think, it's wonderful.
joke, not as a "serious" work of IF. There is definitely a place for
jokes, of course, just as there is also a place for "serious" works --
but the rules are different for comedy, and there are things you can
get away with in jokes, that would be grossly inappropriate for
"serious" IF. Am I wrong to think that CKE was intended as a joke, not
as a "serious" work?
Put it this way: There's a difference between making low-quality
stuff *because you deliberately CHOSE to do so* (as, perhaps, in the
service of a joke), and making low-quality stuff *because you CAN'T do
any better*. My presumption is that CKE is a work in the former
category, not the latter. Am I wrong to think so?
> So join in, spend a few minutes (imagine what you could do in 4.8 or
> even 9.6 minutes!) and create a game. If that's no challenge, do it
in
> a foreign language. Or, if Inform is too easy, do it in Fortran.
No. I have a pretty good idea of what sort of game I could put
together in a single-digit number of minutes. If I did this thing,
anyone who played the resulting game would think it sucks, and they'd
be *right* to think so. For some strange reason, I'd be willing to bet
that *you* spent significantly longer than 2.4, or even 9.6, minutes
writing CKE...
> If you are to busy at the moment I'd accept a catalog of your earlier
> IF works instead.
Sure. Here, between the brackets, is a complete list of all the IF
I've written:
[]
I was unaware that having a catalog of previous IF was a requirement
before one could post opinions to RAIF. If such a requirement exists,
please let me know and I shall never darken your towels again.
cub...@aol.com
> On Mercredi 11 Mai 2005 14:01, cub...@aol.com wrote:
> >
> > *those* guys will be grossly outnumbered by the kind of doofus
> > who whips out "Conan Kill Everything" in 2.4 minutes *and thinks
> > it's wonderful*.
>
> I somewhat agree with the rest of your posts (so far), but here.
> You are so wrong (and insulting). Conan is a short, fun and good
> game. Made two of my commutes vanish in a puff of smoke (or
> something). Not all games do that.
you got the joke and it made you laugh. True?
Adam Thornton
<cub...@aol.com> wrote:
> Put it this way: There's a difference between making low-quality
>stuff *because you deliberately CHOSE to do so* (as, perhaps, in the
>service of a joke), and making low-quality stuff *because you CAN'T do
>any better*. My presumption is that CKE is a work in the former
>category, not the latter. Am I wrong to think so?
I think your fundamental mistake is in your categorization of CKE as
"low-quality stuff."
It's quite competently implemented; it's amusing; I remember no
egregious spelling or grammatical errors. It's not low-quality, just
quite limited in scope.
If you would like to play a low-quality game, I recommend "My First
Stupid Game," "Aunt Nancy's House," "The Incredible Erotic Adventures of
Stiffy Makane," or "Detective."
Adam
Adrien Beau
>
> My guess is, you enjoyed CKE beause you got the joke and it made
> you laugh. True?
I don't know if there's a joke to get in CKE. It's just a silly,
funny little game. A small but well made caricature.
cub...@aol.com
[various bits snipped at random]
> -1- cub...@aol.com
> I find your writing arrogant and irritating, the sort of flasmish "In
> this newsgroup I'm the Only One who knows everything about any
> argument and don't even try to have opinions that I don't share
couase
> they'll surely fall miserably into the darkness because everyone is
> ignorant but me".
I strive to express myself with clarity. I do not expect that my
opinions will necessarily be shared by anyone else; I do, however,
expect that anyone who disagrees with me will set forth his reasons
*why* he disagrees, and with luck, we can have an interesting
discussion which maybe ends up inducing somebody to change their mind.
If someone out there just can't deal with the fact that another person
has a different opinion than they do... well, that's *their* problem,
not mine. [shrug]
> I'm not a biologist, but I can presum you dwell
> somewhere deep in the heart of the Earth or deep in some forest and
> you belong to the the specis commonly known as "trollus comunis".
Hold this thought...
> >> 1. a dedicated language
> > Because writing IF is a specialized task which is best approached
> >with specialized tools. When you *need* a left-handed three-ply
grommet
> >wrench, you *need* a left-handed three-ply grommet wrench, end of
> >iscussion, and there's no point in complaining about how difficult
it
> >is to adjust the knurl flanges on the damn thing.
>
> Considering IF a specialized task is right. On the
> other hand, general languages are not meant for "general tasks"
simply
> because there are no general tasks.
True; rather than "general tasks", there are any number of
individual "specific tasks", each of which has its own specific quirks
and requirements. What you aren't taking into consideration (or, if you
*are* taking it into consideration, it is not at all evident in your
writing) is not all languages are equally well-suited to deal with all
of these specific quirks and requirements. I think the "grommet wrench"
analogy could stand to be extended a bit further here...
Some tasks *do* require (the programming equivalent of) a
left-handed three-ply grommet wrench, and others don't. Similarly, some
languages explicitly provide an honest-to-God left-handed three-ply
grommet wrench, while other languages force you to improvise one out of
pliers, a screwdriver, two Allen wrenches, and duct tape. Technically
speaking, both kinds of languages will let you *do* the task which
requires the grommet wrench... but wouldn't it make more sense to use a
language that *explicitly provides* the tool, rather than a language
that forces you to "roll your own"?
IF languages such as Inform and TADS exist because they provide a
full set of IF-specific, left-handed three-ply grommet wrenches.
> Writing a Doom clone or
> Pakman 2, writing Microsoft Word 2006 or the latest Mp3 player for
> Linux are specialized tasks done with pretty much the same means
using
> extentios like graphic libraries, multimedia libraries, gui
libraries.
> Again, IF seems to be on another world: people have been programming
> all the programs you're running at the moment, including Agent
> newsreader you're writing it, emule in the background, the firewall
> you're using, Firefox and Eudora, the MSN you're chatting with and
> Winamp you're using to listen to your CDs with the same languages but
> *obviously* they arre all easy and straight forward to program...
You read it here first, folks: Everything Gu mentioned -- Firefox,
multimedia libraries, all of that -- it isn't just "easy and straight
forward to program", it's OBVIOUSLY "easy and straight forward to
program".
Wow. And *Gu* has the balls to accuse *me* of being "arrogant" and
displaying trollish traits..?
> ...while IF needs *obviously* a dedicated language.
Again: It makes more sense to use a language which explicitly
provides the needed tools, rather than a language which forces you to
roll your own.
> >> 2. a hard-to-learn language.
> > Because writing IF is *intrinsically difficult*. You can argue
about
> >whether it *should be* intrinsically difficult, but you simply
*cannot*
> >dispute that it *is* intrinsically difficult.
>
> I disagree. Trol.. ehm, cubist has been accused of being elitist.
Yep. Some people apparently failed to distinguish between an "is"
claim and an "ought" claim.
> Affirming that writing IF is a hard task and you can approach it only
> if you're a computer scientist is possibly the worst way of acting
and
> keeping people away from IF.
Where did I say "only if you're a computer scientist", Gu?
> Writing *certain* IF is hard, and those
> *hard to code IF* are not automatically the best IF.
True, and what of it? I honestly don't see what you're driving at
here. Are you seriously arguing that "Feature X doesn't *automatically*
result in Good IF" is a valid reason for an IF toolset to *not* include
Feature X?
> ALAN and Adrift, as samwyse noted, are basic and easy but limitated.
> Still I'm conviced they are ENOUGH to write most of the IF one could
> be willing to write, but people do not even try to give them a run
> "just in case" (keep on reading for the 'just in case' part) they'll
> end up finding something the language doesn't allow you to do.
Doesn't
> matter than 95% of the times you'll never get to such a point.
So... it's a Bad Thing to go *beyond* least-common-denominator? IF
writers should just be content with whatever capabilities are provided
with Adrift (or whatever), and *never* explore outside that particular
boundary? When somebody wants to do something that *is* in the 5% of
the time which they *do* get to that point, their choices should be
limited to (a) give up on doing that outside-the-95% thing at all, or
else (b) throw away *every* *last* *bit* of the experience they have
with their *current* toolset so that they can spend whatever amount of
time learning a *new* toolset, *before* they start to work on their
shiny new outside-the-95% IF concept?
> Say I have to write a "Hello world"
> program that runs under DOS. Don't ask me why should I ever, but pick
> it as an example. Everyone told me that Java is very used, it can run
> in a virtual machine so, once my wonderful Hello World program is
> written, they can run it on Linux and Mac and Sun machines and this
> seems to me great. Plus i've read somewhere it is a very powerful
> language and it can let me do a lot of nice staff. I start learning
> java and after a while i have my program:
>
> ---
> public class Hello {
> public static void main(String[] args) {
> System.out.println("Hello World!");
> }
> }
> ---
> done. Question: have I used the right tool because everyone says Java
> is great and looking for a job in the computer industry it is still
> very popular?
If *all* you want to do is write HELLO, WORLD, Java is indeed not
likely to be the right tool for the job.
> I don't think so. I don't think that learning the types of classes
> (public etc), and the way to declare them, learning the meaning of
> "public", "static", "void", "main" and "Strings[] args" and the {}
> syntax, the object System and what out is (pant, pant ..) is
necessary
> to dirt a black screen with the eleven white letters "Hello World!".
> Is that the right tool because *just in case* with the same language
i
> can connect to a remote server, load a variable and print out
> something different from Hello World" in 3D rotating letters? What if
> I'd used BASIC?
>
> ---
> PRINT "Hello World!"
> ---
You're absolutely right: BASIC is clearly a better language than
Java to write "Hello, world!" in, which, in turn, means that BASIC is
obviously a better language than Java to write *anything* in.
If that wasn't the point you intended to make, perhaps you might try
to explain further..?
> > I've addressed this point elsewhere, so I'll summarize here: The
> >historical record of HyperCard suggests that if you make a toolset
any
> >idiot *can* use, any idiot *will* use it -- and the GOOD stuff which
is
> >made with that toolset, will sink without a trace in the sea of crap
> >produced by idiots.
>
> The IF world is already full of crap which exists in the form of
> unknown staff in ftp archives and that get that last place and a mark
> of 1 out of 10 when enter competions. But there's still people
quoting
> Bad Machine (like me in this post) and playing Zork after almost 30
> years from its first appearance. As you said, is not that there are
> hordes of people willing to write IF, but I think it's unjust to keep
> them out of the game because you've decided that things are hard,
have
> to be hard and no one can do a thing to make them easier.
*I'm* not keeping *anyone* out of IF. And I haven't *decided* that
things are hard; I've merely *recognized* that things are hard. If you
want to make things easier, go right ahead and try. I strongly doubt
you'll succeed, of course, but what the heck? I could be wrong, and for
all I know, you might come up with some nifty/useful/spiffy stuff along
the way.
> Provided with the same tool, no matter what, an artist will ever do a
> better job than the wanna-be, but this does not mean in any sense
that
> the tools have to be different and /or most of all complicated and
> unaccesible and obscure.
Okay, you don't like the complexity of Inform/TADS/etc. So what?
Having stated your opinion, what do you intend to *do* about it? Feel
free to sit around and kvetch about "The toolsets are too hard!", but
that and US$6.50 will get you a cup of coffee at Starbucks.
> ...imagine a newbie writing a game set in Russia. He needs Stalin as
NPC
> and enters the command:
> --
> create Stalin
> --
> The language does it.
How?
Seriously: *How* does the language get from the command "create
Stalin" to the NPC which appears in the game?
> Now, the point is that this Stalin would be ok
> and enough for nearly the 98% of the cases. But, if for some
unnamable
> reason you have to make this Stalin the same Stalin but good, gentle
> and not responsible for 26 million victims, I'll open the
stalin.class
> file to modify some parameters and make it a sort of cosy slavic
> little red riding hood.
Again: *How*? You are seriously deluded if you think *any* language
is going to have an honest-to-God "create Stalin" command, which
creates Stalin as a specific NPC, instead of a generic "create NPC"
command which creates a generic NPC that can be modified to become the
specific NPC Stalin.
> But again, how many times will you run into
> this case? Is it worth forcing you to write a 100 rows Stalin object
> shaping all the things the way you like to give you the power of
> changing something you'll probably never gonna change? Isn't it
better
> to have the simpliest, almost always sufficient "create Stalin"
> command WITH the ability of EVENTUALLY change it according to your
> needs?
No. Because if you have a specific "create Stalin" command, you
*will* be forced to modify the hell out of it for *any* NPC *other
than* Stalin. This being the case, a specific "create Stalin" command
isn't just useless for IF in general, it's exceedingly cumbersome for
an IF-author who is writing a game set in Russia, and it's a pain even
for an IF-author who is writing a game set in Russia during the reign
of Stalin.
Put it this way: "Do what I mean" *would* be an exceedingly useful
command -- but *how the heck are you going to IMPLEMENT the ruddy
thing*?
David Fisher
Thirty three years old, married, no kids, but a very cute albino lop eared
rabbit :-)
(How do you draw an ASCII rabbit ?)
> I remember the first word-like program I used.
[... description of painful word processor ...]
> Now, any idiot can turn on Windows move the mouse
> here and there and write a letter so professional it would
> have been impossible to write 15 years ago. The point
> is always the multi-entrylevel.
...
> The ideal language I'm talking about is much like Python.
> It lets you create [a very complex game] as well as
> [a simple game] writing lines like "print 'hello world'"
> and not caring about the rest.
I love the idea of your "ideal language", and being able to start simply
(print "hello, world") but still have unlimited flexibility if you want it
... but it still seems like a great-but-near-impossible dream to me. (But I
want one if you ever do it !)
Whatever system you use, you need to be able to translate your vision of the
game that you want to create into a programming language of some kind. The
trouble is, people are very imaginative - and there are a lot of possible
"things to be able to do" in an IF game. This is OK as far as the simple /
entry-level commands go, but there is no way to avoid a huge amount of
complexity soon thereafter ...
To try and make things more concrete, imagine an IF system which gives you a
"river" as an object for free - no programming necessary. Maybe it would let
you write:
Location: east of village
Contents: river (flowing north to south)
By default, the river has a built in set of default behaviours: you can wade
across it, it has smooth stones at the bottom, there are reeds at the side
(which can be broken off and used to breathe through), there are some small
fish in it, it is possible to find a frog in the reeds if you look hard
enough, the banks are not slippery ...
How would you specify non-default values ? For example: you can't wade
across, and it is flowing fast enough to carry away someone who is not a
strong swimmer; there are reeds, but you can't breathe through them unless
you use a long, straight object to clear out the insides first; the fish can
be caught if you use a certain type of bait; there are no frogs, and if you
dig into the east bank you will find some light brown clay which can be used
to make a water-holding vessel.
River (flowing north to south, wade(false), frogs(false), current(... ? ...)
... ) with west bank(... something about light brown clay ...) ...
OK, so that's not the way to do it - you can't just have a huge set of
objects with default behaviour, and a long list of parameters to change the
defaults for each one. (I assume you agree !)
The more specific you make the "no programming required" objects, the harder
they are to customise. Even if you do provide a whole set of adjustable
values, someone will always need to adjust something you haven't thought of:
It's winter and the river is frozen over (but you can fall through it if you
are carrying too much weight); the river is polluted and you can't drink
from it; there is a dam up river and it will overflow its banks if the dam
breaks.
So the real solution is not a whole set of specific-but-customisable
objects, it is a set of tools (programming language + libraries) that allow
you to create specific objects and behaviours out of simpler components -
also providing a set of simple objects to use just as they are, if you want
to do that.
Which sounds very similar to TADS, Inform and Hugo ...
David Fisher
Kevin Forchione
news:hpb68191ubdvcthkl...@4ax.com...
> -4- Something I liked (Kevin Forchione)
> I liked your post as much as I disliked the tone of cubist's ones. I
> think you come across various interesting and well exposed ideas and I
> must say I agree with you. The only perplexity rises when you affirm
> that learning what a main() is acceptable for the purpose of the art.
> If this is in a way true (you must learn how to master your tools to
> express your art, being them brushes, pens, harps or computers) but on
> the other hand also tools evolve. Leonardo da Vinci had to make his
> colors on his own mixing herbs with eggs and similar things. Edward
> Hopper just bought his own readly made colors. Now, with an obvious
> abstraction from the century and what it brings such as themes and
> styles, Hopper would have done the same paintings in the '300,
> Leonardo the same Mona Lisa nowadays, with the difference that using
> readly made colors is much easier and time saving and lets you
> concentrate on the smile of the Mona Lisa getting of problems like
> "have i used the right herb? Will this color turn lighter if exposed
> to a string light? Have i used enought egg yolk?".
It's a tempting notion to assume that with more convenience comes more time
to do more of what one wants to do. That's part of the seduction and charm.
But for every man's art, the tools are a part of his craft, part of the
ethos in which art is made, the forge out of which it is wrought. We have
the personal computer now, and the internet, where are all our William
Shakespeares?
But for Leonardo the making of his paints was an art, as much of an art as
that of his painting. For every man in his time, the tools of his craft are
part of his art. For the artist of TADS 3, main() and includes are part of
his tools, and he must learn to master them. In time complexity leads to
simplicity, which leads to more complexity. And for the person of TADS 4
there will be an equivalent main() and include that will be part of their
art. Because, like subatomic physics, the deeper we look into things, the
more we come to realize "it's turtles all the way down."
(http://members.tripod.com/TheoLarch/turtle.html)
--Kevin
Ian Haberkorn
> The more specific you make the "no programming required" objects, the
harder
> they are to customise.
> So the real solution is not a whole set of specific-but-customisable
> objects, it is a set of tools (programming language + libraries) that
allow
> you to create specific objects and behaviours out of simpler
components
I agree completely. An imagined world object has way too many possible
properties and attributes to anticipate in a general object library.
Reading through an Inform game code I think it is already pretty
readable. What cost me a lot of time learning was the use of grammar
and spelling:
"," is not ";"
"{" is not "["
"{;" and "[" are wrong, "{" and "[;" are correct
"=" is not "=="
"if" is not "If"
and so on.
Looking back it is very clear that those symbols are needed to fulfill
structural purposes. As Agnes pointed out, the Inform Beginner's Guide
does a great job at introducing them. Also, the compiler gives a lot of
helpful hints for bugfixing. But still, forgetting a closing tag can be
tedious to track down.
I believe, the best way to ease the learning curve would be a good GUI
for an established language replacing grammatical structure with
graphical structure. Objects could have subwindows for its properties,
attributes could be a list of checkboxes, connections between rooms
could be drawn, containment could be drag'n'drop...
(I think that stuff was discussed in earlier threads and always
abandoned for lack of someone actually writing it).
Once the writer becomes proficient he wants to work faster and can
learn the grammar of the underlying source code, much like using the
graphical interface in MS Access and moving on to SQL.
Ian
samwyse
> Reading through an Inform game code I think it is already pretty
> readable. What cost me a lot of time learning was the use of grammar
> and spelling:
> "," is not ";"
> "{" is not "["
> "{;" and "[" are wrong, "{" and "[;" are correct
> "=" is not "=="
> "if" is not "If"
> and so on.
Speaking as the guy who's always pushing the idea of pre-processors, how
would you feel about something that does away with the funny symbols?
For instance, instead of saying this:
Room Gazebo "Gazebo" with
n_to The_Garden;
Room Garden "Garden" with
s_to The_Gazebo;
you would say this:
The Gazebo is a room.
The Garden is a room.
The Garden is north of the Gazebo.
The Gazebo is south of the Garden.
In this case, the preprocessor's job is to look through a source text
for all sentences that mention the gazebo and pull them together into an
object definition. But note that although the syntax is different, it
is just as rigid as Inform's. For example, saying "The Gazebo and the
Garden are rooms." won't work because they don't fit the "X is a Y."
syntax [1]. That's the bad news, the good news is that you can disperse
your object definitions over a large file and let the pre-processor pull
the various bits together.
I've done something similar to this with a Perl script to translate
transcripts into Inform; it han't been too popular, possibly because
it's written in Perl. (I've thought about re-writing it in Python,
which can be turned into a .EXE file for Windows users. This might give
it more traction with people who don't want to install an entire
language just for one or two tools. But I don't know enough Python yet
to do that.)
The biggest issue in my mind is that the resulting language is like
COBOL, a language invented in the 1950's that used English syntax.
Instead of saying "a=b+c;", the programmer could say "add b to c giving
a." Again, it is perhaps easier for the non-programmer to read and
understand, but the compiler is just as unforgiving of errors as one for
any other programming language. And "real programmers" hate COBOL,
because it takes longer to type its version of an instruction.
[1] Of course, one can always set things up so that "X and Y are Zs." is
also recognized. This requires the pre-processor to recognize that the
plural of "Z" is "Zs", etc, but MUDS have done this in their object
creation languages. This leads to the question of how much English (in
this case) the preprocessor has to understand to be usable. Chatbots
can tease the essential meaning out of a variety of ways of expressing
an idea, so perhaps that technology could be reused. That's just moving
the cliff futher from the playground, however. It reduces the number of
people who suddenly disappear while playing soccer, but makes it more
surprising when they do. The question is, can one push the cliff so far
away that the sudden drop will never, ever, be encountered by the
average person?
JohnnyMrNinja
David Fisher wrote:
> Thirty three years old, married, no kids, but a very cute albino lop
eared
> rabbit :-)
>
> (How do you draw an ASCII rabbit ?)
____
____-------_____/ \
/ | |Q |
| | | |
| | |__}
\|______m__________\_/---m
Fixed-width is nessicary, and that "Q" needs to be red, as it's an
albino.
This is *exactly* what my rabbit looked like... I rescued him from IBM,
who had used him to safety-test ASCII. It's just so cruel...
Ian Haberkorn
friend how well-mannered this forum is, and then I misbehave myself.
samwyse schrieb:
> How would you feel about something that does away with the funny
symbols?
> For instance, instead of saying this:
>
> Room Gazebo "Gazebo" with
> n_to The_Garden;
> Room Garden "Garden" with
> s_to The_Gazebo;
>
> you would say this:
>
> The Gazebo is a room.
> The Garden is a room.
> The Garden is north of the Gazebo.
> The Gazebo is south of the Garden.
That sounds nice for a start, but I suspect the troubles arise when
more complex statements are involved, like nested conditions. Also, the
first example is structured/grouped in a better way (on line 3 of
example 2 there is a property of the Gazebo, but the grammatical
subject is Garden. An alternative:
Room Gazebo "Gazebo"
go north: Garden
Room Garden "Garden"
go south: Gazebo
I've left out the grammar, but that's where it becomes tricky: what is
an easy way to separate logical units (maybe a compiler could know that
all that comes between the two reserved words "Room" belongs to the
first).
With my limited experience I'd stick to the opinion that some GUI
functionality for Inform would help best. Put two boxes on the screen,
and draw a line in between. I made some forms with Visual Basic for
Word, which I found fairly easy to do.
But again - who will write that? There is a new topic "IF language for
nonprogrammers" which might yield someone to do the job...
Ian
Agnes Heyer
"samwyse" <deja...@email.com> skrev i melding
news:L20he.1311$sb5...@newssvr12.news.prodigy.com...
> [1] Of course, one can always set things up so that "X and Y are Zs." is
> also recognized. This requires the pre-processor to recognize that the
> plural of "Z" is "Zs", etc, but MUDS have done this in their object
> creation languages. This leads to the question of how much English (in
> this case) the preprocessor has to understand to be usable. Chatbots can
> tease the essential meaning out of a variety of ways of expressing an
> idea, so perhaps that technology could be reused. That's just moving the
> cliff futher from the playground, however. It reduces the number of
> people who suddenly disappear while playing soccer, but makes it more
> surprising when they do. The question is, can one push the cliff so far
> away that the sudden drop will never, ever, be encountered by the average
> person?
>
Let's not forget that not everyone is a native English speaker. In essence,
you would also need to create a different version of the language for every
popular natural language. Otherwise, it would defeat the purpose of having a
language that would require less time to learn, since the user would need to
learn English first.
. (ASCII rabbit seen from afar.)
Kevin Forchione
news:L20he.1311$sb5...@newssvr12.news.prodigy.com...
<snip... very interesting stuff>
> [1] Of course, one can always set things up so that "X and Y are Zs." is
> also recognized. This requires the pre-processor to recognize that the
> plural of "Z" is "Zs", etc, but MUDS have done this in their object
> creation languages. This leads to the question of how much English (in
> this case) the preprocessor has to understand to be usable. Chatbots can
> tease the essential meaning out of a variety of ways of expressing an
> idea, so perhaps that technology could be reused. That's just moving the
> cliff futher from the playground, however. It reduces the number of
> people who suddenly disappear while playing soccer, but makes it more
> surprising when they do. The question is, can one push the cliff so far
> away that the sudden drop will never, ever, be encountered by the average
> person?
I suspect the answer to your last question is a qualified "Yes, so long as
the average person produces average stories/games." But another issue that's
going to prove even more confusing to the newbie is when the compiler kicks
out syntax error messages that won't bear any resemblance to the author's
source code. Then the newbie will have to go to the precompiled source, find
the cause of the error, and then deduce which lines of his source produced
the error. In the case of an object oriented language such as TADS, this may
mean that the code needed to create a single object definition is peppered
throughout the author's source. So if they can write source that cleanly
compiles, then yes, they'll love the syntax. If it doesn't, then they'll
abhor it.
Still, for experienced authors, it could be an interesting experiment.
--Kevin
Adam Thornton
JohnnyMrNinja <Johnny...@gmail.com> wrote:
> ____
> ____-------_____/ \
> / | |Q |
> | | | |
> | | |__}
> \|______m__________\_/---m
>
>Fixed-width is nessicary, and that "Q" needs to be red, as it's an
>albino.
>
>This is *exactly* what my rabbit looked like... I rescued him from IBM,
>who had used him to safety-test ASCII. It's just so cruel...
You're lying. If he'd been used to safety-test ASCII he'd look like
____
____-------_____/ \
/ | |* |
| | | |
| | |__}
\|______m__________\_/---m
And then of course some arsewank would come along with a sharp stick and
go:
____
____-------_____/ \
/ | |*<--- Perth
| | | |
| | |__}
\|______m__________\_/---m
Which is why you shouldn't let your ASCII rabbits out on usenet.
Adam
David Fisher
news:1115991697.4...@g49g2000cwa.googlegroups.com...
>
> David Fisher wrote:
>> Thirty three years old, married, no kids, but a very cute
>> albino lop eared rabbit :-)
>>
>> (How do you draw an ASCII rabbit ?)
>
> ____
> ____-------_____/ \
> / | |Q |
> | | | |
> | | |__}
> \|______m__________\_/---m
>
> Fixed-width is nessicary, and that "Q" needs to be red, as it's
> an albino.
Perfect ! (I liked Agnes' "ASCII rabbit seen from afar", too ... )
Can you draw him doing a triple backflip with a quarter spin ? (At least, I
*think* that's what I saw him do one day ...)
> This is *exactly* what my rabbit looked like... I rescued him from IBM,
> who had used him to safety-test ASCII. It's just so cruel...
=:P
David Fisher
Max
> first of all, the hard task is to create a system that *manages* the
> world model, and this task should be accoplished by programmers.
> creative prople should be able to focus on the *world-model* solely,
> and i don't see any current language makes it, not, most of all, i see
> that the direction is towards easier system, but toward more complex
> ones.
>
Creating a system that manages the world model is not hard (though
perhaps slow). The laws of quantum mechanics and general relativity are
(probably) enough to code that cat in the box (as well as the guy called
Schroedinger outside of it describing the process of nuclear decay and
poisoning going on inside it: this lecturer can also dismbiguate pronoun
antecedents pretty well). So we'll leave the actual *building* of the
cats, boxes, and the guys called Schroedinger and Einstein. After all,
you just have to put all the quarks in the right place. Then we'll solve
Schroedinger's equation and E=mc^2 and plug Planck's constant into
Bell's Inequality and you'll get a pretty good simulation.
On the other hand, quarks might not be the best thing to build
physicists (or cats) out of. Brains and organs (or even cells) would be
a lot easier. The best thing to make cells (or their organelles) out of
are probably not quarks but molecules.
You might want to choose the right tool for the job.
I might be reimplimenting ADRIFT in Java, but I'll stick with TADS for
myself, thank you.
--Max