defining a new i-f programming language
L. Ron Hubbard
i-f programing languages, but - if someone were to say that he would
implement a new language if this group were to specify it, what
features would it require?
Whilst I am sure that the existing languages are perfect, some folks
may have minor quibbles so...
1) list (exhaustively) the features necessary for such a language
2) don't forget to mention any slight quibles with existing languages
3) hmm, maybe any add-on tools like IDEs to go with it?
Kodrik
The problem with current IF engines is that they generate product that
people are not willing to pay for...
But if an engine was made to recognize Klingon, you would have the whole
star trek fan based ready to pay big bucks to play it.
Just imagine if an engine recognized Psychlos, how much would you pay to
play it? And the maths puzzles would be so interesting.
If IF is to be successful, engines have to adapt and drop live languages in
favor of fictional languages and give a new meaning to the Fiction in
Interactive Fiction.
That's what I'm doing, an engine for fictional languages, and I'm planning
to make big bucks from it.
Magnus Olsson
>The problem with current IF engines is that they generate product that
>people are not willing to pay for...
>But if an engine was made to recognize Klingon, you would have the whole
>star trek fan based ready to pay big bucks to play it.
Really? I doubt that the whole Star Trek fan base is prepared to
learn enough Klingon to play games in it, but, OK, there are a *lot*
of people who study Klingon so you may be right.
But would they be willing to pay big bucks for it? That's the
crux, I suppose.
By the way, would it be possible to write a Klingon language module
for Inform?
>If IF is to be successful, engines have to adapt and drop live languages in
>favor of fictional languages and give a new meaning to the Fiction in
>Interactive Fiction.
Ah, well, that's a new and original solution to an old problem.
>That's what I'm doing, an engine for fictional languages, and I'm planning
>to make big bucks from it.
No disrespect, but I'll believe that when I see it (the big bucks, that
is, I have no reason to doubt that you can produce the engine).
Good luck with the project!
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Plugh!
>
> The problem with current IF engines is that they generate product that
> people are not willing to pay for...
> But if an engine was made to recognize Klingon, you would have the whole
> star trek fan based ready to pay big bucks to play it.
>
> Just imagine if an engine recognized Psychlos, how much would you pay to
> play it? And the maths puzzles would be so interesting.
>
> If IF is to be successful, engines have to adapt and drop live languages in
> favor of fictional languages and give a new meaning to the Fiction in
> Interactive Fiction.
>
> That's what I'm doing, an engine for fictional languages, and I'm planning
> to make big bucks from it.
sounds fascinating. Please tell as much as you can without divulging
trade secrets. Or give us a URL if you have one. Thanks.
Philipp Lenssen
news:e530a463.02020...@posting.google.com...
>..
> I feel that we have more than enough good
> i-f programing languages, but - if someone were to say that he would
> implement a new language if this group were to specify it, what
> features would it require?
I'm sure you're referring to non-graphical output exclusively (parsed text
IF a la Inform). If not, my wish-list would include a Lucasarts
kind-of-games interpreter/ compiler. And yes, I would pay for that.
I've been researching a while back and found many works-in-progress, but no
easy-to-use, complete editor/ project. Still waiting for the SCRAMM engine
to take off, but lately I can't even reach their website anymore (
http://www.scramm.org/ ).
Plugh!
definitely true O-O. Fully extensible. Fully customisable.
I liked the sound of an IDE. Make sure you have a class browser, so
that I can see where a given object derives a certain class or
property from.
Make sure that you have a big class library & implement things like
follower NCPS, or at least make sure that you make such things easy to
implement.
Think about porting, both of your compiler/development IDE and of the
game engine for players.
Think about plug-ins, so that you can start with plain text, but let
others develop plug-ins for graphics, sounds, skins, etc.
Publish a good API to allow user customisation & development of 3rd
party tools.
Have a look for other "Wouldn't it be nice" threads on r.a.i.f.
Ooops. Interruption ... more later (but don't forget a spray-can
mechanism ;-)
Kevin Forchione
Sounds like a good question to ask our Mr. Kodrik, who is apparently doing
just this....
--Kevin
Kodrik
are wrong to be in English.
I don't believe in extremes, so when I use them, it is always for humourous
purposes, even if sometimes at the expense of the extremists.
Knowing that, what do you think of this article:
http://www.cnn.com&year=2002&TECH=industry@418001782/article
Sabrejack
> ok, this one's for fun only. I feel that we have more than enough good
> i-f programing languages, but - if someone were to say that he would
> implement a new language if this group were to specify it, what
> features would it require?
Alright. I'll bite.
It would have perfect C-style syntax --
All lines would be deliniated by a semicolon, never a newline or other
whitespace. newlines and other white space inside strings would not
be ignored, they would be treated C style. Special chars, such as
quotes, would be created using escaped sequences like \", not ~ .. \n
would work for a newline if you wanted, not ^. ALL code blocks would
be enclosed in { } braces, none in [ ] brackets.
In fact, if someone simply fixed Inform (or Glulx Inform), I'd be
happy as a pig in drek.
Peter Seebach
L. Ron Hubbard <xe...@email.com> wrote:
>ok, this one's for fun only. I feel that we have more than enough good
>i-f programing languages, but - if someone were to say that he would
>implement a new language if this group were to specify it, what
>features would it require?
Mutually-exclusive ones, of course!
-s
--
Copyright 2001, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
Kodrik
First, I have no problem with the current IF languages, I mostly admire
them. I am making engine but my motivation was not because of a fault in
the languages to create the worlds, but in the way the data is stored,
accessed and delivered to the public. I wanted my data stored and accessed
through an SQL database.
If I though I could do it the way I wanted with TADS, or even write a
converter for TADS games, I would have gone that route.
When I first contemplated writing an engine, I wanted to do exaclty what
you are, list all the features that I wanted and design my complete
program. It is impossible, the list needs to include all that everyone
would ever want to creare in IF. The list never stops and you have
conflicting opinions about how to do stuff and their importance.
So I decided to organize my data in a way that allowed the most flexibles
relations. And started by offering just a few simple tools. The ability to
make rooms, containers, items and passages, and allow for simple relations
such as:
door needs to be unlocked by key then opened before going through passage.
From there, I invited people to write their own adventures with the system
and ask features as they need them, which I implement within days.
They have, and the capabilities of the engine has grown, not directed by my
own views, but directed by real needs of authors, beginners and experiencd.
I'll probably be adding features forever but since I made my foundation
flexible enough that adding feature is quick and easy, it is not a big
drawback for the authors and quite complex adventure can already be made.
So my advise is, start with simple, plan for expansion, have people use it
while in development and work closely with them.
But don't think it's easy or you can plan it all. There is so much to do,
and it will never end.
Adam Thornton
>people are not willing to pay for...
>But if an engine was made to recognize Klingon, you would have the whole
>star trek fan based ready to pay big bucks to play it.
>
>Just imagine if an engine recognized Psychlos, how much would you pay to
>play it? And the maths puzzles would be so interesting.
>
>If IF is to be successful, engines have to adapt and drop live languages in
>favor of fictional languages and give a new meaning to the Fiction in
>Interactive Fiction.
>
>That's what I'm doing, an engine for fictional languages, and I'm planning
>to make big bucks from it.
You are aware that Inform contains support for multiple languages,
right?
I also think there's a flaw in your reasoning, since I can't even find
anyone willing to test the Latin.h Lingua Latina library replacement
I've been sporadically working on--or was up until I got swamped by real
work--for Inform. Let alone anyone who'd pay for it.
Adam
Adam Thornton
Sabrejack <pho...@urisp.com> wrote:
>It would have perfect C-style syntax --
>All lines would be deliniated by a semicolon, never a newline or other
>whitespace. newlines and other white space inside strings would not
>be ignored, they would be treated C style. Special chars, such as
>quotes, would be created using escaped sequences like \", not ~ .. \n
>would work for a newline if you wanted, not ^. ALL code blocks would
>be enclosed in { } braces, none in [ ] brackets.
>
>In fact, if someone simply fixed Inform (or Glulx Inform), I'd be
>happy as a pig in drek.
All of this seems like minor syntactic sugar that could be fairly easily
"fixed" with a preprocessor. Not that I'm offering to write it, but
that looks like a pretty straightforward filter to write.
Adam
John Elliott
>Knowing that, what do you think of this article:
>http://www.cnn.com&year=2002&TECH=industry@418001782/article
That it's actually on cm118.51.234.24.lvcm.com. The @ sign is a dead
giveaway.
--
John Elliott
Kodrik
Besides being a funky url for 24.234.51.118, the text of my post as well as
the content of the article are dead giveaways. It is not meant to fool for
more than a second.
Magnus Olsson
Well, I was fooled for more than a second.
I suppose that makes me an idiot.
L. Ron Hubbard
ferinstance, to try to get some discussion going)
Kodrik
I don't think you were fooled after you read the article itself, especially
after reading my quote :) in it.
It's normal to be fooled by the url itself, either you know about funky
urls or you don't, nothing to do with intelligence.
I wonder why spammers don't use it in their illegal spam mail, "buy this
great thing, read about it in the NY times, CNN...". It will fool a lareg
percentage of their target.
Magnus Olsson
But you don't have to define a new language in order to get an
inproved parser. Both the Inform and TADS3 parsers are written in
their respective languages - on top of the language rather than as
part of teh language itself.
Jeremy Silver
> By the way, would it be possible to write a Klingon language module
> for Inform?
chaq. *Inform*vaD tlhIngan Hol bobcho' qonlaH vay' 'e' vIQub
(Maybe. I think that someone can compose a Klingon Language module for
Inform ;)
I think the main points to consider would be the case-sensitivity of
the language, and the different compass system. On board ship there
are terms for port, starboard etc., but on land things would be more
problematic.
--
Jeremy Silver |\ jeremy at mupwi.demon.co.uk
__________________| \
|__________________| |
| | A1200T, Blizzard 1260, 34Mb
mupwI' yI'uchtaH! |__| 10Gb HD. Amiga Forever.
Plugh!
automapper in hte interpretter?
David Brain
Yes, but Kodrik's talking about *fictional* languages. You're talking about
Latin, which is* a real language.
--
David Brain
London, UK
*well, that's a matter of opinion really. Personally, I think Latin is a
fictional language that was invented as a joke by medieval monks.
Gary Shannon
the things I type as being "conversations" with my imaginary friend, but
rather as commands to the computer which, like pushing the buttons on my
game console controller, should be as unobstrusive as possible so as not to
interrupt the flow of the story/game.
Viewed in that way terse abbreviated commands work fine for me, even if
there is something of a learning curve involved in getting to know them.
One place a better parser _would_ be nice would be in the area of actual
simulated conversation with NPC AI.
But it occurs to me that if I were going to converse with NPC's on a regular
basis I might want that to be something quite seperate from the commands I
am giving my digital alter ego. Perhaps in addition to the command line
there could be a "chat window" for actually chatting with NPC's. This way
things like "N, E, X rock, take rock, eat rock..." and things like "Good
morning Sam. Have you seen Patricia yet?" would be physically seperate on
the screen just as they are conceptually seperate in my mind. The seperate
chat window combined with decent NPC AI and a better parser would permit a
whole new class of conversation-based games without the clumsiness and
artificiality of commands like:
>say "hello Sam"
Too bad AI hasn't come far enough to do that yet :-(
--gary
"L. Ron Hubbard" <xe...@email.com> wrote in message
news:e530a463.02020...@posting.google.com...
Plugh!
for a previous thread on this topic
Plugh!
(is that correct?). It seems you want requirements for language
syntax/class hierachy & libraries/compiler/interpreter/other tools -
everything from both an authors & a players point of view. If you
clarify that, we can help a bit more.
In terms of a class tree, I think you should attempt the fine
distinction between locations (generally rooms) and objects which can
contain other things (sacks/bags/pockets/etc). That is, the location
of something can be either of these, but the player can't go north
into the rucksack.
Adam Thornton
David Brain <ne...@davidbrain.co.uk> wrote:
>In article <a3rimp$3cj$4...@news.fsf.net>, ad...@fsf.net (Adam Thornton) wrote:
>> I also think there's a flaw in your reasoning, since I can't even find
>> anyone willing to test the Latin.h Lingua Latina library replacement
>> I've been sporadically working on--or was up until I got swamped by real
>> work--for Inform. Let alone anyone who'd pay for it.
>Yes, but Kodrik's talking about *fictional* languages. You're talking about
>Latin, which is* a real language.
Plus, those people who *could* betatest it are quite aware that it will
be used to write _Mentula Macanus: Apocolocyntosis_, and they refuse to
harness the Awesome Power of Inform's Multilingualism for Evil rather
than Good.
Adam
David Thornley
>> ok, this one's for fun only. I feel that we have more than enough good
>> i-f programing languages, but - if someone were to say that he would
>> implement a new language if this group were to specify it, what
>> features would it require?
>
>Alright. I'll bite.
>
>It would have perfect C-style syntax --
No, it would be a set of packages for Common Lisp, and therefore
would be programmed as CL. (CL is *really* flexible; if you don't
like the built-in object-oriented programming system, for example,
you can hack up another, which works within the language, rather
easily. Sometimes done as a one-chapter exercise.)
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Julian Fondren
> Plus, those people who *could* betatest it are quite aware that it will
> be used to write _Mentula Macanus: Apocolocyntosis_, and they refuse to
> harness the Awesome Power of Inform's Multilingualism for Evil rather
> than Good.
Well, this is the first I've heard of it. Where is it?
Adam Thornton
On my hard drive, in ~adam/IF/mma.
It's about 20% done. (The library, not the game, which isn't started.)
Adam
L. Ross Raszewski
>In article <17f6c0a1.0202...@posting.google.com>,
>Sabrejack <pho...@urisp.com> wrote:
>>xe...@email.com (L. Ron Hubbard) wrote:
>>> ok, this one's for fun only. I feel that we have more than enough good
>>> i-f programing languages, but - if someone were to say that he would
>>> implement a new language if this group were to specify it, what
>>> features would it require?
>>
>>Alright. I'll bite.
>>
>>It would have perfect C-style syntax --
>
>No, it would be a set of packages for Common Lisp, and therefore
>would be programmed as CL. (CL is *really* flexible; if you don't
>like the built-in object-oriented programming system, for example,
>you can hack up another, which works within the language, rather
>easily. Sometimes done as a one-chapter exercise.)
>
Screw that. I want the whole thing to adhere to Standard ML of New
Jersey syntax.
Mmm.... Curried Functions....
Gary Shannon
textures:
floor1 = "Square stones, crudely cut and set unevenly cover the floor"
floor2 = "You see narrow oak strips, well worn but highly polished."
...
wall6 = "Floor to ceiling bookcases filled with musty old volumes cover the
%d wall."
....
backdrop3 = "Distant mountains, barely visable through the mist, ..."
Then apply the textures to objects:
room1
floor = floor1
ceiling = ceiling3
northWall = wall6
southWindowView = backdrop3
contains = [ stockDesk3, stockDeskBlotter1, customDeskLamp ]
...
Then use a spreadsheet type of layout for object interactions. When every
cell is filled in then no possible interaction ("unlock chest with loaf of
bread") has been overlooked.
All that is necessary is for the language designer to anticipate every
possible situation the IF author could ever imagine using. (The enumeration
of every possible situation is left as an exercise for the reader. ;-)
--gary
wo...@one.net
>hmm, maybe something slightly more C++/Java like? In any case,
>definitely true O-O. Fully extensible. Fully customisable.
C++/Java syntax? Yuck. :) C++/Java syntax aside, PAWS matches most of
your criteria nicely. 20 OS's, from Palm Pilots to mainframes and
everything in between...
>Think about plug-ins, so that you can start with plain text, but let
>others develop plug-ins for graphics, sounds, skins, etc.
Scads of pre-written libraries for all sorts of things, and all kinds
of multimedia available too. :)
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
Kodrik
* You create rooms placing them in your universe using a 4 coordinate
system and then place elements in your room (containers, items, passages,
creatures...)
* Each element has a descritpion associated to it and an order to specify
where the text of the description should be within the room description.
* Each element has a set of actions associated to it that are triggered
depending on the user input, the state of any other element as well as game
variables (counter, time, turn, score...). These actions can be ordered so
that some have priroties over others.
* When an action is triggered, this action can modify the state of any
element in the game, including their description and outputs an activation
text for the user to read.
It seems pretty simple, but it lets you combine stuff in unlimited ways and
let you do most of what is required for a piece of IF.
Kevin Forchione
news:u66okfr...@corp.supernews.com...
> That's kind of the approach I took:
> * You create rooms placing them in your universe using a 4 coordinate
> system and then place elements in your room (containers, items, passages,
> creatures...)
> * Each element has a descritpion associated to it and an order to specify
> where the text of the description should be within the room description.
> * Each element has a set of actions associated to it that are triggered
> depending on the user input, the state of any other element as well as
game
> variables (counter, time, turn, score...). These actions can be ordered so
> that some have priroties over others.
> * When an action is triggered, this action can modify the state of any
> element in the game, including their description and outputs an activation
> text for the user to read.
>
> It seems pretty simple, but it lets you combine stuff in unlimited ways
and
> let you do most of what is required for a piece of IF.
Most?
--Kevin
David Given
"Philipp Lenssen" <ph...@mrinfo.de> writes:
[...]
> I'm sure you're referring to non-graphical output exclusively (parsed text
> IF a la Inform). If not, my wish-list would include a Lucasarts
> kind-of-games interpreter/ compiler.
[...]
*cough*
http://scummvm.sourceforge.net/
(free SCUMM 'terp)
http://plover.net/~hjalfi/scumm/index.html
or /scumm.html
or /scumm.pdf
or /scumm.dvi
(work-in-progress SCUMM documentation)
http://www.cowlark.com/cgi-bin/getpage.awk?/Unix
(work-in-progress SCUMM compiler/decompiler)
> I've been researching a while back and found many works-in-progress, but no
> easy-to-use, complete editor/ project. Still waiting for the SCRAMM engine
> to take off, but lately I can't even reach their website anymore (
> http://www.scramm.org/ ).
Yeah, Mix'n'mojo, who host them, have been having some major problems.
--
+- David Given --------McQ-+ "The sky was the perfect untroubled blue of a
| Work: d...@tao-group.com | television screen, tuned to a dead channel." ---
| Play: d...@cowlark.com | Neil Gaiman, _Neverwhere_
+- http://www.cowlark.com -+
Kodrik
> and
>> let you do most of what is required for a piece of IF.
>
> Most?
Yes, I've structured the data for the adventure as I explained and then I
program whatever relations I want to check and modify as many element as
needed depending on the action triggered.
I've asked authors to write stories and ask them to request for functions
they lacked to write their stories. So far I haven't had any request for
functions that this structure of data can't handle, and I have been able to
implement requested functions in a matter of days.
But, tomorrow someone might ask for something that the data structure
won't be able to handle.
So I should have said, "so far all", but I said most because I assume there
will be eventually be something that it can't handle.
L. Ron Hubbard
> How about modeling the way worlds are built in 3-D games. Start by defining
> textures:
>
> floor1 = "Square stones, crudely cut and set unevenly cover the floor"
> floor2 = "You see narrow oak strips, well worn but highly polished."
> ...
> wall6 = "Floor to ceiling bookcases filled with musty old volumes cover the
> %d wall."
> ....
> backdrop3 = "Distant mountains, barely visable through the mist, ..."
>
> Then apply the textures to objects:
>
> room1
> floor = floor1
> ceiling = ceiling3
> northWall = wall6
> southWindowView = backdrop3
> contains = [ stockDesk3, stockDeskBlotter1, customDeskLamp ]
> ...
>
TADS/inform, for instance by multiply invoking a fn() to output the
description, but this looks really good.
> Then use a spreadsheet type of layout for object interactions. When every
> cell is filled in then no possible interaction ("unlock chest with loaf of
> bread") has been overlooked.
Well, default non-interaction exists already of course. Are you just
suggesting a graphical tool to help develop the i-f?
> All that is necessary is for the language designer to anticipate every
> possible situation the IF author could ever imagine using.
Or allow him complete control. Now, if you'd care to mention one or
two of those situations...
L. Ron Hubbard
go sucka piss grit, you groin-loitering fruitcake ;-)
L. Ron Hubbard
> you seem to be contemplating a whole new system, not just a language
> (is that correct?). It seems you want requirements for language
> syntax/class hierachy & libraries/compiler/interpreter/other tools -
> everything from both an authors & a players point of view. If you
> clarify that, we can help a bit more.
yes, that's what I mean. The whole shooting match, integrated & seamless.
Gary Shannon
If I thought about it at all I'd probably think about it as some kind of
front end to TADS or INFORM that would use graphical or spreadsheet kind of
input to build a TADS or INFORM source file which could then be customized
further.
The idea woudl be to make the basic creation of the environment as easy and
error free as possible.
--gary
<snip>
Mr. J
> definitely true O-O. Fully extensible. Fully customisable.
actually how about something LESS like C++ and Java that works closer
to English like
if (plant hasnt water)
I'd love to see a program that almost reads like english yet lets you
use C++ like code inserted when the high level isn't enough. Sort of
like using ASM in C
-John
Mr. J
>
> It would have perfect C-style syntax --
> whitespace. newlines and other white space inside strings would not
> be ignored, they would be treated C style. Special chars, such as
> quotes, would be created using escaped sequences like \", not ~ .. \n
> would work for a newline if you wanted, not ^. ALL code blocks would
> be enclosed in { } braces, none in [ ] brackets.
>
> In fact, if someone simply fixed Inform (or Glulx Inform), I'd be
> happy as a pig in drek.
Regarding my previous "more like English" comment. I DO agree with
making the "syntax sugar" more consistant. After all... it IS code no
matter what.
-John
Plugh!
> Hi Plugh!,
>
> >hmm, maybe something slightly more C++/Java like? In any case,
> >definitely true O-O. Fully extensible. Fully customisable.
>
> C++/Java syntax? Yuck. :) C++/Java syntax aside, PAWS matches most of
> your criteria nicely. 20 OS's, from Palm Pilots to mainframes and
> everything in between...
>
> >Think about plug-ins, so that you can start with plain text, but let
> >others develop plug-ins for graphics, sounds, skins, etc.
>
> Scads of pre-written libraries for all sorts of things, and all kinds
> of multimedia available too. :)
>
Sounds very interesting. Do you have a URL?
Plugh!
I'd want to be able to loop through all objects in the game, matching
those where a given property satisfies a condition (weight > 10)
(isLit == true) or which are or, or descended from, a given class and
performing a given action
for_each("darkRoom")
{
textOut("%s is dark\n", result.Name); //where 'result' is the
matching object
}
for_each(descendedFrom("container"))
{
}
Richard Bos
> > hmm, maybe something slightly more C++/Java like? In any case,
> > definitely true O-O. Fully extensible. Fully customisable.
>
> actually how about something LESS like C++ and Java that works closer
> to English like
>
> if (plant hasnt water)
Use Inform <g>.
Richard
Richard Bos
> Screw that. I want the whole thing to adhere to Standard ML of New
> Jersey syntax.
Heretic. I want the Edinburgh syntax. My Symbolic Languages teacher came
from Edinburgh U.
Richard
Alex Warren
> how about a good for_each() loop?
>
> I'd want to be able to loop through all objects in the game, matching
> those where a given property satisfies a condition (weight > 10)
> (isLit == true) or which are or, or descended from, a given class and
> performing a given action
Hmmm....
for each object in game {
if ( #(quest.thing):weight# > 10 ) then msg <#quest.thing# is chunky.>
if property <#quest.thing#; isLit> then msg <#quest.thing# is lit.>
if type <#quest.thing#; monster> then msg <#quest.thing# is a _
terrifying thing indeed.>
}
Works in Quest 3.1 :)
--
Alex Warren
al...@axeuk.com
Quest - make adventure games easily - http://www.axeuk.com/quest/
TheCycoONE
"Adam Thornton" <ad...@fsf.net> wrote in message
news:a3v52s$iig$1...@news.fsf.net...
Well then hurry it up :-)
I'm pretty sure there is demand for a latin language modual and especially a
latin game. I'm trying to study the language myself and I must say
something more interactive and 'fun' would be helpful. (Boring stories in
borning classrooms is hardly the way to learn a language.)
L. Ron Hubbard
> from Edinburgh U.
hairy twats ?
Richard Bos
Adam Thornton
TheCycoONE <cyc...@hotmail.com> wrote:
>I'm pretty sure there is demand for a latin language modual and especially a
>latin game. I'm trying to study the language myself and I must say
>something more interactive and 'fun' would be helpful. (Boring stories in
>borning classrooms is hardly the way to learn a language.)
I was going to say, "you *are* aware what _Mentula Macanus:
Apocolocyntosis_ is going to be, right?"
And then I saw who I was replying to and realized he probably knows
exactly what it is.
Adam
M Joonas Pihlaja
On 6 Feb 2002, Sabrejack wrote:
> It would have perfect C-style syntax -- All lines would be
> deliniated by a semicolon, never a newline or other
> whitespace. newlines and other white space inside strings
> would not be ignored, they would be treated C style.
> Special chars, such as quotes, would be created using escaped
> sequences like \", not ~ .. \n would work for a newline if
> you wanted, not ^. ALL code blocks would be enclosed in { }
> braces, none in [ ] brackets.
If I had the chance, I'd go as far away from perfect C syntax as
possible -- The only separator between words is white space, a
function name can consist of any graphical characters, there are
no ugly { nested } blocks, and *definitely* no parenthesis to
group expressions. Oh, and it's got to be interactive. The
edit-compile-link thing is just *so* last week!
Oh, wait. There already is such a thing:
http://www.cs.helsinki.fi/~jpihlaja/glasforth/
Go there for downloading the sources as a tar.bz2 package, or
just for browsing the source tree and 'documentation'. If you
like to live in the dark and prefer a binary without
documentation, get this file (it's all you really need):
http://www.cs.helsinki.fi/~jpihlaja/glasforth/gf/bin/gf.ulx
Joonas
[ This is a prerelease version only. I'll clean it up for
distribution properly, and redo the documentation, I promise. ]
Kodrik
> possible -- The only separator between words is white space, a
> function name can consist of any graphical characters, there are
> no ugly { nested } blocks, and *definitely* no parenthesis to
> group expressions. Oh, and it's got to be interactive. The
> edit-compile-link thing is just *so* last week!
The syntax of a language such as C evolved from other languages and years
of experience. I don't know the reason behind all the syntax rules but as I
program, I often encounter cases where I say to myself "I'm no happy the
syntax is this way so it let's me easily fdo what I want";
You might not see why a function or a variable cannot have any special
character in it's name, but I've been happy about this perticular syntax
rules many times.
I love blocks and parenthesis in expressions (just like in maths),
actually, I don't see how an advanced modular language can do without them.
I agree with the edit-compile thing. I would be better if you can code and
run it without compiling. If it's a performance issue, when everything
works, compile it then to make it faster.
But I don't think edit-compile is *so*last week, it's just not tomorrow.
Gary Shannon
"M Joonas Pihlaja" <jpih...@cc.helsinki.fi> wrote in message
news:Pine.OSF.4.30.02020...@vesuri.Helsinki.FI...
>
> On 6 Feb 2002, Sabrejack wrote:
>
> > It would have perfect C-style syntax -- All lines would be
> > deliniated by a semicolon, never a newline or other
> > whitespace. newlines and other white space inside strings
> > would not be ignored, they would be treated C style.
> > Special chars, such as quotes, would be created using escaped
> > sequences like \", not ~ .. \n would work for a newline if
> > you wanted, not ^. ALL code blocks would be enclosed in { }
> > braces, none in [ ] brackets.
>
> If I had the chance, I'd go as far away from perfect C syntax as
> possible -- The only separator between words is white space, a
> function name can consist of any graphical characters, there are
> no ugly { nested } blocks, and *definitely* no parenthesis to
> group expressions. Oh, and it's got to be interactive. The
> edit-compile-link thing is just *so* last week!
>
> Oh, wait. There already is such a thing:
>
> http://www.cs.helsinki.fi/~jpihlaja/glasforth/
>
Just the fact that the name has "forth" in it got my attention. However,
being a Windoze junky there's nothing I can do with a tar ball except use it
as a messy paper weight. Any chance the files could be made available in a
Windoze-friendly format?
--gary
--gary
T Raymond
Any good windoze archiver should handle it, even winzip, though I
prefer PowerArchiver or Freezip.
Tom
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond af956 AT osfnDOTorg
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
M Joonas Pihlaja
[snip]
> I agree with the edit-compile thing. I would be better if you
> can code and run it without compiling. If it's a performance
> issue, when everything works, compile it then to make it
> faster. But I don't think edit-compile is *so*last week, it's
> just not tomorrow.
I should've put a ;-) at the end. I thought that (pre)releasing
a Forth for Glulx would've been enough of a smiley. Maybe it's a
culture thing. :-)
Joonas
Julian Fondren
> something more interactive and 'fun' would be helpful. (Boring stories in
> borning classrooms is hardly the way to learn a language.)
Take a look at http://www.cherryh.com/www/latin_language.htm , which is a
Latin tutorial written by a SF writer who majored in the language.
M Joonas Pihlaja
> Just the fact that the name has "forth" in it got my
> attention.
GlasForth is, very nearly, an ANSI/ISO Forth system for the Glulx
VM. It has most of the optional word sets defined in the
standard, except Locals and Float.
There is no external compiler or special interpreter -- the
compiler itself is a Glulx game file and can run on any Glulx
interpreter.
> However, being a Windoze junky there's nothing I can do with
> a tar ball except use it as a messy paper weight. Any chance
> the files could be made available in a Windoze-friendly
> format?
I changed it to .tar.gz. Is this any better? At least an old
WinZip I tried it on can handle it. If not, I'll see about
getting it pkzipped.
Adam Thornton
M Joonas Pihlaja <jpih...@cc.helsinki.fi> wrote:
>GlasForth is, very nearly, an ANSI/ISO Forth system for the Glulx
>VM. It has most of the optional word sets defined in the
>standard, except Locals and Float.
This is, as Delarion Yar might say, *so* fawking cool.
Adam
Gary Shannon
it right away!
--gary
Gary Shannon
> i-f programing languages, but - if someone were to say that he would
> implement a new language if this group were to specify it, what
> features would it require?
After following this thread for a few days, and brain-dumping a few random
thoughts, here's what occured to me over the weekend:
The question should be answered by first adopting a different perpsective.
Do we want a "programming language?" or do we want an easier way to handle
the explosion of possible interactions as new objects are added to a game?
Do we want "C++ syntax" or do we want a design methodology which, by its
very nature, eliminates most of the common bugs that occur in the early
stages of writing an IF? Do we want to write a "computer program" or do we
want to create world in which exciting things happen? Do we want an object
oriented design or do we want to be able to add a new treasure to a working
game without breaking everything else in the game?
I think the question of language "syntax" and "language" should be turned on
its head, or better yet, tossed out the window. The whole authorship
process should be redesigned from scratch in some radical new way. Quibling
over when and where to use a semi-colon is not the kind of radical surgery
needed here.
That said, the two most important characteristics of a new IF language
should be: (IMHO)
1. That the new "authorship method" (rather than "programming language")
should make the process of creating rich, bug-free IF adventures RADICALLY
easier. Otherwise, why bother?
2. That the new "authorship method" produce games that are playable with one
of the current widely accepted game interpretors such as Z-machine or HTML
TADS so that users don't have to be persuaded to dowload yet another
interpretor.
--gary
ally
news:1sd76u41j8v2n954q...@4ax.com:
> Plugh! wrote:
>
>> how about a good for_each() loop?
>>
>> I'd want to be able to loop through all objects in the game, matching
>> those where a given property satisfies a condition (weight > 10)
>> (isLit == true) or which are or, or descended from, a given class and
>> performing a given action
>
> Hmmm....
>
> for each object in game {
> if ( #(quest.thing):weight# > 10 ) then msg <#quest.thing# is
> chunky.> if property <#quest.thing#; isLit> then msg <#quest.thing#
> is lit.> if type <#quest.thing#; monster> then msg <#quest.thing# is
> a _
> terrifying thing indeed.>
> }
>
> Works in Quest 3.1 :)
And
for (o = firstobj(room) ; o != nil ; o = nextobj(o, room)) {
"\n\^<<o.sdesc>> is ";
(o.isLit) ? "lit." : "dark.";
}
works in TADS ;)
--but it still won't lett you loop through all objects that satisfy a
condition other than class membership.
Inform might be better at that.
Never mind me, I'm probably just happy to have used the tertiary operator
thing.
~ally
Sam Dennis
Somewhat: objectloop (x.weight > 10)
--
r@,,+2 'a,kd"
wo...@one.net
Hi Plugh!,
>Sounds very interesting. Do you have a URL?
Two, actually. For PAWS itself:
http://w3.one.net/~wolf/PAWS.shtml
and for Python (the underlying language for PAWS):
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
wo...@one.net
Hi Plugh!,
From PAWS/Python:
for object in Global.AllObjectsList:
if object.HasGround and not object.CurrentlyIlluminated():
say("%s is dark ~n" % object.SDesc)
for object in Global.AllObjectsList:
if object.MaxBulk > 0:
say("%s is %s container" % (object.SDesc,object.ArticleDesc))
Julian Fondren
> I think the question of language "syntax" and "language" should be turned on
> its head, or better yet, tossed out the window. The whole authorship
> process should be redesigned from scratch in some radical new way. Quibling
> over when and where to use a semi-colon is not the kind of radical surgery
> needed here.
Obvious methods to construct an IF game:
1. a system such as inform, wherein you have a programming language, an
instruction set, and a world model.
2. a system such as what many muds have, wherein you have a static world
model and a constant-prone, extremely weak programming language.
3. a system such as what *some* muds have, wherein you build the world
inside the world, and may have a more flexible world model. I'd point
at the Python-written POO (or whatever it is now) as a good example
of this, even if it doesn't have much of a world model.
4. a system wherein you interact with an AI, describing the world you
want and having it Do What You Mean.
5. a system very much like #4, except that you are dealing with a
skilled human.
6. a system wherein you describe the world however you like, and only
then face the problem of getting it translated into an actual game.
These methods are so obvious that an alternative does not yet occur to me.
Well...
7. build a machine that builds a universe, tests whether or not it
contains an original game that'd be acceptable to you: if it is,
stop. If it isn't, destroy the universe and build another. This
could perhaps be combined with a time machine, allowing you to mine
various futures for ideas.
I'd suggest that people here who really want a new IF language first sit
down and WRITE A GAME IN THE LANGUAGE. It's not hard at all: you start
writing and when you need a feature, you invent it. The idea of some of
the posters to this thread, that a language should be written to a spec
constructed by poll, is to me rediculous and amusing. If I weren't
satisfied so far (with my first unfinished game, mind you) that inform
is acceptable to me, I'd sit down all by my lonesome and write a z-machine
assembler in Forth, and then a language on top of that. I'd start by
writing a few games.
Julian Fondren
> I'd want to be able to loop through all objects in the game, matching
> those where a given property satisfies a condition (weight > 10)
> (isLit == true) or which are or, or descended from, a given class and
> performing a given action
Right. Inform can do this trivially.
Joel Finkle
> ok, this one's for fun only. I feel that we have more than enough good
> i-f programing languages, but - if someone were to say that he would
> implement a new language if this group were to specify it, what
> features would it require?
First off, I'm ashamed at those asking for C-language features, when
there's a perfectly good language out there cleaner than C, and suited
for interpreters: Perl! I'm surprised I haven't seen Perl-based
parsers here.
But what I'd want to see in an IF language would be something better
at modeling the behavior of actor vs environment. Currently Inform
drives me nuts with the number of ways I can 'touch' something: Take,
Remove, Transfer, Insert, PutOn... the Inform library currently
doesn't notice that things like this are really really similar, so I
can describe *once* why something can't be touched.
L. Ross Raszewski
<clever...@hotmail.com> wrote:
>I'd suggest that people here who really want a new IF language first sit
>down and WRITE A GAME IN THE LANGUAGE. It's not hard at all: you start
>writing and when you need a feature, you invent it. The idea of some of
>the posters to this thread, that a language should be written to a spec
>constructed by poll, is to me rediculous and amusing. If I weren't
>satisfied so far (with my first unfinished game, mind you) that inform
>is acceptable to me, I'd sit down all by my lonesome and write a z-machine
>assembler in Forth, and then a language on top of that. I'd start by
>writing a few games.
While this is a good way to start, a word of warning is in order here:
I've seen *lots* of systems developed this way, and the vast majority
of them turn out to be purpose-specific. That is, you end up with a
language that is very good at doing games in the style of the game the
author had in mind when writing the system, and very bad at doing
anythign else. AGT has this sort of feeling -- like the author wrote
it with a mind toward creating Zork in it (hence the fact that all its
hard-wired library messages imply a Zork-like world, where dead
enemies disappear in smoke, etc.) Lots of the graphical adventure
creators lean this way too -- in many of them, certain game elements
are implemented at the VM level rather than the source level; it might
have, say, an @sliding_tile_puzzle opcode -- such a language would
make the creation of sliding tile puzzles easy, but almost invariable
is ill-equipped to support any puzzle the system designer didn't think
of.
Since you have the luxury of adding a new feature as you write the
archetypical game for your system, it's easy to lose track of whether
you're adding features too specific to your own case, and omitting
features that are important in the general case.
Philipp Lenssen
news:isjt3a...@172.16.100.88...
> In article <a3rb7h$93j$1...@swifty.westend.com>,
> "Philipp Lenssen" <ph...@mrinfo.de> writes:
> [...]
> > I'm sure you're referring to non-graphical output exclusively (parsed
text
> > IF a la Inform). If not, my wish-list would include a Lucasarts
> > kind-of-games interpreter/ compiler.
> [...]
>
> *cough*
>
> http://scummvm.sourceforge.net/
> (free SCUMM 'terp)
An interpreter for existing Lucasarts binaries, without the IDE to create
them (right?)...
> http://plover.net/~hjalfi/scumm/index.html
> or /scumm.html
> or /scumm.pdf
> or /scumm.dvi
> (work-in-progress SCUMM documentation)
An incomplete, very technical documentation of the binary data format to
save the files...
> http://www.cowlark.com/cgi-bin/getpage.awk?/Unix
> (work-in-progress SCUMM compiler/decompiler)
>
A file not found for me...
Like I said, I'd like to see an easy-to-use & complete editor. (Thanks
anyway. I'm not in a hurry and can wait another year or more...)
And I would be perfectly happy with a solution that couldn't provide
*anything*, but would be fairly straight-forward. In other words, I'd rather
have a good multiple-choice conversation editor, and character animation
import, then an option for writing mini-games/ action-sequences. Again, I'd
be willing to pay for it... but if it's not commercial, I can understand
nothing like that will ever evolve. (I once started my own project --
Adventure Script at http://www.outer-court.com/basic/qbasic.htm -- but this
takes serious time and knowledge to be done right.)
So whatever happened to the SCRAMM project?
Kodrik
Email me and I'll show you something (it's free).
Philipp Lenssen
news:u6i0pej...@corp.supernews.com...
> You email is not valid phil.
> Email me and I'll show you something (it's free).
Sorry, that's my company email and we're having some trouble today.
Try ple...@hotmail.com or for bigger attachments,
len...@hitnet.rwth-aachen.de .
Stephen Granade
> Like I said, I'd like to see an easy-to-use & complete editor. (Thanks
> anyway. I'm not in a hurry and can wait another year or more...)
I'd put my money on "more." When I looked at the state of graphic
adventure game tools back in '99, in terms of ease-of-use things were
about as they are now.
Stephen
--
Stephen Granade
sgra...@phy.duke.edu
Duke University, Physics Dept
David Thornley
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>On 11 Feb 2002 15:35:34 -0800, Julian Fondren
><clever...@hotmail.com> wrote:
>
>>I'd suggest that people here who really want a new IF language first sit
>>down and WRITE A GAME IN THE LANGUAGE. It's not hard at all: you start
>>writing and when you need a feature, you invent it. The idea of some of
>
>I've seen *lots* of systems developed this way, and the vast majority
>of them turn out to be purpose-specific.
One way to avoid this problem is to have the language itself be
extensible. A set of Common Lisp packages would be an example,
since it's very easy to exend the language. Somebody's actually
working on a Forth for glulx, and Forth is a very extensible
language also. Of course, these languages can be a bit hard to
pick up, being notably different from Visual Basic. (Not to
mention that some people like heavy syntax, which seems to go
very badly with the ability to extend the language.)
So, right now, my advice would be to learn Forth, help the guy
who's doing the (glasForth?), and when available design a game
and go Forth and design the language! (Note: bad puns on the
word Forth seem even more imperative in what of the Forth community
I've seen than Monty Python references among Python users. Be
warned.)
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David Thornley
Joel Finkle <joelf...@hotmail.com> wrote:
>xe...@email.com (L. Ron Hubbard) wrote in message news:<e530a463.02020...@posting.google.com>...
>> ok, this one's for fun only. I feel that we have more than enough good
>> i-f programing languages, but - if someone were to say that he would
>> implement a new language if this group were to specify it, what
>> features would it require?
>
>First off, I'm ashamed at those asking for C-language features, when
>there's a perfectly good language out there cleaner than C, and suited
>for interpreters: Perl! I'm surprised I haven't seen Perl-based
>parsers here.
>
familiar with. I do like Perl, but I don't consider it any sort of
clean language, and it doesn't have the data structures to make
something large easy to manage.
>But what I'd want to see in an IF language would be something better
>at modeling the behavior of actor vs environment. Currently Inform
>drives me nuts with the number of ways I can 'touch' something: Take,
>Remove, Transfer, Insert, PutOn... the Inform library currently
>doesn't notice that things like this are really really similar, so I
>can describe *once* why something can't be touched.
Or perhaps this is a meaning of "Perl" I was previously unaware of.
One of the mottos of the language is "There's more than one way to
do it!", often abbreviated to something like TMTOWTDI - and when
the Perl people toss around that acronym, they're obviously
serious about the phrase.
If you like clean syntax and clear ways to do things, I'd suggest
Python or Common Lisp, and there already is a Python system available.
Peter Seebach
David Thornley <thor...@visi.com> wrote:
>This is apparently a definition of "cleaner" I was not previously
>familiar with. I do like Perl, but I don't consider it any sort of
>clean language, and it doesn't have the data structures to make
>something large easy to manage.
It has pretty good structure types, although they are a bit surprising
compared to the way C's work.
>If you like clean syntax and clear ways to do things, I'd suggest
>Python or Common Lisp, and there already is a Python system available.
I keep thinking I'm going to learn Python, and then retching at the concept
of a language that enforces its own indentation rules. :)
To be fair, Inform is a *very* nice language, though. I'm quite comfortable
with C and perl, and I'd have a hard time making either of them as suitable
for this as Inform is.
-s
--
Copyright 2001, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
John W. Kennedy
> This is apparently a definition of "cleaner" I was not previously
> familiar with. I do like Perl, but I don't consider it any sort of
> clean language, and it doesn't have the data structures to make
> something large easy to manage.
Statement bracketing is an intrinsic part of all compound statements in
PERL, as in all modern languages (but not C or Pascal). I grant you
there's not much else.
--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html
L. Ron Hubbard
> should be: (IMHO)
>
> 1. That the new "authorship method" (rather than "programming language")
> should make the process of creating rich, bug-free IF adventures RADICALLY
> easier. Otherwise, why bother?
Sounds absolutely right. Any ideas? what are the most common errors of
which you speak? what are the most tedious, nit-picking chores which
can be automated?
> 2. That the new "authorship method" produce games that are playable with one
> of the current widely accepted game interpretors such as Z-machine or HTML
> TADS so that users don't have to be persuaded to dowload yet another
> interpretor.
Sounds more difficult. If the new language/environment/whatever adds
any new twists which aren't supported in the current interpreters, or
even which don't follow the syntax.
Julian Fondren
> Statement bracketing is an intrinsic part of all compound statements in
> PERL, as in all modern languages (but not C or Pascal). I grant you
> there's not much else.
Or Forth or Scheme or Python or Ruby or numerous other more specific
languages -- unless you've a view of 'statement bracketing' so general
that a Forth word definition would fit under it.
John W. Kennedy
I don't understand that last sentence.
Gary Shannon
> "Gary Shannon" <fiz...@starband.net> wrote in message
news:<zeR98.1084$yP7.64...@twister2.starband.net>...
> > That said, the two most important characteristics of a new IF language
> > should be: (IMHO)
> >
> > 1. That the new "authorship method" (rather than "programming language")
> > should make the process of creating rich, bug-free IF adventures
RADICALLY
> > easier. Otherwise, why bother?
>
> Sounds absolutely right. Any ideas? what are the most common errors of
> which you speak? what are the most tedious, nit-picking chores which
> can be automated?
>
I'm mostly thinking about the biggest complaint I got when I gave my first
game to a couple of beta testers. Missing objects and missing interactions.
Somehow those need to be made more obvious (or even automated) in the way
interactions are coded. I got complaints like the description of the room
mentioned a rug but when the player types "x rug" it doesn't know the word
"rug". Or when I created a pool of water but forgot descriptions of what
happens for couple of possible interactions like "throw bread in water",
which I never thought anyone would do.
I'd like some kind of format that would make such oversights obvious at a
glance.
Or maybe what I want is a "dignostic scan" program to scan the source code
and compile a table of all possible interactions of verbs with object and
mark the ones that seem to be missing.
--gary
wo...@one.net
Hi Julian,
>I'd suggest that people here who really want a new IF language first sit
>down and WRITE A GAME IN THE LANGUAGE. It's not hard at all: you start
>writing and when you need a feature, you invent it. The idea of some of
>the posters to this thread, that a language should be written to a spec
>constructed by poll, is to me rediculous and amusing.
Now hold on a minute... :)
Having done exactly what you suggest (PAWS) I can say from personal
experience it *IS* hard. Very hard. Most especially when you intend
the language to be used by lots of other people.
Second, nobody is an endless font of ideas. I suspect everyone who's
spent the months of effort it takes to write a language (or put
together libraries that piggyback an existing language) has at one
time or another asked the group for feedback, wishlist features, or
their pet peeve about existing lanaguges.
That's what raif is *for*. :)
I would also note that building a language in such an unstructured and
ad hoc way is a prime recipe for a Mulligan stew that makes for
terrible leftovers, if you get my drift.
Any language/library/parser/whatever has to be carefully considered
from the beginning, because most important features have to be built
in from the start, they can't be welded on after the fact without
running the risk of gomming up the design.
L. Ron Hubbard
> I'm mostly thinking about the biggest complaint I got when I gave my first
> game to a couple of beta testers. Missing objects and missing interactions.
> Somehow those need to be made more obvious (or even automated) in the way
> interactions are coded. I got complaints like the description of the room
> mentioned a rug but when the player types "x rug" it doesn't know the word
> "rug". Or when I created a pool of water but forgot descriptions of what
> happens for couple of possible interactions like "throw bread in water",
> which I never thought anyone would do.
All well & good, but who wants a thousand loaves of soggy bread?
>
> I'd like some kind of format that would make such oversights obvious at a
> glance.
hmmm, the best way towards that is to be in the habit of never using
plain text words for descriptions. "There is a gorgeous " +
rug.adjective() + rug.noun() + "spread in front of the " +
fireplace.noun() ... might be easier to automate. Otherwise, we're
talking about a large dictionary which knows the 20,00 most common
objects in the ?english? language (or maybe we could get away with 1,k
or so). Even there, it'd be tricky to automatically check that that
you had handled all possible fire interactions, since you mention a
fireplace not a fire. The program would have to know that fireplaces
contain fire. And what if you refer to it as a grate?
I still think that it's a desirable idea; I'm just pointing out
difficulties. It could be doable if authors would realise that it may
never catch 100%. However, there are some commonly understood
side-effects/pitfalls when dealing with fire/flammable obejcts, or
even scenery - "burn rug/ignite curtain (the flames spread throught
the library, consuming all in their path, including you)" and
liquids/containers "pour oil (for rusty door) onto fire"/"mix oil &
water" / "pour water onto fire" may extinhuish it, pitching the room
into darkness, etc, etc. If we could come up with some list of these,
a tool might be specified
> Or maybe what I want is a "dignostic scan" program to scan the source code
> and compile a table of all possible interactions of verbs with object and
> mark the ones that seem to be missing.
Now, that might be easier. Espcially if it allows you mark soem as
"ignore". You could whittle away at them until no unresolved cases
remain.
Let's see if there's any more discussion about this...
L. Ron Hubbard
currently a thread where someone wants to know how to output a
preamble to his i-f in TADS. So, I expected people to tell me that
there would need to be some form of initialization routine. Or mention
the verXXX() functions which verify whether a verb is doable, before
executing XXX() to perform it.
Maybe you had problems with this sort of thing, or disambiguation, in
existing i-f languages & would like to describe these problems so that
we can figure out how to simplify them?
Maybe you'd like to actually be able to specify the user's input
syntax (with meaningful defaults):
VERB OBJECT [ADVERB]
[ADVERB] [ADJECTIVE} VERB OBJECT
etc, etc
then you could derive your objects from classes like "directObject"
"indirectObject", etc, although this seems to be implying a class for
every vocabulary word, including adjectives, participles, adverbs,
etc. Hmmm, maybe this one's a little too esoteric.
M Joonas Pihlaja
> Julian Fondren wrote:
> > Or Forth or Scheme or Python or Ruby or numerous other more specific
> > languages -- unless you've a view of 'statement bracketing' so general
> > that a Forth word definition would fit under it.
>
> I don't understand that last sentence.
Normal Forth definitions are usually bracketed by : and ; . They
look like
: name [code] ;
You can pretty much define the syntax yourself, and it's mostly
easy to do too. Be wary of too much custom syntax though -- just
because it's easy, doesn't mean it's a good idea (he says,
regurgitating triteness one more time.)
Joonas
David Thornley
L. Ron Hubbard <xe...@email.com> wrote:
>"Gary Shannon" <fiz...@starband.net> wrote in message news:<zeR98.1084$yP7.64...@twister2.starband.net>...
>
>> of the current widely accepted game interpretors such as Z-machine or HTML
>> TADS so that users don't have to be persuaded to dowload yet another
>> interpretor.
>Sounds more difficult. If the new language/environment/whatever adds
>any new twists which aren't supported in the current interpreters, or
>even which don't follow the syntax.
There is no syntax inherent in the Z-machine (there is in TADS 2),
and so you can compile anything to it. The same is true of glulx
or TADS 3.
This means that you'd only have problems when introducing a new
screen model, and that's going to be a big jump.
Plugh!
instance, I'd like to be able to ask what class an oject is of.
wo...@one.net
Hi Plugh!,
>how about putting some debugiing commands into the game engine? For
>instance, I'd like to be able to ask what class an oject is of.
PAWS has that too... :)
Plugh!
> Hi Plugh!,
>
> >how about putting some debugiing commands into the game engine? For
> >instance, I'd like to be able to ask what class an oject is of.
>
> PAWS has that too... :)
then I *must* check it out.