[Dis]Advantages of IF languages
Tzvetan Mikov
occasions I've seen the claim that IF languages (Inform, TADS, etc.) are
much better suited for writing IF than conventional mainstream languages
(C++, Java, etc.). I've gained the impression that this is a commonly
accepted and understood fact.
I don't understand why; below I have described a few reasons why I think it
is in fact the other way around.
Please, do not accept the following as bashing the IF languages. I am
sharing some thoughts/questions and am waiting for opinions and corrections
from people who undoubtedly know much more about IF than I do. Hopefully
some interesting discussion might arise.
Disadvantages of IF languages:
=================================
- IF languages are less powerfull than mainstream languages, especially when
used for implementing algorithms. For example I remember (I might be wrong)
that in some versions of TADS the only data structure is the linked list.
- Inform has an awkward syntax from the view point of programmers and there
is no proof either that it is easier to understand by non-programmers.
(Advanced IF requires quite a lot of real programming, as far as I can
tell). Anyway, it creates an artificial gap between IF and regular
programming.
In reality, this has stopped me more than once, not having the time to learn
an entire new language, which seems less powerfull and unfortunately not
usefull outside of a hobby.
False advantages of IF languages
================================
- Convenient syntactic sugar not present in mainstream languages.
While I am not closely familiar with any of the IF languages (I've examined
a few sources, read a few tutorials, and read discussions here), I remember
that there are convenient shortcuts, for example, "print text and return
from subroutine". This particular one, IMHO, stimulates bad programming
style but undoubtedly there are others, which do save typing without
sacrificing style. I am however not convinced that they can't be emulated in
a mainstream language (e.g. using macroses, C++ templates, etc.)
- Parser and library.
I don't thing there is a reason why Inform's parser couldn't be translated
to C++, for example. This is an advantage of the status-quo, but not a
substantial one.
- Ability to execute in a minimal environment.
Again, there is no reason why the same functionality implemented in another
language, should take more space and resources.
Of course there is the issue of the mainstream language's standard library
and execution environment - in the case of Java or C# these can be
ridiculously large. This problem can be solved as described in the next
point.
- Portability across paltforms.
This is an important one. The ability to distribute one game file and play
it on any machine
A simple (and more sane in comparison to Zcode - may be GLUX is already
that) VM can be developed. Existing compilers of standard languages can
easily be retargeted for that VM. In addition, only parts of the language's
libraries relevant to IF can be provided with the VM. Come to think of it,
JVM without the gigantic class libraries could serve that purpose rather
nicely.
This solution will in no way be more limited that the existing IF execution
environments, but would benefit from existing programming experience,
sharing of common code, etc. It would even be possible to develop IF using
standard (native) compilers (and more importantly debuggers) and then only
for distribution compile and test with a compiler targeting the VM.
There are more things but I think this is good for a start.
Please, understand that the above are not suggestions. I am merely trying to
illustrate why I think that there are no *theoretical* advantages to IF
languages. The most important *practical* advantage (lots of existing games,
examples and coding experience, loyal community) is real and is here and I
would not think to (or want to) try to change it.
So, I will appreciate comments on the points described above. I am also very
curious about concrete programming examples of things that you think can't
be conveniently (or at all) done using mainstream languages (with aid of
libraries of course).
regards,
-tzvetan
David A. Cornelson
news:PhEf8.94381$B61.29...@news1.rsm1.occa.home.com...
> During the time in which I've been lurking in this newsgroup, on numerous
> occasions I've seen the claim that IF languages (Inform, TADS, etc.) are
> much better suited for writing IF than conventional mainstream languages
> (C++, Java, etc.). I've gained the impression that this is a commonly
> accepted and understood fact.
>
> I don't understand why; below I have described a few reasons why I think
it
> is in fact the other way around.
>
It's not that they're better. It's that they currently exist in a form that
allows someone to begin coding a world without first constructing the
foundation of that world as well as the parser to interact with that world.
If you want to port the inform parser and library to a c++ or java format,
go for it. Might be something interesting to see. The resulting file should
be something cross-platform, but that's up to you.
I don't think anyone is contending that IF languages are better for IF
because they're better programming languages. What we've always said is,
"Here is a standard by which we've all sort of agreed upon. Use it, instead
of creating your own. But if you want to create your own, go for it."
Many people here are more interested in the resulting games than the
compiler talk. They're first response to this kind of post is, "Bah, we
already have what we need, why do we need a c++ or java version of something
we already have?"
Languages like c++ have a much greater capacity than Inform and TADS, but
they also have a broader scope. IF languages have been tailored to do one
thing: build a model world with various types of objects in it and allow a
user to interact with that world in a mostly logical manner. c++ is meant to
program 'anything'. There are probably many things you can do in c++ that
simply aren't necessary in IF.
Anyway, I completely disagree with the notion that Inform is a badly
constructed language. It has some goofy syntax sure, but as far as power and
ease of use it concerned, nothing comes close. I find Inform quite
accomodating.
Jarb
Jim Aikin
There are certainly times when I get frustrated by the syntax weirdness
or arbitrary limitations of IF languages. But...
> Disadvantages of IF languages:
> =================================
>
> - IF languages are less powerful than mainstream languages, especially when
> used for implementing algorithms. For example I remember (I might be wrong)
> that in some versions of TADS the only data structure is the linked list.
TADS has straight-up lists. Inform uses an effective but annoying linked
list architecture for its object handling. I could give better examples:
Neither TADS nor Inform supports floating-point variables. TADS supports
pointers only in very restricted ways, and Inform doesn't support them
at all. Neither language supports strict variable typing; a variable can
be basically anything. (You can even stuff different data types into the
same TADS list!)
> (Advanced IF requires quite a lot of real programming, as far as I can
> tell).
All too true.
> Anyway, it creates an artificial gap between IF and regular
> programming.
A good point (although "regular programming" is one of those loaded
phrases, like "normal sex drive").
> While I am not closely familiar with any of the IF languages (I've examined
> a few sources, read a few tutorials, and read discussions here), I remember
> that there are convenient shortcuts, for example, "print text and return
> from subroutine". This particular one, IMHO, stimulates bad programming
> style but undoubtedly there are others, which do save typing without
> sacrificing style.
Until you've tried developing a large game, you're probably not well
equipped to evaluate this factor.
> I am however not convinced that they can't be emulated in
> a mainstream language (e.g. using macros, C++ templates, etc.)
Emulated, yes. Emulated with a minimum of extra typing? I'm not
convinced. To give the most basic example I can think of, consider that
I want to print out a string to the screen. Which of the following is
easier to type:
"The troll easily dodges your clumsy blow.";
or
say("The troll easily dodges your clumsy blow.");
A trivial example? Try typing it about five thousand times, and then get
back to me.
> I don't thing there is a reason why Inform's parser couldn't be translated
> to C++, for example.
I used to have fantasies about this. There's no technical reason, of
course. There are legal reasons: You'd have to convince Graham Nelson to
agree to it.
If it were simply a matter of porting the parser (or creating your own),
that would be one thing. But in reality, you'd also have to create a
game-playing engine with, you know, scrolling windows and menus and an
undo buffer and stuff. You'd have to do it for free, 'cuz there ain't no
money in IF. And after you did it, your game engine wouldn't be highly
portable. It would run under, oh, Windows or Linux or your favorite OS,
unless you spend a lot _more_ of your free time porting and debugging
it. And if you wanted your user base to be able to compile once and run
on any of your game engines, you'd have to write your own compiler too,
and your own portable object-code template. In other words, you'd end up
recreating TADS.
Beyond this, there's the question of what the IF authoring community
actually wants and needs.
(a) We like feeling that we're the carriers of a special torch, and our
nice insular little group here makes that easier. The minute you start
writing IF in C++, you're going to have to post "help!" messages to a
much larger and colder newsgroup, most of whom would probably roll on
the floor laughing if they knew what you were doing.
(b) The advanced features of C++ would be total overkill in most IF.
You'd be building a cannon to shoot a mouse.
On the whole, I'm inclined to be stupidly grateful that I can choose
from among several decent IF programming languages that have bug-free
compilers, decent documentation, and zero cost. Complaining that they
don't include arrays or data hiding is just too much trouble.
That's my 2 cents, anyhow.
--Jim Aikin
(and never has my occasional postscript block seemed more apropos:)
***********************************
"Those instances of it which lack
the quality referred to as 'swing'
are meaningless." --Duke Ellington
***********************************
Kodrik
> it is in fact the other way around.
I agree it's better to code your IF game from scratch. But how long will it
take you?
Not only do you have to recode the wheel for many things, fall into the
traps that IF engine fell and learn from.
You are trying to write an adventure and you if you get a 10% increase in
quality for a 1000% increase in work, it's not worth it for most people.
Why even write in C, code it in assembly language and you'll gain another
10% increase in performance, but at what cost.
An author wants to write the story, whatever offers the tools to let him
write it the most efficiently, that is the one he will use.
L. Ross Raszewski
>=================================
>
>- IF languages are less powerfull than mainstream languages, especially when
>used for implementing algorithms. For example I remember (I might be wrong)
>that in some versions of TADS the only data structure is the linked list.
This is not true.
Inform has objects and arrays, in terms of large data structures. the
objects form a parent-sibling-child tree automatically. Inform has the
equivalent of C structs and arrays. Admittedly, it doesn't have a
union, but this is not a major problem in a weakly-typed language.
Inform has, therefore, at least the same data structure capabilities
as C. Inform has a class system and multiple inheritance. TADS has
similar capabilities. I find it unlikely that any algorithm which can
be conveniently coded in C or C++ could not be coded similarly in
inform or tads (obviously, this excludes I/O, which is why I, like
you, say "algorithm". See also: quicksort implementation for Inform,
by me.)
Obviously, the major IF languages are turing complete, and are equal in
expressive power. Though this is not the be-all-and-end-all (I myself
have recently pointed out that being turing complete is not really a
useful measure of what it's feasable to do in a language), I am
hard-pressed to find any particular algorithm which cannot be
expressed in inform or similar IF languages (The first person to
mention dynamic allocation will be shot. In the first place, I think it's
provable that any program using dynamic allocation of memory can be
expressed by an equivalent program using static allocation. Further,
inform does allow dynamic allocation of memory, up to the limit of
memory available in the simulated ram of the Z-machine. ANd of
course, Glulx).
>
>- Inform has an awkward syntax from the view point of programmers and there
>is no proof either that it is easier to understand by non-programmers.
>(Advanced IF requires quite a lot of real programming, as far as I can
>tell). Anyway, it creates an artificial gap between IF and regular
>programming.
>In reality, this has stopped me more than once, not having the time to learn
>an entire new language, which seems less powerfull and unfortunately not
>usefull outside of a hobby.
>
>
I suspect you have not actually used inform. I press you to point out
any single "awkward" bit of syntax relevant to "real programming"
(This does exclude the grammar system, though I don't find it to be
"awkward"). I can program in quite a few languages, and inform has,
in my experience, been no more awkward than any other C-like language;
indeed, inform's syntax is largely identical to C, with a few minor
exceptions. This may suggest that a programmer movign from C to
inform might have some trouble, but this is a silly thign to call a
"disadvantage", unless you want to mandate that any language without C
syntax is a "bad language". Inform is certainly easier to learn from
a C background than, say, ML or lisp.
>False advantages of IF languages
>================================
>
>- Convenient syntactic sugar not present in mainstream languages.
>While I am not closely familiar with any of the IF languages (I've examined
>a few sources, read a few tutorials, and read discussions here), I remember
>that there are convenient shortcuts, for example, "print text and return
>from subroutine". This particular one, IMHO, stimulates bad programming
>style but undoubtedly there are others, which do save typing without
>sacrificing style. I am however not convinced that they can't be emulated in
>a mainstream language (e.g. using macroses, C++ templates, etc.)
>
Search google for discussions on the declarative nature of the IF
model world. It is *massively* inconvenience in a language like C or
C++ to declare the sort of relationships which are trivially captured
by the inform code:
Object wroom "west room" with e_to eroom;
Object eroom "east room" with w_to wroom;
>- Parser and library.
>I don't thing there is a reason why Inform's parser couldn't be translated
>to C++, for example. This is an advantage of the status-quo, but not a
>substantial one.
>
Yes... ish. It would be simililarly more complex to add, say, a new
line of grammar to a C++ parser.
IF programming differs from mainstream programming (or, rather, the
programming required by C-like languages) in that it consists of a
much larger amount of declarative information. A C++ IF engine would
need an intial step of initializing the object tree, loading new
grammar, and so forth. THis step could not be entirely automated
within the C++ language (granted, an IF-preprocessor could do it, just
as preprocessors exist to turn the declarative structures used by
certain C-integrated systems (such as embedded SQL, or the Qt library)
into loading code, but now you've just created an IF-specific language
which hosts itself in C)
>- Ability to execute in a minimal environment.
>Again, there is no reason why the same functionality implemented in another
>language, should take more space and resources.
>Of course there is the issue of the mainstream language's standard library
>and execution environment - in the case of Java or C# these can be
>ridiculously large. This problem can be solved as described in the next
>point.
>
Idon't think this is percieved as a major advantage of IF languages;
certainly, there are those who appreciate the fact that IF written in
inform will run on their pocket devices (or, indeed, toasters), but I
have never seen a thread proposing that TADS or Glulx are somehow
inherently inferior to Z-code inform because they have larger runtime
environments.
>- Portability across paltforms.
>This is an important one. The ability to distribute one game file and play
>it on any machine
>A simple (and more sane in comparison to Zcode - may be GLUX is already
>that) VM can be developed. Existing compilers of standard languages can
>easily be retargeted for that VM. In addition, only parts of the language's
>libraries relevant to IF can be provided with the VM. Come to think of it,
>JVM without the gigantic class libraries could serve that purpose rather
>nicely.
>This solution will in no way be more limited that the existing IF execution
>environments, but would benefit from existing programming experience,
>sharing of common code, etc. It would even be possible to develop IF using
>standard (native) compilers (and more importantly debuggers) and then only
>for distribution compile and test with a compiler targeting the VM.
>
Indeed. And see also: there exists a C compiler which targets the
Z-machine. (There is not, to my knowledge, and interestingly enough, a
C compiler clever enough to target the JVM.) There existed at one
time a compiler for a Lisp-derived language to the Z-machine.
However, I think it is foolhardy to suggest that existing (C) code for all
but the most trivial things could be ported to a IF virtual machine
without excpetional effort. It requies exceptional effort to port
*ANSI C* from a Mac to a PC if it does any but the most trivial sorts
of things.
Further, there exists no base of code in C++ or any other "mainstream"
language which is of clear and specific use to IF, so there would be
no advantage of suddenly beign able to link in all the useful C++
modules already oth there for IF. Certainly, if a C++-to-IF-VM
compiler were created, one could then write code for it, and share it
around. But this is not an advantage over the existing systems; there
already exist large numbers of libraries *in IF languages* (a
nontrivial number written by me) which can do both IF-related and
general programming functions.
I do not see that you have presented any evidence that there is
anything to be gained by targeting a "general purpose" language to
produce IF, especially in the context of an IF-oriented virtual
machine (And at least one of the major IF languages is *more* portable
and more widely ported than java, and the JVM is still considered
unacceptably slow in many circles (espeically the circles who do the
sort of fancy algortihms work which you've erroneously claimed IF
languages are incapable of)). Using a C-like general purpose language
to produce IF necessarily imposes a higher overhead on the programmer
than using a domain-sepcific language, and the benefits of using a
general purpose language are relatively minimal, so long as one
imposes the portability constraint. Even if one removes the
portability constraint, I suspect that the advantages would not
outweigh the overhead. (I will note that there may be certain "general
purpose" languages which would be better suited to IF. Certainly,
languages like PL/SQL have better facilities for handling the sort of
declarative data that IF programming uses. However, since your
argument hinges on the idea that the "widespreadedness" of a
"mainstream" language is its major advantage over an IF language, I
doubt such a model would make sense were I to start talking about the
benefits of writing IF in ML.)
I suspect that you have not actually given a substantial look to the
IF languages. You mention almost as much above, and I think that your
grasp of the languages is not so great as you think. On a regular
basis, I do a fair amount of programming in C, C++, PL/SQL, ML, Java,
Perl, and Inform. Inform is the only one I consider well suited to
IF. Inform is the only one I would consider well-suited to IF even if
IF-related libraries existed for the others. In fact, of the
thirty-several programming languages I can muddle along in, I can't
think of a one better suited to IF than inform (IANAL, and I don't
know TADS or Hugo.)
Magnus Olsson
Tzvetan Mikov <ce...@jupiter.com> wrote:
>- IF languages are less powerfull than mainstream languages, especially when
>used for implementing algorithms. For example I remember (I might be wrong)
>that in some versions of TADS the only data structure is the linked list.
The crucial question is really: are they more or less powerful for the
kind of algorithms that you usually implement in an adventure game?
To take an even more striking example than linked list in TADS:
Inform's support for arrays and strings is quite primitive compared to
C (and that's even taking into account that C's string handling
functions are, to say the least, on the primitive side). This is a real
disadvantage if you want to implement an algorithm that's heavy on
array processing; fortunately, such algorithms are very rare in IF.
So it depends on what you want to do with the language. It wouldn't
hurt to have an IF language with better support for data structures -
I believe TADS3 may have some promise in this direction.
>- Inform has an awkward syntax from the view point of programmers and there
>is no proof either that it is easier to understand by non-programmers.
This seems to be a matter of taste. I find it more awkward than C++ in
some respects, and less in others.
>(Advanced IF requires quite a lot of real programming, as far as I can
>tell). Anyway, it creates an artificial gap between IF and regular
>programming.
Not really. The difference isn't that great.
>False advantages of IF languages
>================================
>
>- Convenient syntactic sugar not present in mainstream languages.
>While I am not closely familiar with any of the IF languages (I've examined
>a few sources, read a few tutorials, and read discussions here), I remember
>that there are convenient shortcuts, for example, "print text and return
>from subroutine". This particular one, IMHO, stimulates bad programming
>style
It does? Examples, please.
>I am however not convinced that they can't be emulated in
>a mainstream language (e.g. using macroses, C++ templates, etc.)
In my experience, C macros have a really big potential for messing
things up.
And I really fail to see how C++ templates could help in cases like
this.
Personally, I don't see that Inform's
"Hello world.";
is that much better or more convenient than C++
cout << "Hello world" << endl; return true;
but it's definitely more convenient than having to write thousands of
printf statements in C.
>- Parser and library.
>I don't thing there is a reason why Inform's parser couldn't be translated
>to C++, for example.
No reason whatsoever.
>This is an advantage of the status-quo, but not a
>substantial one.
I think you'll find that it's a very substantial one - what would
you rather do, use an existing library or first port it to C++ before
you can even start thinking about writing a game?
Are you volunteering to port the entire Inform library to C++? I'm
sure people will be grateful if you do (this is not ironic; I really
mean this). But if you're not prepared to do it, I don't think you
should call the advantage of Inform "not a substantial one".
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Fredrik Ramsberg
> occasions I've seen the claim that IF languages (Inform, TADS, etc.) are
> much better suited for writing IF than conventional mainstream languages
> (C++, Java, etc.). I've gained the impression that this is a commonly
> accepted and understood fact.
>
> I don't understand why; below I have described a few reasons why I think it
> is in fact the other way around.
I think your arguments have been well answered by others, so I'll not go
into all that much details. I do have something to say though:
Everyone can choose their own language for coding IF games. However, people
who choose C or C++ just don't seem to produce very good games. How come?
I know many of the best IF authors are very good programmers, often with
skills in many different programming languages. So why do they keep
choosing Inform or TADS for their IF projects? You tell me.
When it comes to the Java Virtual Machine, you can actually write in a
gazillion different languages, including C, and have the final program run
in the JVM. Here's a list: http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
Have there been any good IF games written in any of the 160 systems listed
there? Not that I know of.
I'm a professional programmer myself. Over the past 17 years, I've written IF
games in all sorts of languages, but have never seen a language that makes
it even remotely as easy as Inform does. Inform is designed to be good for
IF programming, and quite a lot of people seem to think it succeeds
in this. Sure, I can write a program to process log files in C, but I can
save 99% of the code and time by writing it in Awk instead, so why bother?
Inform is for IF games what Awk is for text file processing.
Best regards,
/Fredrik
PS: Anyone for an IF mini-comp where the games have to be written in InterCal?
OKB -- not okblacke
>During the time in which I've been lurking in this newsgroup, on numerous
>occasions I've seen the claim that IF languages (Inform, TADS, etc.) are
>much better suited for writing IF than conventional mainstream languages
>(C++, Java, etc.). I've gained the impression that this is a commonly
>accepted and understood fact.
>
>I don't understand why; below I have described a few reasons why I think it
>is in fact the other way around.
Let me just say that I am hugely grateful to you for bringing this topic
up in such a civil manner. It's an interesting topic, and I've been irritated
in the past when people came in with a "you guys are dumb for using IF
langauges" tone -- your post is a breath of fresh air.
>- Inform has an awkward syntax from the view point of programmers and there
>is no proof either that it is easier to understand by non-programmers.
I think the proof is the pudding, the pudding in this case being the large
number of authors who have chosen Inform over TADS (which has a more
conventional syntax). Now, certainly there are things about Inform's syntax I
don't like, but on the whole it is nicely sprinkled with shortcuts which,
although not necessarily making the procedural flow of the code more apparent,
DO make it easier to write code relevant to IF.
>- Convenient syntactic sugar not present in mainstream languages.
>While I am not closely familiar with any of the IF languages (I've examined
>a few sources, read a few tutorials, and read discussions here), I remember
>that there are convenient shortcuts, for example, "print text and return
>from subroutine". This particular one, IMHO, stimulates bad programming
>style but undoubtedly there are others, which do save typing without
>sacrificing style. I am however not convinced that they can't be emulated in
>a mainstream language (e.g. using macroses, C++ templates, etc.)
I think this may be true; certainly we see a lot of posts from new users
of Inform who have stumbled on one of these "shortcuts" from the wrong
direction (your example of the automatic print-and-return being one of the most
common). Also, I have recently begun to play around with TADS 3, which uses a
C-style preprocessor, and I think this is indeed a far more powerful approach.
There are some situations, though, where the syntactic sugar you want can't be
created with macros (again, the automatic print-and-return is an example), and,
as has been said, some of these situations are so common that it would be a
substantial burden to code without them.
>- Parser and library.
>I don't thing there is a reason why Inform's parser couldn't be translated
>to C++, for example. This is an advantage of the status-quo, but not a
>substantial one.
On the contrary, I think this is THE primary reason for choosing an
IF-specific language over a general-purpose language. There are very few
people willing to undertake the massive effort of porting a parser and world
model (the world model is just as important) to another system. If someone
were to create some kind of C++ setup with a parser and world model comparable
to those of Inform and TADS (as well as some syntactic sugar), I think we'd see
a fair number of people use it. Not so much existing IF authors, but newcomers
to the scene who already know C++.
>- Ability to execute in a minimal environment.
>Again, there is no reason why the same functionality implemented in another
>language, should take more space and resources.
I am definitely in agreement that this is not a major advantage of IF
systems. In fact, I think that the focus on small size and resource needs
(particularly in the Z-machine) imposes unduly bothersome restrictions on the
size and complexity of games that can be created. We are seeing a shift away
from this, though: Glulx is a 32-bit VM, and T3 is also full of features.
>- Portability across paltforms.
>This is an important one. The ability to distribute one game file and play
>it on any machine
This, as you say, goes hand in hand with the previous point, and I have
similar feelings about it. Portability is a nice thing, but I would much
rather have the game I want on one platform than have some stunted version on
many platforms -- or, more accurately, I would much rather be able to write the
game I want and not have to worry about it going haywire on various platforms.
>I am merely trying to
>illustrate why I think that there are no *theoretical* advantages to IF
>languages. The most important *practical* advantage (lots of existing games,
>examples and coding experience, loyal community) is real and is here and I
>would not think to (or want to) try to change it.
I think you're largely correct, with the proviso that existing libraries
and parsers also fall into the "practical" cateogory. It would be much easier
to write IF in C++ WITH a good library than to write IF in Inform WITHOUT the
library. As you say, the reality is that Inform has the relevant library and
C++ does not.
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Lewis Raszewski
>
> I think the proof is the pudding, the pudding in this case being the large
> number of authors who have chosen Inform over TADS (which has a more
> conventional syntax). Now, certainly there are things about Inform's syntax I
> don't like, but on the whole it is nicely sprinkled with shortcuts which,
> although not necessarily making the procedural flow of the code more apparent,
> DO make it easier to write code relevant to IF.
>
I don't see how its syntax is "more conventional", though I've seen this
claim in more than one place; what sort of specific structures are "more
conventional" in TADS?
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
"And it's a bittersweet symphony, this life" -- The Verve, Bittersweet
Symphony
Dan Schmidt
| OKB -- not okblacke wrote:
| >
| > I think the proof is the pudding, the pudding in this case
| > being the large number of authors who have chosen Inform over TADS
| > (which has a more conventional syntax). Now, certainly there are
| > things about Inform's syntax I don't like, but on the whole it is
| > nicely sprinkled with shortcuts which, although not necessarily
| > making the procedural flow of the code more apparent, DO make it
| > easier to write code relevant to IF.
|
| I'm actually curious about this; I've looked at a little TADS code,
| and I don't see how its syntax is "more conventional", though I've
| seen this claim in more than one place; what sort of specific
| structures are "more conventional" in TADS?
Here's a list of things I find syntactically weird about Inform that
have more conventional syntax in TADS:
Also see
http://groups.google.com/groups?selm=5a748r%24iir%40life.ai.mit.edu&output=gplain
though it's five years old and refers to an earlier version of Inform.
Dan
Peter Seebach
Fredrik Ramsberg <f...@mail.com> wrote:
>Everyone can choose their own language for coding IF games. However, people
>who choose C or C++ just don't seem to produce very good games. How come?
When I am writing performance-oriented number crunching, I generally do C.
Fortran might be better, but I don't do enough of it to have learned Fortran.
I do drivers in C. I do text processing utilities in perl, and most file
manipulation utilities in Bourne shell.
I write interactive fiction in Inform.
I think there's a very clear pattern here. I'm certainly *much* better at C
than I am at Inform, but Inform is the right tool for the job, so I use it.
The sorts of people who write text adventures in C or C++ are probably not
very good at picking the right tool for the job. :)
-s
--
Copyright 2002, 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/
Peter Seebach
Tzvetan Mikov <ce...@jupiter.com> wrote:
>is no proof either that it is easier to understand by non-programmers.
Could you explain exactly what about the syntax should have struck me as
awkward? I thought Inform was quite elegant for the task it's designed for.
Sean T Barrett
>During the time in which I've been lurking in this newsgroup, on numerous
>occasions I've seen the claim that IF languages (Inform, TADS, etc.) are
>much better suited for writing IF than conventional mainstream languages
>(C++, Java, etc.). I've gained the impression that this is a commonly
>accepted and understood fact.
Actually, the advantage isn't really any of the
things you've listed. I'll say the same thing in
reply to this that I've said the last three times...
No, actually I won't. I'll quote it instead.
http://groups.google.com/groups?selm=GF59x0.762%40world.std.com
SeanB
OKB -- not okblacke
>I'm actually curious about this; I've looked at a little TADS code, and
>I don't see how its syntax is "more conventional", though I've seen this
>claim in more than one place; what sort of specific structures are "more
>conventional" in TADS?
What I meant by "more conventional" was that TADS does not have all the
little English-word thingies that Inform does. There is no "with" or "has" or
"hasnt". There is no "rtrue" or "rfalse". (Actually, some things with names
like these exist, but the point is that they're not part of the language
itself, they're part of the library or some kind of intrinsic class.) Also,
TADS uses more C-like syntax for routine definitions and stuff ("{" instead of
"[", ";" instead of ":" in for loops). More generally, TADS seems generally
designed so that to find out something about an object you do
obj.findSomething(), whereas in Inform you're just as likely to do
SomeGlobalFunction(obj), viz., "obj.location" vs. "parent(obj)".
Sean T Barrett
>>- Parser and library.
>>I don't thing there is a reason why Inform's parser couldn't be translated
>>to C++, for example. This is an advantage of the status-quo, but not a
>>substantial one.
> On the contrary, I think this is THE primary reason for choosing an
>IF-specific language over a general-purpose language. There are very few
>people willing to undertake the massive effort of porting a parser and world
>model (the world model is just as important) to another system. If someone
>were to create some kind of C++ setup with a parser and world model comparable
>to those of Inform and TADS (as well as some syntactic sugar), I think we'd see
>a fair number of people use it. Not so much existing IF authors, but newcomers
>to the scene who already know C++.
I think this is actually fairly far off the mark. For most
authors, "what system should I use to write IF", the "there's
already a parser and library in system X" *is* a meaningful
and valid answer, yes.
But if we step back for a moment and look at the problem,
"what language (independent of libraries) is good for writing
IF", we see that essentially *every* bit of large-scale IF
development has been written in a custom language (other than
the LISP-derived languages): Adventure in Fortran used a little
mini-interpreter, as I understand it; Scott Adam's used a tightly
packed interpreted description; the Phoenix games use a custom
interpreted language; the Infocom games retargeted to the
Z-Machine; Inform and Tads and AGT probably account for way
beyond the vast majority of games at this point.
None of this is coincidence. If you ever sit down and try to
write a large-scale adventure "from scratch", not only do you
have to code a parser and a world model, which you can do just
fine in C, but you find you need to describe and characterize
lots and lots of objects. You can try to do that with C struct
definitions and perhaps lots of macros, but it will be clumsy,
and you'll almost certainly end up wanting to create some kind
of database or other clearer representation of that data. But
now, when you want to attach exceptional *behaviors* to the
objects, you have to write them in C code in your program,
not in the database, and it gets clumsy to debug. So maybe
you put a flag on the object, or perhaps a 1-digit code
suggesting which of several behaviors that object should have
in certain circumstances.
It's only a small step from a 1-digit-action code to adding
some primitive scripting capability stored *in the database*
with the object. From there it's only a small step until all
the code moves into the "database". (The LISPish languages
were the exception above because they *already* allow a rather
free intermixing of code and data.)
If anyone has any specific anecdotes of this process actually
occurring, I'd be curious to hear it.
SeanB
Kent Tessman
news:GsB7...@world.std.com...
> It's only a small step from a 1-digit-action code to adding
> some primitive scripting capability stored *in the database*
> with the object. From there it's only a small step until all
> the code moves into the "database". (The LISPish languages
> were the exception above because they *already* allow a rather
> free intermixing of code and data.)
>
> If anyone has any specific anecdotes of this process actually
> occurring, I'd be curious to hear it.
As an example, Hugo actually started out, way back, as a simple database
format. Then it became a complex database format. Then, as Sean noted,
that small step was taken (followed by a hundred other small steps) to
incorporate scripting, which put it on the road to becoming its own
language.
The reality that seems to have been shown out repeatedly is that it's
ultimately easier to do the things that are most important to IF (at least
in the way that IF is currently written) in a custom programming framework.
And ultimately, like Mr. Barrett says, that framework becomes a specialized
programming language.
Then there's the win (as a game-writer, not as a system developer) of not
having to port the UI layer to target multiple platforms. Oh, and there's
also my probably-unprovable-yet-sneaking suspicion that people familiar with
C++ and the like who would list consistency and clarity among those
languages' advantages overestimate just how steep the learning and
comprehension curve is for those who aren't quite as programmer-y by nature
or experience.
--Kent
Aris Katsaris
"Peter Seebach" <se...@plethora.net> wrote in message
news:3c7fca3c$0$79564$3c09...@news.plethora.net...
> In article <PhEf8.94381$B61.29...@news1.rsm1.occa.home.com>,
> Tzvetan Mikov <ce...@jupiter.com> wrote:
> >- Inform has an awkward syntax from the view point of programmers and there
> >is no proof either that it is easier to understand by non-programmers.
>
> Could you explain exactly what about the syntax should have struck me as
> awkward? I thought Inform was quite elegant for the task it's designed for.
Eh. I'm an Inform programmer but I also find things like "hasnt <attribute>"
(vs "has ~attribute") rather embarrassing syntax-wise. I'd much like it if this
one was completely equivalent to "give".
On the other hand there are also some beautiful things like the use of "or".
Aris Katsaris
Fredrik Ramsberg
> Actually, the advantage isn't really any of the
> things you've listed. I'll say the same thing in
> reply to this that I've said the last three times...
>
> No, actually I won't. I'll quote it instead.
>
> http://groups.google.com/groups?selm=GF59x0.762%40world.std.com
I'd say Common Lisp has the advantages you talk about. It's also one of
the languages that get the most support from experienced IF writers when
this topic pops up. And it's no coincidence Infocom's Muddle was a Lisp
dialect of sorts.
Common Lisp treats data and programs all the same, it has no typing as such,
but you can query what type a value has. Higher-order functions is a breeze,
you can declare objects very smoothly in your source code. A library would
have to be written, but I guess that's doable too, if someone has a few
years on their hands... (Not any more years than it would take in any other
language)
Common Lisp may not be the best basis for IF writing though, since it's
a pretty huge language (A full level 2 implementation has what, 700 built-in
functions or so, and many are quite powerful). Interpreters would be big and
arrive late. However, there are plenty Lisp dialects out there, but I'm not
familiar enough with them to say which one is best. There are also many Lisp
dialects available for the JVM, so that would be a way to go.
Maybe someone will write a Lisp based kit that compiles to Glulx? (Lisp is
usually interpreted, but if you avoid using certain features that evaluate
code generated at run-time, it can be compiled.)
/Fredrik
Fredrik Ramsberg
> Tzvetan Mikov" ce...@jupiter.com wrote:
>
> >- Ability to execute in a minimal environment.
> >Again, there is no reason why the same functionality implemented in another
> >language, should take more space and resources.
>
> I am definitely in agreement that this is not a major advantage of IF
> systems. In fact, I think that the focus on small size and resource needs
> (particularly in the Z-machine) imposes unduly bothersome restrictions on the
> size and complexity of games that can be created. We are seeing a shift away
> from this, though: Glulx is a 32-bit VM, and T3 is also full of features.
I think only the Z-machine has any restrictions worth talking about. Those
"unduly bothersome" restrictions mean you can't write games any bigger than
Anchorhead. To me, that reads as "not any bigger than mind-bogglingly huge".
Anyone who hits this ceiling and feels limited by it will most likely move
into Glulx without a whole lot of hassle, so it ends up not being a real
restriction anyway.
If we're talking about other resource needs than memory, the only thing
I can think of right now is lack of some data structures and floats in
Inform, and I can't see when one would need them. Has anyone ever missed
floating point numbers when writing IF games? I can come up with reasons
why I would need more datastructures, but only fictional reasons, not
any that would matter for games I may write.
Somehow I find this whole leaning towards C++, of all languages, to be
somewhere between disturbing and insane. Short of Befunge and InterCal,
it's possibly the worst syntax I could think of. People who had to learn
C++ for one reason or another in the past, and have spent years doing so,
may think it's practical, and want it to be the standard for IF writing
too. Anyone who doesn't already know C++ will have a lot less work and
more fun learning Inform to program IF than learning C++ to do it.
I'm resonably certain that I will get flamed for this, but it's my firm
and honest belief that the C++ syntax was devised in a place where snowballs
are in demand. The C syntax comes from the same team, but they had less
time to make it as interesting as they wanted.
/Fredrik
Adam Thornton
>and honest belief that the C++ syntax was devised in a place where snowballs
>are in demand. The C syntax comes from the same team, but they had less
>time to make it as interesting as they wanted.
Wrong.
C is a fine assembler preprocessor for a PDP-11.
C++ had some interesting ideas, but its insistence on making it a
superset of C made it huge and warty and gross.
A much better attempt at the same sort of thing is Java, which has C-ish
syntax and Smalltalk-ish semantics. My big problem with Java is that
runtimes tend to be very heavyweight.
Adam
Gary Shannon
"Fredrik Ramsberg" <f...@mail.com> wrote in message
news:ab01df60.02030...@posting.google.com...
<snip>
> I'd say Common Lisp has the advantages you talk about. It's also one of
> the languages that get the most support from experienced IF writers when
> this topic pops up. And it's no coincidence Infocom's Muddle was a Lisp
> dialect of sorts.
I first learned LSIP about 150 years ago, it seems. Back in the 70's,
anyway. But when I'm writing a cool adventure the last thing I want to have
to do is interupt my flow of thought to stop and count parens!
--gary
Gary Shannon
<snip>
> Somehow I find this whole leaning towards C++, of all languages, to be
> somewhere between disturbing and insane. Short of Befunge and InterCal,
> it's possibly the worst syntax I could think of. People who had to learn
> C++ for one reason or another in the past, and have spent years doing so,
> may think it's practical, and want it to be the standard for IF writing
> too. Anyone who doesn't already know C++ will have a lot less work and
> more fun learning Inform to program IF than learning C++ to do it.
>
> I'm resonably certain that I will get flamed for this, but it's my firm
> and honest belief that the C++ syntax was devised in a place where
snowballs
> are in demand. The C syntax comes from the same team, but they had less
> time to make it as interesting as they wanted.
>
> /Fredrik
No flames here. I had 18 years of assembly language experience under my
belt when I first tackled C++. I spent at least a year of coding 8 to 10
hours a day before I started feeling comfortable with the language. I use
it because there are no viable alternatives for the kind of code I write.
I've gotten used to it over the years, but I'm never going to "like" it!
--gary
Adam Thornton
Gary Shannon <fiz...@starband.net> wrote:
>I first learned LSIP about 150 years ago, it seems. Back in the 70's,
>anyway. But when I'm writing a cool adventure the last thing I want to have
>to do is interupt my flow of thought to stop and count parens!
And that, my friend, is what a decent editor is for.
Adam
OKB -- not okblacke
>I think only the Z-machine has any restrictions worth talking about. Those
>"unduly bothersome" restrictions mean you can't write games any bigger than
>Anchorhead. To me, that reads as "not any bigger than mind-bogglingly huge".
>Anyone who hits this ceiling and feels limited by it will most likely move
>into Glulx without a whole lot of hassle, so it ends up not being a real
>restriction anyway.
>
>If we're talking about other resource needs than memory, the only thing
>I can think of right now is lack of some data structures and floats in
>Inform, and I can't see when one would need them.
There are also limits on attributes, global variables, etc. (although I'm
not sure whether these come from Inform or from the Z-machine). There are also
limits on "what you can do" -- i.e., crappy I/O, crappy control over the
screen, etc.
Tzvetan Mikov
>[...]
> I write interactive fiction in Inform.
>
> I think there's a very clear pattern here. I'm certainly *much* better at C
> than I am at Inform, but Inform is the right tool for the job, so I use it.
OK, this is what most people have been saying, but it just goes back
to my initial post. Which asked the question "Why ?". Why is Inform
the better tool for the job ? What are the features of the language
that make writing IF easier ?
> The sorts of people who write text adventures in C or C++ are probably not
> very good at picking the right tool for the job. :)
Writing an adventure in C is madness, not the least because of its
string handling capabilites.
However I still think (I haven't seen evidence for the contrary) that
if somebody created a C++ framework functionally equivalent to Inform,
writing games using that framework wouldn't be any more difficult.
Note that I am talking theoretically: As I already said I don't have
the slightest intention of creating such a framework or writing IF in
C++.
-tzvetan
Jim Nelson
>
> However I still think (I haven't seen evidence for the contrary) that
> if somebody created a C++ framework functionally equivalent to Inform,
> writing games using that framework wouldn't be any more difficult.
Even if this is true, it's a far cry from what you stated in your
original post.
You know, you could prove your point without a tremendous amount of work.
Take a sample IF game -- TADS' golden skull, or Inform's museum -- and
build it in C++ with an imaginary support framework behind it. Don't
bother writing support libraries, or even compiling your result. Just
see how much upfront work it would require and compare it to the original
game.
--
Jim Nelson
jim_n...@mindspring.com
wo...@one.net
Hi Tzvetan,
>I don't understand why; below I have described a few reasons why I think it
>is in fact the other way around.
I tend to agree with you, PAWS is nothing more than a couple of
libraries on top of Python. However, having said that there are lots
of things that IF languages do well because they've been specialized
to the IF domain.
Just as you wouldn't write a device driver in Python or a database
application in pure APL, you should seriously consider not doing IF in
mainstream languages like C++.
>- IF languages are less powerfull than mainstream languages, especially when
>used for implementing algorithms. For example I remember (I might be wrong)
>that in some versions of TADS the only data structure is the linked list.
Depends on the language. Hugo, for instance struck me as very much a
Basic-like IF language with lots of power. TADS is an OOP version of C
with weak type casting. Inform, well, is Inform. :) ADVSYS was a poor
man's LISP.
One advantage IF languages do have is text handling, both ease of
handling large chunks and generally manipulating strings. The built-in
parsers are a MAJOR benefit in that you don't have to write your
own--and trust me, that's a BIG BIG deal.
The PAWS parser for instance is only so-so as parsers go, and it's a
1,000+ lines of Python source code. Granted, about 70% of that is
comments but Python's a really high level language with a lot of bang
for the buck lines of code-wise. In C++ I shudder to think how many
lines of code it would be--or how hard it would be to debug and
maintain.
>- Inform has an awkward syntax from the view point of programmers and there
>is no proof either that it is easier to understand by non-programmers.
>(Advanced IF requires quite a lot of real programming, as far as I can
>tell). Anyway, it creates an artificial gap between IF and regular
>programming.
Hmm. Inform's syntax is linguistically distinct from other language
families, but I wouldn't characterize it as awkward. It's been
designed with specific goals in mind, both to deal with z-machine
idiosyncracies (if I recall correctly) and to make common IF tasks
easier.
If you want to talk about awkward syntax let's talk about LISP. :)
As for creating a gap between IF and regular programming, I think I
have to disagree. Programming in Inform is *programming*, it's just
you're programming in a domain the language is particularly adapted
for. A domain with a number of unique characteristics not normally
encountered in the day-to-day grind most programmers face.
>In reality, this has stopped me more than once, not having the time to learn
>an entire new language, which seems less powerfull and unfortunately not
>usefull outside of a hobby.
Since computer langauges are one of my hobbies :) this isn't a
particularly compelling point to me. You have to consider the IF
domain poses a unique set of challenges. IF languages are shaped to
answer those challenges.
Plus, most IF language authors aren't professional language designers,
and they don't have infinite resources to devote to their projects. So
they naturally concentrate on the areas that are the most important in
the IF domain. Parsing, text manipulation, OOP in many cases, making
the language overhead as small as possible...
Things like math functions, exotic control structures and data types
take a back seat. But the *reason* they take a back seat is because by
and large they aren't as important in the IF domain--you don't
normally need the ability to calculate a square root or do a shell
sort or whatever.
>
>False advantages of IF languages
>================================
>
>- Convenient syntactic sugar not present in mainstream languages.
>While I am not closely familiar with any of the IF languages (I've examined
>a few sources, read a few tutorials, and read discussions here), I remember
>that there are convenient shortcuts, for example, "print text and return
>from subroutine". This particular one, IMHO, stimulates bad programming
>style but undoubtedly there are others, which do save typing without
>sacrificing style. I am however not convinced that they can't be emulated in
>a mainstream language (e.g. using macroses, C++ templates, etc.)
Two points. First, any particular feature is going to have to be
viewed not in terms of general best programming practice but in terms
of the IF domain and the problem solved by the feature.
To take a mainstream example, conventional wisdom says that any
sub-routine or function should have one entry point and one exit
point.
My programming style violates this principle. I test for exception
conditions (bad arguments, premature exit conditions, etc) and if
those conditions exist I exit the sub/function immediately. This can
result in as many as half a dozen exit points from a typical
function--but it can also reduce the nesting depth by 3 or 4
levels--and that is worth having multiple exit points in a function.
Likewise the print-and-return capability (in ADVSYS this was the
continue and abort keywords IIRC) is perfectly acceptable PROVIDED you
are aware of the nature of the feature and use it consistantly.
The resulting style may not agree with conventional programming style
but need not be "bad" programming style either.
Second point, C++ can be fiendishly complex in overhead, especially
once you start delving into the more advanced features of the
language. Most game authors aren't professional programmers, they only
want to do enough programming to solve their immediate needs and no
more. :)
Subtleties can rapidly spiral into outright untracable bugs, even for
pros. Tell you the truth, I've been programming for over 25 years and
I prefer an almost Zen level of simplicity in programming, avoiding
complex features and subtle interactions whereever possible.
>- Parser and library.
>I don't thing there is a reason why Inform's parser couldn't be translated
>to C++, for example. This is an advantage of the status-quo, but not a
>substantial one.
Um, ever designed a parser? :) It isn't easy, in fact the parser is
arguably the most complex part of an IF system. While you could
certainly do a one-time conversion and use the parser as just another
routine allowing the parser behavior to be extended and modified in a
strongly typed language like C++ isn't all that simple.
>- Ability to execute in a minimal environment.
>Again, there is no reason why the same functionality implemented in another
>language, should take more space and resources.
>Of course there is the issue of the mainstream language's standard library
>and execution environment - in the case of Java or C# these can be
>ridiculously large. This problem can be solved as described in the next
>point.
Ah, now here the IF languages have a *distinct* advantage. Z-machine
interpreters are a couple of hundred K--usually much smaller. They're
usually self-contained, installation means putting it in a directory,
and it's a 5 minute download with a dial-up connection.
On the other hand Python is a 5 *megabyte* download, it has to be
installed (which can be trivial or hairy depending on the platform),
and many people won't want to do that just to play IF games.
>- Portability across paltforms.
>This is an important one. The ability to distribute one game file and play
>it on any machine
>A simple (and more sane in comparison to Zcode - may be GLUX is already
>that) VM can be developed. Existing compilers of standard languages can
>easily be retargeted for that VM. In addition, only parts of the language's
>libraries relevant to IF can be provided with the VM. Come to think of it,
>JVM without the gigantic class libraries could serve that purpose rather
>nicely.
>This solution will in no way be more limited that the existing IF execution
>environments, but would benefit from existing programming experience,
>sharing of common code, etc. It would even be possible to develop IF using
>standard (native) compilers (and more importantly debuggers) and then only
>for distribution compile and test with a compiler targeting the VM.
Ah, portability. Here you have a problem. Nobody in their right mind
would create a C++ compiler for the Z-machine. Or a Java
implementation. (At least not unless they've won the lottery and have
nothing better to do... :))
The same is true for all the major languages. Retargeting them isn't
nearly as simple as you imply.
Java is *supposed* to be portable, Python is binary compatible across
20+ platforms. Maybe other high-level scripting languages like Perl,
or Ruby are too, but certainly not C/C++/Basic/Pascal/LISP/Etc.
>Please, understand that the above are not suggestions. I am merely trying to
>illustrate why I think that there are no *theoretical* advantages to IF
>languages. The most important *practical* advantage (lots of existing games,
>examples and coding experience, loyal community) is real and is here and I
>would not think to (or want to) try to change it.
I think there are solid theoretical advantages, as well as massively
compelling practical reasons as I've shown above.
>So, I will appreciate comments on the points described above. I am also very
>curious about concrete programming examples of things that you think can't
>be conveniently (or at all) done using mainstream languages (with aid of
>libraries of course).
Can't be done? That really isn't the issue. Can be done *more easily*?
Oh, many different things. Again, see above. Never underestimate the
benefits to be gained from using domain specific languages! :)
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
Tzvetan Mikov
"Magnus Olsson" <m...@df.lth.se> wrote in message
news:a5ngdg$v1$1...@news.lth.se...
> The crucial question is really: are they more or less powerful for the
> kind of algorithms that you usually implement in an adventure game?
>
> To take an even more striking example than linked list in TADS:
> Inform's support for arrays and strings is quite primitive compared to
> C (and that's even taking into account that C's string handling
> functions are, to say the least, on the primitive side). This is a real
> disadvantage if you want to implement an algorithm that's heavy on
> array processing; fortunately, such algorithms are very rare in IF.
I am under the impression that simulationst games, for example, require more
advanced programming techniques. Of course, it is debatable whether good IF
really needs to simulate reality and whether it should be called IF when it
does. That aside, isn't the programming language ever a limiting factor? Can
you be sure that the capabilities of the language (or lack there of) aren't
affecting the choices you make in a design of IF story ?
> >- Inform has an awkward syntax from the view point of programmers and
there
> >is no proof either that it is easier to understand by non-programmers.
>
> This seems to be a matter of taste. I find it more awkward than C++ in
> some respects, and less in others.
Yes, as far as I can tell the IF community has mixed opinions on this.
> >- Convenient syntactic sugar not present in mainstream languages.
> >While I am not closely familiar with any of the IF languages (I've
examined
> >a few sources, read a few tutorials, and read discussions here), I
remember
> >that there are convenient shortcuts, for example, "print text and return
> >from subroutine". This particular one, IMHO, stimulates bad programming
> >style
>
> It does? Examples, please.
I don't have any examples offhand. My experience however shows that
combining control flow statements with side-effect-causing actions is
dangerous. I would even go as far as to say that even statements like
"break" or "return" are usually harmful in software modules that have a long
life cycle and have to be actively maintained - they make the logic harder
to follow and more difficult to modify. Of course there are exceptions to
this rule - cases when brevity helps to clarify the intent.
> Personally, I don't see that Inform's
> "Hello world.";
> is that much better or more convenient than C++
> cout << "Hello world" << endl; return true;
> but it's definitely more convenient than having to write thousands of
> printf statements in C.
This is a valid point that Jim Aikin also made earlier. I think that if one
was trying to develop a convenient C++ library for IF, he might choose a
different syntax. For example a viable possibility using C++ overloaded
operators and string would be:
o < "Hello world."
"A line of text."
"Another line of text."
"and so on...";
return true;
> Are you volunteering to port the entire Inform library to C++? I'm
> sure people will be grateful if you do (this is not ironic; I really
> mean this). But if you're not prepared to do it, I don't think you
> should call the advantage of Inform "not a substantial one".
As I stated in my initial post, I have no intent of doing anything of the
kind, nor am I proposing that someone else should do it. My question is a
purely hypothetical one. To put it in a different way:
If Inform and TADS didn't exist and you had to create an IF system, would
you just recreate Inform, extend Inform (or TADS) with additional features,
or use an existing popular language ?
I think that it has mostly been answered - it seems most people here would
prefer Inform (or TADS) with somewhat improved syntax and algorithmical
capabilities.
-tzvetan
Tzvetan Mikov
"Sean T Barrett" <buz...@TheWorld.com> wrote in message
news:GsB7...@world.std.com...
> authors, "what system should I use to write IF", the "there's
> already a parser and library in system X" *is* a meaningful
> and valid answer, yes.
>
> But if we step back for a moment and look at the problem,
> "what language (independent of libraries) is good for writing
> IF", we see that essentially *every* bit of large-scale IF
> development has been written in a custom language (other than
>
> None of this is coincidence. If you ever sit down and try to
> write a large-scale adventure "from scratch", not only do you
> have to code a parser and a world model, which you can do just
> fine in C, but you find you need to describe and characterize
> lots and lots of objects. You can try to do that with C struct
> definitions and perhaps lots of macros, but it will be clumsy,
> and you'll almost certainly end up wanting to create some kind
> of database or other clearer representation of that data. But
> now, when you want to attach exceptional *behaviors* to the
> objects, you have to write them in C code in your program,
> not in the database, and it gets clumsy to debug. So maybe
> you put a flag on the object, or perhaps a 1-digit code
> suggesting which of several behaviors that object should have
> in certain circumstances.
>
> It's only a small step from a 1-digit-action code to adding
> some primitive scripting capability stored *in the database*
> with the object. From there it's only a small step until all
> the code moves into the "database". (The LISPish languages
> were the exception above because they *already* allow a rather
> free intermixing of code and data.)
>
Thank you for the nice explanation. You and L. Ross Raszewski seem to be
making the same point, which I am interpreting in the following way:
The power of the IF-specific languages (and their main advantage over
conventional ones) is in their ability to easily declare data objects (not
classes but rather instances of classes) *and* their behaviour.
Conceptually it isn't any diferent than conventional object-oriented
languages (instead of moving the behaviour into the "database", we move the
"database" into the program - it is the same thing), but in conventional
languages it would be cumbersome to describe the "database" in the program
code. So, the advantage is one of syntax (unless I am entirely mistaken).
That makes perfect sense and now I can imagine how it would it be very ugly
to translate an Inform game into Java for example.
-tzvetan
Fredrik Ramsberg
> There are also limits on attributes, global variables, etc. (although I'm
> not sure whether these come from Inform or from the Z-machine).
The limits you mention all come from the Z-machine.
With custom properties being just about unlimited in Inform 6, I think the
limits on properties and attributes are pretty much unimportant. The fact
that arrays as values in properties can only be 64 bytes long is a bit more
serious, but can be worked around in those rare instances when it's needed.
> There are also limits on "what you can do" -- i.e., crappy I/O, crappy
> control over the screen, etc.
That's all for the sake of portability. The Z-machine was designed to be
as portable as possible, and it has also been ported to more platforms
than any other IF platform. If we were to start using C as a language
for writing IF, rather than Inform, we'd have to standardise on what
I/O operations should be supported anyway, or we'd be back to compiling
games separately for each platform, with a porting process in between.
Most authors seem to think the Z-machine is sufficient for telling
the stories they want, and by using a system with minimal I/O, they
gain an incredible portability and thus a larger audience. I say it's
a calculated and necessary trade-off.
/Fredrik
Kodrik
> if somebody created a C++ framework functionally equivalent to Inform,
> writing games using that framework wouldn't be any more difficult.
That's not what I understood from your original post. I though you were
saying that a game should be coded in C++ from scratch.
Now I understand you are saying functions for IF should be developed in C++
to offer a framework for developing IF.
> OK, this is what most people have been saying, but it just goes back
> to my initial post. Which asked the question "Why ?". Why is Inform
> the better tool for the job ? What are the features of the language
> that make writing IF easier ?
Developing a framework is like developing an engine, and this is a huge
amount of work.
I am doing something along those lines, storing the data in a datbase and
writing functions to store the data in specific waysa nd establish
relationships.
I'm over 80,000 lines of code, all typed manually, and far from finished.
Engines like Inform have 10 years of development behind them. I think there
is room for new concepts in game engines but it will take a lot of work to
get a decent "framework" and be able to match most features that inform
took so many years to implement and authors expect.
Sean T Barrett
>Conceptually it isn't any diferent than conventional object-oriented
>languages (instead of moving the behaviour into the "database", we move the
>"database" into the program - it is the same thing), but in conventional
>languages it would be cumbersome to describe the "database" in the program
>code. So, the advantage is one of syntax (unless I am entirely mistaken).
The other major issue is that most convention OO languages are
class-based, and do not allow you to attach methods to individual
objects. (E.g. Smalltalk, C++.) Since most objects in IF are
exceptional, you have to do clumsy define-a-class-for-each object
in each language. Again, you can argue that this is "just syntax",
but I think it shows a basic impedance mismatch between those
languages and IF--there *are* other languages that allow for
per-object methods (e.g. Self, which is prototype-based, not
class-based), and I don't think people normally say that these
language changes are just syntactic sugar.
SeanB
Mike Roberts
> If you ever sit down and try to write a large-scale adventure
> "from scratch", not only do you have to code a parser and a
> world model, which you can do just fine in C, but you find
> you need to describe and characterize lots and lots of objects.
> of database or other clearer representation of that data [and
> then attach some flags or action codes to the objects to
> indicate special behaviors].
>
> It's only a small step from a 1-digit-action code to adding
> some primitive scripting capability stored *in the database*
> with the object.
This is exactly the progression I went through many years ago and which
ultimately led to TADS. I started with in-program statically initialized
structures, which got too tedious; so I moved to external text files with a
tiny compiler to turn them into initialized structures, but then you have
your code for a single object spread out over several files in different
"languages," so it's a pain to write and impossible to maintain; so I adding
a primitive language so the data and code for each object could be kept
together in the external text files, but it's really a pain to program in a
primitive scripting language; so I set out to make the scripting language
usable and full-featured.
--Mike
Peter Seebach
Tzvetan Mikov <ce...@jupiter.com> wrote:
>OK, this is what most people have been saying, but it just goes back
>to my initial post. Which asked the question "Why ?". Why is Inform
>the better tool for the job ? What are the features of the language
>that make writing IF easier ?
Nicely generic objects with named attributes, which can refer to each others'
attributes fairly conveniently, and not a whole lot of hassle about trying
to remember where the members came from. String handling and parsing nicely
done for you, and a *very* convenient way to extend verbs. A message-passing
interface among objects that's quite well-suited to task.
Magnus Olsson
Sean T Barrett <buz...@TheWorld.com> wrote:
>"what language (independent of libraries) is good for writing
>IF", we see that essentially *every* bit of large-scale IF
>development has been written in a custom language (other than
>the LISP-derived languages):
Arguably, the LISP-derived languages can be counted as "custom"
as well.
>Adventure in Fortran used a little
>mini-interpreter, as I understand it
Not the original. The original ADVENT was written directly in
Fortran. I think you're thinking of ACODE, which is used for
a number of Advenutre versions, but not for the original.
>None of this is coincidence. If you ever sit down and try to
>write a large-scale adventure "from scratch", not only do you
>have to code a parser and a world model, which you can do just
>fine in C, but you find you need to describe and characterize
>lots and lots of objects.
(snip)
I think that an alternative direction that IF language development
could have taken would have been to extend existing languages, rather
than to define entirely new ones. In particular, I'm thinking of
extending C, C++ or Pascal with adventure-writing primitives, and then
writing a translator program/preprocessor to translate these
primitives into C, C++ or Pascal code. (In the case of langauges
derived from Lisp or Forth, this wouldn't be necessary, since those
languages are designed to be extensible. C++ is also extensible in a
more limited way.)
Why didn't this happen? Mostly, I think, because the development
started when target machines were small, 8-bit micros, too small to
support full-fledged compilers. But had the first IF wave happened
ten years earlier or later, we might very well have gone that way.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Alex Watson
interrupted me...
> > There are also limits on attributes, global variables, etc. (although I'm
> > not sure whether these come from Inform or from the Z-machine).
>
> The limits you mention all come from the Z-machine.
Incidentally, is the 16-bit integer limit and wraparound in Inform due to
the Z-Machine or Inform itself?
--
Alex Watson
http://www.watson1999-69.freeserve.co.uk/froup/
Replies to me[AT]watson1999-69.freeserve.co.uk
"Never underestimate the power of stupid people in large groups."
Adam Thornton
Alex Watson <alexw...@deadspam.com> wrote:
>Incidentally, is the 16-bit integer limit and wraparound in Inform due to
>the Z-Machine or Inform itself?
Z-machine.
Glulx Inform is 32-bit.
Adam
L. Ross Raszewski
>I think that it has mostly been answered - it seems most people here would
>prefer Inform (or TADS) with somewhat improved syntax and algorithmical
>capabilities.
I'm extremely curious about what sort of syntactic or algorithmic
capabilities you think would be useful; the only obvious things that
come to mind are:
stronger typing (Inform is weakly typed, and typechecking is all done
at runtime. To what extent this is a Bad Thing is debatable; there
are other general pupose languages which have similar type systems)
Operator overloading (Yes, it might be nice to use a '+' to do string
concatenation. But, otoh, whether or not operator overloading is a
Good Thing is a subject of some heated discussion amongs pl people. )
L. Ross Raszewski
>
>OK, this is what most people have been saying, but it just goes back
>to my initial post. Which asked the question "Why ?". Why is Inform
>the better tool for the job ? What are the features of the language
>that make writing IF easier ?
Okay. Speaking just of syntactic features of the language, IF
languages have substantially superior capabilities in terms of
declaring formatted static data. Imperative languages (such as C and
C++), even OO imperative languages, do not generally have comparable
abilities, being more oriented toward dynamically generated data. IF
relies heavily on data structures whose initial contents are known at
compile-time.
>Writing an adventure in C is madness, not the least because of its
>string handling capabilites.
Eh. C++ doesn't really have better string handling facilities than
C. It just has more syntactic sugar.
>
>However I still think (I haven't seen evidence for the contrary) that
>if somebody created a C++ framework functionally equivalent to Inform,
>writing games using that framework wouldn't be any more difficult.
>
I suspect this not to be the case.
L. Ross Raszewski
>Lewis Raszewski <rras...@hotmail.com> writes:
>
>| OKB -- not okblacke wrote:
>| >
>| > I think the proof is the pudding, the pudding in this case
>| > being the large number of authors who have chosen Inform over TADS
>| > (which has a more conventional syntax). Now, certainly there are
>| > things about Inform's syntax I don't like, but on the whole it is
>| > nicely sprinkled with shortcuts which, although not necessarily
>| > making the procedural flow of the code more apparent, DO make it
>| > easier to write code relevant to IF.
>|
>| I'm actually curious about this; I've looked at a little TADS code,
>| and I don't see how its syntax is "more conventional", though I've
>| seen this claim in more than one place; what sort of specific
>| structures are "more conventional" in TADS?
>
>Here's a list of things I find syntactically weird about Inform that
>have more conventional syntax in TADS:
Huh. A very long list, which interests me, jsut because I've never
found anything odd about any of these. I'll grant that they are
something different from C syntax (well, syntax like print (the)
.. reminds me of C++ IO manipulators), so perhaps my mistake is that I
don't take "conventional" to mean "just like C".
I always found the TADS use of a pascal-like := assignment operator
far more "jarring" than any of the not-quite-C things in Inform.
L. Ross Raszewski
<bren...@aol.comRemove> wrote:
>>I'm actually curious about this; I've looked at a little TADS code, and
>>I don't see how its syntax is "more conventional", though I've seen this
>>claim in more than one place; what sort of specific structures are "more
>>conventional" in TADS?
>
>little English-word thingies that Inform does. There is no "with" or "has" or
>"hasnt". There is no "rtrue" or "rfalse". (Actually, some things with names
Hm... I'm trying to imagine how inform would cope without these. I
mean, since rtrue and rfalse are, in essence, just aliases for return
1 and return 0, but "has" and "hasnt" are boolean operators for
things that most other languages don't have an analogue of. I could
understand, though, if one felt that the fact that attributes and
properties are distinctly different things was a "non-conventional"
thing (TADS, iirc, doesn't have a sense of an attribute as anything but
a boolean-valued property), though it is the closest thing a
weakly-typed language can have to type-safety.
>like these exist, but the point is that they're not part of the language
>itself, they're part of the library or some kind of intrinsic class.) Also,
>TADS uses more C-like syntax for routine definitions and stuff ("{" instead of
>"[", ";" instead of ":" in for loops). More generally, TADS seems generally
Mmm. Yeah. Okay. I wouldn't call this "conventional" as much as
C-like. 'Course, I did expect "Inform doesn't declare functions the
way C does" to be one of the things mentioned.
TADS, otoh, (and, some of this is things I've only heard from other
people), has "non-conventional" things like the ability to embed
executable code in a printed string, and, as I understand it, makes no
distinction between retrieving a value from an object's property, and
executing a function stored in an object property and retrieving its
return value.
>designed so that to find out something about an object you do
>obj.findSomething(), whereas in Inform you're just as likely to do
>SomeGlobalFunction(obj), viz., "obj.location" vs. "parent(obj)".
>
Well, inform is certainly less rigorously OO than tads. While this
might be a legitimate complaint about the language, I don't think
calling it "less conventional" is accurate (unless Java now defines
convention :-)
L. Ross Raszewski
I think a fair bit of this comes out of the fact that C was written by
a couple of guys. C++, on the other hand, appears to have been written
by a committee full of guys who sat around sayuing "Y'know what would
be cool in a language?" (A group of these people much less obsessed
with contemporary theories in Good Programming Language Design no
doubt are responsible for Perl, the language which is undoubtedly the
most full of "stuff that seemed like a good idea at the time")
Now, Java feels a lot like it was written by a bunch of erudite
college professors who knew exactly what a language should be like,
with a corporate bigwig standing in the corner of the room, weildign a
firehose.
I can appreciate Java, but I've never really liked it. I can use C++,
but it always leaves me feeling dirty. C, on the other hand, can do
everythign I want, and I feel like I've actually accomplished
something at the end of it.
When I want to the sort of theorhetically satisfying programming that
people write papers about, I'll give the finger to the lot of them,
and use Smalltalk or ML.
[ObIF] And when I wanna write IF, it's inform all the way, baybee :-)
L. Ross Raszewski
>Eh. I'm an Inform programmer but I also find things like "hasnt <attribute>"
>(vs "has ~attribute") rather embarrassing syntax-wise. I'd much like
it if this
>one was completely equivalent to "give".
Hm... See, my issue with this is, if I want to test if x is equal to
three, I say "x==3", and if I want to test if it's not equal to 3, I
say "x~=3" (or in C, "x!=3" -- Y'know, I think inform has C beat in
negation; in C, you go from bitwise to boolean operators by doubling
them; &->&& |->||, except for negation, which pulls a ~->!; inform,
OTOH, goes ~->~~); It wouldn't make sense to say "x == ~~3". I
likewise find it hard to say that "x has ~attribute" would make more
sense than "x doesn't-have attribute". Though maybe some of us would
be pleased if a suitable non-textual glyph could have been concovted
for 'has'.
OKB -- not okblacke
>Huh. A very long list, which interests me, jsut because I've never
>found anything odd about any of these. I'll grant that they are
>something different from C syntax (well, syntax like print (the)
>.. reminds me of C++ IO manipulators), so perhaps my mistake is that I
>don't take "conventional" to mean "just like C".
Well, it's not just that. Internally, there's something of an
inconsistency. Why is it, for example, that "move x to y" is a unique syntax
construct, "parent(x)" is a built-in function, and "x.short_name" is a property
value? The thing is that in TADS most of these things are accomplished via a
single syntactic structure ("obj.method(args)") where as in Inform there's a
hodgepodge of dissimilar syntaxes.
Whether this is good or bad is another question; I think it depends on
the person. Originally I found Inform much easier to learn, but now I'm having
a look at TADS 3 and I'm not encountering too much difficulty in learning the
different syntax.
Tzvetan Mikov
"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:a5uhe3$a9$1...@foobar.cs.jhu.edu...
> On Sat, 02 Mar 2002 08:14:05 GMT, Tzvetan Mikov <ce...@jupiter.com> wrote:
> >I think that it has mostly been answered - it seems most people here
would
> >prefer Inform (or TADS) with somewhat improved syntax and algorithmical
> >capabilities.
> I'm extremely curious about what sort of syntactic or algorithmic
> capabilities you think would be useful;
I can read a little bit of sarcasm here, since it is clear that I haven't
programmed in IF languages and it would be silly to suggest improvements...
:-) This discussion has definitely encougared me to educate myself. In your
earlier post you claimed that IF languages are sufficiently powerful for any
algorithm and I can accept that (although I have to admit I had different
impressions).
I think there is at least some discontent with Inform's syntax; a few people
have said so. This is only a personal opinion but I think that more
similarity with C or Pascal syntax might be better. Similarity is a good
thing not because C (or Pascal) is the perfect language, but because it
would just be easier for people who already do programming; it probably
wouldn't matter for people who don't.
Leaving the syntax aside, would it be hard to implement (off the top of my
head) a hash table or a balanced binary tree in Inform or TADS ?
> Operator overloading (Yes, it might be nice to use a '+' to do string
> concatenation. But, otoh, whether or not operator overloading is a
> Good Thing is a subject of some heated discussion amongs pl people. )
General purpose operator overoading would be an overkill IMHO. But the
immediate problem of string concatenation is better solved (in the context
of IF) by simply supporting string as a native type.
-tzvetan
Tzvetan Mikov
> On 1 Mar 2002 21:00:10 -0800, Tzvetan Mikov <ce...@jupiter.com> wrote:
> >
> >OK, this is what most people have been saying, but it just goes back
> >to my initial post. Which asked the question "Why ?". Why is Inform
> >the better tool for the job ? What are the features of the language
> >that make writing IF easier ?
>
> Okay. Speaking just of syntactic features of the language, IF
> languages have substantially superior capabilities in terms of
> declaring formatted static data. Imperative languages (such as C and
> C++), even OO imperative languages, do not generally have comparable
> abilities, being more oriented toward dynamically generated data. IF
> relies heavily on data structures whose initial contents are known at
> compile-time.
I believe this answers my initial question.
> >Writing an adventure in C is madness, not the least because of its
> >string handling capabilites.
>
> Eh. C++ doesn't really have better string handling facilities than
> C. It just has more syntactic sugar.
I can't agree. Using your reasoning even assembler has perfect string
handling facilities. C++ combined with a garbage collector, can seamlessly
implement almost any model of string handling that I can think of.
> >However I still think (I haven't seen evidence for the contrary) that
> >if somebody created a C++ framework functionally equivalent to Inform,
> >writing games using that framework wouldn't be any more difficult.
> >
>
> I suspect this not to be the case.
Actually, a lot of evidence has been presented since I wrote this, so I too
begin to think that this is not the case.
-tzvetan
Tzvetan Mikov
"Sean T Barrett" <buz...@TheWorld.com> wrote in message
> The other major issue is that most convention OO languages are
> class-based, and do not allow you to attach methods to individual
> objects. (E.g. Smalltalk, C++.) Since most objects in IF are
> exceptional, you have to do clumsy define-a-class-for-each object
> in each language. Again, you can argue that this is "just syntax",
> but I think it shows a basic impedance mismatch between those
> languages and IF--there *are* other languages that allow for
> per-object methods (e.g. Self, which is prototype-based, not
> class-based), and I don't think people normally say that these
> language changes are just syntactic sugar.
To go one step further than define-a-class-for-each object, is it possible
to dynamically attach methods and properties to objects ?
If not, defining a class per object doesn't necessarily seem that clumsy to
me, except in the sense that it differs from the established programming
practices for that language. The layout and contents of the class/object
have to be defined anyway and the only "extra" coding would be to
instanciate the object.
Of course I haven't thought this through and there may be very good reasons
why this is not sufficient.
I think I will have to really educate myself more about some IF language
before I can ask more reasonable questions. Are TADS and Inform comparable
in the aspect that interrests me (difference from non-IF languages, noting
Inform's different syntax) ?
-tzvetan
Tzvetan Mikov
<wo...@one.net> wrote in message
news:dnr08u83o03nmf97b...@4ax.com...
Hi Wolf,
In fact PAWS (its existence) was one of the reasons I started thinking on
this subject. Unfortunately I have never taken a look at it (nor a serious
look at the IF languages).
>[...snip...]
> >- Parser and library.
> >I don't thing there is a reason why Inform's parser couldn't be
translated
> >to C++, for example. This is an advantage of the status-quo, but not a
> >substantial one.
>
> Um, ever designed a parser? :) It isn't easy, in fact the parser is
> arguably the most complex part of an IF system.
I think I know what you mean, kind of. About seven years ago I designed a
very very simple (two word only - verb + object) parser for Bulgarian (my
mother tongue - it has somewhat similar grammar structure to Russian, but
with different irregularities). I started thinking about enhancing it
further and I think that experience damaged me for life .. an English parser
would be a programmer's dream by comparison ... :-)
>[...snip...]
> I think there are solid theoretical advantages, as well as massively
> compelling practical reasons as I've shown above.
>
> Can't be done? That really isn't the issue. Can be done *more easily*?
> Oh, many different things. Again, see above. Never underestimate the
> benefits to be gained from using domain specific languages! :)
I agree with many of the things you say above (well, may be except about
"break" and "exit function" :-) and actually by now I have been largerly
persuaded by many posts that IF languages have distinct advantages for
writing IF.
So, then (to be blunt) do you think that PAWS (as a system) is inferior to
Inform or TADS ?
-tzvetan
Jim Nelson
> to dynamically attach methods and properties to objects ?
In TADS, properties yes, methods no. TADS 2 understands method pointers
though, so you can fake this sort of thing. TADS 3, I don't know.
You could emulate this in Java or C++ with get/setProperty methods,
hashing objects by a string name. My suspicion is this properties table
would quickly be overworked as the library developed, to the point that
the benefits of sticking with the language offered diminishing returns.
> If not, defining a class per object doesn't necessarily seem that clumsy to
> me, except in the sense that it differs from the established programming
> practices for that language. The layout and contents of the class/object
> have to be defined anyway and the only "extra" coding would be to
> instanciate the object.
> Of course I haven't thought this through and there may be very good reasons
> why this is not sufficient.
At first blush, it does seem like a simple matter of a little extra
typing. But in IF, statically-defined objects aren't a onesy-twosy
thing. Hundred, or hundreds, of objects may exist in a game. Creating a
class for each and then instantiating one measly object out of it is not
helping matters. In TADS, some object definitions may require four short
lines. In C++ or Java, it could take half a screen.
Think of it this way. If the engineering situation requires an app with
hundreds of statically-defined objects, each different in unpredictable
ways, the engineers would think real hard how to make life simpler. In
C/C++, the preprocessor would be studied for help. Or a custom
preprocessor might be coded to do the job. (I worked at a company that
used such a tool, but for different reasons.)
The point is, a lot of talk has been made about the importance of IF's
libraries. But also consider that the languages themselves were not
designed by committee or professors, but by amateurs (in the appreciative
sense of the word) who required a particular form of expressive power. I
believe in the supply-demand school of thought on languages. If it's
highly used and produces successful results, then something's right.
I'm not saying there's no room for discussion. You're making some
interesting points. I know of one of my old college professors who'd
love to dissect TADS and Inform, and this discussion is reminding me why.
--
Jim Nelson
jim_n...@mindspring.com
Magnus Olsson
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>Eh. C++ doesn't really have better string handling facilities than
>C. It just has more syntactic sugar.
The string class in the standard library is IMHO susbtantially more
than syntactic sugar. (It's still not *great* string processing, just
adequate, but compared to C it's a different world).
Fredrik Ramsberg
> To go one step further than define-a-class-for-each object, is it possible
> to dynamically attach methods and properties to objects ?
A method in Inform is just a property whose value is a pointer to a
routine. This comes very much in handy for writing IF Games. For example,
there's a property called n_to, which is used to say where the player
ends up if he goes north. It can be a pointer to a room, or it can be
a string to print (like "You'd fall off the cliff!"), or it can be a routine
which either returns a room or prints a string. The library will decide
which it is, and act accordingly.
Returning to your question: Since mehtods are also properties, it all boils
down to what can be done with properties:
Property values can of course be changed run-time, but you have to
assign them some kind of value at compile time to do this. The Z-machine
,which Inform compiles to, uses this technique to save space. Since
the Z-machine only has as much memory as it seems to need at compile-
time, there is no space for adding new properties to an object if you
haven't made preparations at compile-time.
> If not, defining a class per object doesn't necessarily seem that clumsy to
> me, except in the sense that it differs from the established programming
> practices for that language. The layout and contents of the class/object
> have to be defined anyway and the only "extra" coding would be to
> instanciate the object.
With hundreds or even thousands of objects, this is not something you
want to do. Only tedious extra-work, and more lines of code that can
contain errors. It also means that you have to edit two places in your
code for every object you create. These systems are otherwise pretty
good at keeping everything related to one object in one place.
/Fredrik
Aris Katsaris
"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:a5uk9t$a9$6...@foobar.cs.jhu.edu...
> On Fri, 1 Mar 2002 23:57:31 +0200, Aris Katsaris <kats...@otenet.gr> wrote:
>
> >Eh. I'm an Inform programmer but I also find things like "hasnt <attribute>"
> >(vs "has ~attribute") rather embarrassing syntax-wise. I'd much like
> it if this
> >one was completely equivalent to "give".
>
> Hm... See, my issue with this is, if I want to test if x is equal to
> three, I say "x==3", and if I want to test if it's not equal to 3, I
> say "x~=3"
But the thing is that these are binary attributes. If you want to
test if a binary variable is 0, you wouldn't say "x~=1", you'd
say "x==0" and that'd remove the need for an extra operator.
But mostly I'd like has to be *completely* equivalent to give,
so that one could write things like
"if (object has clothing ~worn container ~large)"
rather than
"if (object has clothing && object hasnt worn && object has container
&& object hasnt large)
Aris Katsaris
Richard Bos
> I first learned LSIP about 150 years ago, it seems. Back in the 70's,
> anyway. But when I'm writing a cool adventure the last thing I want to have
> to do is interupt my flow of thought to stop and count parens!
Amen. LISP managed to cure the problem of spaghetti code, but in
hindsight, maccheroni code isn't much fun, either.
Richard
Fredrik Ramsberg
More like Ahem. As Adam pointed out, there's no need to count parenthesis
unless Notepad is the only editor you can imagine working with. A good
Lisp editor will also support auto-indent so it will always be obvious
which constructs are on the same level in the code.
/Fredrik
L. Ross Raszewski
>lrasz...@loyola.edu (L. Ross Raszewski) wrote:
>>Huh. A very long list, which interests me, jsut because I've never
>>found anything odd about any of these. I'll grant that they are
>>something different from C syntax (well, syntax like print (the)
>>.. reminds me of C++ IO manipulators), so perhaps my mistake is that I
>>don't take "conventional" to mean "just like C".
>
> Well, it's not just that. Internally, there's something of an
>inconsistency. Why is it, for example, that "move x to y" is a unique syntax
>construct, "parent(x)" is a built-in function, and "x.short_name" is
a property
x.short_name is something different from what you think it is (it's
not the short name of the object. It overrides the short name of the
object) parent(x), I'll grant you. I don't see anythign stranger about
"move x to y" than "x + y"; granted, it'd be better OO for addition to
be "x.addTo(y)", but still.
>value? The thing is that in TADS most of these things are accomplished via a
>single syntactic structure ("obj.method(args)") where as in Inform there's a
>hodgepodge of dissimilar syntaxes.
>
Okay. This is starting to make sense to me. Inform basically has a lot
more operators. I'm not entirely sure I'd be comfortable with inform
going the TADS route, because there seems to be a lot more confusion
in it about what's what. In inform, a x.y *always* and *only* means
that x is an object, whose property table contains a value named 'y'.
People don't generally use inform properties as operators.
L. Ross Raszewski
>
>I think there is at least some discontent with Inform's syntax; a few people
>have said so. This is only a personal opinion but I think that more
>similarity with C or Pascal syntax might be better. Similarity is a good
>thing not because C (or Pascal) is the perfect language, but because it
>would just be easier for people who already do programming; it probably
>wouldn't matter for people who don't.
>
The same argument could me made for making it closer to basic or java,
of course.
I don't know how many people who already do programming program
exclusively in C or Pascal. I'd imagine that they would be the only
ones who would be particularly better off if the language's syntax was
more C-like.
>Leaving the syntax aside, would it be hard to implement (off the top of my
>head) a hash table or a balanced binary tree in Inform or TADS ?
>
I've had a go at balanced binary trees. It was actually easier to do
in inform than C (I don't recall every writing a balanced binary tree
in C++), simply because the language could maintain a well-founded
object tree on its own.
>General purpose operator overoading would be an overkill IMHO. But the
>immediate problem of string concatenation is better solved (in the context
>of IF) by simply supporting string as a native type.
Well yea. It generally flummoxes these sort of things that inform
makes strings immutables. (Java does this too, of course, but
someone's already written the code to compile a new immutable string
at runtime in Java; no one's every gone to the trouble in inform)
David Thornley
>
>I think that an alternative direction that IF language development
>could have taken would have been to extend existing languages, rather
>than to define entirely new ones. In particular, I'm thinking of
>extending C, C++ or Pascal with adventure-writing primitives, and then
>writing a translator program/preprocessor to translate these
>primitives into C, C++ or Pascal code. (In the case of langauges
>derived from Lisp or Forth, this wouldn't be necessary, since those
>languages are designed to be extensible. C++ is also extensible in a
>more limited way.)
>
that expanded such things as control structure. The first edition of
Kernighan & Plauger's "Software Tools" used it as the base language.
Fortran 77 incorporated a lot of similar ideas, and C looks a lot like
an extension of Ratfor ("rational Fortran").
I'm not really familiar with successful preprocessors like that;
every one I'm familiar with became part of a language, either becoming
some sort of extension to the original or heading off on its own.
I may of course be missing something major and extremely obvious,
and welcome corrections.
>Why didn't this happen? Mostly, I think, because the development
>started when target machines were small, 8-bit micros, too small to
>support full-fledged compilers. But had the first IF wave happened
>ten years earlier or later, we might very well have gone that way.
>
I think that that's when IF had to develop, basically before graphics
became really good. It flourished commercially when computer games
didn't live or die by frame rate and rendering quality.
Anyway, this doesn't apply to modern IF languages, which came along
after computers became more powerful. When I first heard of TADS,
it was available in MS-DOS and Macintosh versions, not CP/M or
Apple II formats. Inform came considerably later. We're talking
about a time period when computers were well able to handle preprocessors
conveniently, about the time C was standardized, and when C++ was
available. People have continued to produce languages, and the only
one I've heard of that is embedded in another language system is
PAWS (again, I'm not omniscient here, or free from error), and Python
is designed to be highly extensible.
So, I think that the problem with Ratfor-like IF preprocessors is
largely a matter of the base language being inconvenient, rather
than a lack of processing power or technical ability.
--
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
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>
>I think a fair bit of this comes out of the fact that C was written by
>a couple of guys. C++, on the other hand, appears to have been written
>by a committee full of guys who sat around sayuing "Y'know what would
>be cool in a language?" (A group of these people much less obsessed
>with contemporary theories in Good Programming Language Design no
>doubt are responsible for Perl, the language which is undoubtedly the
>most full of "stuff that seemed like a good idea at the time")
>
the design of Bjarne Stroustrup, and mostly evolved as he wanted it.
There was a good deal of work in committee, but it was mostly to his
liking. Read "Design and Evolution of C++" to learn about it.
Stroustrup had clear goals and criteria for C++, and the language
is a good implementation of them. (This is certainly not to say that
it doesn't have more than its share of warts.)
>Now, Java feels a lot like it was written by a bunch of erudite
>college professors who knew exactly what a language should be like,
>with a corporate bigwig standing in the corner of the room, weildign a
>firehose.
>
It feels to me like a dumbed-down C++ in many respects, with the authors
concluding that any feature that's confusing in C++ has to be
eliminated.
I tend to see languages as practical vs. academic, and Java rubs me
on the academic side. C++ and Perl and Common Lisp are practical
languages. Java and Pascal and Scheme are academic languages, cleaner
but making me work harder for the same result.
>[ObIF] And when I wanna write IF, it's inform all the way, baybee :-)
>
TADS works well too.
Tzvetan Mikov
> The same argument could me made for making it closer to basic or java,
> of course.
I would put Java in the same bag as C, as it has exactly the same expression
syntax. As for Basic ... let's not go there :-)
> I don't know how many people who already do programming program
> exclusively in C or Pascal. I'd imagine that they would be the only
> ones who would be particularly better off if the language's syntax was
> more C-like.
Adding Java and C# (sharing the same syntax with C/C++), I think that they
covers a significant percentage of the industry (for good or bad). I realize
that this was not so when Inform was created, so my whining is againg purely
theoretical.
> >Leaving the syntax aside, would it be hard to implement (off the top of
my
> >head) a hash table or a balanced binary tree in Inform or TADS ?
> >
>
> I've had a go at balanced binary trees. It was actually easier to do
> in inform than C (I don't recall every writing a balanced binary tree
> in C++), simply because the language could maintain a well-founded
> object tree on its own.
Out of curiousity: how did you do it without dynamic memory; did you use
array indexes to represent the links (which is perfectly fine and actually
more cache friendly)?
> >General purpose operator overoading would be an overkill IMHO. But the
> >immediate problem of string concatenation is better solved (in the
context
> >of IF) by simply supporting string as a native type.
>
> Well yea. It generally flummoxes these sort of things that inform
> makes strings immutables. (Java does this too, of course, but
> someone's already written the code to compile a new immutable string
> at runtime in Java; no one's every gone to the trouble in inform)
Hm. I think immutable strings are a rather good idea. They can be statically
initialized without tricks and their semantics are very clean and ellegant.
Constant strings can be merged at compile time (cases like "abc" + "bcd").
Simple reference counting can take care of any operation at runtime (by
creating a new string for the result of the operation and decreasing the ref
count of the operands); of course that would require some form of simple
dynamic memory management.
-tzvetan
Dan Schmidt
| Okay. This is starting to make sense to me. Inform basically has a lot
| more operators. I'm not entirely sure I'd be comfortable with inform
| going the TADS route, because there seems to be a lot more confusion
| in it about what's what. In inform, a x.y *always* and *only* means
| that x is an object, whose property table contains a value named 'y'.
This is true in TADS as well.
Dan
Magnus Olsson
David Thornley <thor...@visi.com> wrote:
>In article <a5ss5i$f4v$4...@news.lth.se>, Magnus Olsson <m...@df.lth.se> wrote:
>>
>>I think that an alternative direction that IF language development
>>could have taken would have been to extend existing languages, rather
>>than to define entirely new ones. In particular, I'm thinking of
>>extending C, C++ or Pascal with adventure-writing primitives, and then
>>writing a translator program/preprocessor to translate these
>>primitives into C, C++ or Pascal code.
>>
>that expanded such things as control structure.
Yes, that kind of thing is exactly what I had in mind. The min
disadvantage with such a preprocessor is that the code it generates is
in a high-level language that will still have to be compiled for every
platform on which you want to run the game.
>The first edition of
>Kernighan & Plauger's "Software Tools" used it as the base language.
Yes, and IIRC the man page for f77 on at least some Unix systems
say that the compiler can handle Ratfor source, and refer to Kernighan
& Plauger for details.
>Fortran 77 incorporated a lot of similar ideas,
Did it? Compound if statements, but not much else, I think - certainly
not while loops or data structures.
>and C looks a lot like
>an extension of Ratfor ("rational Fortran").
C doesn't count Ratfor among its ancestors, and I think the influence
may actually have gone in the other direction, or perhaps both were
influenced by C's predecessors BCPL and B.
>>Why didn't this happen? Mostly, I think, because the development
>>started when target machines were small, 8-bit micros, too small to
>>support full-fledged compilers. But had the first IF wave happened
>>ten years earlier or later, we might very well have gone that way.
>>
>I think that that's when IF had to develop, basically before graphics
>became really good. It flourished commercially when computer games
>didn't live or die by frame rate and rendering quality.
It could have happened earlier, though; there's no compelling reason
why ADVENT couldn't have been written in the mid 60's rather than
in the mid 70's.
>Anyway, this doesn't apply to modern IF languages, which came along
>after computers became more powerful. When I first heard of TADS,
>it was available in MS-DOS and Macintosh versions, not CP/M or
>Apple II formats. Inform came considerably later.
In the case of Inform, the target platform came first - Graham wrote
it because he liked the idea of writing for the Z-machine. I don't
know about the pre-history of TADS; Mike Roberts posted something
about it starting as a dtabase format, which I interpret as the
platform coming first. And Dave Betz' ADVSYS comes from the world of
interpreted Lisp, where it's also natural to target a VM.
Peter Seebach
David Thornley <thor...@visi.com> wrote:
>This is not a good description of how C++ came about. It was originally
>the design of Bjarne Stroustrup, and mostly evolved as he wanted it.
>There was a good deal of work in committee, but it was mostly to his
>liking. Read "Design and Evolution of C++" to learn about it.
But note that you will find occasional cases where the language as it is today
contradicts what you find. :)
>Stroustrup had clear goals and criteria for C++, and the language
>is a good implementation of them.
I don't think it's possible to evaluate how well it succeeds, because I
wouldn't call the goals and criteria "clear". There's a certain amount of
opinion and point of view to it.
>I tend to see languages as practical vs. academic, and Java rubs me
>on the academic side. C++ and Perl and Common Lisp are practical
>languages. Java and Pascal and Scheme are academic languages, cleaner
>but making me work harder for the same result.
My impression (admittedly, a limited one) is that Java is fairly practical,
it's just a different kind of language than C++. The people I know who do
Java never complain of being unable to achieve basic results, or having
to work too hard - unless they're fighting a particularly bad development
environment.
-s
--
Copyright 2002, 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/
Matthew Russotto
>Stroustrup had clear goals and criteria for C++, and the language
>is a good implementation of them. (This is certainly not to say that
>it doesn't have more than its share of warts.)
I thought his goals were maximization of programming effort and ensuring
continual employment for C++ programmers.
--
Matthew T. Russotto mrus...@speakeasy.net
=====
Dmitry is free, but the DMCA survives. DMCA delenda est!
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
OKB -- not okblacke
>x.short_name is something different from what you think it is (it's
>not the short name of the object. It overrides the short name of the
>object) parent(x), I'll grant you. I don't see anythign stranger about
>"move x to y" than "x + y"; granted, it'd be better OO for addition to
>be "x.addTo(y)", but still.
Okay, pick any property. name, description, whatever. I picked
short_name out of the blue.
>>value? The thing is that in TADS most of these things are accomplished via
>a
>>single syntactic structure ("obj.method(args)") where as in Inform there's a
>>hodgepodge of dissimilar syntaxes.
>>
>
>Okay. This is starting to make sense to me. Inform basically has a lot
>more operators. I'm not entirely sure I'd be comfortable with inform
>going the TADS route, because there seems to be a lot more confusion
>in it about what's what. In inform, a x.y *always* and *only* means
>that x is an object, whose property table contains a value named 'y'.
>People don't generally use inform properties as operators.
Not really, unless you expand your definition of "object" beyond "x such
that metaclass(x) == Object". You can send messages to classes as well, and to
strings and routines. As Dan Schmidt has just posted, the same is true in
TADS, if you use this expanded definition of "object".
Gary Shannon
"Fredrik Ramsberg" <f...@mail.com> wrote in message
news:ab01df60.02030...@posting.google.com...
Ah. But when I learned LISP the only "text editor" was a keypunch machine
and the only source file was a deck of punched cards.
>
> /Fredrik
wo...@one.net
Hi Tzvetan,
>So, then (to be blunt) do you think that PAWS (as a system) is inferior to
>Inform or TADS ?
You actually expect me to say PAWS is inferior? :)
That's a hard question to answer. TADS and Inform definitely have an
edge on PAWS when it comes to the parser--but then again the PAWS
parser is capable of a few unique tricks of its own, such as dealing
with multiple indirect objects (which may or may not matter to anyone
:)).
PAWS uses Python as its language, and Python in my opinion is a nicer
language than TADS or Inform from a syntactic point of view. It's
simpler and more consistant, without a lot of punctuation intended to
make the compiler's job easier at the cost of the programmer's sanity.
Python contains a lot of high-level goodies, from lists to
dictionaries to operators which work intuitively across similar but
different data types. For example, to get the length of a string, a
dictionary, a tuple, or a list you use the same function: len().
Python is OO, has great introspection capabilities, is available on
about as many systems as Inform is (RISC OS and Palms included), and
has tons of libraries included for free. It has cross-platform
graphical capability (which I've deliberately avoided for now), a
built-in library to store the memory image (save/restore with almost
no effort :)), and lots of other tools a full-blown language tends to
have. There's even a graphical debugger, if I could ever find the time
to learn to use it...
As an aside, there's even a version of Python for Visual Studio .Net!
PAWS/Universe the engine/library also does a good job of implementing
most things game authors need: containers, shelves, doors, etc.
Of course both Inform and TADS are far more mature than PAWS, and
their libraries contain extra goodies. Like the clothing in Inform,
for instance. And their maturity has given them an advantage in polish
and refinement. There are even tools like the IF-IDE for Inform.
Oh, and let's not forget Inform's wonderous manual. It really and
truly is exceptional. Graham Nelson has done quite a bit of terrific
writing over the years. I may not be up to his standard, but the PAWS
tutorial isn't bad. (It isn't completely *finished* either, but most
of the important bits are done).
Python as a language choice has a few disadvantages as well. At 5
megabytes for the download it's extremely hefty as a runtime engine.
:) On non-mainstream platforms it can be difficult to configure.
Howsomever. :)
PAWS 1.1 should be available in the next couple of days. It fixes a
few bugs, and makes a major improvement in the ease of creating
classes--the SetMyProperties() function is no longer a mandatory
function, and you no longer have to manually call its ancestor
methods. This ease of use improvement melts one of the ugliest warts
in PAWS.
Which is to say PAWS is improving as I have time to fix things. :)
TADS and Inform have about 8 years head-start, and are well refined
already.
I suspect, for now, PAWS isn't quite the system Inform and TADS are.
But Python's cleaner syntax, and PAWS laser-like focus on ease of use
for new game authors is quite valuable in itself.
So is the careful documentation (and availablily) of every screw,
bolt, nut, and sub-system in PAWS, from the parser to the game loop
logic to the class hierarchy. 70% comments by volume. :)
All in all, PAWS is quite capable. You could certainly implement a
game the size and complexity of Zork or Colossal Cave, for instance.
Thief's Quest (an incomplete sample game in progress) shows some of
PAWS capabilities, especially the ease of full-sensory implementation.
In the end, all I can say is look over the Cloak Of Darkness site. The
PAWS COD version there was written with a beta copy of PAWS so take a
look at version 1.1 (when it becomes available) and the updated COD
that comes with it to judge for yourself.
Some people like C syntax, some like Basic. Python is far more Basic
than C, with some of the best of other languages thrown in. Best of
all, Python is *consistant*, with a limited number of operators, which
makes it easy to learn.
I may be biased, but I think it's an IF-system horse race and PAWS
won't be the last one across the line... :)
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
Tzvetan Mikov
done long time ago) and what can I say ... I must apologize for
wasting everybody's time. It is now obvious to me that it is
impossible to achieve similar functionality in C++ without an enormous
amount of typing (I am not even talking about the library).
Initially I started playing around with macroses, trying to "port" the
Cloak of Darkness (which I could finally understand, having read the
DM4) to C++, as if there was a C++ library. The initial results were
reasonably encouraging - I got something like this to even compile
with a C++ compiler:
Object( foyer, "Foyer of the Opera House" )
with
prop( description )
retprn "You are standing in a spacious hall...";
prop( s_to ) return bar;
prop( w_to ) return cloakroom;
prop( n_to ) retprn "You've only just arrived, and besides...";
has
attr |= light;
EndObject( foyer );
Se
Tzvetan Mikov
was supposed to be:
Seemed good at first, but of course soon after that I came to a dead
end. I just couldn't implement polymorphic properties - there was no
way to check for their existence in an object and keep an intuitive
syntax for accessing them. I realized that it is insane to
try to artificially transplant another language's concepts into C++.
Finally, I must admit that I felt significantly more comfortable with
Inform than I thought I would. It feels pretty neat.
The only thing that worries me is that this domain-specific "neatness"
is may be (just may be) making it harder to create something conceptually
different. Can we say that most games in the last 10 years have been
created using one and the same technology ?
-tzvetan
Magnus Olsson
Tzvetan Mikov <ce...@jupiter.com> wrote:
>The only thing that worries me is that this domain-specific "neatness"
>is may be (just may be) making it harder to create something conceptually
>different. Can we say that most games in the last 10 years have been
>created using one and the same technology ?
This relates to Dennis Jerz's question some time ago about if and how
the library conventions influence game design.
I can only say that while most Inform games fall in the Infocom mold,
at least superficially, there have been a large number of Inform games
that are amazingly creative departures from the conventions. Somebody
reading this can no doubt give a list of examples.
ally
news:a626pf$25l$1...@news.lth.se:
> In article <cP_g8.4067$Hf7....@rwcrnsc51.ops.asp.att.net>,
> Tzvetan Mikov <ce...@jupiter.com> wrote:
>>The only thing that worries me is that this domain-specific "neatness"
>>is may be (just may be) making it harder to create something conceptually
>>different. Can we say that most games in the last 10 years have been
>>created using one and the same technology ?
>
> This relates to Dennis Jerz's question some time ago about if and how
> the library conventions influence game design.
>
> I can only say that while most Inform games fall in the Infocom mold,
> at least superficially, there have been a large number of Inform games
> that are amazingly creative departures from the conventions. Somebody
> reading this can no doubt give a list of examples.
There are a few IF standard library conventions that bother me at times. I
suppose all of them have a great influence on game design, for better or
worse; they don't actually *hurt* the playing experience, but I've been
wondering what could be done to create a richer, more dynamic world model
without devising one-off special case behaviour each time.
One of those conventions is darkness. Light is either "on" or "off", and,
when "off", the game basically stops the player from doing anything at all.
Instead, alternate senses could be used to explore unfamiliar objects until
you get a chance to inspect them by light.
"The dark" needn't neccessarily be an all-swallowing inky blackness either.
There's room for shadowy twilight or some such intermediate stage, altering
room descriptions and obscuring distant scenery (or stuff in adjacent
locations), disabling only a subset of verbs, and only for unfamiliar
objects.
Light never leaves the room its source is in, nor do sounds or smells, nor
is there a way to determine which light source is strongest, or which light
source an actor might use to, say, decipher hieroglyphs, or to scrutinize an
NPC.
Likewise, you can't look through doors, not even across a picket-fence at
your neighbour (say).
Basically, you're trapped in a maze of interconnected one-room universes.
They might include static bits of adjacent "universes" as scenery, but
that's about it, usually, at least from the library's point of view. Or
maybe I'm wrong.
What I am looking for are practical examples, real games that don't feel
like a newbie's coding exercises (aided in part by simpleSense.t, I've dealt
with almost all of the above, under sheltered test-bed conditions and in
various kludgy ways; I'm afraid it still needs a *lot* of fine-tuning, as
well as an *awful* lot of extra text.)
Both "Hunter, In Darkness" and "Aayela" use darkness very effectively. Any
others?
Any games that allow players to interact with (or at least observe) objects-
-actors, especially--in adjacent locations, on a library level?
Does this actually *matter* to anyone else? (I hardly notice it myself when
playing. Is that because I just don't expect it? It's not the be-all, end-
all of good game design, after all.)
Oh, and I believe adv 3 addresses most of those issues to some extent, in, I
am sure, an elegant and thorough fashion --
-- *sigh*,
~ally (craving attention again, mh?)
Magnus Olsson
ally <REMkitz...@gmx.co.uk> wrote:
>There are a few IF standard library conventions that bother me at times.
(...)
>Light never leaves the room its source is in, nor do sounds or smells, nor
>is there a way to determine which light source is strongest, or which light
>source an actor might use to, say, decipher hieroglyphs, or to scrutinize an
>NPC.
>
>Likewise, you can't look through doors, not even across a picket-fence at
>your neighbour (say).
>
>Basically, you're trapped in a maze of interconnected one-room universes.
>They might include static bits of adjacent "universes" as scenery, but
>that's about it, usually, at least from the library's point of view. Or
>maybe I'm wrong.
The WorldClass library puts a lot of effort into "sense passing" that
allows you to implement these sorts of things. I've never played a
game that implemented it, though, or if I did I've forgotten it (which
no doubt says more about me than about the game in that case).
>Both "Hunter, In Darkness" and "Aayela" use darkness very effectively.
Thanks!
Andrew Plotkin
> "The dark" needn't neccessarily be an all-swallowing inky blackness either.
> There's room for shadowy twilight or some such intermediate stage, altering
> room descriptions and obscuring distant scenery (or stuff in adjacent
> locations), disabling only a subset of verbs, and only for unfamiliar
> objects.
I implemented multiple light levels in _Hunter_. Nobody noticed.
This bothered me, until I realized that -- as an author -- *I* hadn't
noticed either. I wrote the library hacks to support it, and then
pretty much forgot about it when I was writing the game.
Many of the descriptions and messages change, but it's hard for the
player to realize this is even going on, much less that it has some
consistent basis.
> Both "Hunter, In Darkness" and "Aayela" use darkness very effectively.
Well, I'm glad the effort wasn't totally wasted. :)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
David Thornley
Gary Shannon <fiz...@starband.net> wrote:
>
>Ah. But when I learned LISP the only "text editor" was a keypunch machine
>and the only source file was a deck of punched cards.
>
an unsuitable editor (like a 026 or 029) is much like the difference
between cutting a tree down with a chainsaw and convincing a live
beaver to do the job for you.
Trust me: most of the pain you went through is completely
unnecessary nowadays.
Hanson
when "off", the game basically stops the player from doing anything at all.
Instead, alternate senses could be used to explore unfamiliar objects until
you get a chance to inspect them by light. >>
One game idea I had involved a character who darkness presented no barrier
to--she had a kind of sense that guided her in the darkness. Sort of a magical
version of echolocation. As a matter of fact, at one time, her goal was to get
rid of all the light sources so she could enjoy an advantage against the NPCs
blundering in the darkness. I put this idea on the back shelf after I realized
it would be quite a bit of work for a newbie programmer. Maybe some time in
the future.
- David Hanson
Daniel Barkalow
> During the time in which I've been lurking in this newsgroup, on numerous
> occasions I've seen the claim that IF languages (Inform, TADS, etc.) are
> much better suited for writing IF than conventional mainstream languages
> (C++, Java, etc.). I've gained the impression that this is a commonly
> accepted and understood fact.
I believe the fundamental issue is that IF is high-content/low-structure,
while most programs are high-structure/low-content. In this way, IF is
similar to documents or configuration files.
Consider writing a paper. You could use a special-purpose language (TeX,
PostScript, etc.), or a conventional language. In the former case, the
syntax is designed around static data. In the latter case, it is designed
around data manipulation. You're likely to want to do some complex data
manipulation (put page and line breaks in sensible places, etc), but
that's largely done by the libraries you'll use, so the difficulty of the
syntax for that sort of thing is irrelevent. You'll probably want to do
some simple data manipulation (put in page references to sections of the
text, section numbers, formatting instructions, etc), so it needs to be
possible to do a bit of that. But almost everything you want to write is
data. Even the data manipulation you do write is either just calling
library functions or is only useful in the one situation you happen to be
in.
Normally what you do what you have a lot of content is to split it into a
separate file, which your program reads. This file contains data and
possibly scripts, which are then interpreted (consider sendmail,
procmail, ghostscript, quake, etc.). Of course, when you do this with IF,
you get the current situation.
Now, Inform isn't ideal; scripting languages have come a long way, and the
syntax isn't very consistent. But it's not a terrible scripting language,
and it isn't a data-manipulation-oriented language, so it is one of the
more suitable languages.
What conventional languages would be suitable for IF? Ones which are
designed to support programmer-specified data. I can think of Python and
LISP. In Python, there's PAWS, and in LISP (Scheme, actually), there is an
MIT CS intro course problem set.
-Iabervon
*This .sig unintentionally changed*
Gary Shannon
"ally" <REMkitz...@gmx.co.uk> wrote in message
news:Xns91C88B1E2A4C...@62.153.159.134...
> On 05 Mrz 2002, m...@df.lth.se (Magnus Olsson) wrote in
> news:a626pf$25l$1...@news.lth.se:
>
> > In article <cP_g8.4067$Hf7....@rwcrnsc51.ops.asp.att.net>,
> > Tzvetan Mikov <ce...@jupiter.com> wrote:
> >>The only thing that worries me is that this domain-specific "neatness"
> >>is may be (just may be) making it harder to create something
conceptually
> >>different. Can we say that most games in the last 10 years have been
> >>created using one and the same technology ?
> >
> > This relates to Dennis Jerz's question some time ago about if and how
> > the library conventions influence game design.
> >
> > I can only say that while most Inform games fall in the Infocom mold,
> > at least superficially, there have been a large number of Inform games
> > that are amazingly creative departures from the conventions. Somebody
> > reading this can no doubt give a list of examples.
>
> There are a few IF standard library conventions that bother me at times. I
When I started my first game I designed the game before I knew anything
about the library I would be using (which turned out to be TADS after trying
ALAN and looking at Inform). I think I can honestly say that my design was
not at all influenced by the library. If I needed something that was
different from the library or not supported by the library I just coded it.
> >
> > This relates to Dennis Jerz's question some time ago about if and how
> > the library conventions influence game design.
> >
<snip>
>
> One of those conventions is darkness. Light is either "on" or "off", and,
> when "off", the game basically stops the player from doing anything at
all.
> Instead, alternate senses could be used to explore unfamiliar objects
until
> you get a chance to inspect them by light.
>
One example: I needed to have rooms that were light enough to see in, but
too
dim to read a note, and other rooms that were bright enough to read in. I
dindn't know the library wouldn't handle taht, but who cares? How hard is
it to put a variable in the room class for level of light? No problem.
<snip>
>
> Any games that allow players to interact with (or at least observe)
objects-
> -actors, especially--in adjacent locations, on a library level?
>
My game only required that you could see a certain NPC coming from the
adjacent room. That was just coded in a function that runs when that NPC is
scheduled to show up.
In real life I code for aeronautical simulations where everything has to be
exactly like it is in real life. In a text adventure I take the approach
that the text can say anything it wants to and give the appearance that
something is happening that is not "really" happening. In other words, the
frog does not have to actually be in the box for the player to be convinced
that the frog is actually in the box. So whatever coding hack works is what
I tend to go for, and to heck with the library conventions.
Andrew Plotkin
> <<One of those conventions is darkness. Light is either "on" or "off", and,
> when "off", the game basically stops the player from doing anything at all.
> Instead, alternate senses could be used to explore unfamiliar objects until
> you get a chance to inspect them by light. >>
> One game idea I had involved a character who darkness presented no barrier
> to--she had a kind of sense that guided her in the darkness.
I've always thought it would be cool to do an IF game in which the
protagonist is blind, but is perfectly competent at dealing with his
life anyway -- the blindness just never becomes an issue. Ideally, the
player doesn't notice he's playing a blind character until the end.
Sure, it'd be a gimmick.
Kevin Forchione
> The only thing that worries me is that this domain-specific "neatness"
> is may be (just may be) making it harder to create something conceptually
> different. Can we say that most games in the last 10 years have been
> created using one and the same technology ?
Well... that's debatable. IF languages have evolved over the past
decade. Libraries have changed, extensions have been devised to
explore various aspects of game play, from sense-passing to
text-morphing, etc.
The technology is driven mainly by the players, and what they expect
of an IF game. It's also driven by the authors, by what they want to
write in terms of artistic creation. There is some small contribution
by library extension authors, such as myself, but only in so far as
these fall within the service of the author.
Major changes occur from time to time, as witnessed by Gluxl Inform,
the Inform Platypus library, TADS 3, PAWS.
I shouldn't be too concerned about technology, in IF it's less subject
to fads, and more practically-driven.
--Kevin
Gary Shannon
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:a6439l$sbs$1...@reader1.panix.com...
> Hanson <runm...@aol.comnospam> wrote:
> > <<One of those conventions is darkness. Light is either "on" or "off",
and,
> > when "off", the game basically stops the player from doing anything at
all.
> > Instead, alternate senses could be used to explore unfamiliar objects
until
> > you get a chance to inspect them by light. >>
>
> > One game idea I had involved a character who darkness presented no
barrier
> > to--she had a kind of sense that guided her in the darkness.
>
> I've always thought it would be cool to do an IF game in which the
> protagonist is blind, but is perfectly competent at dealing with his
> life anyway -- the blindness just never becomes an issue. Ideally, the
> player doesn't notice he's playing a blind character until the end.
>
> Sure, it'd be a gimmick.
Or you could give it away right at the beginning with your room
descriptions:
You are in what sounds like a large, empty room. You hear running water
coming from the north and the sound of hushed voices and clikcing dishes
from the east. Somewhere in the distance a dog is barking.
--gary
Fredrik Ramsberg
> > <<One of those conventions is darkness. Light is either "on" or "off", and,
> > when "off", the game basically stops the player from doing anything at all.
> > Instead, alternate senses could be used to explore unfamiliar objects until
> > you get a chance to inspect them by light. >>
>
> > One game idea I had involved a character who darkness presented no barrier
> > to--she had a kind of sense that guided her in the darkness.
>
> I've always thought it would be cool to do an IF game in which the
> protagonist is blind, but is perfectly competent at dealing with his
> life anyway -- the blindness just never becomes an issue. Ideally, the
> player doesn't notice he's playing a blind character until the end.
Well, if the game was set in complete darkness, you could perhaps get
away with it. Otherwise, wouldn't the descriptions have to give the
twist away? Unless you write descriptions like those used by Poet in
Suspended, obscure enough to conceal by what sense the impressions
have been acquired. In real life, I would expect blind people to
be *much* better at navigating and understanding their environment in
darkness than seeing people.
*VERY MILD SPOILER FOR VACATION GONE AWRY*
While betatesting Vacation Gone Awry, our most hard working tester, Michael
Gerwat, had a hard time solving a certain puzzle because he's blind.
To solve the puzzle in question, you have to understand that two objects are
similar. The descriptions don't say so, but anyone who has seen such objects
in real life knows they are visually similar. To people who have always been
blind though, these objects must seem very different.
Until Michael ran into trouble, we had no idea our game was based on the
assumption that the players can see. We discussed what to do about it,
but figured that changing the descriptions would make the problem too easy
or maybe even look ridiculous.
This is at least something to be aware of in game design. Seeing impaired
people is not an unimportant part of your audience.
/Fredrik
Rikard Peterson
news:Xns91C88B1E2A4C...@62.153.159.134...
>
> Both "Hunter, In Darkness" and "Aayela" use darkness very
> effectively. Any others?
I like the (easy) darkness puzzle in Augmented Fourth.
Rikard
David Thornley
>is may be (just may be) making it harder to create something conceptually
>different. Can we say that most games in the last 10 years have been
>created using one and the same technology ?
>
Three" is TADS, and Dave Baggett came out with a replacement library
(World Class) that did some things a lot differently. Since then,
there have been lots of snippets of code to do different things.
Inform, of course, came with a different library, and again people
have done things to it, or even replaced it. Currently, people are
doing very interesting things in Inform to replace the standard
ASK/TELL conversation interface.
I assume that Hugo has such libraries, although I doubt there's been
nearly the independent hacking at it.
So, aside from the fact that most IF is done nowadays in languages
that resemble hybrids between C and something declarative, I don't
see that people are using the same technology.
Andrew Plotkin
> Andrew Plotkin <erky...@eblong.com> wrote in message news:<a6439l$sbs$1...@reader1.panix.com>...
>> Hanson <runm...@aol.comnospam> wrote:
>> > <<One of those conventions is darkness. Light is either "on" or "off", and,
>> > when "off", the game basically stops the player from doing anything at all.
>> > Instead, alternate senses could be used to explore unfamiliar objects until
>> > you get a chance to inspect them by light. >>
>>
>> > One game idea I had involved a character who darkness presented no barrier
>> > to--she had a kind of sense that guided her in the darkness.
>>
>> I've always thought it would be cool to do an IF game in which the
>> protagonist is blind, but is perfectly competent at dealing with his
>> life anyway -- the blindness just never becomes an issue. Ideally, the
>> player doesn't notice he's playing a blind character until the end.
> Well, if the game was set in complete darkness, you could perhaps get
> away with it. Otherwise, wouldn't the descriptions have to give the
> twist away?
I don't know. That's why it would be cool, if you could do it.
I'd rely heavily on the familiar environment, and the protagonist's
assumed knowledge of it. When the game says "The living room is to the
north", it doesn't have to say whether you can see it or you just know
it's there.
Once you move into an unfamiliar location, it gets a lot trickier.
Peter Seebach
Fredrik Ramsberg <f...@mail.com> wrote:
>Well, if the game was set in complete darkness, you could perhaps get
>away with it. Otherwise, wouldn't the descriptions have to give the
>twist away?
Hmm. If you *know* the environment, no surprise; you can describe things
because the character *KNOWS* them, and interleave that with additional
sensory data. Like so:
Bedroom
You are in your bedroom. The sun's warmth beats down on you through the
southern window. Your cat is here (sleeping on the bed). The door to the
north is open, and you can hear the fishtank splashing in the next room;
perhaps it's time to refill the tank.
> examine cat
The cat has rolled over in his sleep to find the exact geometric center of the
sunbeam. He appears to be asleep.
> n
Gaming room
You are in the gaming room. The fishtank is splashing; you should top it off
when you have time. Last night's pizza boxes are still out on the table,
smelling faintly of pepperoni. Another cat is here, washing herself quietly.
> examine cat
She's licking herself, and chewing on her claws with a distinctive clicking
sound. If a string were to be dangled near her, bloodshed would ensue.
> examine pizza
There's still a slice left! Cold pepperoni, no less.
> take pizza
You have a slice of pepperoni pizza.
> examine it
Cold, a little greasy, and probably thoroughly inedible; it smells delicious.
Daniel Barkalow
I've implemented a bit of library code to allow rooms to have descriptions
when they are dark, and to have some objects be mentioned and in scope in
the dark. It wasn't too hard. I didn't put objects which you'd dropped or
seen in scope, although I think that's a DM exercise.
> Light never leaves the room its source is in, nor do sounds or smells, nor
> is there a way to determine which light source is strongest, or which light
> source an actor might use to, say, decipher hieroglyphs, or to scrutinize an
> NPC.
>
> Likewise, you can't look through doors, not even across a picket-fence at
> your neighbour (say).
Locale() is not nearly as well used as I'd like. You can actually do
descriptions of the contents of other rooms as if you were there. Of
course, you want the description of the room to reflect that you're at a
different angle. But it is quite possible to have a three-location room,
with items at the other end in scope and described (as being at the
other end) but not accessible.
> What I am looking for are practical examples, real games that don't feel
> like a newbie's coding exercises (aided in part by simpleSense.t, I've dealt
> with almost all of the above, under sheltered test-bed conditions and in
> various kludgy ways; I'm afraid it still needs a *lot* of fine-tuning, as
> well as an *awful* lot of extra text.)
If I ever got a game written, it would probably feature "look north",
multiple location rooms, and at least some "partial" darkness. Having
light flow from room to room isn't something I've thought much about,
because I don't usually think about portable light sources you might
leave behind or lots of rooms with switchable lights.
I don't think there's necessarily that much more text you have to
write. It's mostly moving the text you want to write. You've presumably
written a response to "listen" in the dark room; just put it in the room's
darkness description, too. The dynamic description of another room is
mostly the same as the dynamic description in the room, except that
"... here." is replaced with "... there."
> Both "Hunter, In Darkness" and "Aayela" use darkness very effectively. Any
> others?
>
> Any games that allow players to interact with (or at least observe) objects-
> -actors, especially--in adjacent locations, on a library level?
>
> Does this actually *matter* to anyone else? (I hardly notice it myself when
> playing. Is that because I just don't expect it? It's not the be-all, end-
> all of good game design, after all.)
It bothers me when I'm in one location from which I should be able to see
other locations and I can't. Particularly if going to the location is
dangerous, but that fact is not evident despite the danger being logically
visible from a safe distance. Jigsaw annoyed me that way pretty
frequently, but games have generally gotten better about that since.
Sean T Barrett
to Peter's message but is meant as a reply to the thread in general:
Peter Seebach <se...@plethora.net> wrote:
>> N
>Gaming room
>You are in the gaming room. The fishtank is splashing; you should top it off
>when you have time. Last night's pizza boxes are still out on the table,
>smelling faintly of pepperoni. Another cat is here, washing herself quietly.
>
>> TAKE PIZZA
>You have a slice of pepperoni pizza.
>
>> EXAMINE IT
>Cold, a little greasy, and probably thoroughly inedible; it smells delicious.
All well and good until the player types
>> LOOK
at which point it will be difficult to keep the cat in the bag.
Responding to 'LOOK' with a room description is dishonest, and
disallowing 'LOOK' is going to be a dead giveaway, unless you
can come up with some OTHER reason to disable LOOK.
Two ways around it: write a lipogrammatic or other word-game-y
sort of game, like Ad Verbum, and set up the rules so that LOOK
is not a legal command; or set up the display with a 'room
description window' in which the room description is always
displayed, so there is never a need to type 'LOOK'.
SeanB
Keith A. Marrocco
>All well and good until the player types
>
>>> LOOK
>
>at which point it will be difficult to keep the cat in the bag.
>Responding to 'LOOK' with a room description is dishonest, and
>disallowing 'LOOK' is going to be a dead giveaway, unless you
>can come up with some OTHER reason to disable LOOK.
You see nothing unusual.
K.
---
Keith A. Marrocco - Computing and Information Services
Texas A&M University - (979) 845-1037 - http://lt.tamu.edu/~keith/
Co-Advisor - Society of Mexican American Engineers and Scientists
Advisor - Sigma Lambda Beta Fraternity
--
Keith A. Marrocco - Computing and Information Services
Texas A&M University - (979) 845-1037 - http://lt.tamu.edu/~keith/
Co-Advisor - Society of Mexican American Engineers and Scientists
Advisor - Sigma Lambda Beta Fraternity
Matthew Russotto
Andrew Plotkin <erky...@eblong.com> wrote:
>
>> Well, if the game was set in complete darkness, you could perhaps get
>> away with it. Otherwise, wouldn't the descriptions have to give the
>> twist away?
>
>I don't know. That's why it would be cool, if you could do it.
My thought is you would set the game in complete darkness -- but only
from the viewpoint of the protagonist. He could find a light switch,
for instance, flip it, and nothing would apparently happen. Unless as a
reward for a very stubborn player you made the light accessible and he
can find out it is warm.
ally
news:u8dorqt...@corp.supernews.com:
> In article <a65ke3$hg8$2...@reader1.panix.com>,
> Andrew Plotkin <erky...@eblong.com> wrote:
>>
>>> Well, if the game was set in complete darkness, you could perhaps get
>>> away with it. Otherwise, wouldn't the descriptions have to give the
>>> twist away?
>>
>>I don't know. That's why it would be cool, if you could do it.
>
> My thought is you would set the game in complete darkness -- but only
> from the viewpoint of the protagonist. He could find a light switch,
> for instance, flip it, and nothing would apparently happen. Unless as a
> reward for a very stubborn player you made the light accessible and he
> can find out it is warm.
Please keep debating blind protagonists, it's interesting *gryn*
My Project #1 first cast the player as canine*, then feline* in the endgame.
Both would know how to get along even in complete darkness, albeit in
different (yet overlapping) ways. I might already have much of the code for
a blind protagonist, but I think I'd feel uneasy about it. After all, I have
no idea what it's like to actually *be* blind. (A point could be made that I
have no idea what it's like to be canine either, or some of the other things
I sometimes feel like writing about, but, hm.)
Project #2 had a "negative" light source that would make the room go even
darker (yet not completely dark). Er, never mind. Still: A protagonist who
would notice certain things, or properties of things, only in the dark...
hm. Intrigues me, at least at 5:23 AM.
Re: blindness, and flipping light switches--it might be a great opportunity
for the game to surprise the player (who presumably wasn't aware the
protagonist hasn't been using sight). Or have an NPC walk in, complain about
the darkness, turn on the light.
No idea what to do about LOOK AROUND/AT/IN/UNDER/ON/BEHIND, though... Mh.
~ally
* -ish
--
"It is bone-deep with her, though buried and frozen."
ally
> The WorldClass library puts a lot of effort into "sense passing" that
> allows you to implement these sorts of things. I've never played a
> game that implemented it, though, or if I did I've forgotten it (which
> no doubt says more about me than about the game in that case).
"[Wormhole: The Beginning] includes portions of WorldClass, [...]" -- I
never played it, though. Which no doubt says more about me than... :)
~ally
Peter Seebach
Sean T Barrett <buz...@TheWorld.com> wrote:
>>> LOOK
>at which point it will be difficult to keep the cat in the bag.
>Responding to 'LOOK' with a room description is dishonest, and
>disallowing 'LOOK' is going to be a dead giveaway, unless you
>can come up with some OTHER reason to disable LOOK.
Why? Blind people can refer to "looking around for something". The
word *normally* implies visual data, but doesn't require it.
I expect "look" to duplicate the original description; I have no expectation
that it will specifically use my eyes unless I'm running Iris.
-s
ally
news:_2gh8.2892$0r2.107...@twister2.starband.net:
> When I started my first game I designed the game before I knew anything
> about the library I would be using (which turned out to be TADS after
> trying ALAN and looking at Inform). I think I can honestly say that my
> design was not at all influenced by the library. If I needed something
> that was different from the library or not supported by the library I
> just coded it.
I presume your objects still don't have temperature properties, your
containers don't know whether they're airtight, and none of your NPCs will
grow older and, eventually, die in case the player takes forever :)
--Right, your game/story probably doesn't *need* any of that, and if it did,
you could code it--but not doing it means you silently accept (or tolerate)
the existing conventions, which thus creep into your game design through the
backdoor.
Well, "game design". I was probably thinking of it as the result, the "sum",
rather than the author's active contributions.
Anyway, I believe that if elaborate sense-passing (say) was a part of all
the major authoring systems' default libraries, and well-documented as well-
-it'd play a more important role in many games than it does now. I mean,
text adventures "happen" in separate rooms since day one, and every default
library perpetuates this model (that wasn't a complaint)
>> One of those conventions is darkness. Light is either "on" or "off",
>> and, when "off", the game basically stops the player from doing anything
>> at all. Instead, alternate senses could be used to explore unfamiliar
>> objects until you get a chance to inspect them by light.
>>
>
> One example: I needed to have rooms that were light enough to see in, but
> too
> dim to read a note, and other rooms that were bright enough to read in.
> I dindn't know the library wouldn't handle taht, but who cares? How hard
> is it to put a variable in the room class for level of light? No
> problem.
No problem if you keep a firm authorial grip on the situation. We seem to be
dealing with this in totally different manners. I want all of that and more
to "happen" consistently, automagically, and throughout the entire game, no
matter if I foresaw a particular constellation of objects, light sources and
locations or not.
(Aye, I'm obsessed with that, and fuss too much.
What if the player decides to open the curtains and wait for the sun to
rise? (The sun would of course be a floating lightsource.)
What if the fact that room r1 is dark prevents the player from looking at
object o in the neighbouring room r2, which is dimly lit--illuminating
object o, but not room r1, which therefore believes it's got a right to
disable "look"?
What about vocabulary and short descriptions--shouldn't you keep the player,
in darkness from refering to that newly discovered piece of cloth as the
royal hooded wedding sweater until there's light enough to identify the
thing?
And so on, until you start pondering mirrors, infravision, echolocation and
spontaneous self-combustion :)
>> Any games that allow players to interact with (or at least observe)
>> objects- -actors, especially--in adjacent locations, on a library
>> level?
>>
>
> My game only required that you could see a certain NPC coming from the
> adjacent room. That was just coded in a function that runs when that NPC
> is scheduled to show up.
>
> In real life I code for aeronautical simulations where everything has to
> be exactly like it is in real life. In a text adventure I take the
> approach that the text can say anything it wants to and give the
> appearance that something is happening that is not "really" happening.
> In other words, the frog does not have to actually be in the box for the
> player to be convinced that the frog is actually in the box. So whatever
> coding hack works is what I tend to go for, and to heck with the library
> conventions.
That does make sense. I'd rather change the conventions (by modifying the
library) than work around them, but then I don't have to deal with
programming (or simulations) outside of IF, and am slow with the actual
game-writing due to the language barrier (my vocabulary just isn't big
enough.)
~ally
Magnus Olsson
ally <REMkitz...@gmx.co.uk> wrote:
>am slow with the actual
>game-writing due to the language barrier (my vocabulary just isn't big
>enough.)
What langauge barrier? I haven't seen any signs of a too-small vocabulary
in your Usenet posts...
Granted, the vocabulary needed to write fiction (including int-fiction)
is different from that needed to discuss programming and game design -
but I wonder (in general, not just in your case) what kind of vocabulary
is needed for IF.
Fredrik Ramsberg
> Ewwww. The difference between using Lisp with a suitable editor versus
> an unsuitable editor (like a 026 or 029) is much like the difference
> between cutting a tree down with a chainsaw and convincing a live
> beaver to do the job for you.
I'd say editing Lisp with an unsuitable editor is more like cutting down
a live beaver with a chainsaw; terribly messy, not very satisfying and
usually unnecessary.
/Fredrik
ally
news:a67cab$b0s$1...@news.lth.se:
> In article <Xns91CA414125B6...@62.153.159.134>,
> ally <REMkitz...@gmx.co.uk> wrote:
>>am slow with the actual
>>game-writing due to the language barrier (my vocabulary just isn't big
>>enough.)
>
> What langauge barrier? I haven't seen any signs of a too-small
> vocabulary in your Usenet posts...
Whenever I want to write dialogue, or describe architecture, gestures,
facial expressions, or fashion or a dance, or an archaic machine or
vegetation, I start to feel insecure (even in German, at times.) Knowing
"unwinnable", "foobar" and "language barrier" doesn't help :)
> Granted, the vocabulary needed to write fiction (including int-fiction)
> is different from that needed to discuss programming and game design -
> but I wonder (in general, not just in your case) what kind of
> vocabulary is needed for IF.
Different for each game or genre, no? Best Of Three, Planetfall, ...--all
different. And you will usually want to express yourself un-awkwardly, so a
large active vocabulary isn't all there is to it.
Maybe I'll have to raise a small militia of highly literate native speakers
somehow.
~ally
Ferlin Scarborough
"Peter Seebach" <se...@plethora.net> wrote in message
news:3c86f3e3$0$79561$3c09...@news.plethora.net...
> In article <GsKMD...@world.std.com>,
> Sean T Barrett <buz...@TheWorld.com> wrote:
> >>> LOOK
>
> >at which point it will be difficult to keep the cat in the bag.
> >Responding to 'LOOK' with a room description is dishonest, and
> >disallowing 'LOOK' is going to be a dead giveaway, unless you
> >can come up with some OTHER reason to disable LOOK.
>
> Why? Blind people can refer to "looking around for something". The
> word *normally* implies visual data, but doesn't require it.
>
except for him. (Called them selves the Night Hawks). For several years I
traveled around different places with them when they played.
When they talked to each other, I remember I used to get a kick out of it,
because the would say things like "I SAW a great movie on TV last night", or
when they were listening to Audio Books they would say "I READ so and so
book this weekend."
Thus said, the limitations shouldn't be too restricted with a little thought
put into the prose.
Later all,
Ferlin.
David Thornley
cutting down a tree with a dead beaver.
Magnus Olsson
ally <REMkitz...@gmx.co.uk> wrote:
>On 07 Mrz 2002, m...@df.lth.se (Magnus Olsson) wrote in
>news:a67cab$b0s$1...@news.lth.se:
>> In article <Xns91CA414125B6...@62.153.159.134>,
>> ally <REMkitz...@gmx.co.uk> wrote:
>>>am slow with the actual
>>>game-writing due to the language barrier (my vocabulary just isn't big
>>>enough.)
>>
>> What langauge barrier? I haven't seen any signs of a too-small
>> vocabulary in your Usenet posts...
>
>Whenever I want to write dialogue, or describe architecture, gestures,
>facial expressions, or fashion or a dance, or an archaic machine or
>vegetation, I start to feel insecure
Finding the right word is always difficult, and having a large
vocabulary doesn't necessarily help. I have the same problem when I'm
writing in Swedish.
> (even in German, at times.)
Oh, so you're German? It's impossible to tell from your posts here.
>Knowing
>"unwinnable", "foobar" and "language barrier" doesn't help :)
Depends on what kind of game you're writing, I suppose :-).
But what can I say? The dictionary is your friend, of course. Be more
wary of the thesaurus, since it often lists near-synonyms rather than
exact synonyms. And read lots of books.
>Maybe I'll have to raise a small militia of highly literate native speakers
>somehow.
One suggestion could be to write the game as well as you can, possibly
marking places where you aren't sure that you've picked the right word,
and then let your highly literate native speakers loose on it.
Sean T Barrett
>Sean T Barrett <buz...@TheWorld.com> wrote:
>>Responding to 'LOOK' with a room description is dishonest, and
>>disallowing 'LOOK' is going to be a dead giveaway, unless you
>>can come up with some OTHER reason to disable LOOK.
>
>Why? Blind people can refer to "looking around for something". The
>word *normally* implies visual data, but doesn't require it.
"Look for" is an idiom. If I were in a pitch black room,
and somebody told me to "look around for a flashlight",
I wouldn't bat an eye; but if somebody put on a Pink Floyd
album in a pitch-black room and told me to "look closely",
I would think he was high--or that he thought I was.
If a magician said "I'm going to do a trick, everyone close
your eyes", then makes a bunch of weird noises, and then says
"watch carefully", everyone in the audience is going to
open their eyes, not interpret it as "listen carefully."
I think players are used to "LOOK" meaning "produce a room
description by any sense means available", but I don't think
the word means that in conventional English, and I think if
you wanted to do something like the blind-player-game-twist
right you have to confront what the English is actually saying.
("LOOK AT" is also problematic.) To do otherwise is to risk
players saying "well, that was an ok gimmick, but it was really
misleading to allow 'look', effectively cheating"; I certainly
know of one player who will react this way.
"EXAMINE" is marvelously sense-neutral; it's just unfortunate
historical baggage that the "EXAMINE THE ROOM" command everyone
uses explicitly names the visual sense. The inconsistency between
the meaning of "LOOK" vs. "LISTEN" is actually something of a
real issue in next generation libraries that handle senses
more robustly.
If I called a blind person on the phone and said, "Look around
your apartment and tell me what you see", they might infer what
they think I really mean, and go ahead and recite from memory
or acquire the info through other senses, but they'd be "playing
along" with me--after the third or fourth time I said something
like this they might get frustrated and say "you do know I'm
blind, don't you", unless they perhaps decided to keep playing
along to prove a point or teach me a lesson. But the relation
between player and PC is normally tighter than that and shouldn't
involve such "playing along", with the PC willfully misinterpreting
commands to keep from spoiling the surprise twist--not unless you
want to decouple the PC and player explicitly, along the lines of
FailSafe.
Sean
Jason Etheridge
[examining the room]
Here is a seemingly typical room description.