Best for New Author
crow...@gmail.com
topic-I tried searching and couldn't find any, but I may not have been
doing it well.
For years, I've had an idea for a game bouncing around in my head, but
have been somewhat turned off from the idea of writing it by the fact
that I'm not actually a programmer or anysuch, and the last time I
wrote any kind of program, it was decades ago in BASIC. But after the
last Comp, I've decided that I may as well get up and out there, or I
never will-also, some comments on rec.games.int-fiction suggested that
some innovations make things easier. Inform 7 was specifically
mentioned, as I believe another that I cannot recall.
My question to you is thus: which is best to begin with? I suffer from
the handicaps of being both code-challenged and also a fairly ambitious
storyteller. Thus, something which is easy to begin with, but also has
the capability for doing everything I'll want to do with it later would
be ideal. (I'm particularly interested in making NPCs whose options
change according to things you have done in the game previous, and
where you can make their responses be different according to what has
gone before as well, though this is a for-later goal). If one of the
two has to suffer, I'd prefer that the ease-of-code take a hit, because
I don't want to learn how to write the whole thing up only to learn
that my ultimate goal is unreachable. However, if anyone has any
reasons why that's not a good idea to try so much, I'm willing to
listen to those as well.
Appreciate any aid you can provide,
-S.
Jim Aikin
> the handicaps of being both code-challenged and also a fairly ambitious
> storyteller.
All of the major languages are good -- it sort of comes down to questions of
what style of code you're comfortable with. You might want to download
several and have a look.
Inform 7 is reputed to have a gentle learning curve. Inform 6 is more of a
"classic" computer programming model, but not difficult and with many nice
tools. TADS 3 has lots of code tools that are designed to get you up and
running quickly, but my impression is that you'll need to memorize how to
use the tools.
> (I'm particularly interested in making NPCs whose options
> change according to things you have done in the game previous, and
> where you can make their responses be different according to what has
> gone before as well, though this is a for-later goal).
Inform 6 does that. It's a piece of cake. I do it all the time. I'll let
others address the ease or difficulty in other languages, but I can't
imagine it would be difficult.
--Jim Aikin
James Mitchelhill
<snip>
> My question to you is thus: which is best to begin with? I suffer from
> the handicaps of being both code-challenged and also a fairly ambitious
> storyteller. Thus, something which is easy to begin with, but also has
> the capability for doing everything I'll want to do with it later would
> be ideal. (I'm particularly interested in making NPCs whose options
> change according to things you have done in the game previous, and
> where you can make their responses be different according to what has
> gone before as well, though this is a for-later goal). If one of the
> two has to suffer, I'd prefer that the ease-of-code take a hit, because
> I don't want to learn how to write the whole thing up only to learn
> that my ultimate goal is unreachable. However, if anyone has any
> reasons why that's not a good idea to try so much, I'm willing to
> listen to those as well.
I'm going to suggest something a little different to the usual responses to
this kind of question. Whatever language you choose (and I'd imagine your
eventual choice will be between I7 and TADS3), you'll reach a point where
something you want to acheive is beyond your ability to code it.
I7 undoubtedly has a gentler learning curve for non-programmers, but I
suspect that above a certain amount of complexity, TADS3 will beat I7 for
ease of implementation.
Anyway, my suggestion is that you learn to program first.
This might sound back to front - after all you'll be learning to code as
you go along. The trouble is that IF languages are fairly bad languages to
learn programming with. You'll be using libraries and world models that
make things much easier for you. Most of the time when writing IF you won't
be doing much real coding at all. You'll be filling in text and
constructing some basic logic to switch what text is displayed. Which means
it'll come as something of a shock when you reach the point where the
documentation doesn't tell you all that you need to know about how things
work.
Because at that point, you'll have to delve into the actual workings of the
library and your head will explode. The simplicity and power that IF
languages strive to present is produced with some very scary complexity
behind the scenes. At some point, if your goals are ambitious, you'll have
to unravel and understand some of that complexity.
Approaching this from a basic understanding of whatever IF language you've
chosen will hurt a lot more than if you approach it with a reasonable
understanding of programming.
I'd suggest Python as a good introduction to programming.
<http://www.python.org>. There's some gentle introductions here:
<http://wiki.python.org/moin/BeginnersGuide/NonProgrammers>.
Programming isn't difficult. If it was, a lot of programmers wouldn't be
able to do it. I'm not suggesting you spend a long time learning to
program, but a couple of weeks, maybe even a month would be a huge asset
when you come to write your IF. The actual details of IF languages differ
from Python and other mainstream languages, but the techniques, good habits
and ways of thinking you'll pick up will help a lot when you reach the edge
of your understanding. And it'll probably make it easier to learn an IF
language in the first place.
--
James Mitchelhill
ja...@disorderfeed.net
http://disorderfeed.net
Danny Semmel
you, and with roughly the same background in writing BASIC back during
the heyday of the Commodore 64. Having researched the matter, I opted
for Inform 7. I like the layout and ease of use, plus if there is
truly something really complex going on I need to know how to do, I
just post here and James Mitchelhill does the programming for me. :)
Or Eric or Emily or Andrew or Graham or someone else. I've spent my
entire life working in the Navy, or for the government or in big
business, and I'm not so arrogant as to think I can do it all myself.
World of Warcraft took 40,000 people to create. The adventure game
"The Longest Journey" took dozens, if not hundreds of people. I'm a
writer and a roleplayer. What I bring to the table is my singular and
unique vision of what I want to do. If the code is buggy.. pfft.
That's what Tuesday patches are for. :)
Jim Aikin
This is probably good advice ... but of course, programming is fiddly stuff,
and most people find it easier to devote endless hours to learning fiddly
stuff if they can clearly see a goal toward which they're working.
With that in mind, I'll suggest that Inform 6 would be a good compromise. It
_is_ programming, in a visible way. Inform 7 strives to create the illusion
that it isn't programming, which may prove confusing, or at least won't help
you get in sync with the above advice. TADS 3 has almost the opposite
problem -- it's so chock-full of macros and classes that you'll spend most
of your time writing declarations rather than writing actual code.
--JA
James Mitchelhill
> I'm brand-new to the world of creating interactive fiction, same as
> you, and with roughly the same background in writing BASIC back during
> the heyday of the Commodore 64. Having researched the matter, I opted
> for Inform 7. I like the layout and ease of use, plus if there is
> truly something really complex going on I need to know how to do, I
> just post here and James Mitchelhill does the programming for me. :)
Heh. I wish I was confident enough with my coding abilities to write code
for other people. I leave that to people who've actually released games in
the last five years.
James Mitchelhill
>> Anyway, my suggestion is that you learn to program first.
>
> This is probably good advice ... but of course, programming is fiddly stuff,
> and most people find it easier to devote endless hours to learning fiddly
> stuff if they can clearly see a goal toward which they're working.
This is true. I think Python mitigates this somewhat, since it's possible
for novices to start producing useful code very quickly. It's also very
useful for quick-and-dirty scripts and anyone who uses a computer much has
something that'd be made easier by writing a couple.
(I speak from experience - Python was the first language I ever tried to
learn. I had a little experience with BASIC and cut-and-paste javascript,
but not much else. Within a couple of hours I was able to write some kind
of very basic file renaming utility. It was a revelation. Suddenly I was a
programmer!)
> With that in mind, I'll suggest that Inform 6 would be a good compromise. It
> _is_ programming, in a visible way. Inform 7 strives to create the illusion
> that it isn't programming, which may prove confusing, or at least won't help
> you get in sync with the above advice. TADS 3 has almost the opposite
> problem -- it's so chock-full of macros and classes that you'll spend most
> of your time writing declarations rather than writing actual code.
I'm rather prejudiced against Inform 6. It just looks ugly as hell to me.
Then again, TADS3 is *scary* once you get past all the macros and classes
and look at the actual libraries.
ChicagoDave
> My question to you is thus: which is best to begin with?
At one time I would have suggested choosing a platform to begin your IF
endeavors. Not to say that this isn't a perfectly acceptable approach,
but I think something else might be better for people new to IF
entirely.
Understanding what IF is first might be a better approach. You may want
to pick up Nick Montofrt's "Twisty Little Passages" book and read
through it. You may also want to read some of the excellent essays
written by Emily Short, Stephen Granade, Graham Nelson, smong others in
the IF Community. You can find links to many of these articles through
the IFWiki.Org website maintained by David Welbourn and hosted by Carl
Muckenhoupt.
The next thing to consider might be your personal stengths. Are you a
writer or a programmer by nature? Or neither? Or both?
If you're a writer, you may want to play a few of the more popular or
"highly regarded" IF works with your writer or programmer's "hat" on. I
compare this to picking up books that do things you like (as a writer)
and really dissecting them. Take notes. Try to observe those elements
of IF that you think work well.
If you're a programmer, you might want to download source code from the
IF Archive (http://www.ifarchive.org) and scour through it for examples
of how things are implemented. You might do this while playing the
game, learning as you go. Take notes.
Once you have an idea of how IF is constructed, then I suggest you
dabble with Inform 7, not as a final platform to do your work, but as a
sort of prototyping tool. Put together a map of locations. Write
different kinds of room descriptions. Create objects that can be
carried around.
Then I would pick a story you like...a small story...and try to
implement it thoroughly. When I say small story I mean it. Only 5 or 10
locations, a few objects, one puzzle, and one punch-line. Work through
it until its perfect. This will give you an idea of what it takes to do
bigger work.
At this point, we can discuss bigger works, which I will do in a
subsequent post.
David C.
crow...@gmail.com
ChicagoDave wrote:
> At one time I would have suggested choosing a platform to begin your IF
> endeavors. Not to say that this isn't a perfectly acceptable approach,
> but I think something else might be better for people new to IF
> entirely.
Let me clarify: I am far from new to IF entirely. I simply haven't
actually created a game of my own yet. I've done betatesting of other
people's games, I've checked out the Comp for almost as long as there
has been a comp, etc. I know roughly, I think what types of things need
to go into games, etc. That's probably the reason why I have such high
standards-I want to write, but I don't want to be the next Paul Panks.
Therefore, I see no real reason to do something if I'm not going to do
it well.
Neil Cerutti
I think you should start by copying some source code verbatim
from a tutorial, and getting it to compile and run. In my
experience, mastering the cycle of
edit->save->compile->run->repeat can be an enormous challenge if
you've never programmed (I speak from experience here). The
greatest advantage of Inform 7 is its elegant IDE, which renders
the above process totally transparent, and doesn't burden
you with needless choices.
But do take the trouble of getting TADS, Hugo or Inform 6 to
work. Whatever pain you go through will be repaid handsomely.
--
Neil Cerutti
Danny Semmel
crow...@gmail.com wrote:
> ChicagoDave wrote:
>
> > At one time I would have suggested choosing a platform to begin your IF
> > endeavors. Not to say that this isn't a perfectly acceptable approach,
> > but I think something else might be better for people new to IF
> > entirely.
>
> Let me clarify: I am far from new to IF entirely. I simply haven't
> actually created a game of my own yet. I've done betatesting of other
> people's games, I've checked out the Comp for almost as long as there
> has been a comp, etc. I know roughly, I think what types of things need
> to go into games, etc. That's probably the reason why I have such high
> standards-I want to write, but I don't want to be the next Paul Panks.
I have no idea who that is, though from the context this is apparently
an object of derision.
> Therefore, I see no real reason to do something if I'm not going to do
> it well.
You've obviously never been married. ;)
Anyway, I still think Inform 7 is the way to go.
Jeff Nyman
news:1164141823.2...@e3g2000cwe.googlegroups.com...
> some innovations make things easier. Inform 7 was specifically
> mentioned, as I believe another that I cannot recall.
I would say some innovations make it easier to write certain things related
to Interactive Fiction. That said, Inform 7 (nor any other system) makes it
easier to create better games. That comes from the author. So I think coming
up with a good story and good puzzles is not made any easier by Inform 7 or
TADS 3 or anything else.
A good example for me, that really highlighted this (although this may mean
nothing to you) came about when Inform 7 presented the ideas of rules and
relations. This seemed, on the surface, pretty cool. And it is. You can do
nifty things with it. So I was debating if I should switch to Inform 7 from
TADS 3. (Now, mind you, this only would make sense if I was actually going
to use rules and relations to any great extent.) Then, however, two
extensions were written for TADS 3 (rules.t and relation.t) and those made
me realize that not only could TADS 3 do what Inform 7 could do (albeit
without the natural language) but it showcased the way for how powerfully
customizable TADS was as a whole.
In any event, neither of these things helped make better games. They just
helped make things easier to write for more complicated scenarios. Then you
just have to decide which format you find more amenable: TADS 3's emphasis
on Java-like code syntax or Inform 7's emphasis on natural language syntax.
> My question to you is thus: which is best to begin with?
Everyone will generally answer this with the system *they* like, really
telling you nothing. You have to dive in and try the various systems and see
what you like. So there is no "best" to start with; there's simply what's
better for you.
> storyteller. Thus, something which is easy to begin with, but also has
> the capability for doing everything I'll want to do with it later would
> be ideal.
For me, this would be TADS 3. And I say this after having played around a
lot with Inform 6, Inform 7, ALAN and Hugo. Here I'm emphasizing the
"everything I'll want to do with it later" part because that's what I've
found. TADS 3 can do just about anything I want. Granted, when I was first
starting out I wasn't entirely sure of what things I would want and what
things I would not, but I came to learn that it was a good bet that TADS 3
could handle whatever situation I threw at it.
TADS may not be the easiest system to learn from some people's perspective.
Speaking for myself, I try not to limit myself by worrying about something
being too complicated. I've yet to see any practically relevant programming
language that a moderately intelligent person can't learn with a little
effort. You may not master the language in a few days, but you can certainly
learn a heck of a lot and keep building off of that.
> (I'm particularly interested in making NPCs whose options
> change according to things you have done in the game previous, and
> where you can make their responses be different according to what has
> gone before as well, though this is a for-later goal).
Any of the systems can handle this. Personally, I've found TADS 3 offers the
most options and the most power in terms of actual implementation. That's
not to say I didn't have some headaches figuring out how to do it in many
cases, but eventually I did.
Again, though, the other systems available can handle what you are
describing here. How workable you find such a system is largely going to be
up to you.
As far as others suggesting learning programming, that might be a way to go.
However, I wouldn't recommend Perl or Python. If you go a scripting route,
consider Ruby. It's much more powerful than Perl and it's much more
object-oriented than Python. Further, some of the constructs in Ruby are
good preparation for languages like C# and Java (both of which now support
annotations, generics, and iterators). TADS 3 is very Java-like in its
syntax (and thus somewhat C#-like as well).
I do disagree with the idea that making an interactive programming language
your first language to learn is necessarily a bad way to go. For some
people, perhaps it would be. However, I think it can actually be very
effective and can make learning another programming language a bit easier,
particularly if the IF language you're using has similar constructs to other
languages.
You'll note here that I put emphasis on TADS 3. I'm not recommending that as
your choice. What I was trying to point out was that I came to that decision
after working with many of the languages and determining what I liked and
disliked about each. I've found no better way for someone to make the
decision than to just hop right in and start learning. Further, I've found
that a good way to go about things is take a general idea (like your NPC
idea) and try to learn enough about each system to write up an example that
showcases your idea. Then ask yourself:
How easy was it? What problems did I run into? Did I feel too limited by the
system?
And most importantly:
Was I having fun doing this?
I believe that the system that you really enjoy working with, even if it's
not the most powerful or the most simple to learn, is often the one that you
will produce the best results with.
- Jeff
steve....@gmail.com
> I've found TADS 3 offers the
> though, the other systems available can handle what you are
> describing here. How workable you find such a system is largely going to be
> up to you.
Jeff is right on all counts. But be aware that most of the claims we
hear in favor of Inform 7 are based on an Inform 6 context. Not only
are I7 cheerleaders primed by an attachment to Inform (via I6), but
they're basing their judgement of I7's strengths on a context of I6's
weaknesses.
Yes, the I7 IDE is a fantastic improvement, if you're coming from an I6
background, which is terrible in this regard. But the TADS 3 Workbench
has evolved over more than a decade, so its capabilities have developed
to match very well the needs of the user. It is certainly not inferior
to the I7 IDE. Recommending I7 because it has a nice IDE seems silly,
unless you're coming from an I6 background.
Yes, the I7 programming structure seems promising, if you're used to
writing in I6. If, however, you're used to writing in TADS 3, I7 seems
nothing more than an odd combination of bad design decisions, owing
mostly to its closed development, and an amazingly ideological approach
to system design.
I7 prides itself on being "readable", but once you learn the symbolism
of the language (which you have to do in any case), a more formal
language is far easier to read.
I would recommend TADS 3 as far and away the development system of the
future, if only because it's good to program in.
Neil Cerutti
> Jeff Nyman wrote:
>> I've found TADS 3 offers the most options and the most power
>> in terms of actual implementation[...] though, the other
>> systems available can handle what you are describing here. How
>> workable you find such a system is largely going to be up to
>> you.
>
> Jeff is right on all counts. But be aware that most of the
> claims we hear in favor of Inform 7 are based on an Inform 6
> context. Not only are I7 cheerleaders primed by an attachment
> to Inform (via I6), but they're basing their judgement of I7's
> strengths on a context of I6's weaknesses.
Back in the bottle with you!
> I would recommend TADS 3 as far and away the development system
> of the future, if only because it's good to program in.
I commend Steve's comments regarding Inform 7 to the dustbin, if
only because they are garbage.
--
Neil Cerutti
vaporware
[...]
> Yes, the I7 programming structure seems promising, if you're used to
> writing in I6. If, however, you're used to writing in TADS 3, I7 seems
> nothing more than an odd combination of bad design decisions, owing
> mostly to its closed development, and an amazingly ideological approach
> to system design.
If you're used to writing in TADS 3, you probably aren't going to be
starting threads called "Best for New Author". But hey, why let that
stand in the way of a good old I7-bashing?
vw
James Cunningham
<jeffnyman_nospam@nospam_gmail.com> said:
> [snip]
> As far as others suggesting learning programming, that might be a way
> to go. However, I wouldn't recommend Perl or Python. If you go a
> scripting route, consider Ruby. It's much more powerful than Perl and
> it's much more object-oriented than Python. Further, some of the
> constructs in Ruby are good preparation for languages like C# and Java
> (both of which now support annotations, generics, and iterators). TADS
> 3 is very Java-like in its syntax (and thus somewhat C#-like as well).
I realize that this pushes us onto a detour, but I do want to respond
to the above: Ruby is in no way more object-oriented than Python. Both
languages were designed from the ground-up with object-oriented
development in mind; both celebrate dynamism; both allow
meta-programming and modification of classes at runtime.
It may seem, superficially, that Python is not very object-oriented; if
you're used to Ruby's "hello, world".length then len("hello, world") is
admittedly jarring. But it's just an idiom - special syntax for "hello,
world".__len__() - and it detracts nothing.
Python users aren't afraid of functions instead of class/static
methods, but the letter capability is there.
Anyway. It's interesting to see this misconception continue for so
long. (Of course, I use Ruby. While Python may not lack
object-orientation, it *does* possess a good bit of confusing, clumsy
syntax, wildly inconsistent naming conventions, and massive feature
bloat.)
>
> I do disagree with the idea that making an interactive programming
> language your first language to learn is necessarily a bad way to go.
> For some people, perhaps it would be. However, I think it can actually
> be very effective and can make learning another programming language a
> bit easier, particularly if the IF language you're using has similar
> constructs to other languages.
>
>
> - Jeff
I agree with this. Some of IF's best authors - Adam Cadre, for one, and
I think Ian Finley for another - had no previous programming experience
before taking up text adventure creation.
Best,
James
Jeff Nyman
news:2006112221133916807-jameshcunningham@gmailcom...
> On 2006-11-22 13:57:09 -0500, "Jeff Nyman"
> <jeffnyman_nospam@nospam_gmail.com> said:
>
> I realize that this pushes us onto a detour, but I do want to respond to
> the above: Ruby is in no way more object-oriented than Python.
I don't necessarily want to go into detour either, but maybe there's a
salient point here for people asking about what IF system to choose. The
relevant point is at the end of this post because the foregoing parts are
largely like debates about competing IF systems, I think.
I use both Python and Ruby regularly and, to me, Ruby does have a more
object-oriented construction underlying it. (As another example, C++ is
object-oriented as well as Java, but I believe Java displays it more and
utilizes it more. I would say Java is "more" object-oriented than C++.
That's the sense in which I feel Ruby is "more" object-oriented than
Python.) I just think Ruby makes OOP more intrinsic, whereas Python is more
a mix of OOP ideas and procedural styles. I'm not saying that makes Python
bad and Ruby good, but I have to teach both Python and Ruby and I've found
people react much better to Ruby from a learning standpoint, particularly
when they have little programming background. (Granted, that's anecdotal and
I can point to many exceptions in my experience.)
> Anyway. It's interesting to see this misconception continue for so long.
The misconception, I think, is that Python is not object-oriented at all,
which I agree is a misconception. I just think the way object-oriented
programming was considered in Ruby is philosophically different than it was
in Python. (Granted, Python is "catching up" as it goes on. To me, Ruby
never had to catch up. It was designed the way it was.)
= = Here come's the relevant part ... = =
Streering this back on track, though, I think it's a good point overall and
I appreciate you calling me out on it because it just shows that with any
language, everyone has their ideas about how good or bad it is at certain
things or how easy or not it is to use or even how rigidly it adhers to the
fundamental design it was made to handle. You and I are both displaying what
I said people tend to do: tell you about the system *they* like and why
someone should learn *that* system rather than another. We're both talking
about things here that someone unfamiliar with them would probably be like:
"Yeah, great. But this doesn't help me decide which one to use."
So just as people unfamiliar with Ruby or Python would have to jump into
both to determine how accurate you and I are in our statements here, someone
unfamiliar with Inform or TADS or whatever else will have to simply jump in
and see what works. So while we detoured a bit, maybe the detour makes it
clear why individual people saying which IF system is "best" or even
"better" is largely unhelpful without working context.
- Jeff
James Mitchelhill
> As far as others suggesting learning programming, that might be a way to go.
> However, I wouldn't recommend Perl or Python. If you go a scripting route,
> consider Ruby. It's much more powerful than Perl and it's much more
> object-oriented than Python. Further, some of the constructs in Ruby are
> good preparation for languages like C# and Java (both of which now support
> annotations, generics, and iterators). TADS 3 is very Java-like in its
> syntax (and thus somewhat C#-like as well).
Quibbling over which of two fairly similar languages is the best starter
language for people new to programming is probably not a very interesting
argument, although I'd suggest running away if anyone seriously suggests
Perl.
Ruby and Python are both powerful and reasonably easy to learn. IME
Python's slightly confused object orientation isn't really an issue.
Knowing either language will make leaning C# or Java easier (though
possibly more annoying).
I don't know about Ruby, but the level of peer support for Python is
astounding. There's a dedicated tutor mailing list specifically designed
for people new to python or programming in general. The helpfulness of
people in comp.lang.python is almost supernatural. (Last time I posted
there, I got an answer to my question and sample code from the author of
the O'Reilly _Python in a Nutshell_ book. In less than five minutes.)
But like I say, both are good choices.
Ken
news:aczos0gqluno.1f...@40tude.net...
> Ruby and Python are both powerful and reasonably easy to learn. IME
> Python's slightly confused object orientation isn't really an issue.
It's definitely an issue for many people. I don't know if anyone knows or
cares but there was an attempt to emulate TADS functionality in Ruby. It's
called RADS. This was also tried between LISP and Python as well. It was
universally agreed that Ruby was much better for learning purposes. (I think
Python might have been more powerful in some ways, but the goal wasn't to
build a full game or anything. It was just to help a new programmer get up
to speed with programming concepts in adventure games.) The Story Generator
in Ruby was also found to be a better learning tool than the same thing
implemented in Python. (I think Haskell was brought into the mix too.) The
RPG Generator was another project that Ruby won hands down when new
programmers were asked what they liked learning in better.
I'm really curious though why everyone's suggesting learning another
programming language to learn IF. Why not just sorta like learn the IF
language itself? That's programming, isn't it? My vote for learning a
language for IF: Javascript. Have y'all seen
http://www.versificator.co.uk/?)
Conrad Kayne
Inform 7, without a doubt.
I7 is designed for authors (as opposed to programmers), uses natural
English, is just as powerful as I6 and TADS, and has an integrated
development environment to die for. And support on this newsgroup is
second to none.
It is not only for newbies and the code-challenged: most of the better
known and most dedicated IF authors (Emily Short, Michael Gentry, Jon
Ingold, Andrew Plotkin - to name just four), are embracing it. I can't
think of a more telling recommendation than that.
> I suffer from
> the handicaps of being both code-challenged and also a fairly ambitious
> storyteller. Thus, something which is easy to begin with, but also has
> the capability for doing everything I'll want to do with it later would
> be ideal.
Though a veteran programmer, I am new to writing IF, so please take
what follows with a pinch of salt, but from my own limited experience
and from reading the testimony of others with more claim to authority
in the field, my suggestion as to how to go about your first game is:
jump right in.
Download I7, create a starting location for your game, and *write*.
With every paragraph, your path through the game will become clearer.
New ideas will spring up in your imagination like weeds, but only
through writing. You've done the initial planning already: you have the
idea for your game. More planning can so easily become the excuse for
never starting. This is true not only here but in conventional fiction
also. The recommendation has always been *write* and write regularly.
Whether what you write is junk and ultimately discarded doesn't matter.
It's your only tool for ploughing the ground and making it fertile.
No other IF language removes the obstacles to writing as effectively as
I7. Since the code is largely natural English, you'll experience very
little disconnect between 'code' and text, the one tending to flow
easily into the other. Narrative thought is not broken, or at worst
only minimally at certain special junctures in the game. And for those
you have recourse to the excellent integrated manual in I7, as well as
all the IF luminaries here.
Finally, I'd just like to register my bafflement at this thread. It
started with a simple plea for guidance on the best course for an IF
beginner, and quickly degenerated into discussion of the relative
merits of two non-IF programming languages: Python and Ruby.
I wouldn't be at all surprised if the original poster were not now in a
state of even more confusion because of this. Let's try to bring the
discussion back on track, namely -
>My question to you is thus: which is best to begin with?
He/she posted to rec.arts.int-fiction, *not* comp.lang.python.
Regards,
ck
James Mitchelhill
> "James Mitchelhill" <ja...@disorderfeed.net> wrote in message
> news:aczos0gqluno.1f...@40tude.net...
>
>
>> Ruby and Python are both powerful and reasonably easy to learn. IME
>> Python's slightly confused object orientation isn't really an issue.
>
> It's definitely an issue for many people. I don't know if anyone knows or
> cares but there was an attempt to emulate TADS functionality in Ruby. It's
> called RADS. This was also tried between LISP and Python as well. It was
> universally agreed that Ruby was much better for learning purposes. (I think
> Python might have been more powerful in some ways, but the goal wasn't to
> build a full game or anything. It was just to help a new programmer get up
> to speed with programming concepts in adventure games.) The Story Generator
> in Ruby was also found to be a better learning tool than the same thing
> implemented in Python. (I think Haskell was brought into the mix too.) The
> RPG Generator was another project that Ruby won hands down when new
> programmers were asked what they liked learning in better.
I had a quick look for some of these and drew a blank. As I said, I think
arguing about this is rather silly.
> I'm really curious though why everyone's suggesting learning another
> programming language to learn IF. Why not just sorta like learn the IF
> language itself? That's programming, isn't it? My vote for learning a
> language for IF: Javascript. Have y'all seen
> http://www.versificator.co.uk/?)
I explained my reasons in my original post. Personally, I think learning
Ruby, Python or, to a lesser extent, Javascript would be good preparation
for learning an IF language.
Conrad Kayne
James Mitchelhill wrote:
> I explained my reasons in my original post. Personally, I think learning
> Ruby, Python or, to a lesser extent, Javascript would be good preparation
> for learning an IF language.
FWIW, it's my experience - and that of many other IF authors more
qualified to comment - that the best preparation is *no* preparation.
Preparation is procrastination. Writing is doing.
My advice is take the plunge into the *IF* language with the most
gentle learning curve, and have fun. There's plenty to be had and, as
stated, writing in I7 does not feel in the least like programming.
(this from a programmer). Personally, now that we have I7, I don't
think there's even an excuse to brand ourselves programmers in this
medium. We are authors.
ck
Robin Johnson
> James Mitchelhill wrote:
>
> > I explained my reasons in my original post. Personally, I think learning
> > Ruby, Python or, to a lesser extent, Javascript would be good preparation
> > for learning an IF language.
I don't think learning Javascript is a very good introduction to
programming: it's so bloated you'd barely know where to start, its
object model is not like many other languages', and the need to write
an HTML interface for your programs makes it more difficult to Just Get
Something Working.
> FWIW, it's my experience - and that of many other IF authors more
> qualified to comment - that the best preparation is *no* preparation.
> Preparation is procrastination. Writing is doing.
True. Preparing for something isn't the same as learning how to do it,
though.
> My advice is take the plunge into the *IF* language with the most
> gentle learning curve, and have fun. There's plenty to be had and, as
> stated, writing in I7 does not feel in the least like programming.
> (this from a programmer).
This isn't how I7 feels to me.
It's all very well when I think "Victor is a man in the parlour" and
write that. But when I think something like "There's a bookcase in
Victor's bedroom, with a few books on it, one of which is called Steal
This Book, and when you grab that particular book the bookcase revolves
and you're in the secret lab." This is going to have to be expressed
more precisely before a computer can understand it, and I'd rather
express it in a mathematical syntax like that of a conventional
programming language - because that's the shape it's easiest to get
into in my mind. When I try to write something like this in I7 I get it
expressed mathematically in my head, then I struggle to surround it
with the fuzz that makes it into I7's idea of natural language. It
makes my head ache.
> Personally, now that we have I7, I don't
> think there's even an excuse to brand ourselves programmers in this
> medium. We are authors.
Programming is precise thought. Declaring a puzzle, or the behaviour of
an NPC in response to whatever stimuli, requires that precise thought.
I7 hasn't made the need for precise thought go away. The best it can do
is make the precise thought come easier. It has apparently done so for
a lot of people, but not everyone, because not everyone's mind works
the same way.
I definitely recommend looking at I7 as one of the first things someone
should do if they're thinking of getting into IF writing.
--
Robin Johnson
rj at robinjohnson dot f9 dot co dot uk
http://rdouglasjohnson.blogspot.com - http://www.versificator.co.uk
James Mitchelhill
> James Mitchelhill wrote:
>
>> I explained my reasons in my original post. Personally, I think learning
>> Ruby, Python or, to a lesser extent, Javascript would be good preparation
>> for learning an IF language.
>
> FWIW, it's my experience - and that of many other IF authors more
> qualified to comment - that the best preparation is *no* preparation.
> Preparation is procrastination. Writing is doing.
Preparation can take many forms, from research through to small
proof-of-concept programming exercises. I'm fairly sure a lot of IF authors
engage in significant planning before leaping in.
> My advice is take the plunge into the *IF* language with the most
> gentle learning curve, and have fun. There's plenty to be had and, as
> stated, writing in I7 does not feel in the least like programming.
> (this from a programmer). Personally, now that we have I7, I don't
> think there's even an excuse to brand ourselves programmers in this
> medium. We are authors.
I disagree. The kind of IF I'm interested in writing requires fairly
significant programming.
I7 provides a very easy way to program higher level elements of IF. That's
fine and many good games don't mess with low level stuff. Some do, and I
suspect that the learning curve becomes real steep at this point.
Jeff Nyman
news:1164387066.8...@m7g2000cwm.googlegroups.com...
> Whether what you write is junk and ultimately discarded doesn't matter.
> It's your only tool for ploughing the ground and making it fertile.
I completely agree with this. I tend to place my emphasis more on TADS 3 for
myself, but your thoughts here with I7 mirror my own path. Simply start with
a system and go with it for a bit. See what you can come up with. There's no
need to write the next greatest game on your first shot.
Some of my initial forays into Inform 7 and TADS 3 were largely abysmal and
downright embarrassing. That said, no one's ever going to see them anyway
and I went in with that intention. (For anyone participating in NaNoWriMo
this year, that's pretty much the same logic used for the conventional
fiction as well.)
Like I said before, take a system and start working with it. Better yet, to
form an informed opinion, try a couple systems. Initially I thought it would
be better if I learned one and then learned another but I actually found
that, for me, it was better to take a simple game concept that I wanted to
write and try to learn both languages at the same time. Usually finding one
thing that Inform 7 could do made me try to figure out if TADS 3 could do
the same thing, and vice versa. I learned quite a lot about both systems
that way and that ultimately helped me figure out what system I preferred
using simply because I was enjoying the process more.
This also speaks to the original concern of the original poster: "...I'd
prefer that the ease-of-code take a hit, because I don't want to learn how
to write the whole thing up only to learn that my ultimate goal is
unreachable." The key is you're not really going to know if your goal is
unreachable until you know what you want to do and then try to do that in
the various systems. No matter what any of us say about how much we like one
system or the other, it all means nothing if you find your goal is still
unreachable.
- Jeff
Ken
>
> My advice is take the plunge into the *IF* language with the most
> gentle learning curve, and have fun. There's plenty to be had and, as
> stated, writing in I7 does not feel in the least like programming.
You're automatically assuming I7 should be the choice here. And how, pray
tell, do you tell ahead of time that the language you picked has a "gentle
learning curve?" I7 is still very much in beta, so a lot could change.
That's not always a gentle curve.
> (this from a programmer). Personally, now that we have I7, I don't
> think there's even an excuse to brand ourselves programmers in this
> medium. We are authors.
God save us.
Hate to tell you: you're still programming in I7. Have you seen how some
extensions are written? Have you seen how you have to drop into I6 for many
things? You're misleading people if you tell them they can avoid all
programming and just "be an author."
Ken
>
> Finally, I'd just like to register my bafflement at this thread. It
> started with a simple plea for guidance on the best course for an IF
> beginner, and quickly degenerated into discussion of the relative
> merits of two non-IF programming languages: Python and Ruby.
Yup - and notice how none of you really helped since all of you just said
"Use Inform 7!" or "Use TADS 3!" That's not helpful, is it? Your response
basically boiled down to "Use Inform 7 because lots of popular people here
use it." And I notice no one brought up ADRIFT or Quest or other systems. So
in trying to be so helpful you all degenerated this into a discussion of
just Inform 7 and TADS 3. I noticed you didn't bitch about that, though.
> He/she posted to rec.arts.int-fiction, *not* comp.lang.python.
Interestingly enough, there's a couple of IF systems in Python and one in
Ruby that I'm aware of. So, actually, this could be really relevant if
someone wanted to use one of those systems and needed to know if Python was
the "best." Again, though, none of you brought that up: everything is just
locked in I7 or T3 land. Full speed ahead and fuck those torpedoes.
James Mitchelhill
> I wouldn't be at all surprised if the original poster were not now in a
> state of even more confusion because of this. Let's try to bring the
> discussion back on track, namely -
>
>>My question to you is thus: which is best to begin with?
>
> He/she posted to rec.arts.int-fiction, *not* comp.lang.python.
What's your point? Are we supposed to block out all thoughts of the rest of
the world while posting to raif?
If someone was unfamiliar with creative writing and wanted to start writing
IF, I'd suggest they get some writing experience first. Suggesting that
someone get some programming experience first is no different.
In addition, someone who's spent a couple of weeks learning a bit about
programming will be in a better position to evaluate which IF language will
suit them. And regardless of the advice they get here, that's something the
OP will have to decide.
greg
> I notice no one brought up ADRIFT or Quest or other systems.
My recommendation is to investigate Alan. It
has much of the friendliness of I7, but with a
well-defined syntax that permits clear thought.
It has some limitations, but of all the current
major systems, I can't think of anything that
would be better all-round for a beginning IF
author.
Alan is currently in transition between versions
2 and 3, and the documentation hasn't entirely
caught up yet. If you find this too confusing,
you might prefer to start with Alan 2, and move
on to Alan 3 later.
--
Greg
James Mitchelhill
> Ken wrote:
>> I notice no one brought up ADRIFT or Quest or other systems.
>
> My recommendation is to investigate Alan. It
> has much of the friendliness of I7, but with a
> well-defined syntax that permits clear thought.
> It has some limitations, but of all the current
> major systems, I can't think of anything that
> would be better all-round for a beginning IF
> author.
Note that the OP was looking for a system able to handle complex NPCs.
Adrift, Quest and Alan aren't that system.
Alex Warren
James Mitchelhill wrote:
> On Sat, 25 Nov 2006 12:50:56 +1300, greg wrote:
>
> > Ken wrote:
> >> I notice no one brought up ADRIFT or Quest or other systems.
> >
> > My recommendation is to investigate Alan. It
> > has much of the friendliness of I7, but with a
> > well-defined syntax that permits clear thought.
> > It has some limitations, but of all the current
> > major systems, I can't think of anything that
> > would be better all-round for a beginning IF
> > author.
>
> Note that the OP was looking for a system able to handle complex NPCs.
> Adrift, Quest and Alan aren't that system.
Says who? The OP said "I'm particularly interested in making NPCs whose
options change according to things you have done in the game previous,
and where you can make their responses be different according to what
has gone before as well" - perfectly possible, and easy to do, using
Quest.
Alex Warren
al...@axeuk.com
http://www.axeuk.com/quest
greg
> Says who? The OP said "I'm particularly interested in making NPCs whose
> options change according to things you have done in the game previous,
> and where you can make their responses be different according to what
> has gone before as well" - perfectly possible, and easy to do, using
> Quest.
Perfectly possible using Alan too, and not really any
harder than it would be using any of the other major
systems. All of them require any non-trivial NPC behaviour
to be programmed, one way or another.
Alan as a language is actually a little ahead of the
others with its built-in notion of an actor "script".
A single script is not all that flexible, but with
conditional code that switches around between different
scripts you can get quite complex behaviour.
--
Greg
James Mitchelhill
> Alex Warren wrote:
>
>> Says who? The OP said "I'm particularly interested in making NPCs whose
>> options change according to things you have done in the game previous,
>> and where you can make their responses be different according to what
>> has gone before as well" - perfectly possible, and easy to do, using
>> Quest.
I took a look at Quest. It was only a quick look, so feel free to correct
me if I get this wrong.
Quest includes no built in support for NPCs.
> Perfectly possible using Alan too, and not really any
> harder than it would be using any of the other major
> systems. All of them require any non-trivial NPC behaviour
> to be programmed, one way or another.
>
> Alan as a language is actually a little ahead of the
> others with its built-in notion of an actor "script".
> A single script is not all that flexible, but with
> conditional code that switches around between different
> scripts you can get quite complex behaviour.
Alan doesn't seem to have any built in support for conversation. The author
is left to code this on their own.
Compare this to TADS 3 and then try claiming that Quest or Alan are good
choices for writing complex NPCs. I'm sure that Alan has its strong points,
but this is not one of them. From what I've seen, Quest doesn't have any
strong points and the idea that it's suitable for an ambitious project with
complex NPCs is nothing short of laughable.
The point isn't whether the OP's goals are possible in a given language,
but how much support the language provides.
Alex Warren
James Mitchelhill wrote:
> I took a look at Quest. It was only a quick look, so feel free to correct
> me if I get this wrong.
>
> Quest includes no built in support for NPCs.
I suggest you take a little longer look. Quest does include support for
NPCs - they're a type of object.
> Compare this to TADS 3 and then try claiming that Quest or Alan are good
> choices for writing complex NPCs. I'm sure that Alan has its strong points,
> but this is not one of them. From what I've seen, Quest doesn't have any
> strong points and the idea that it's suitable for an ambitious project with
> complex NPCs is nothing short of laughable.
You say yourself that you've only taken a quick look at Quest, so on
what basis can you make this claim? What complex NPC functionality is
overly difficult to implement in Quest?
Alex
David Whyld
James Mitchelhill wrote:
You can certainly have complex NPCs in Adrift. A few custom tasks, a
few variables and you could have NPCs as complex as you like.
Khelwood
Yeah, but you could do that in BASIC too. Whereas some languages
actually provide mechanisms for handling NPC interactions that make
them transparent and easy to write. Adrift doesn't even recognise
"show" or "tell" or "npc, command", does it?
David Whyld
Khelwood wrote:
"Show" is covered; "tell" could be added quicker than it takes me to
type this; "npc, command"? Nope, not in. Adrift separates commands by
placing a comma between them, so "npc, command" would actually be read
as two separate commands "npc" and "command". But there are easy work
arounds.
James Cunningham
This other James may be shooting from the hip, but I think he's basing
his claim on the quality of - um - pretty much *every* Quest game
that's ever made it to the competition. (And every other Quest game
*I've* played, at least.)
Could you point out a Quest game that has what you believe are complex
NPCs, that we might better judge Quest's abilities? Preferably NPCs
that fluidly change behavior based on player stimuli.
Best,
James
Alex Warren
James Cunningham wrote:
> This other James may be shooting from the hip, but I think he's basing
> his claim on the quality of - um - pretty much *every* Quest game
> that's ever made it to the competition. (And every other Quest game
> *I've* played, at least.)
Yes, there are plenty of bad Quest games, but that doesn't mean it's
impossible, or difficult, to create a good one. It's a bit of a
catch-22 really - the lack of good games gives the system a bad name,
hence the people who are capable of writing good games are more likely
to choose an alternative system.
I don't think that means Quest is a bad system though. Perhaps just a
rather misunderstood one.
Alex
Mark Tilford
I've heard on the ADRIFT board that the most recent versions of ADRIFT
don't separate commands at a comma.
David Whyld
Are you talking about the current version of Adrift (V4, R46) or a
newer one?
James Mitchelhill
> James Mitchelhill wrote:
>
>> I took a look at Quest. It was only a quick look, so feel free to correct
>> me if I get this wrong.
>>
>> Quest includes no built in support for NPCs.
>
> I suggest you take a little longer look. Quest does include support for
> NPCs - they're a type of object.
Ah, I apologise. I missed that, what with the whole lack of distinction
between characters and objects.
After a little more research I feel better equipped to summarise Quest's
built in support for NPCs:
Objects can have a gender.
Objects can be spoken to, which can cause text to be displayed or a script
to be run.
Have I missed anything?
>> Compare this to TADS 3 and then try claiming that Quest or Alan are good
>> choices for writing complex NPCs. I'm sure that Alan has its strong points,
>> but this is not one of them. From what I've seen, Quest doesn't have any
>> strong points and the idea that it's suitable for an ambitious project with
>> complex NPCs is nothing short of laughable.
>
> You say yourself that you've only taken a quick look at Quest, so on
> what basis can you make this claim? What complex NPC functionality is
> overly difficult to implement in Quest?
Take a look at <http://www.tads.org/howto/t3actor.htm>.
A more in depth, and rather different answer:
In one of my toy projects, in which I'm experimenting with physical
simulation, I have NPCs that have bodies. I wrote a small bit of code that
runs when the game is compiled that runs through all the appropriate
bodypart classes and adds any that are not separately defined for an NPC,
then structures the containment hierarchy automatically.
This means that some bits of characters bodies will not have very
interesting descriptions. So, rather than printing that uninteresting
description, I redirect the verb up the chain of body parts until it
reaches one that has a non-default description.
At the same time, a body part can be clothed, which will result in the
description possibly being redirected to the clothing object.
The vocabulary associated with each bodypart is modified at compile time to
include the possessive name of the NPC (eg. "Henry's") as an adjective.
This means that one set of classes can be used across multiple NPCs without
worrying about what the NPC is called.
Additionally, it's possible to play with the way TADS 3 diambiguates
objects on a per-object basis, which is helpful in avoiding spurious
disambiguation questions.
All this is very easy to do with TADS 3. It would not have been too painful
with TADS 2. The idea of writing the entire infrastructure needed to get
this to work in Quest seems absurd.
The same kind of concerns apply to conversation. It's not that it's
impossible with Quest, but that there is a complete lack of the necessary
infrastructure needed to make the author's life easier.
Mark Tilford
I don't know; other drifters were talking about it.
Mark Tilford
>
>
>
> James Cunningham wrote:
>
>> This other James may be shooting from the hip, but I think he's basing
>> his claim on the quality of - um - pretty much *every* Quest game
>> that's ever made it to the competition. (And every other Quest game
>> *I've* played, at least.)
>
> Yes, there are plenty of bad Quest games, but that doesn't mean it's
> impossible, or difficult, to create a good one. It's a bit of a
> catch-22 really - the lack of good games gives the system a bad name,
> hence the people who are capable of writing good games are more likely
> to choose an alternative system.
Try porting a few games (there are plenty that have source available) to
Quest. Do this by only using ASL; don't write any additional code in VB.
Mark Tilford
Here's where Todd Watson mentioned it:
http://www.adrift.org.uk/cgi/iB/ikonboard.cgi?act=ST;f=1;t=5578
David Whyld
In V4, R46 commas still separate commands.
Alex Warren
James Mitchelhill wrote:
> After a little more research I feel better equipped to summarise Quest's
> built in support for NPCs:
>
> Objects can have a gender.
> Objects can be spoken to, which can cause text to be displayed or a script
> to be run.
>
> Have I missed anything?
Objects can have other objects given to or used on them.
Objects can have custom properties
Objects can have custom actions (methods, i.e. script associated with
them)
Objects can work with specific verbs (from v4.0, but you can use
commands in v3.53 to do the same thing)
Objects can contain other objects (from v4.0)
And of course, when a script runs anything can happen - the object can
be moved, hidden, or have their properties or actions updated (this can
include updating the object's description or its response to a verb,
for example).
Hence Quest can be used to create dynamic characters.
> >> Compare this to TADS 3 and then try claiming that Quest or Alan are good
> >> choices for writing complex NPCs. I'm sure that Alan has its strong points,
> >> but this is not one of them. From what I've seen, Quest doesn't have any
> >> strong points and the idea that it's suitable for an ambitious project with
> >> complex NPCs is nothing short of laughable.
> >
> > You say yourself that you've only taken a quick look at Quest, so on
> > what basis can you make this claim? What complex NPC functionality is
> > overly difficult to implement in Quest?
>
> Take a look at <http://www.tads.org/howto/t3actor.htm>.
The TADS 2 approach is easily doable - the object's look script can
check for a flag, or a property of that object, and print a message
accordingly.
You could even go for the TADS 3 approach, though it's less obvious.
Set up a type for each of the object states ("if hair on fire" and so
on), and then apply that type to the object at the required time using
a script.
> A more in depth, and rather different answer:
>[snip description of body parts code]
> All this is very easy to do with TADS 3. It would not have been too painful
> with TADS 2. The idea of writing the entire infrastructure needed to get
> this to work in Quest seems absurd.
You've clearly had to create quite a bit of custom code though - the
behaviour you describe is not out of the box TADS behaviour. I don't
see any particular reason why it would be harder in Quest - just
different.
Alex
David Whyld
really as big a deal as it's made out to be. Maybe it can, maybe it
can't. From my (limited) use of it, it's certainly got potential, but
that potential was hidden away behind a horribly confusing GUI that
made doing even simple things a chore. However, persevere with it and
Quest could be very powerful indeed. But that's kind of irrelevant.
It's not what Quest can do but what people can do with it.
So the big question is: can anyone using Quest now actually write a
decent game? No one will ever take it seriously until it produces a
decent game.
James Mitchelhill
> James Mitchelhill wrote:
>
>> After a little more research I feel better equipped to summarise Quest's
>> built in support for NPCs:
>>
>> Objects can have a gender.
>> Objects can be spoken to, which can cause text to be displayed or a script
>> to be run.
>>
>> Have I missed anything?
>
> Objects can have other objects given to or used on them.
> Objects can have custom properties
> Objects can have custom actions (methods, i.e. script associated with
> them)
> Objects can work with specific verbs (from v4.0, but you can use
> commands in v3.53 to do the same thing)
> Objects can contain other objects (from v4.0)
These all apply generally to objects, not specifically NPCs. You can't
really claim these are "support for NPCs", except in the widest terms.
> And of course, when a script runs anything can happen - the object can
> be moved, hidden, or have their properties or actions updated (this can
> include updating the object's description or its response to a verb,
> for example).
>
> Hence Quest can be used to create dynamic characters.
As has been pointed out elsewhere, any language at all - Basic, Fortran,
Cobol - can be used to create dynamic characters. It's the ease of doing so
that's in question.
>>>> Compare this to TADS 3 and then try claiming that Quest or Alan are good
>>>> choices for writing complex NPCs. I'm sure that Alan has its strong points,
>>>> but this is not one of them. From what I've seen, Quest doesn't have any
>>>> strong points and the idea that it's suitable for an ambitious project with
>>>> complex NPCs is nothing short of laughable.
>>>
>>> You say yourself that you've only taken a quick look at Quest, so on
>>> what basis can you make this claim? What complex NPC functionality is
>>> overly difficult to implement in Quest?
>>
>> Take a look at <http://www.tads.org/howto/t3actor.htm>.
>
> The TADS 2 approach is easily doable - the object's look script can
> check for a flag, or a property of that object, and print a message
> accordingly.
>
> You could even go for the TADS 3 approach, though it's less obvious.
> Set up a type for each of the object states ("if hair on fire" and so
> on), and then apply that type to the object at the required time using
> a script.
So, essentially, you could write the TADS 3 library in Quest. That's not
suprising. But I'd class that as "overly difficult to implement".
>> A more in depth, and rather different answer:
>>[snip description of body parts code]
>> All this is very easy to do with TADS 3. It would not have been too painful
>> with TADS 2. The idea of writing the entire infrastructure needed to get
>> this to work in Quest seems absurd.
>
> You've clearly had to create quite a bit of custom code though - the
> behaviour you describe is not out of the box TADS behaviour. I don't
> see any particular reason why it would be harder in Quest - just
> different.
Almost all interesting behaviour an IF author implements is not out of the
box. That's why it's interesting. The important difference is how much work
it takes.
Alex Warren
James Mitchelhill wrote:
> On 27 Nov 2006 13:31:16 -0800, Alex Warren wrote:
> > Objects can have other objects given to or used on them.
> > Objects can have custom properties
> > Objects can have custom actions (methods, i.e. script associated with
> > them)
> > Objects can work with specific verbs (from v4.0, but you can use
> > commands in v3.53 to do the same thing)
> > Objects can contain other objects (from v4.0)
>
> These all apply generally to objects, not specifically NPCs. You can't
> really claim these are "support for NPCs", except in the widest terms.
Is there anything missing, then?
> > You could even go for the TADS 3 approach, though it's less obvious.
> > Set up a type for each of the object states ("if hair on fire" and so
> > on), and then apply that type to the object at the required time using
> > a script.
>
> So, essentially, you could write the TADS 3 library in Quest. That's not
> suprising. But I'd class that as "overly difficult to implement".
I should point out that when I say you could apply a type to an object
using a script, that's one command. Which from what I understood makes
it precisely as difficult as TADS 3.
Alex
steve....@gmail.com
hasn't given an honest look at, and he's got the issues confused. In
any case, we are well reminded that the balance of sophistication
versus simplicity, or the natural strengths that emerge from a given
programming environment, is not some cockfight, and the shrillest cock
is unlikely to have any winning insight at all.
James pretended that Alex Warren had argued...
> So, essentially, you could write the TADS 3 library in Quest. That's not
> suprising. But I'd class that as "overly difficult to implement".
Now it's perfectly clear that Alex was not saying this in the first
place, and James should probably ride his high horse out of town and
give things a quiet think for a change. (Alex was saying only that some
behavior of the TADS 3 conversation system could be produced by Quest,
given that this proves little on either side.)
James' inflammatory and intentional misprision aside, my main problem
with his argument is simply that it's either technically incorrect or
uselessly vague (and probably both). The TADS 3 library is not a
specification which might be implemented in any given language. It is
instead a long series of developments that condensed around one
another, and upon the specifics of the targeted language, in a highly
dynamic and self-specializing way. One would not expect it to translate
well.
"That it does not taste like an apple" is a poor argument against the
orange. I hope James can stop misquoting TADS 3 literature as a
substitute for thinking. And if he really wants an example of an
authoring environment that fancies itself too cool for school, he
should bark at a different tree.
James Mitchelhill
> Obviously, James has been mounting an argument against a system he
> hasn't given an honest look at, and he's got the issues confused. In
> any case, we are well reminded that the balance of sophistication
> versus simplicity, or the natural strengths that emerge from a given
> programming environment, is not some cockfight, and the shrillest cock
> is unlikely to have any winning insight at all.
I'm not mounting an argument against Quest as such. But Alex's claims that
Quest - a language that barely differentiates between NPCs and other
objects - is suited to developing complex characters strike me as odd.
Doubtless Quest has strengths (though I, personally, fail to see them),
but, as I stated before, this isn't one of them.
> James pretended that Alex Warren had argued...
>
>> So, essentially, you could write the TADS 3 library in Quest. That's not
>> suprising. But I'd class that as "overly difficult to implement".
>
> Now it's perfectly clear that Alex was not saying this in the first
> place, and James should probably ride his high horse out of town and
> give things a quiet think for a change. (Alex was saying only that some
> behavior of the TADS 3 conversation system could be produced by Quest,
> given that this proves little on either side.)
>
> James' inflammatory and intentional misprision aside,
You know, this is the first time I've ever been accused of misprision. But
thanks, you've taught me a new word.
> my main problem
> with his argument is simply that it's either technically incorrect or
> uselessly vague (and probably both). The TADS 3 library is not a
> specification which might be implemented in any given language.
It is if you use it that way.
> It is
> instead a long series of developments that condensed around one
> another, and upon the specifics of the targeted language, in a highly
> dynamic and self-specializing way. One would not expect it to translate
> well.
True. But this has nothing at all to do with my argument, which could be
summed up as follows:
Capability is not suitability.
TADS 3 is particularly suitable for programming complex NPCs, because it
provides sophisticated and flexible support for implementing them. Quest
does not provide anything approaching this, which makes it less suitable
for implementing them, regardless of whether to do so would be possible.
Richard Bos
> Personally, now that we have I7, I don't think there's even an
> excuse to brand ourselves programmers in this medium. We are authors.
Yeah, sure. Come back when you've encountered your first Inform 7 syntax
error.
Yes, I know it calls them "issues" or something similarly obfuscatory.
They're still syntax errors.
Richard
Richard Bos
> Ken wrote:
> > I notice no one brought up ADRIFT or Quest or other systems.
>
> My recommendation is to investigate Alan. It
> has much of the friendliness of I7, but with a
> well-defined syntax that permits clear thought.
Then again, my recommendation would be to check the quality of Alan
games entered into the IFComp recently. Enter The Dark was... less than
ideal. 01 wasn't much better. Presumably Alan _can_ be used to write
good games, but I've yet to see one.
Richard