New IF Language
Olaf Bickern
I didn't read every message in these threads, so please bear with me
if some points have been adressed already.
Right now, I'm working on a IF game with inform. I don't have any
programming background; I do not plan to do any programming either.
I use inform because I don't want the language limiting my writing
efforts; as far as I can tell, inform doesn't limit me (if you use
any other language, that might be true for that language as well:
I just don't know).
Why this post? I' quite content with inform. However, recent threads
made me wonder. I have two questions:
1) To those who want an easier IF language. An easier language would be
a "good thing". I would love it. In a recent thred when asked how to allow
"light (burning) torch with (unlit) torch" Zarf replied: redign your game.
As long as the design is reasonable, the IF system (language and libary)
shoud make it possible. The example is not singuar; containership doesen't
work intuitive as well (considering googled thread). Maybe many others.
The inform library goes *ways* to accomodate for traditional adventure
games: sack object, score (multiple systems!), darkness (never useful in a
"realistic" game), inventory system. The whole libary is intended for
object driven, simulationst games, but awkward for plot driven games [1].
So, as much as I would like an easier language, I'm asking how you intend
to make easier these tasks.
(I'm sill design my game, which is plot driven [1]; therefore I might have
more demands for an easy language in tæ„£e future.)
2)To those who want to crate a new IF language. The only one who not
only talks about it but who is trying, is David. And I feel quite angry
about it. (Sorry.) Not with David and not with the .NET-project (which I
*still* do not understand) but with the whole discussion (and David *as well*).
What I feel angry about is that David is planning to spend a lot of work
to create something that only *recreates* something that already exists.
This is not the first time. A lot of people choose for their first (?)
project something that alread exists. It still sucks. Why not adress the
issues I mentioned under (1)? And *if* you want to recreate everything
(because of all the librariers!) - why not create a C++ libary for
christs sake?
Ok. I' shut up now. I'm jut irritated about all this well ment effort that is out tp waste.
--
olaf
[1] Plot-driven games are what I aim for: nither simulationist, nor CYOA.
Andrew Plotkin
> Why this post? I' quite content with inform. However, recent threads
> made me wonder. I have two questions:
>
> 1) To those who want an easier IF language. An easier language would be
> a "good thing". I would love it. In a recent thred when asked how to allow
> "light (burning) torch with (unlit) torch" Zarf replied: redign your game.
> As long as the design is reasonable, the IF system (language and libary)
> shoud make it possible.
Now, be fair. What I said was, "*I* wouldn't design my game that way."
(People had *already* offered sample code on how to make Inform behave
in the desired manner.)
I said that as much for the player's benefit as for the implementor's.
If the player has to *think* about how to phrase "light the unlit
torch with the lit torch", there's already a problem -- and the
problem occurs *before* he types the command.
Other things being equal, I prefer to give the player a world full of
things that aren't so easily confused.
(Mind you, I have notes towards a game in which most of the objects
*are* torches, made of different substances, which burn at different
temperatures. In that game, I would probably wind up with a
ChooseObjects routine much like what that thread suggested.)
> The inform library goes *ways* to accomodate for traditional adventure
> games: sack object, score (multiple systems!), darkness (never useful in a
> "realistic" game), inventory system.
These are not good examples, because if your game doesn't contain
them, the library facilities don't get in your way. Patching out
darkness is a two-line fix; eliminating the score command is nearly as
easy; skipping the sack object is zero work. If you don't want an
inventory system, get rid of the "take" and "inventory" commands.
These are not barriers to game creation.
I agree that there are plenty of awkwardnesses in Inform. The example
of containership, which you mention, is good. Disambiguation of inputs
is only weakly customizable. Chained, automatic actions (like implicit
take) are a terrible hack and almost impossible to handle cleanly.
Location is a tree, and there's no support for distance, sublocation,
or what TADS calls sense-paths.
These are things that are hard to add. If you want them, Inform's
design *does* get in your way. That's the distinction I'm making.
> The whole libary is intended for object driven, simulationst games,
> but awkward for plot driven games [1].
> [1] Plot-driven games are what I aim for: nither simulationist, nor
> CYOA.
What distinction are you making here?
I usually think of Inform as *not* good for simulation-mode games. It
has a very simple action model -- really just location, containers,
get, drop, and put. Everything else is left entirely up the author.
The balance was designed for Zork-style games, of course; Inform
exists because Graham wanted to write _Curses_. But I don't know what
you mean by "plot-driven" that *doesn't* fit into this model.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
OKB (not okblacke)
> 1) To those who want an easier IF language. An easier language
> would be a "good thing". I would love it. In a recent thred when
> asked how to allow "light (burning) torch with (unlit) torch" Zarf
> replied: redign your game. As long as the design is reasonable, the
> IF system (language and libary) shoud make it possible. The example
> is not singuar; containership doesen't work intuitive as well
> (considering googled thread). Maybe many others. The inform library
> goes *ways* to accomodate for traditional adventure games: sack
> object, score (multiple systems!), darkness (never useful in a
> "realistic" game), inventory system. The whole libary is intended
> for object driven, simulationst games, but awkward for plot driven
> games [1]. So, as much as I would like an easier language, I'm
> asking how you intend to make easier these tasks.
As zarf pointed out in his post, you are both right and wrong.
Inform IS quite inflexible in certain areas, but the examples you cite
are not the most difficult ones. I agree with you wholeheartedly on
this point, and it is a big reason why I have stopped using Inform.
> 2)To those who want to crate a new IF language. The only one who
> not only talks about it but who is trying, is David. And I feel
> quite angry about it. (Sorry.) Not with David and not with the
> .NET-project (which I *still* do not understand) but with the whole
> discussion (and David *as well*). What I feel angry about is that
> David is planning to spend a lot of work to create something that
> only *recreates* something that already exists. This is not the
> first time. A lot of people choose for their first (?) project
> something that alread exists. It still sucks. Why not adress the
> issues I mentioned under (1)?
This I disagree with. I don't actually know how far Dave has
progressed with his .NET IF project, but what I do know is that TADS 3
is a new language-and-library system currently under development,
pretty close to beta status, which goes quite a ways to addressing
your concerns. It has a much more unified design than Inform and
hence is more flexible in many ways. (Whether it incorporates
specific features you would find helpful to the creation of your plot-
based games I can't say, since I can't really tell from your post what
those features would be.) Moreover, Mike Roberts has been and
continues to be phenomenally productive, both in discerning areas of
IF programming that warrant the development of more sophisticated
tools and in evaluating suggestions from others on what might be
useful.
Now, I don't mean to say that TADS 3 is necessarily the be-all and
the end-all for your IF authorship needs; it is complex, and whether
it's a good fit for you can't be decided by anyone else. Nor do I
mean to say that this is an opportunity to spam the tads3 list with
zany suggestions (not that I think you would); that would be
unhelpful. BUT: if you are irritated by the cobbled-together nature
of Inform, and are looking for something whose design is more planned
and careful, you may want to look at TADS 3.
(The only reason I babble about this at such length is that your
concerns as expressed seem to closely resemble my own, so I think that
you too may be interested in this.)
> And *if* you want to recreate
> everything (because of all the librariers!) - why not create a C++
> libary for christs sake?
This has been discussed repeatedly. I don't have the Google links
at hand just this minute, but suffice it to say that C++ (and most
general-purpose programming languages) are ill-suited to writing IF.
--
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
David A. Cornelson
news:llthcp...@gmx.net...
>
> 2)To those who want to crate a new IF language. The only one who not
> only talks about it but who is trying, is David. And I feel quite angry
> about it. (Sorry.) Not with David and not with the .NET-project (which I
> *still* do not understand) but with the whole discussion (and David *as
well*).
> What I feel angry about is that David is planning to spend a lot of work
> to create something that only *recreates* something that already exists.
> This is not the first time. A lot of people choose for their first (?)
> project something that alread exists. It still sucks. Why not adress the
> issues I mentioned under (1)? And *if* you want to recreate everything
> (because of all the librariers!) - why not create a C++ libary for
> christs sake?
The only answer I can give you is "because I want to". None of the other
reasons I have make any sense to anyone but me it seems.
And I hate pointers and mallocs and such. The C++ syntax is not exactly
poetry if you ask me.
Also, I have been in this community for 6 years. I know how big of an idiot
I am. Trust me.
Dave
Kevin Forchione
> Also, I have been in this community for 6 years. I know how big of an
idiot
> I am. Trust me.
Heh. We're all fools to our muse. Don't let that stop you. If you succeed,
the community is better for it. If you don't, well, pick up the pieces and
no harm done.
--Kevin
Jim Aikin
news:llthcp...@gmx.net...
> [1] Plot-driven games are what I aim for: nither simulationist, nor CYOA.
I've thought a bit about what the term "plot" means in the context of IF.
I'd be very curious to learn more about what you mean by this, or how you
envision the unfolding of a plot-driven game.
The easiest and perhaps most sensible way to look at plot in IF is that the
player character is the protagonist, and the puzzles are the obstacles that
lie between the protagonist and the achievement of his/her happy ending.
The rising action of the IF plot is the process in which new regions of the
landscape open up and new perplexities confront the protagonist. The "master
puzzle" at the end of the game forms the dramatic climax.
There's nothing particularly esoteric or obscure about this parallelism with
conventional fiction. In the hands of a decent author, all of the resources
and dramatic possibilities of conventional fiction should be readily
available in IF -- plot reversals and twists, revelations about various
characters (including, perhaps, the player character, who might be revealed
midway through the game to have motives or defects that were not apparent at
the outset), atmosphere, dramatic incident, even symbolism.
The one thing the IF author has limited control over is pacing. But so what?
A painter has even less control over audio. Every genre has limitations.
The fact that so few works of IF written to date rise anywhere near the
level of literature has very little to do with the limitations of the
existing programming languages, it seems to me. It may have something to do
with the fact that conceiving of and assembling an effective interactive
story is an order of magnitude more complex than conceiving of and writing a
conventional story. It may have something to do with the fact that the field
is still very small and very new. Or, if you'll forgive my ending on a
cynical note, it may have something to do with the fact that, as happens in
other genres, IF authors have become enamored of certain conventional
gestures that please the cognoscenti but don't lend themselves to much in
the way of literary depth or quality.
--JA
Gene Wirchenko
[snip]
>(Mind you, I have notes towards a game in which most of the objects
>*are* torches, made of different substances, which burn at different
>temperatures. In that game, I would probably wind up with a
>ChooseObjects routine much like what that thread suggested.)
>light torch
Which torch do you mean? The wooden torch, the torch made of
rushes, or the torch that Leftpondians call a flashlight?
>flashlight
Lit. You know you just wasted a match though, don't you?
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
dgr...@cs.csbuak.edu
> I now have read numerous threads on "easiest" and "new" IF languages.
> I didn't read every message in these threads, so please bear with me
> if some points have been adressed already.
> Right now, I'm working on a IF game with inform. I don't have any
> programming background; I do not plan to do any programming either.
> I use inform because I don't want the language limiting my writing
> efforts; as far as I can tell, inform doesn't limit me (if you use
> any other language, that might be true for that language as well:
> I just don't know).
You need to keep in mind that Inform was written specifically to make it
easy to create IF games. Sure, you can use C, Perl, or maybe even COBOL
to make IF, but that rapidly approaches the pleasure of kicking dead
whales down the beach. If you were to examine "real" programming
languages, you'd see that different languages are suited for different
tasks. You are indeed programming when you create your game. The main
reason why Inform resembles C and to some extend C++ is because the
designers saw no reason to reinvent wheels when simply mounting new tires
would do the job.
> Why this post? I' quite content with inform. However, recent threads
> made me wonder. I have two questions:
> 1) To those who want an easier IF language. An easier language would be
> a "good thing". I would love it. In a recent thred when asked how to allow
> "light (burning) torch with (unlit) torch" Zarf replied: redign your game.
> As long as the design is reasonable, the IF system (language and libary)
> shoud make it possible. The example is not singuar; containership doesen't
> work intuitive as well (considering googled thread). Maybe many others.
> The inform library goes *ways* to accomodate for traditional adventure
> games: sack object, score (multiple systems!), darkness (never useful in a
> "realistic" game), inventory system. The whole libary is intended for
> object driven, simulationst games, but awkward for plot driven games [1].
> So, as much as I would like an easier language, I'm asking how you intend
> to make easier these tasks.
I am of the opinion that if you make a game TOO simulationist, it stops
being a game and turns into drudgery. You can see this in action with
certain paper-and-pencil role-playing games. I think it was Warhammer 40k
that was described as taking some 8 hours to play 4 turns if you
scrupulously stick to the rules. I can't even tolerate some of the
bondage and discipline that AD&D imposes. So, omitting certain bits of
reality is necessary for a good game.
BTW, I was the one who was fiddling around with the "light unlit torch
with burning torch" thing. I've solved that problem handily and
eliminated the dependencies on special attributes. At least one person
correctly guessed that this torch code is in my Inform implementation of
Shadowgate. In a few days I'll upload the torch code to the IF Archive.
--
David Griffith
dgr...@cs.csbuak.edu <-- Switch the 'b' and 'u'
Adam Thornton
>the pleasure of kicking dead whales down the beach.
I have an uneasy feeling that there's a specific word for this in
Japanese porn, and that it comes in subgenres, like schoolgirls deriving
pleasure from kicking dead whales down the beach, women with big plastic
anime character heads deriving pleasure from kicking dead whales down
the beach, immaculately-dressed businesswomen deriving pleasure from
kicking dead whales down the beach, and so forth.
Adam
Adam Thornton
Anson Turner <platyp...@yahoo.com> wrote:
>In article <bif9bj$3sb7j$1...@hades.csu.net>, dgr...@cs.csbuak.edu wrote:
Obviously AD&D v1, with the Wandering Harlot table on page 192. You
ignorant <rattle rattle> slovenly trull.
Adam
Quintin Stone
> >> I can't even tolerate some of the bondage and discipline that AD&D imposes.
> >Er... What version of AD&D are *you* playing?
>
> Obviously AD&D v1, with the Wandering Harlot table on page 192. You
> ignorant <rattle rattle> slovenly trull.
Is that the PHB or the DMG?
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
Adam Thornton
DMG, duh, you cracksmoking <rattle rattle> brazen strumpet.
Adam
Daryl McCullough
>
Since you guys mentioned dungeons and dragons, I think I'll reask a
question I asked once before: Is the experience of playing interactive
fiction different from playing a role-playing game? And if so, how?
It seems to me that for any work of IF, a human "Dungeon Master" could
take over the role of the computer. A skilled DM would do a much better
job than a computer program in several ways (such as better responses
to unanticipated player actions). But is IF a cheap substitute for having
a patient DM, or is there something that people get out of IF that they
wouldn't get out of role-playing?
There are some practical advantages to IF, namely being able to play it
at any hour, being able to do stupid actions without embarassment. IF
involves no face-to-face human contact, and sometimes you don't want
any when you are playing a game.
But is there any benefit to the player from the limitations of IF? The
imperfect natural language processing, the limited range of actions,
the text-based input? Or would an artificially intelligent program
that could function as well as a human DM always be preferrable, if
it were possible?
--
Daryl McCullough
Ithaca, NY
Adam Thornton
Daryl McCullough <da...@atc-nycorp.com> wrote:
>Since you guys mentioned dungeons and dragons, I think I'll reask a
>question I asked once before: Is the experience of playing interactive
>fiction different from playing a role-playing game? And if so, how?
Ah, a topic near and dear to my heart.
>It seems to me that for any work of IF, a human "Dungeon Master" could
>take over the role of the computer. A skilled DM would do a much better
>job than a computer program in several ways (such as better responses
>to unanticipated player actions). But is IF a cheap substitute for having
>a patient DM, or is there something that people get out of IF that they
>wouldn't get out of role-playing?
IF: more detailed puzzle-solving: you see that "skilled DM would do a
much better job" bit? What that means is that if you have a tricky
puzzle, your players will either find some ingenious and unforseen way
to bypass it, or they'll solve it "the half-orc way". Often, IF has
better writing and presentation, although that depends critically on the
DM's skills. It can have a much smoother narrative arc: you can force
the shape of the story in IF in a way that would be really really
railroady and annoying if it happened in a pen-and-paper RPG.
Plus, of course, at this point all or nearly all IF is single-player
while RPGs are designed to be, generally, group experiences. David
Cornelson has invited me to talk with him about MPIF, but right now I
don't understand what that might mean if not either "chatroom" or
"RPG".
RPGs are inherently simulationist, while IF can be narrativist. I
believe that it's not a good idea to spend too much time on making IF
simulationism better, because in the limit, it converges, I think,
precisely to an RPG. This is where I and the Erasmatron part ways, of
course. But that school of thought makes sense if you take the
Aristotelean position that plot emerges dialectically out of character.
I do not. Crawford evidently does.
>There are some practical advantages to IF, namely being able to play it
>at any hour, being able to do stupid actions without embarassment. IF
>involves no face-to-face human contact, and sometimes you don't want
>any when you are playing a game.
These are good reasons too. You can play IF alone on a plane flight, for
instance.
>But is there any benefit to the player from the limitations of IF? The
>imperfect natural language processing, the limited range of actions,
>the text-based input?
The limited range of actions, yes; see above. You can constrain the
player to experience the story the way you envisioned it. I can't begin
to count the number of times my carefully-constructed scenarios and
clever hints got shredded by a party cheerily tromping through them,
paying no attention to all the cleverness I had carefully installed.
Or, worse yet, deciding to turn it into an intra-party kind of session
where everyone sits at a tavern, hassles the barmaid, and ignores the
plot hook dangling from the ceiling. Limited NLP in the form of
text-based input is only preferable in that it allows you to play IF
places that live RPGs would be socially inappropriate. Single-player
CRPGs usually let you undo actions (through a save-restore mechanism or
something); while I guess you could ask your DM to take it from the top
of the gnoll-bandits-in-the-cave encounter again if you were the only
one playing, it'd be boring for him and rude of you, probably. (Sure,
I too can construct scenarios where you and a friend are playing
one-on-one and attempting different combinations of tactics to see what
works, but in the general case, I don't think it'd work.)
>Or would an artificially intelligent program
>that could function as well as a human DM always be preferrable, if
>it were possible?
It would be very different. Is a book always preferable to a CD?
There's your answer, I think. And an AI program that could function as
well as a human DM, well, you'd feel embarassed about trying stupid
stuff in front of it. At least, I would.
Adam
Andrew Plotkin
> Andrew Plotkin <erky...@eblong.com> wrote:
>
> [snip]
>
> >(Mind you, I have notes towards a game in which most of the objects
> >*are* torches, made of different substances, which burn at different
> >temperatures. In that game, I would probably wind up with a
> >ChooseObjects routine much like what that thread suggested.)
>
> >light torch
> Which torch do you mean? The wooden torch, the torch made of
> rushes, or the torch that Leftpondians call a flashlight?
>
> >flashlight
> Lit. You know you just wasted a match though, don't you?
No, that wouldn't happen.
Adam Thornton
Anson Turner <platyp...@yahoo.com> wrote:
>> And an AI program that could function as well as a human DM, well,
>> you'd feel embarassed about trying stupid stuff in front of it. At
>> least, I would.
>Wow, that was snarky.
I certainly don't when the interface is by your grandmother the
succubus.
Adam
Adam Thornton
Anson Turner <platyp...@yahoo.com> wrote:
>Besides, at least *my* great-grandfather wasn't a DRAGON.
All right, Mister Turner, if that *IS* your real name. The gloves are
off now. No more Mister Nice Guy. Them's Fightin' Words.
Adam
Glenn P.,
> ...being able to do stupid actions without embarassment...
One of the very first games of Interactive Fiction I ever played (when
I was still young), was Infocom's "Seastalker"; and in that game, at
one point, you (the hero) are supposed to break into an NPC's locker
and read his diary... both actions that in an IF game oughtn't cause
any concern at all -- right? Well, no. I felt TERRIBLY guilty about
doing both of these things! And the diary was "mushy", too! And also,
though I could put the diary back afterwards, there was no way to
"re-lock" the locker! MUCH guilt, MUCH embarassment.
Don't imagine, therefore, that just because an IF game is computerized,
it cannot cause the player any embarassment! :(
-- _____
{~._.~} %%%%%%%%%% [ "Glenn P.," <C128...@FVI.Net> ] %%%%%%%%%%
_( Y )_ -------------------------------
(:_~*~_:) "I wasn't asleep -- I was checking my eyelids for holes!"
(_)-(_) --Heard on "Deep Space Nine."
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Olaf Bickern
> Here, Olaf Bickern <olaf.b...@gmx.net> wrote:
>> 1) To those who want an easier IF language. An easier language would be
>> a "good thing". I would love it. In a recent thred when asked how to allow
>> "light (burning) torch with (unlit) torch" Zarf replied: redign your game.
>> As long as the design is reasonable, the IF system (language and libary)
>> shoud make it possible.
>
> Now, be fair. What I said was, "*I* wouldn't design my game that way."
> (People had *already* offered sample code on how to make Inform behave
> in the desired manner.)
>
> I said that as much for the player's benefit as for the implementor's.
> If the player has to *think* about how to phrase "light the unlit
> torch with the lit torch", there's already a problem -- and the
> problem occurs *before* he types the command.
>
> Other things being equal, I prefer to give the player a world full of
> things that aren't so easily confused.
Yes. After reading other replies, it seems people are thinking I'm bashing
inform here. I'm not. I mentioned some thing that are examples where the
author's intend is not easliy translated into code. Most likely, *any*
language will have those issues. My concern is that much more effort is
put into creation *new* languages than adressing these issues. (wrt
announcing plans that is; concerning read coding it could well be different;
I am aware of all the inform library contributions).
> (Mind you, I have notes towards a game in which most of the objects
> *are* torches, made of different substances, which burn at different
> temperatures. In that game, I would probably wind up with a
> ChooseObjects routine much like what that thread suggested.)
Ok. And I agree that redesigning a game *might* be a good idea: It's easy
to think of something that is not only har to code but also irritating to
the player. Those things are not alwys identical, though.
>> The inform library goes *ways* to accomodate for traditional adventure
>> games: sack object, score (multiple systems!), darkness (never useful in a
>> "realistic" game), inventory system.
>
> These are not good examples, because if your game doesn't contain
> them, the library facilities don't get in your way. Patching out
> darkness is a two-line fix; eliminating the score command is nearly as
> easy; skipping the sack object is zero work. If you don't want an
> inventory system, get rid of the "take" and "inventory" commands.
> These are not barriers to game creation.
Sorry, you misunderstood me. No, these things don't get into my way. I
wanted to show how far inform went to accommodate a certain style of IF
game. I wanted to contrast these examples with recent threads that seemed
to say: inform (or TADS or hugo) don't help authors how want to focus on
just writing a story. It was that *conclusion* I wanted to challange.
> I agree that there are plenty of awkwardnesses in Inform. The example
> of containership, which you mention, is good. Disambiguation of inputs
> is only weakly customizable. Chained, automatic actions (like implicit
> take) are a terrible hack and almost impossible to handle cleanly.
> Location is a tree, and there's no support for distance, sublocation,
> or what TADS calls sense-paths.
>
> These are things that are hard to add. If you want them, Inform's
> design *does* get in your way. That's the distinction I'm making.
I agree. Indeed that is exactly my concern. There are so many people,
it seems, who willing to put *many* hours of their life in to IF systems.
I'd love to see these precious hours put into *advancing* IF systems
rather than into recreating that which already exists vaguley "easier".
>> The whole libary is intended for object driven, simulationst games,
>> but awkward for plot driven games [1].
>> [1] Plot-driven games are what I aim for: nither simulationist, nor
>> CYOA.
>
> What distinction are you making here?
>
> I usually think of Inform as *not* good for simulation-mode games. It
> has a very simple action model -- really just location, containers,
> get, drop, and put. Everything else is left entirely up the author.
> The balance was designed for Zork-style games, of course; Inform
> exists because Graham wanted to write _Curses_. But I don't know what
> you mean by "plot-driven" that *doesn't* fit into this model.
I guess this is the most controversial assertion I made. The world model
(in inform, but I think in TADS or hugo and I guess even in adrift, etc.)
is based on rooms and objects. You walk through rooms and manipulate
objects. Games, therefore, consist of discriptions and sub-discriptions.
Now, even in literature, which moved way from realism and discription on
the last century, I have and issue with this: even when I realise it's use,
I find it hard to accept that any mind can be concerned with the details of
someone's office, desk, house, or face (and no, *beauty* does not lie in
the details, no matter how far you go with you discriptions.
You might say, I have picked the wrong hobby (which it is not); but my game,
if I ever will finish it, *will* be in the room-object model. Inform allows
for others (mercy, apple from nowhere, and your space under the window, were
steps in into this direction I think. I'm not even sure how an IF could help
with a non-room/object game. I will certainly not be the one who is
progamming this. The idea I have is that the player's acts will not
(primariliy) manipulate objects and rooms, but a plot element. I have
accumulated some ideas, but it'S rather early. Some other time perhaps.
Olaf Bickern
> Olaf Bickern wrote:
>
> As zarf pointed out in his post, you are both right and wrong.
> Inform IS quite inflexible in certain areas, but the examples you cite
> are not the most difficult ones. I agree with you wholeheartedly on
> this point, and it is a big reason why I have stopped using Inform.
See my reply to Zarf.
[Concerning TADS.]
It seems promising. I looked into TADS 2 when I started; seemed very
similar to inform then. The reason I did not look into TADS 3 is that
the documentation is not yet done and I thought I could just as well
with inform then (concering the effort). My focus was not the weakness
of inform but the wasted effort I feel are people are making.
>> And *if* you want to recreate
>> everything (because of all the librariers!) - why not create a C++
>> libary for christs sake?
>
> This has been discussed repeatedly. I don't have the Google links
> at hand just this minute, but suffice it to say that C++ (and most
> general-purpose programming languages) are ill-suited to writing IF.
I know. I mostly agree with these arguments. I mentioned it only because
(1) the .NET project specifically mentioned all the generic libaries you
could use and (2) "*if* you want to recreate" an IF system that would at
least allow for a lot of flexibility (even if little may be useful for writing IF.
--
olaf
Olaf Bickern
> The only answer I can give you is "because I want to". None of the other
> reasons I have make any sense to anyone but me it seems.
I'm not going to attack that. My point was that I think doing something
"because I want to" is very valueable. I'd prefer some joint effort, though.
(Specifically, I'm not challenging because of using MS. (I disagree with
you advocation it, however. They are not worse than any other company.
Other's are just smaller. That's capitalism.)
--
olaf
Olaf Bickern
> The one thing the IF author has limited control over is pacing. But so what?
> A painter has even less control over audio. Every genre has limitations.
See my reply to Zarf. *This* is one thing, probably *the* one thing I find
intriguing about IF. (On an aside, I think the way to go is *faking* the
conrtol the player i.e the non-controll the author has. The perfect work
of IF might be one where the player thinks the author has no control at all,
but in truth the author has all the control.)
> The fact that so few works of IF written to date rise anywhere near the
> level of literature has very little to do with the limitations of the
> existing programming languages, it seems to me. It may have something to do
> with the fact that conceiving of and assembling an effective interactive
> story is an order of magnitude more complex than conceiving of and writing a
> conventional story. It may have something to do with the fact that the field
> is still very small and very new. Or, if you'll forgive my ending on a
> cynical note, it may have something to do with the fact that, as happens in
> other genres, IF authors have become enamored of certain conventional
> gestures that please the cognoscenti but don't lend themselves to much in
> the way of literary depth or quality.
Yes. And I'm disguted with descriptions even in literature. Plot, plot-twists,
notoriously the famous "standard plots" and plot devices, climax,
cliff-hangers, in IF: the implemetation of anything that is mentioned and of
anything the player/reader can think of: it's all very nice; no, it's very
*impressive*, and I don't think I could compete with it. Nevertheless, I
don't think it's what makes literature OR IF "great" or even worthwhile.
The artistic content tends to get in the way of the *form*. At the authors'
side - but also at the players.
--
olaf
Olaf Bickern
> In article <llthcp...@gmx.net>, Olaf Bickern <olaf.b...@gmx.net>
> wrote:
>
>> [1] Plot-driven games are what I aim for: nither simulationist, nor CYOA.
>
> I don't see why a game couldn't be both plot-driven and either of those
> things. (*Both* would be tricky.)
See my last post. I agree completly. I challange the assertion that
artistic content presupposes either perfect simulation or has to take
the cheap way out (coya).
--
olaf
Olaf Bickern
> Olaf Bickern <olaf.b...@gmx.net> wrote:
> You need to keep in mind that Inform was written specifically to make it
> easy to create IF games. Sure, you can use C, Perl, or maybe even COBOL
> to make IF, but that rapidly approaches the pleasure of kicking dead
> whales down the beach. If you were to examine "real" programming
> languages, you'd see that different languages are suited for different
> tasks. You are indeed programming when you create your game. The main
> reason why Inform resembles C and to some extend C++ is because the
> designers saw no reason to reinvent wheels when simply mounting new tires
> would do the job.
I wrote I'm not a programmer. I am indeed programming when writing an
IF game; nevertheless, I now this much about programming: you usually (!)
don't don't need advanced programming knowledge (i.e. studying programming
to write a game. Even with inform, TADS, etc.
> I am of the opinion that if you make a game TOO simulationist, it stops
> being a game and turns into drudgery. You can see this in action with
> certain paper-and-pencil role-playing games. I think it was Warhammer 40k
> that was described as taking some 8 hours to play 4 turns if you
> scrupulously stick to the rules. I can't even tolerate some of the
> bondage and discipline that AD&D imposes. So, omitting certain bits of
> reality is necessary for a good game.
I agree. And I only challanged some views that popped up in recent threads.
Or rather, I wanted them clarified.
> BTW, I was the one who was fiddling around with the "light unlit torch
> with burning torch" thing. I've solved that problem handily and
> eliminated the dependencies on special attributes. At least one person
> correctly guessed that this torch code is in my Inform implementation of
> Shadowgate. In a few days I'll upload the torch code to the IF Archive.
Fine. I only brought up the example because I thought that was something
that *is* an issue with inform (not an easy one to resolve, probably
impossibly to resolve in a general way). I have browsed the group for some
time and disambiguation problems have popped up every now and then.
--
olaf
OKB (not okblacke)
> There are so many people,
> it seems, who willing to put *many* hours of their life in to IF
> systems. I'd love to see these precious hours put into *advancing*
> IF systems rather than into recreating that which already exists
> vaguley "easier".
Hmmmm. I sort of agree with this and sort of don't. On the one
hand, yes, I think systems like ADRIFT that don't really offer any new
functionality and are just aimed at being super-easy to use are not
really major steps in the development of IF. On the other hand, it
seems to me that a lot of those hours people are putting in ARE
advancing existing systems. People write library extensions and stuff
all the time.
Admittedly, not so much is going on in the particular type of
advancement that you seem to be interested in (which you describe
below). I do think, though, that making it easier to write good games
is just as much a legitimate "advacement" of IF technology as widening
the perceived domain of what can be included in good IF.
> The world
> model (in inform, but I think in TADS or hugo and I guess even in
> adrift, etc.) is based on rooms and objects. You walk through rooms
> and manipulate objects. Games, therefore, consist of discriptions
> and sub-discriptions. Now, even in literature, which moved way from
> realism and discription on the last century, I have and issue with
> this: even when I realise it's use, I find it hard to accept that
> any mind can be concerned with the details of someone's office,
> desk, house, or face (and no, *beauty* does not lie in the details,
> no matter how far you go with you discriptions.
I definitely agree it would be great to see more games that expand
this model, or take it a new direction, or try an entirely different
model. I think, though, that this is something that has to happen
first with innovation from individual authors in individual games.
Almost by definition, it's not possible to put these kinds of things
in a library, because libraries are designed primarily for making the
common tasks easier. It's usually not clear how to implement the
innovative new ideas in the general kind of way that's needed in a
library until AFTER one or two games have paved the way.
> You might say, I have picked the wrong hobby (which it is not); but
> my game, if I ever will finish it, *will* be in the room-object
> model. Inform allows for others (mercy, apple from nowhere, and
> your space under the window, were steps in into this direction I
> think. I'm not even sure how an IF could help with a
> non-room/object game. I will certainly not be the one who is
> progamming this. The idea I have is that the player's acts will not
> (primariliy) manipulate objects and rooms, but a plot element. I
> have accumulated some ideas, but it'S rather early. Some other time
> perhaps.
Well, that sounds great! I very much look forward to seeing that
game.
Jeff Mitchell
> The only answer I can give you is "because I want to". None of the other
> reasons I have make any sense to anyone but me it seems.
See thats pretty cool; it seems sort of odd to keep certain blinders
on while coming up with a design, if you're going at it as a new project
.. you know, like you pick the right tool for the job, not picking the
job for the tool. But this is *your* project idea, so you do what the
heck you ewant, and thats pretty cool.. everyone must respect that,
though it catches every one of us off guard :) You keep bringing it
up so no one should forget, but we do anyway :)
I respect that. Don't let anyone slow you down. Someone
else will do their own project if they disagree :)
I think in terms of portability, always; I like a clean
design, and I like code that is built for maximum coverage, survivability,
expandability. I naturally discard .net except for my Windows oriented
projects.
Maybe you should just aim the discussions at the design, which
is really what you've been asking to do.. but you mention .net each time,
and that irritates the heck out of everyone, and side tracks what irt
is you want to talk about.
We can probably discuss new IF languages in general without
reference to your project per se.. talk about new languages for your
project and for (say) MUDs or whatever. Then you'd adopt the discussion
for your needs.
> And I hate pointers and mallocs and such. The C++ syntax is not exactly
> poetry if you ask me.
Even Stroustrup will agree with you :) Its pragmatic, not
pretty.
> Also, I have been in this community for 6 years. I know how big of an idiot
> I am. Trust me.
*g*
jeff
--
--
"Have you played Atari today?"