Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

want an I-F development GUI?

3 views
Skip to first unread message

if_...@my-deja.com

unread,
Jan 16, 2000, 3:00:00 AM1/16/00
to
I was playing around & decided to see how
difficult it would be to develop a tool which
would allow me to develop I-F using a GUI.

Yes, I know that this holy grail of I-F
programming has been oft discussed & oft
dismissed. However, I believe that it is not so
much a difficult task, as a time-consuming one.

If enough people actually express an interest, I
may even follow it through to completion. I have
produced a first pass pre-alpha version which
should give you some idea of what I foresee. You
can download it & see some screenshots at
http://plugh.tsx.org

Rather than develop it fully & present a fait-
accompli (which would only cause me to receive
heaps of 'suggestions for improvement'), I have
decided to show a little of what can be done &
then to ask you guys how the tool should actually
fucntion in operation.

Oh, why don't you just visit the web page, then
give some feedback?


Sent via Deja.com http://www.deja.com/
Before you buy.

okbl...@my-deja.com

unread,
Jan 16, 2000, 3:00:00 AM1/16/00
to
In article <85t873$tel$1...@nnrp1.deja.com>,

if_...@my-deja.com wrote:
> I was playing around & decided to see how
> difficult it would be to develop a tool which
> would allow me to develop I-F using a GUI.

Haven't we all, late at night after an evening of drunken revelry?

> Yes, I know that this holy grail of I-F
> programming has been oft discussed & oft
> dismissed. However, I believe that it is not so
> much a difficult task, as a time-consuming one.

Actually, no, I don't think a GUI is The Holy Grail. I think the general
consensus (around here) is that a thing that a GUI is going to be the
most obvious help with--creating a map--is really easy in the existing
non-GUI environments.

Not to say that, if a GUI were available, people wouldn't use it,
regardless of what they say here. :-)

Now, start talking natural language parsing and easy-to-flesh-out,
responsive, realistic NPCs--now yer talkin' grails, dude.

> Oh, why don't you just visit the web page, then
> give some feedback?

Kudos for making it a front-end to TADS instead of rolling-your-own
language. That will make the project easier and more interesting to a
lot of a people.

The thing I think a GUI could be really useful for is handling
combinatorial explosion. If you had a system for handling that, I'd
definitely take a look at it.
--
[ok]

if_...@my-deja.com

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to

> Haven't we all, late at night after an evening of drunken revelry?
oddly enough, I was sober (this time round).

> the thing that a GUI is going to be the


> most obvious help with--creating a map--is really easy in the existing
> non-GUI environments.

and a shift stick is easy till you try driving an automatic (bad
example, really, I always drive shift & hate automatics). The point
being that you don't know that you have a tedious chore until you get
the labour saving device.

Also, I think that the convenience of a GUI can be useful for more than
just the map (but, let me know if you want a map drawing tool only, as
that would be realtively simple to produce, compared with the full
Magnum Opus).


> Not to say that, if a GUI were available, people wouldn't use it,
> regardless of what they say here. :-)

would those be the same folks who tell us that they never watch T.V, or
honestly believe that they work out regularly, watch what they eat, etc?
(i.e, the vast majority of us (me inluded)).


> Now, start talking natural language parsing and easy-to-flesh-out,
> responsive, realistic NPCs--now yer talkin' grails, dude.

I might be able to talk the talk, but doubt very much if I could walk
the walk.


> > Oh, why don't you just visit the web page, then
> > give some feedback?
>
> Kudos for making it a front-end to TADS instead of rolling-your-own
> language. That will make the project easier and more interesting to a
> lot of a people.

What's the point of yet another lanuage with less than a handful of
users. Whenever the subject of such a GUI has come up in the past, it
has always been stressed that it would only be accepted if it supported
an established language.


> The thing I think a GUI could be really useful for is handling
> combinatorial explosion.

say what now? que est-ce que c#est, le "combinatorial explosion"?

> If you had a system for handling that, I'd
> definitely take a look at it.

why not take a look anyhoo?

btw, aplogies to all, the stupid demo won't run. I compiled & linked it
with full debugging, so it won't run standalone. I discovered that when
I got into the office Monday morning & D/Led it. Dagnabit, Musky! Expect
a running version Monday evening. In the meantime, you can still look at
the screen shots.

okbl...@my-deja.com

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to
In article <85uh7k$p6t$1...@nnrp1.deja.com>,

if_...@my-deja.com wrote:
> oddly enough, I was sober (this time round).

I'll believe it when I see the results from your urine sample.

> and a shift stick is easy till you try driving an automatic (bad
> example, really, I always drive shift & hate automatics). The point
> being that you don't know that you have a tedious chore until you get
> the labour saving device.

It *is* a lousy example but, yes, I was thinking the same thing.

> would those be the same folks who tell us that they never watch T.V,
or
> honestly believe that they work out regularly, watch what they eat,
etc?
> (i.e, the vast majority of us (me inluded)).

The peer pressure here is pretty intense.

> I might be able to talk the talk, but doubt very much if I could walk
> the walk.

Fair 'nuff.

> What's the point of yet another lanuage with less than a handful of
> users. Whenever the subject of such a GUI has come up in the past, it
> has always been stressed that it would only be accepted if it
supported
> an established language.

Dunno. But there people go, writing new languages every day...

> say what now? que est-ce que c#est, le "combinatorial explosion"?

Combinatorial explosion: You have a glass of water in your game, so you
try to make sure you've covered all the things that might happen if the
player tries pouring it out everywhere, then later you add a torch, so
you try to cover all the things he might burn with the torch--but you
also have to cover what happens if he tries to put out the torch with
the water. Later, you add a sealed envelope, so you handle
opening it, reading it, tearing it up, etc, but you also have to handle
what happens if the guy pours water on it, burns it, or attempts to
use the fire to heat the water to create steam so he can open it without
anyone knowing. Etc.

The combination of all actions with all objects applied to any other
object to create an effect. It's a bear. But ultimately, the hardest
thing has to be keeping track of all the possibilities.

> why not take a look anyhoo?

I did "look". When I said "I might take a look", what I really meant
was "I might actually invest some time in trying it out if it had a
really compelling feature, like handling combinatorial explosions."

> btw, aplogies to all, the stupid demo won't run. I compiled & linked
it
> with full debugging, so it won't run standalone. I discovered that
when
> I got into the office Monday morning & D/Led it. Dagnabit, Musky!
Expect
> a running version Monday evening. In the meantime, you can still look
at
> the screen shots.

Looks cool. Though not quite to my aesthetics. <g,d&r>

--
[ok]

if_...@my-deja.com

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to

> I'll believe it when I see the results from your urine sample.
If you post a snail mail address, I'll mail you some in a zip-loc bag &
you can have it analyzed.

> > and a shift stick is easy till you try driving an automatic (bad
> > example, really, I always drive shift & hate automatics). The point
> > being that you don't know that you have a tedious chore until you
get
> > the labour saving device.
>
> It *is* a lousy example but, yes, I was thinking the same thing.

which is why I think that such a thing could be really helpful

> The peer pressure here is pretty intense.

I guess that means that if I start, I'd better be prepared to stay the
course. That's why I'd rather have requirements up front.

> Dunno. But there people go, writing new languages every day...

and they never get used. Why don't these obviously creative folks write
some I-F instead?


> > say what now? que est-ce que c#est, le "combinatorial explosion"?
>
> Combinatorial explosion: You have a glass of water in your game, so
you
> try to make sure you've covered all the things that might happen if
the
> player tries pouring it out everywhere, then later you add a torch, so
> you try to cover all the things he might burn with the torch--but you
> also have to cover what happens if he tries to put out the torch with
> the water. Later, you add a sealed envelope, so you handle
> opening it, reading it, tearing it up, etc, but you also have to
handle
> what happens if the guy pours water on it, burns it, or attempts to
> use the fire to heat the water to create steam so he can open it
without
> anyone knowing. Etc.
>
> The combination of all actions with all objects applied to any other
> object to create an effect. It's a bear. But ultimately, the hardest
> thing has to be keeping track of all the possibilities.

hmm, maybe if you add whole bunch of new properties : isFlammable,
isSoggyable, etc, then the s/w could flag any such interacions which
don't have any special code written to handle them (the paper becomes
illegible when soaked).

However, that is a very powerful piece of AI. Frankly, I can code
anything that someone can specify; I just don't think that someone could
specify this exactly enough; I'd just get vague & wooly stuff.

> I did "look" at the screen shots.


> Looks cool. Though not quite to my aesthetics. <g,d&r>

great! so gimme some feedback. Like I said, if I produce it to _my_
aesthetics then unveil it, I'll get a bunch of folks telling me how I
*ought* to have done it. So, I'd like to ask those folks up front what
it should look & operate like.

C'mon, you've got you own personal slave coder here, folks. Just tell me
how you'd like it & I'll hack it out.

kar...@fermi2.chem.yale.edu

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to
if_...@my-deja.com wrote:

> Oh, why don't you just visit the web page, then
> give some feedback?

So I was pretty pessimistic when I headed over there. I'm a UNIX geek, and
I use xterms and text editors. But I have to admit it looked pretty slick.
The main question, of course, is not whether *I* will use it, but whether
lots of people (especially those who would otherwise not write IF) would
use it.

The main problem with GUI is that there's just so much depth to TADS.
(Disclaimer for zealots: I only know TADS, but this stuff probably applies
to other languages. Has to if you want interesting games.) I think you've
taken a very smart direction by having many of your input windows allow
arbitrary TADS code, since there's no way you could handle everything. (And
let me reiterate ok's point that using an existing language was a Good
Idea.) Nonetheless, I suspect you might still run into problems. For
example, you of course need to allow for arbitrary code for "north" etc.,
not just other room locations. And if said code returns a room, how will
your mapping software handle that? Maybe you could have it do nothing, but
have a couple drawing tools in the Map window to allow special paths with
writing on them or something. (Speaking of which, for Up/Down, I think a
lot of people pick an arbitrary location on the map square and put a little
'u' next to it, e.g.)

One important thing. As I said, it's great that you allow for arbitrary
TADS code, but I think you haven't given quite enough room for it. For
example, what if I want an object that's not of one of the classes in the
Objects window? Could you have a "other" button with a fill-in-the-blank?
Similarly, what if I want to add different properties to an object
(firstseen, or my_stupid_property, or whatever). I think you need a "add
property" functionality.

The important question you need to ask yourself when you write a GUI is
whether it actually makes things easier and/or faster. I'm not entirely
sure it's faster to have a "north" combobox from which to choose a
destination, rather than just writing "north = foo" in a text file.
And I'm not even convinced that PLUGH would be easier to use. Because you'd
still have to learn the intricacies of TADS for all the Code boxes, on top
of learning how to use the GUI tools.

You'll probably argue that most people don't want to do complicated stuff
when they start off. Maybe true. But I found even when I was trying to make
a simple little puzzle, I had to use more than just the basics (like location,
directions, searchHider).

Nonetheless, I could be wrong, so don't stop now. It's possible that this
could save time in coding up the basic map and object for a game---especially
if you have a *copy* object/room/etc. feature. You could then export the
TADS code, and add the more complicated stuff.

Oh. One more thing. I'm sure you've accounted for #include commands. You
might want to have a "Sophisticated Actor" option which would include
chatter.t and then add the twenty or thirty extra chatter options, along
with topic support. Perhaps you (or others) could add support for other
packages as well, although localized ones (like, say, phone.t :) would be
simpler than ones that make widespread changes, like sense.t. All that
could be added after the basic code was working.

I probably could have just said, "looks OK. Let's see how it turns out."
instead of writing all this. But you *asked* for feedback!

-Amir

M. David Krauss

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to
if_...@my-deja.com writes:

[sub-quotes snipped]

> and a shift stick is easy till you try driving an automatic (bad
> example, really, I always drive shift & hate automatics). The point
> being that you don't know that you have a tedious chore until you
> get the labour saving device.

And once you get the 'labour-saving device' you promptly forget the
greater control and freedom you had without it. Your example is
actually pretty good, in that light... :)


> Also, I think that the convenience of a GUI can be useful for more than
> just the map (but, let me know if you want a map drawing tool only, as
> that would be realtively simple to produce, compared with the full
> Magnum Opus).

Well... My primitivistic streak aside, I'd be thrilled to see your
magnum opus. But, nonetheless, notwithstanding, the map-tool would be
the logical first implementation step. Like the Gnome project first
released Glade, a GUI designer, and is following up with a full IDE
that utilizes Glade as a component. Er, okay, does anyone know what
I'm talking about?? Nevermind...

The point is, if you really Really want to go through with this, make
the mapper first, keeping in mind how it will fit in the broader
system. And good luck to you!

-M

(Mumbling and ducking back to his corner to work on Big Important
Secret Stuff)

M. David Krauss

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to
if_...@my-deja.com writes:

> C'mon, you've got you own personal slave coder here, folks. Just tell me
> how you'd like it & I'll hack it out.

Waait a minute. Personal slaves on the internet responding to textual
demands of strangers in cyberspace? Are you sure this thread doesn't
belong in the alt.*.erotica groups?

okbl...@my-deja.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
In article <85v2kj$582$1...@nnrp1.deja.com>,

if_...@my-deja.com wrote:
> If you post a snail mail address, I'll mail you some in a zip-loc bag
&
> you can have it analyzed.

Heh. Send it to 1600 Pennsylvania Avenue, c/o "I Wanna Have Your Baby,
Mr. President."

> which is why I think that such a thing could be really helpful

Indeed, it *could* be.

> I guess that means that if I start, I'd better be prepared to stay the
> course. That's why I'd rather have requirements up front.

Nah, you can always abandon the project and vanish into oblivion. Or
not. But still, better to aim for success. :-)

> and they never get used. Why don't these obviously creative folks
> write some I-F instead?

- reluctance to learn someone else's language
- lack of awareness
- dissatisfaction with the way the current systems handle things
- intrigued by the problems creating a new language presents

> hmm, maybe if you add whole bunch of new properties : isFlammable,
> isSoggyable, etc, then the s/w could flag any such interacions which
> don't have any special code written to handle them (the paper becomes
> illegible when soaked).

Yes, basically. But...

> However, that is a very powerful piece of AI. Frankly, I can code
> anything that someone can specify; I just don't think that someone
> could specify this exactly enough; I'd just get vague & wooly stuff.

I don't think it has to be vague and wooly--let me give a shot, right
here, to describing some specific stuff.

Combinations in IF are actions done to objects using one or more other
objects. The actor and all the objects, including the overall game
object, may be in various states. Now, how can the actions be presented
in such a way that illustrates this?

The author wants water in a game, so he adds a pool of water. The GUI
then presents all of the verbs in the game, maybe with default negatives
for certain things (like eating and drinking, which can't be done to
most objects). That would be the most basic display you could provide,
and not very complete, but at least the author would know what to code
for.

The trick after that would be knowing what and how to present the
settings for various verbs, and having a simple way to input a message.
For example, a lot of objects have requirements that must be met before
certain tasks can be performed. In order to take water, you must have a
container that can hold water.

I think you'd want some kind of tree, with each branch of the tree
getting more specific. Each branch would specify success or failure,
have an optional message, and sub-branches underneath would address
objects and combinations of objects:

Water
- Drink
succeeds "My, that's refreshing!"
- Take
fails "Ineffective. Besides, you just washed your hands."
with bottle
[full] fails "You'll have to empty it first."
[empty] succeeds "You fill the bottle."
with axe
with goldcoins
[etc.]

The first thing you'd want to do is make it possible to specify by
attribute as well as class:

- Take
with isLiquidContainer

And you'd want to be able to eliminate a whole bunch of nonsensical
object combinations. For example, "FILL BOTTLE WIITH WATER USING STRAW"
works, as might "HEAT WATER WITH TORCH CREATING STEAM TO OPEN LETTER",
but most combinations of objects are *never* going to make sense. If the
author can rule out those combinations up front, that will make the job
a lot easier.

The other thing that would make the job easier would be providing a way
to generalize. All (or even just most) liquids might behave the same way
as water, and all objects could have to respond to a makeWet type
action.

> great! so gimme some feedback. Like I said, if I produce it to _my_
> aesthetics then unveil it, I'll get a bunch of folks telling me how I
> *ought* to have done it. So, I'd like to ask those folks up front what
> it should look & operate like.

OK. I'll actually download it.

--
[ok]

if_...@my-deja.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to

> > I guess that means that if I start, I'd better be prepared to stay
the
> > course. That's why I'd rather have requirements up front.
>
> Nah, you can always abandon the project and vanish into oblivion.
why is why I'm not going to publish my real name until I'm sure that the
thing will be a success :-)

> > However, that is a very powerful piece of AI. Frankly, I can code
> > anything that someone can specify; I just don't think that someone
> > could specify this exactly enough; I'd just get vague & wooly stuff.
>
> I don't think it has to be vague and wooly--let me give a shot, right
> here, to describing some specific stuff.

< *BIG* snip>

well, that was certainly illuminating (isLightSource/isKnowledgeSource).
What makes such a tool even more of a Holy Grail & a Magnum Opus than my
modest effort is that it needs to be entirely user driven. When I'm
writing it, I can't forsee every possible attribute (isWearable,
isWritable, isLaunchable, etc). The user will be making more & more of
these as he designs his adventure. So, such a program needs a way of
allowing the user to specify the properties available; each time a new
properties is added, all verbs have to be upadted, to say whether they
affect/are affected by that property; every time a new verb is defined,
it has to take into account all existing properties.

The user still has to define the interactions (while teh number of
verbs/properties increases linearly, the number of possible interactions
increases exponentially). There may be as much manual work involved
entering all of this stuff as there would be trying to check it by
eye-ball.

I think my cop-out^H^H^H^H^H^H^answer ius that I am already on a roll
with the first tool & will add that to the wish list :-)^H^H^H

I may be able to add simple checks (fire/water, etc) in about verion 11
or 12 (currently planned for 2007/2008). It may take a little longer for
the full thing.

> > great! so gimme some feedback. Like I said, if I produce it to _my_
> > aesthetics then unveil it, I'll get a bunch of folks telling me how
I
> > *ought* to have done it. So, I'd like to ask those folks up front
what
> > it should look & operate like.
>
> OK. I'll actually download it.

Thanks a 1,000,000. Now, beware that there is a warning on the D/L page
saying that the mapping functionality doesn't quite work properly. This
is because I wanted to make sure that it would run on other PCs than
mine. There can sometimes be problems there, for instance I have the
development system (Borland C++ Builder) and you may not. I D/Led to
another P.C at home & sure enough it needed 3 Borland DLLS to run
(these are now in the D/L, bring it to about 900k, but you won't need
to D/L them in the future - only the .EXE, which is about 40k). In
addition, it had a problem with the map. However, I have just D/Led it
in the office & it runs fine. Please let me know how it is for you.

if_...@my-deja.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to

> The point is, if you really Really want to go through with this, make
> the mapper first, keeping in mind how it will fit in the broader
> system. And good luck to you!
the mapper will be pretty much functional today or tommorrow. I have got
"add room" working & am just trying to figure out the best ergonomics
for "add passage". I will add a separate post to ask a bunch of
questiosn about how folks might like to see this implemented.


> (Mumbling and ducking back to his corner to work on Big Important
> Secret Stuff)

Bigger that the 650 point Colossal Cave? More important than Plugh?
Secreter than (sorry, I can't mention that) ?

if_...@my-deja.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to

> > Oh, why don't you just visit the web page, then
> > give some feedback?
>
> So I was pretty pessimistic when I headed over there. I'm a UNIX geek
Me three! (I like Un*x twice as much as Windoze).


> But I have to admit it looked pretty slick.

muchos gracias. That sort of thing is relatively simple to throw
together quickly with Borland C++ builder. If they would port it to
Linux, I could free up a partition on my harddrive. Without C++ Builder,
I wouldn't even contemplate such a project.

> The main question, of course, is not whether *I* will use it, but
whether
> lots of people (especially those who would otherwise not write IF)
would
> use it.

It may be a momentum thing. If it doesn't get widely used, it won't be
widely discussed & I may be less motivated to continue. Otoh, if I get
it to the point that it actually actually runs and has a single user,
I'll feel duty bound to continue.


> The main problem with GUI is that there's just so much depth to TADS.

> I think you've
> taken a very smart direction by having many of your input windows
allow
> arbitrary TADS code, since there's no way you could handle everything.

Yep, that's the #1 shortcoming with other previous attempts - I believe
that it even gets a mention in the FAQ.

> Nonetheless, I suspect you might still run into problems. For
> example, you of course need to allow for arbitrary code for "north"
etc.,
> not just other room locations. And if said code returns a room, how
will
> your mapping software handle that?

damn good point.

> Maybe you could have it do nothing, but
> have a couple drawing tools in the Map window to allow special paths
with
> writing on them or something.

that was certainly what I was thinking of in the first version. For
instance, paths which are actually magic words "y2, plover" could be
shown as dotted lines.


> (Speaking of which, for Up/Down, I think
a
> lot of people pick an arbitrary location on the map square and put a
little
> 'u' next to it, e.g.)

I presume that you are replying to teh question on the web site about
how to represent directopns for which there isn't an obvious corner of
the box which represents the room? (Ping! ligh bulb! why do the rooms
have to be represented as rectangular? Couldn't I just add a few
corners?) I will address this in a new post today.


> One important thing. As I said, it's great that you allow for
arbitrary
> TADS code, but I think you haven't given quite enough room for it.

not physically, I guess? Those text boxes are scrollable.

> For example, what if I want an object that's not of one of the classes
in the
> Objects window? Could you have a "other" button with a
fill-in-the-blank?

Great idea. I could then add that new class to standard list of
selectable classes. I will put this on the to-do list (there's a whole
lot of stuff to be done before this is anywhere near ready).

> Similarly, what if I want to add different properties to an object
> (firstseen, or my_stupid_property, or whatever). I think you need a
"add
> property" functionality.

O.K, can do. Please keep pointing this sort of stuff out.

> The important question you need to ask yourself when you write a GUI
is
> whether it actually makes things easier and/or faster. I'm not
entirely
> sure it's faster to have a "north" combobox from which to choose a
> destination, rather than just writing "north = foo" in a text file.

Maybe not, it's the overview which the map offers which I see as the
bonus. Also, when you click on a room & see its contents, I intend that
you can just click on an item in the room to see its properties (click
on the item's location to return, click on the items contents, if any,
etc). I need to find how to colour code the map so that light/dark
rooms, rooms containing water/items/actors/puzzles/where spells
work/locked doors/etc are easily visible from this overview. This may
take some working out. Either a little coloured dot (or several) in the
room box on the map, or a series or keys letters (e.g, "DIS" for Dark,
Item, Spell).

> And I'm not even convinced that PLUGH would be easier to use. Because
you'd
> still have to learn the intricacies of TADS for all the Code boxes, on
top
> of learning how to use the GUI tools.

Sure, you have to learn TADS, there's no way around that. I'm hoping to
make Plugh so simple to operate that there is no learning curve.

> You'll probably argue that most people don't want to do complicated
stuff
> when they start off. Maybe true. But I found even when I was trying to
make
> a simple little puzzle, I had to use more than just the basics (like
location,
> directions, searchHider).

Ideally, it should default to simple stuff, but allow for guru
flexibility. Help guide me there.

> Nonetheless, I could be wrong, so don't stop now.

I don't intend to. I'll continue even without feedback, but tehn you'll
get my vision, not what you all out there want.

> It's possible that this
> could save time in coding up the basic map and object for a
game---especially
> if you have a *copy* object/room/etc. feature.

Noted & thanks (hadn't though of that yet).

> You could then export
the
> TADS code, and add the more complicated stuff.

Nope, because it must be round trip. When I save the file, I will add a
CRC. I don't want anyone hacking it around with an editor, as tehy may
destroy stuff needed by Plugh. In aact, I may just save it as binary. If
Plugh is designed correctly, you will be able to add code wherever
required from inside Plugh (and compile, debug & run your adventure).


> Oh. One more thing. I'm sure you've accounted for #include commands.

You have an overly high opinion of me. I've just thrown together the
graphic stuff 'cos C++ Builder makes it easy. I've tried to anticipate
future development, but don't knwo how successful I was.


> You
> might want to have a "Sophisticated Actor" option which would include
> chatter.t and then add the twenty or thirty extra chatter options,
along
> with topic support. Perhaps you (or others) could add support for
other
> packages as well, although localized ones (like, say, phone.t :) would
be
> simpler than ones that make widespread changes, like sense.t. All that
> could be added after the basic code was working.

An interesting future project; I will try to design in such a way that
it can be added later.

>
> I probably could have just said, "looks OK. Let's see how it turns
out."
> instead of writing all this. But you *asked* for feedback!

Amir, this is all *greatly* appreciated. Please give more & more & more.

> -Amir

if_...@my-deja.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
Well, there is some sort of a demo available (please let me know if you
D/L it on 1/18/00 & it gives an exception, "Read of address #FFFFFFFF".
This happened to me on a 2nd P.C, but not on a 3rd).

On the map currently, there are two hard coded rooms. You can drag them
around & watch the passge follow or double click to view/edit their
details.

I have now code for a pop up menu on the map & have coded "new room".
This prompts for a name, puts a room on the map (across & down a bit
from the currently active room) & opens the room view/edit screen.

Now for a bunch of usability questions. If there are no replies, I'll
code whatever seems ergonomcially best to me.

1) How to add passages? I see 2 possibilities. A) on the map, pop up
menu, "new passgae", then click on two rooms to connect them, which pops
up some selector box for directions. B) On the Room edit, choose the
"directions" tab. You will see that for each direction there is a drop
down menu containing all known rooms; you select from there.

I suppose that I could support both. A bit of hassle, so I might
implement one first & add the other later. Which first?

I incline towards B), which leads me to ask ... When I'm in the Lounge &
go North to the Kitchen, should that automatically add a passage south
from the Kitchen to the lounge (what if there is already a passage south
from the Kitchen to the Hall?)

Alernatively, I could say that it automatically adds a passage back, but
lets the user decide the direction (with a sensible default n/s se/nw
in/out, etc). Or, I could make all passages single direction, giving the
user twice the work & more chance to make mistakes.

I could impelment all & have an option on the configuration panel, so
that each user can set things to his own taste (I intend to make heavy
use of the configuration panel (room default = lighted/dark, etc)).

My idea is to implement B), to have it pop up a dialog box where
escape/cancel would leave a uni-directional path & return would accpet
the defaults. The dialog would name the current room & the linked to
room & offer a choice of directions back, with already used directions
greyed out & non-selectable.

2) should passages on the map be fixed to particular corners or
automatic (play with the demo to see what I mean - it's automatic). If a
particular corner, this may be tricky. The component which I use for a
passage attaches to 4 corners & 4 sides; what would I do for
in/out/up/down?

3) (how) should I (colour) code the map? Should dark rooms be marked
with black, water sources with blue, fire with red, etc? Should I mark
locked doors & puzzles?

It all seems very sensible, the only question is how to mark. I can
change the colour of the background in the room's box on the map; I can
also change the text colour of the room's name; I can change the outside
bevel of the box (but I'm currently doing this to indicate the currently
active room). So, not so many permutations & we're sure to want more.

I could add some little coloured dots in the box (say, above the name).
Or I could just have a single property (different background, text a
different colour) to indicate that there's something special about a
room.

I could then add a tools tip, such that when the user hovers the cursor
over the room on the map, a little text box pops up showing what is
special about the room (the box would automatically disappear when the
cursor moves away from the room).

I don't think that I want to let the map become too cluttered. What do
you think?

4) which leads me to ask if you want me to label the passages with
directions? This could be user configurable, I may add it to the next
demo, so that we can see how it looks.

I'd like to have the demos coming out every day or 2 at first, which
means that they are more likely to be graphical bells & whistles than
serious functionality. It will any case take months to be complete, but
I want the user interface specified pretty quickly.

Please provide feedback & gelp keep me motivated:-)

The demo is at http://plugh.tsx.org

okbl...@my-deja.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
In article <8616fs$n0s$1...@nnrp1.deja.com>,

if_...@my-deja.com wrote:
>
> why is why I'm not going to publish my real name until I'm sure that
the
> thing will be a success :-)

Aw, come on. Tell us who you are. Take your hits like a man. Er,
woman. Er...whatever.

> well, that was certainly illuminating
(isLightSource/isKnowledgeSource).
> What makes such a tool even more of a Holy Grail & a Magnum Opus than
my
> modest effort is that it needs to be entirely user driven. When I'm
> writing it, I can't forsee every possible attribute (isWearable,
> isWritable, isLaunchable, etc). The user will be making more & more of
> these as he designs his adventure. So, such a program needs a way of
> allowing the user to specify the properties available; each time a new
> properties is added, all verbs have to be upadted, to say whether they
> affect/are affected by that property; every time a new verb is
defined,
> it has to take into account all existing properties.

Yep. But you're going to have to be able to make that stuff highly
customizable anyway. Otherwise every time I need to work with even a
simple attriibute, I'm going to have to drop back into straight code
mode--and then why am I using the GUI?

> The user still has to define the interactions (while teh number of
> verbs/properties increases linearly, the number of possible
interactions
> increases exponentially). There may be as much manual work involved
> entering all of this stuff as there would be trying to check it by
> eye-ball.

The eye-ball advantage would be in explicitly ruling out large classes
of actions and combinations.

> I think my cop-out^H^H^H^H^H^H^answer ius that I am already on a roll
> with the first tool & will add that to the wish list :-)^H^H^H

OK. What is it you wanted feedback for? ;-)

> I may be able to add simple checks (fire/water, etc) in about verion
11
> or 12 (currently planned for 2007/2008). It may take a little longer
for
> the full thing.

I'm not going anywhere....

> Thanks a 1,000,000. Now, beware that there is a warning on the D/L
page
> saying that the mapping functionality doesn't quite work properly.
This
> is because I wanted to make sure that it would run on other PCs than
> mine. There can sometimes be problems there, for instance I have the
> development system (Borland C++ Builder) and you may not. I D/Led to
> another P.C at home & sure enough it needed 3 Borland DLLS to run
> (these are now in the D/L, bring it to about 900k, but you won't need
> to D/L them in the future - only the .EXE, which is about 40k). In
> addition, it had a problem with the map. However, I have just D/Led it
> in the office & it runs fine. Please let me know how it is for you.

Doesn't C++ Builder come with Install Shield Express for JUST such
situations?

--
[ok]

okbl...@my-deja.com

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
In article <861b7q$qt4$1...@nnrp1.deja.com>,

if_...@my-deja.com wrote:
> Well, there is some sort of a demo available (please let me know if
you
> D/L it on 1/18/00 & it gives an exception, "Read of address
#FFFFFFFF".
> This happened to me on a 2nd P.C, but not on a 3rd).

It starts. It gives me a lot of different exceptions when I try to do
stuff. My favorite is "A Win32 API failed." Well, duh. You're supposed
to code around those random failures. ;-)

> On the map currently, there are two hard coded rooms. You can drag
them
> around & watch the passge follow or double click to view/edit their
> details.

OK. I prefer the display to be dynamic. Right now you turn the cursor
inito a drag icon and wait for the guy to drop the room before showing
the new placement. The change should be visible as you move, or you end
up fiddling to get your lines straight.

> I have now code for a pop up menu on the map & have coded "new room".
> This prompts for a name, puts a room on the map (across & down a bit
> from the currently active room) & opens the room view/edit screen.

And removes the map view. Uh-uh. Less modality. One window more map, one
for property editing.

And get your tabs ironed out. There's going to be a lot of text entry
going on, so making your app touch-typist friendly is key.

> 1) How to add passages? I see 2 possibilities. A) on the map, pop up
> menu, "new passgae", then click on two rooms to connect them, which
pops
> up some selector box for directions. B) On the Room edit, choose the
> "directions" tab. You will see that for each direction there is a drop
> down menu containing all known rooms; you select from there.

Yuck to both. Let me drag the mouse from one room to another. You can
make this work with the drag-and-drop room feature a number of ways,
like adding tabs around the room for north, south, east, west, etc., or
by having a special mapping-mode tool or allowing the user to use the
other mouse button, or whatever.

For typists, "n", "s", "e", "u", etc. aren't doing anything else, so why
not allow those keys to add rooms in those directions?

Let the user modify the name of the room from inside the map view so
that it becomes VERY easy to churn out a quick skeleton map for an
adventure.

> I incline towards B), which leads me to ask ... When I'm in the Lounge
&
> go North to the Kitchen, should that automatically add a passage south
> from the Kitchen to the lounge

Yes.

> (what if there is already a passage south
> from the Kitchen to the Hall?)

Issue a non-intrusive warning on the status line. "WARNING: One-way
passage added." Allow the user to select as a feature a complementary
passage constructor. In other words, if there already is a passage south
from the Kitchen, the program (optionally, again) pops up a dialog for a
passage from the Kitchen to the Lounge, where the user only has to type
in the directiion.

> I could impelment all & have an option on the configuration panel, so
> that each user can set things to his own taste (I intend to make heavy
> use of the configuration panel (room default = lighted/dark, etc)).

Yeah, but that ocnfiguration panel has to go. :-)

> My idea is to implement B), to have it pop up a dialog box where
> escape/cancel would leave a uni-directional path & return would accpet
> the defaults. The dialog would name the current room & the linked to
> room & offer a choice of directions back, with already used directions
> greyed out & non-selectable.

Make it optional. The key thing your GUI needs to compete with is the
speed of doing things by hand in text.

> 2) should passages on the map be fixed to particular corners or
> automatic (play with the demo to see what I mean - it's automatic). If

They should make as much sense as they can. North should go up, south
should go down. The user should be able to customize with curves and
corners to make the map neat.

> particular corner, this may be tricky. The component which I use for a
> passage attaches to 4 corners & 4 sides; what would I do for
> in/out/up/down?

Up and down should extend from points inside the room and be placed
in northerly and southerly directions respectively. Clear
representatioin of these rooms is a little trickier.

> 3) (how) should I (colour) code the map? Should dark rooms be marked
> with black, water sources with blue, fire with red, etc? Should I mark
> locked doors & puzzles?

There's probably not much use for a fixed set of color codes. Let the
user choose what properties should have what color/icon/representation.

The properties simply *must* be extensible. A series of check boxes
isn't going to cut it. The author must be able to define room classes
and object classes.

Lighted/Dark and nested is fine, but doorway and locked properties
should be characteristics of a particular exit.

> It all seems very sensible, the only question is how to mark. I can
> change the colour of the background in the room's box on the map; I
can
> also change the text colour of the room's name; I can change the
outside
> bevel of the box (but I'm currently doing this to indicate the
currently
> active room). So, not so many permutations & we're sure to want more.

The bevel could be used to indicate higher and lower rooms, maybe.

> I could then add a tools tip, such that when the user hovers the
cursor
> over the room on the map, a little text box pops up showing what is
> special about the room (the box would automatically disappear when the
> cursor moves away from the room).

Good idea.

> 4) which leads me to ask if you want me to label the passages with
> directions? This could be user configurable, I may add it to the next
> demo, so that we can see how it looks.

Yes, make it configurable. Maybe only default to using it for up and
down and non-standard directions like EXIT and ENTER, XYZZY, GO THERE
and others.

> Please provide feedback & gelp keep me motivated:-)

There's some feedback for you. Dunno if it helps you stay motivated.<g>

R Blaylock

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to


if_...@my-deja.com wrote:

> Oh, why don't you just visit the web page, then
> give some feedback?
>

Just downloaded and experimented with plugh. It seems pretty simple and
straightforward to use, which would be perfect for someone like myself.
Many years ago I was studying computer programming, but I was led down
another career path and my programming went by the wayside. I have
downloaded TADS and, using the manual, have started to work on my own IF
creation. I have been looking for something just like this to aid in
the development of my story.

Of course, I am not so naive to think that I will need no programming
knowledge, but with a GUI such as this it will make the repetetive
programming of rooms and similar items much simpler, allowing me to
spend more time concentrating and learning how to develop actors, and
working on the storyline, rather than programming several different
light sources, beds, chairs, etc.

I like what you're doing, and can't wait to see the finished project.


Daniel Barkalow

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
On Tue, 18 Jan 2000 if_...@my-deja.com wrote:

> > You could then export the
> > TADS code, and add the more complicated stuff.
> Nope, because it must be round trip. When I save the file, I will add a
> CRC. I don't want anyone hacking it around with an editor, as tehy may
> destroy stuff needed by Plugh. In aact, I may just save it as binary. If
> Plugh is designed correctly, you will be able to add code wherever
> required from inside Plugh (and compile, debug & run your adventure).

The problem with this is that it will make it impossible to get the source
to someone else's text adventure and use Plugh to edit it or view
it. This may be necessary to avoid having to do human-level spacial
reasoning to get the map to look nice when generated on the fly, of
course, but it's something to wish for.

Also, you should make sure the format is such that you can share files
between the Windows version and the HP/UX port that someone will do
eventually, and also export results to show the game source to people who
don't have your program.

-Iabervon
*This .sig unintentionally changed*


kar...@fermi2.chem.yale.edu

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
R Blaylock <mrbla...@prodigy.net> wrote:

> if_...@my-deja.com wrote:

> Just downloaded and experimented with plugh. It seems pretty simple and
> straightforward to use, which would be perfect for someone like myself.

> Of course, I am not so naive to think that I will need no programming


> knowledge, but with a GUI such as this it will make the repetetive
> programming of rooms and similar items much simpler, allowing me to
> spend more time concentrating and learning how to develop actors, and
> working on the storyline, rather than programming several different
> light sources, beds, chairs, etc.

This is what I meant when I said I wasn't convinced, even if you are.
If you're going to have several chairs, make one chair and use copy & paste
to get n chairs. That doesn't take fancy programming skill, and probably
takes less time than loading up a separate application and clicking your
way through various menus to use the copy function within the program and
then clicking through the various objects to change the couple of
properties you want to change.

It's one thing to use a word processor because you want to know what the
output is going to look like. (E.g. that's IMO the main problem with
TeX---you have to debug your equations using compile/fix cycles.
<plug>Which is why I like LyX</plug>.) I can sort of see if's point that
being able to look at the map and access various rooms etc. from it is
convenient. But I don't really see how this will remove the tedium.

-Amir


kar...@fermi2.chem.yale.edu

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
if_...@my-deja.com wrote:

>> (Speaking of which, for Up/Down, I think
> a
>> lot of people pick an arbitrary location on the map square and put a
> little
>> 'u' next to it, e.g.)
> I presume that you are replying to teh question on the web site about
> how to represent directopns for which there isn't an obvious corner of
> the box which represents the room? (Ping! ligh bulb! why do the rooms
> have to be represented as rectangular? Couldn't I just add a few
> corners?) I will address this in a new post today.

Still not sure that the idea of adding corners is the best. I think people
expect rectangles. Why not just use a rectangle, and have all "interesting"
routes end up at a given point, say, between sw and s?

>> One important thing. As I said, it's great that you allow for
> arbitrary
>> TADS code, but I think you haven't given quite enough room for it.
> not physically, I guess? Those text boxes are scrollable.

No, I meant you're not allowing TADS code in enough *circumstances*, as
I described later.

>> The important question you need to ask yourself when you write a GUI
> is
>> whether it actually makes things easier and/or faster. I'm not
> entirely
>> sure it's faster to have a "north" combobox from which to choose a
>> destination, rather than just writing "north = foo" in a text file.
> Maybe not, it's the overview which the map offers which I see as the
> bonus. Also, when you click on a room & see its contents, I intend that
> you can just click on an item in the room to see its properties (click
> on the item's location to return, click on the items contents, if any,
> etc). I need to find how to colour code the map so that light/dark
> rooms, rooms containing water/items/actors/puzzles/where spells
> work/locked doors/etc are easily visible from this overview. This may
> take some working out. Either a little coloured dot (or several) in the
> room box on the map, or a series or keys letters (e.g, "DIS" for Dark,
> Item, Spell).

> Sure, you have to learn TADS, there's no way around that. I'm hoping to


> make Plugh so simple to operate that there is no learning curve.

Ha! Ahem, sorry. *Everyone* who makes a GUI wants to make it so simple to
operate that there's no learning curve. However, if you want any but the
most basic functionality, someone will find something you do
counterintuitive. Trust me. (Any GUI with more than, say, one button will
be misunderstood by somebody.)

>> You could then export
> the
>> TADS code, and add the more complicated stuff.
> Nope, because it must be round trip. When I save the file, I will add a
> CRC. I don't want anyone hacking it around with an editor, as tehy may
> destroy stuff needed by Plugh. In aact, I may just save it as binary. If
> Plugh is designed correctly, you will be able to add code wherever
> required from inside Plugh (and compile, debug & run your adventure).

I'm strongly against this sort of policy. Can't you trust people just a
little bit? There's nothing wrong with putting a "#This file written by
PLUGH. PLEASE don't mess with it unless you know what you're doing!" at the
top of each file. But there are oh so many reasons to keep it ASCII:

- what that other post mentioned about letting other people see the
source code even if they don't have PLUGH.

- what if I'm logging in to work from home, and I don't have the ability or
bandwidth to handle a GUI?

- what if I want to change Edna to Ernestine? OK, maybe I just thought of
this because I'm a perl geek but it would take about 10 seconds in Perl
and might take a week with a GUI.

- what if your GUI isn't perfect yet and there's some extra code I need to
add? E.g. if you haven't yet added the code to let me put arbitrary
methods in the "north" property.

Frankly, I would be happiest with a program that could read in a TADS game
I've partly written, and let me see what the map looks like, etc., tinker
with it, then write out TADS code that will look similar to what I had
before. Admittedly, this is Hard, because it means you need to account for
arbitrary coding standards in your file reading routines. But even if you
don't do this, I would like the program much more if I could change, say, a
typo without having to load up the GUI, and page through menus to find what
I need. The upshot: GUIs are VERY useful, but you should never think
they're the only useful tool, or that someone would want to use them
always. (That's why those of us who like Unix like Unix. We've got GUIs for
GUI things, but xterms for non-GUI.)

>> Oh. One more thing. I'm sure you've accounted for #include commands.
> You have an overly high opinion of me. I've just thrown together the
> graphic stuff 'cos C++ Builder makes it easy. I've tried to anticipate
> future development, but don't knwo how successful I was.

OK. Well, #include's are IMO essential.

>> [howabout chatter?]


> An interesting future project; I will try to design in such a way that
> it can be added later.

That's fair.

> Amir, this is all *greatly* appreciated. Please give more & more & more.

You asked for it!

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
if_...@my-deja.com wrote:

> 1) How to add passages? I see 2 possibilities. A) on the map, pop up
> menu, "new passgae", then click on two rooms to connect them, which pops
> up some selector box for directions. B) On the Room edit, choose the
> "directions" tab. You will see that for each direction there is a drop
> down menu containing all known rooms; you select from there.

> I suppose that I could support both. A bit of hassle, so I might


> implement one first & add the other later. Which first?

Seems to me like A is fine. For a first step towards B, you could let the
user type in the destination room.

> I incline towards B), which leads me to ask ... When I'm in the Lounge &
> go North to the Kitchen, should that automatically add a passage south

> from the Kitchen to the lounge (what if there is already a passage south


> from the Kitchen to the Hall?)

> My idea is to implement B), to have it pop up a dialog box where


> escape/cancel would leave a uni-directional path & return would accpet
> the defaults. The dialog would name the current room & the linked to
> room & offer a choice of directions back, with already used directions
> greyed out & non-selectable.

Remember. The point of GUI is to save time and tedium. IMO, pressing an
extra return every time you make a passage is tedious. Wouldn't you agree
that in the vast majority of games, the vast majority of passages are
two-way? And going north to a room means you can go south to get back? Yes,
many games have sw instead of s, but still, that's the exception to the
rule. You shouldn't have a dialog box if 99% of the time you'll pick one of
the choices. Just have a passage editor that lets you change it for special
cases.

> (I intend to make heavy use of the configuration panel (room default =
> lighted/dark, etc)).

Configuration is Good. Too much configuration is Bad, because you can't
find the thing you're trying to configure. You can partially get around
this by intelligently organizing your configure window. But remember that
someone else will think the north/south thing should be configured under
"rooms" not under "passages". So don't overconfigure.

> 3) (how) should I (colour) code the map? Should dark rooms be marked
> with black, water sources with blue, fire with red, etc? Should I mark
> locked doors & puzzles?

How many games have a water source that actually matters in the game? Same
question for fire. While it might make the GUI look fancy, I don't think
it'll help usability at all. I mean, the author probably knows that the sink
is in the kitchen. If you mark doors, it's probably not hard to mark locked
ones. Again, though, how useful is that to the author?

> It all seems very sensible, the only question is how to mark. I can
> change the colour of the background in the room's box on the map; I can
> also change the text colour of the room's name; I can change the outside
> bevel of the box (but I'm currently doing this to indicate the currently
> active room). So, not so many permutations & we're sure to want more.

> I could add some little coloured dots in the box (say, above the name).

As you say, there's many properties that you might like to mark, and only
so much to work with. And I thought the GUI was supposed to have no
learning curve. Changing the color of the room name, or the room
background, or having lots of colored dots, will NOT be intuitive! A little
picture of fire might be intuitive, but as I said, I don't think it would
be useful.

> Or I could just have a single property (different background, text a
> different colour) to indicate that there's something special about a
> room.

How many rooms aren't "special"? How many rooms are lit rooms with no
puzzles? One of the "howto write IF" essays talks about how you should have
as few rooms as necessary for your game. So probably most of your rooms
will be special. How will it help to have 70% of your room names written in
green text instead of black?

> I could then add a tools tip, such that when the user hovers the cursor
> over the room on the map, a little text box pops up showing what is
> special about the room (the box would automatically disappear when the
> cursor moves away from the room).

Define special! I just don't think it's worth it. Especially since after
they first map out the game, the authors will know (only too well) where
each puzzle etc. is.

> I don't think that I want to let the map become too cluttered. What do
> you think?

I agree. Hiking maps don't show exit numbers, road maps don't show the tree
line, physical maps don't show roads. Don't put in stuff you don't need.

> 4) which leads me to ask if you want me to label the passages with
> directions? This could be user configurable, I may add it to the next
> demo, so that we can see how it looks.

That's the point of using rectangles! So that the GUI map is intuitive. If
you have to read everything, why not use a text editor? You just need to
label u/d and other fancy directions.

> I'd like to have the demos coming out every day or 2 at first, which
> means that they are more likely to be graphical bells & whistles than
> serious functionality. It will any case take months to be complete, but
> I want the user interface specified pretty quickly.

Good luck coding that fast!

> Please provide feedback & gelp keep me motivated:-)

I'm sorry. My gelp machine ran out this morning.

-Amir

R Blaylock

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to

>
>
> This is what I meant when I said I wasn't convinced, even if you are.
> If you're going to have several chairs, make one chair and use copy & paste
> to get n chairs. That doesn't take fancy programming skill, and probably
> takes less time than loading up a separate application and clicking your
> way through various menus to use the copy function within the program and
> then clicking through the various objects to change the couple of
> properties you want to change.
>
> It's one thing to use a word processor because you want to know what the
> output is going to look like. (E.g. that's IMO the main problem with
> TeX---you have to debug your equations using compile/fix cycles.
> <plug>Which is why I like LyX</plug>.) I can sort of see if's point that
> being able to look at the map and access various rooms etc. from it is
> convenient. But I don't really see how this will remove the tedium.
>
> -Amir

I also agree with what you are saying, but, it doesn't take long before you
have several pages in a word processor to sort thru to copy and paste each
item. Then you have to worry about renaming each object in order to compile
the game correctly. I think it would be easier to point and click with minimal
coding for each object, and simple variable names to plug into the plugh
compiler.

Just MHO, for what it's worth.

Rodney Blaylock


if_...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to

> > Nope, because it must be round trip. When I save the file, I will
add a
> > CRC. I don't want anyone hacking it around with an editor, as tehy
may
> > destroy stuff needed by Plugh. In aact, I may just save it as
binary. If
> > Plugh is designed correctly, you will be able to add code wherever
> > required from inside Plugh (and compile, debug & run your
adventure).
>
> The problem with this is that it will make it impossible to get the
source
> to someone else's text adventure and use Plugh to edit it or view
> it. This may be necessary to avoid having to do human-level spacial
> reasoning to get the map to look nice when generated on the fly, of
> course, but it's something to wish for.
>
> Also, you should make sure the format is such that you can share files
> between the Windows version and the HP/UX port that someone will do
> eventually, and also export results to show the game source to people
who
> don't have your program.

Hmmm, you're absolutely correct of course. I'm not yet at save/restore,
though it will come reasonably soon. I will save as a plain text file
and make any Plugh specific stuff a TADS comment. Of course, if anyone
messes with any of the comments, they will have a file which Plugh won't
accept any more (but which TADS will). Hmmm, maybe I _should_ stick to
a proprietary save file format and include an export function to spit
out a plain text TADS file?

David Cornelson

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
<okbl...@my-deja.com> wrote in message news:85thsr$3v6$1...@nnrp1.deja.com...

> In article <85t873$tel$1...@nnrp1.deja.com>,
> if_...@my-deja.com wrote:
> > I was playing around & decided to see how
> > difficult it would be to develop a tool which
> > would allow me to develop I-F using a GUI.
>

And I'm working on an Inform GUI with similarities to this...

> The thing I think a GUI could be really useful for is handling

> combinatorial explosion. If you had a system for handling that, I'd


> definitely take a look at it.

> --

I have every intention of allowing the user of Visual Inform to do some of
the following things:

1. Click a check box that automatically turns on or off additional text in
your room descriptions for exits in a format of your choosing.

2. Click on a button and a list of undefined nouns appears and you can
create quick text references for them. As you progress through your game,
you can reuse or overwrite these references. This basically would allow you
to make a reference to everything in your game without all of the braindrain
of creating scattered objects for each little tiny detail. Visual Inform
will manage it - you just type text. How many times have you written the
following text?

Object stone "stone" with name 'stone', description "It's just a damn
stone - leave it alone!", has scenery;

VI will allow you to click on 'stone' and type in the description. It will
do the rest for you, including placing it in multiple locations using the
found_in property.

3. Same goes for combinatorial explosion - I'm sure I can create an
interface that will make it easier to handle adding objects that require
reactions in multiple places. If you add the ability to 'THROW EGG', Visual
Inform will help you deal with the disparate consequences of throwing that
egg in different locations.

Of course this is all dreams as of today - I have an interface, but it's
going to take some time. I'm not releasing anything until it's usable. I
might release screen shots for feedback, but my guess is that no one will
really appreciate this sort of thing until they can use it and actually make
it do something constructive.

Jarb


if_...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
In article <862k48$6bi$4...@news.ycc.yale.edu>,
kar...@fermi2.chem.yale.edu wrote:

> if_...@my-deja.com wrote:
> Still not sure that the idea of adding corners is the best. I think
people
> expect rectangles. Why not just use a rectangle, and have all
"interesting"
> routes end up at a given point, say, between sw and s?
for teh time being, it's automatic. I'll work on this, but not at
highest priority. That may mean problems for rooms with > 8 exits, so
obviously it will have to be done in the finished product, but will have
lower priority in the prototype. I'm trying to keep momentum going &
collect feedback, so I'm adding stuff where the least coding has the
most effect first, to keep your interest whetted. The "lotsa code for
little effect" comes later :-)

> Ha! Ahem, sorry. *Everyone* who makes a GUI wants to make it so simple
to
> operate that there's no learning curve. However, if you want any but
the
> most basic functionality, someone will find something you do
> counterintuitive. Trust me. (Any GUI with more than, say, one button
will
> be misunderstood by somebody.)

I concur 100%. Let's just set the usually wooly target - to make it as
simple & intuitive to operate for most folks as possible ( & add lots
of tools tips, help files, wizards & tutorials as possible (eventually
<g>)).

>> [snipped my suggestion of a propietary save file format]


> I'm strongly against this sort of policy. Can't you trust people just
a
> little bit? There's nothing wrong with putting a "#This file written
by
> PLUGH. PLEASE don't mess with it unless you know what you're doing!"
at the
> top of each file. But there are oh so many reasons to keep it ASCII:

well, I agreed with the previous post & I agree with you. I would still
like to have a propietary file format with the ability to spit out a an
ascii, TADS only file. Is this an acceptable compromise. I'd just like
to idiot proof it, cos - sure as eggs is eggs - someone will delete some
of the Plugh commentary & it won't reload (you know yourself - all users
are idiots (and that includes me)).

If you feel very strongly, I will keep it plain text.


> - what that other post mentioned about letting other people see the
> source code even if they don't have PLUGH.

would the Export option suffice?


> - what if I'm logging in to work from home, and I don't have the
ability or
> bandwidth to handle a GUI?

don't quite follow? you won't be running Plugh over any bandwidth (I
hope).

> - what if I want to change Edna to Ernestine? OK, maybe I just thought
of
> this because I'm a perl geek but it would take about 10 seconds in
Perl
> and might take a week with a GUI.

Either fire up Plugh, or hex edit teh save file. Otherwise the above
mentioned idiots will do a global replace & eventually will
conicidentally replace a Plugh keyword in a comment somewhere (instead
of edna, you type enda & take out my Plugh "endAdjective" code. Or
maybe I even use Edna, correctly spelled somewhere)).


> - what if your GUI isn't perfect yet and there's some extra code I
need to
> add? E.g. if you haven't yet added the code to let me put arbitrary
> methods in the "north" property.

Excellent point. That argues strongly for a plain text save file. (of
course, you could always submit a bug report & wait for me to update
Plugh <g>).


> Frankly, I would be happiest with a program that could read in a TADS
game
> I've partly written, and let me see what the map looks like, etc.,
tinker
> with it, then write out TADS code that will look similar to what I had
> before. Admittedly, this is Hard, because it means you need to account
for
> arbitrary coding standards in your file reading routines.

hmm, very good idea. I will aim to include this in version 2.

> > Amir, this is all *greatly* appreciated. Please give more & more &
more.
>
> You asked for it!

and more & more & more & more (give it to me, big boy).

I fully intend to complete Plugh, but if it falls to the wayside, this
is the bets thread that I've ever found about just what such an I-F
development GUI should do. Please keep adding to it.

if_...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to

> It starts. It gives me a lot of different exceptions when I try to do
> stuff. My favorite is "A Win32 API failed." Well, duh. You're
supposed
> to code around those random failures. ;-)
Ooops! of course, it works for me, cos I've got all the development
environment on my machine. I've only just discovered how to produce a
standalone .EXE and will upload one tonite (19th Jan, GMT +1). I am
sure that exceptions are not because of bad code, rather because of bad
environment (but we'll know tomorrow, won't we <g> ?).


> > On the map currently, there are two hard coded rooms. You can drag
> them
> > around & watch the passge follow or double click to view/edit their
> > details.
> OK. I prefer the display to be dynamic. Right now you turn the cursor
> inito a drag icon and wait for the guy to drop the room before showing
> the new placement. The change should be visible as you move, or you
end
> up fiddling to get your lines straight.

I will look at this, it should be a flag somewhere. But, if Borland C++
builder/Windows doesn't offer this, then it might take a lot of work
:-(


> > I have now code for a pop up menu on the map & have coded "new
room".
> > This prompts for a name, puts a room on the map (across & down a bit
> > from the currently active room) & opens the room view/edit screen.
>
> And removes the map view. Uh-uh. Less modality. One window more map,
one
> for property editing.

Well, I had thought that that was better - you have created a new room,
so want to add at least a short description, if not a long description,
a few items, etc.

I suspect that creation is a personal thing. From what you write later,
I believe that you draw the whole map first before fleshing out the
rooms, items, etc. I'll add an option to the configuration.

> And get your tabs ironed out. There's going to be a lot of text entry
> going on, so making your app touch-typist friendly is key.

will be done (but probably low priotiry, please see my later post
today).

> > 1) How to add passages? I see 2 possibilities. A) on the map, pop up
> > menu, "new passgae", then click on two rooms to connect them, which
> pops
> > up some selector box for directions. B) On the Room edit, choose the
> > "directions" tab. You will see that for each direction there is a
drop
> > down menu containing all known rooms; you select from there.
>
> Yuck to both. Let me drag the mouse from one room to another. You
can
> make this work with the drag-and-drop room feature a number of ways,
> like adding tabs around the room for north, south, east, west, etc.,
or
> by having a special mapping-mode tool or allowing the user to use the
> other mouse button, or whatever.

sorry about your Yuck :-) I see B) as a must & have already implemented
it. If it's not there, many people will complain & demand it there.

It would require a mega work to add tabs as you suggest. I will only do
it if there is a lot of demand (sorry, honestly, its just that if I've
got something working, I want to work on something else. Once I have a
working version, I can afford teh time to tweak it. Hope you
understand).

I will try to add option A) today, for you map first guys.

> For typists, "n", "s", "e", "u", etc. aren't doing anything else, so
why
> not allow those keys to add rooms in those directions?

sounds good (of course ALT+N, etc is much easier to implement - can you
live with that - at least at first?).

> Let the user modify the name of the room from inside the map view so
> that it becomes VERY easy to churn out a quick skeleton map for an
> adventure.

O.K, fairly trivial, should be in by the weeknd.

> > I incline towards B), which leads me to ask ... When I'm in the
Lounge
> &
> > go North to the Kitchen, should that automatically add a passage
south
> > from the Kitchen to the lounge
> Yes.

offered as default, hit enetr to accpt, but you can change it (see
latest d/l).


> > (what if there is already a passage south
> > from the Kitchen to the Hall?)
> Issue a non-intrusive warning on the status line. "WARNING: One-way
> passage added." Allow the user to select as a feature a complementary
> passage constructor. In other words, if there already is a passage
south
> from the Kitchen, the program (optionally, again) pops up a dialog for
a
> passage from the Kitchen to the Lounge, where the user only has to
type
> in the directiion.

Didn't handle this last night - I would propose that I offer a list of
directions with all used ones grayed out.


> > I could impelment all & have an option on the configuration panel,
so
> > that each user can set things to his own taste (I intend to make
heavy
> > use of the configuration panel (room default = lighted/dark, etc)).
>
> Yeah, but that ocnfiguration panel has to go. :-)

Hmm, what do you suggest to replace it? I fear that it has to stay & be
extended & extended & extended.


[snip]


> Make it optional. The key thing your GUI needs to compete with is the
> speed of doing things by hand in text.

Yeees. Mostly. It certainly shouldn't take longer. But I think that
automation is bonus too.


> > 2) should passages on the map be fixed to particular corners or
> > automatic (play with the demo to see what I mean - it's automatic).
If
> They should make as much sense as they can. North should go up, south
> should go down. The user should be able to customize with curves and
> corners to make the map neat.

I'll implement "North should go up, south should go down" (probably as
another damned option <G>). Anything other than stright lines will
require major work & is for a later phase.

> > particular corner, this may be tricky. The component which I use for
a
> > passage attaches to 4 corners & 4 sides; what would I do for
> > in/out/up/down?
> Up and down should extend from points inside the room and be placed
> in northerly and southerly directions respectively. Clear
> representatioin of these rooms is a little trickier.

Yes, I guess so. It's a little more work, so I will go with automatic
for the time being & add that in a few weeks.

> > 3) (how) should I (colour) code the map? Should dark rooms be marked
> > with black, water sources with blue, fire with red, etc? Should I
mark
> > locked doors & puzzles?
> There's probably not much use for a fixed set of color codes. Let the
> user choose what properties should have what
color/icon/representation.

agreed, especially because of your next point.

> The properties simply *must* be extensible. A series of check boxes
> isn't going to cut it. The author must be able to define room classes
> and object classes.

o.k, I ought to be able to do something with a list box & the standard
colour selection tool. It sounds like a few people want a mapper first,
then the rest of the functionality.

> Lighted/Dark and nested is fine, but doorway and locked properties
> should be characteristics of a particular exit.

I can colur code or annotate the passage, use a different arrow ehad, or
a dotted arrow line, etc. But shouldn't doorways be shown as rooms in
their own right anyway?

> The bevel could be used to indicate higher and lower rooms, maybe.

hmm, good idea, as long as it doiesn't interfere with the current room
indication (maybe I can do that with the background colour of the box).

> > I could then add a tools tip, such that when the user hovers the
> cursor
> > over the room on the map, a little text box pops up showing what is
> > special about the room (the box would automatically disappear when
the
> > cursor moves away from the room).
> Good idea.

o.k, it's on the To Do list.

> > 4) which leads me to ask if you want me to label the passages with
> > directions? This could be user configurable, I may add it to the
next
> > demo, so that we can see how it looks.

will do

> Yes, make it configurable. Maybe only default to using it for up and
> down and non-standard directions like EXIT and ENTER, XYZZY, GO THERE
> and others.

will do

> > Please provide feedback & gelp keep me motivated:-)
> There's some feedback for you. Dunno if it helps you stay
motivated.<g>

It sure does. I'd do this for myself anyway, but it might not proceed at
the same pace.

if_...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
In article <862l70$6bi$5...@news.ycc.yale.edu>,

kar...@fermi2.chem.yale.edu wrote:
> if_...@my-deja.com wrote:
>
> > 1) How to add passages? I see 2 possibilities. A) on the map, pop up
> > menu, "new passgae", then click on two rooms to connect them, which
pops
> > up some selector box for directions. B) On the Room edit, choose the
> > "directions" tab. You will see that for each direction there is a
drop
> > down menu containing all known rooms; you select from there.
>
> > I suppose that I could support both. A bit of hassle, so I might
> > implement one first & add the other later. Which first?
>
> Seems to me like A is fine. For a first step towards B, you could let
the
> user type in the destination room.
oops, I already implemented B) it was a little easier. I will add A)
asap.

good point & worth considering. Not everyone will agree, so I ought to
make it an option.


> > (I intend to make heavy use of the configuration panel (room default
=
> > lighted/dark, etc)).
>
> Configuration is Good. Too much configuration is Bad, because you
can't
> find the thing you're trying to configure. You can partially get
around
> this by intelligently organizing your configure window. But remember
that
> someone else will think the north/south thing should be configured
under
> "rooms" not under "passages". So don't overconfigure.

Yes, that will be a bear. The major complaint about GUIs, when they have
been suggested before, was that they won't offer enough flexibility. I
intend to make most everything configurable.


> > 3) (how) should I (colour) code the map? Should dark rooms be marked
> > with black, water sources with blue, fire with red, etc? Should I
mark
> > locked doors & puzzles?
> How many games have a water source that actually matters in the game?
Same
> question for fire. While it might make the GUI look fancy, I don't
think
> it'll help usability at all. I mean, the author probably knows that
the sink
> is in the kitchen. If you mark doors, it's probably not hard to mark
locked
> ones. Again, though, how useful is that to the author?

Well, I'd like to see it (so that means that it probably makes the ToDo
list <g>. If its easy enough to implement, why not? If you *don't* want
to see it, I can let you configure it away).

I think that it helps with the overview of the game. Then I'd better not
just mark water/fire/oil sources, but places where it can be used (so
that you can see if tehre is a puzzle/locked door/ticght squeeze/troll
in-between).


> > I could add some little coloured dots in the box (say, above the
name).
>
> As you say, there's many properties that you might like to mark, and
only
> so much to work with. And I thought the GUI was supposed to have no
> learning curve. Changing the color of the room name, or the room
> background, or having lots of colored dots, will NOT be intuitive! A
little
> picture of fire might be intuitive, but as I said, I don't think it
would
> be useful.

little pictures certainly seem like overkill.


> How many rooms aren't "special"? How many rooms are lit rooms with no
> puzzles? One of the "howto write IF" essays talks about how you should
have
> as few rooms as necessary for your game. So probably most of your
rooms
> will be special. How will it help to have 70% of your room names
written in
> green text instead of black?

good point, I like to have mostly special rooms. Hmm, you're very anti
this colour coding idea, aren't you :-) maybe the pop up tool tip would
be enough - it'd certainly be much easier than colour coding. Of course,
then you don't have the overview.

> Define special! I just don't think it's worth it. Especially since
after
> they first map out the game, the authors will know (only too well)
where
> each puzzle etc. is.

yes, but human nature almost guarantees that you'll forgetsomething in a
complex system. This would keep it in your face (don't you hate that
phrase?).


> > I don't think that I want to let the map become too cluttered. What
do
> > you think?
>
> I agree. Hiking maps don't show exit numbers, road maps don't show the
tree
> line, physical maps don't show roads. Don't put in stuff you don't
need.

or, make it configurable?


> > 4) which leads me to ask if you want me to label the passages with
> > directions? This could be user configurable, I may add it to the
next
> > demo, so that we can see how it looks.
>
> That's the point of using rectangles! So that the GUI map is
intuitive. If
> you have to read everything, why not use a text editor?

I personally agree. But it won't work with colossal cave.

> You just need to label u/d and other fancy directions.

sounds good.


> > I'd like to have the demos coming out every day or 2 at first, which
> > means that they are more likely to be graphical bells & whistles
than
> > serious functionality. It will any case take months to be complete,
but
> > I want the user interface specified pretty quickly.
>
> Good luck coding that fast!

yeah, it takes 3 or 4 hours per night, but I despearately want to keep
you guys' attention, otherwise the feedback may dry up.


> > Please provide feedback & gelp keep me motivated:-)
>
> I'm sorry. My gelp machine ran out this morning.

Sorry, should've been "kelp".

if_...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
In article <38846839...@prodigy.net>,

R Blaylock <mrbla...@prodigy.net> wrote:
>
>
> if_...@my-deja.com wrote:
>
> > Oh, why don't you just visit the web page, then
> > give some feedback?
> >
>
> Just downloaded and experimented with plugh. It seems pretty simple
and
> straightforward to use, which would be perfect for someone like
myself.
> Many years ago I was studying computer programming, but I was led down
> another career path and my programming went by the wayside. I have
> downloaded TADS and, using the manual, have started to work on my own
IF
> creation. I have been looking for something just like this to aid in
> the development of my story.
>
> Of course, I am not so naive to think that I will need no programming
> knowledge, but with a GUI such as this it will make the repetetive
> programming of rooms and similar items much simpler, allowing me to
> spend more time concentrating and learning how to develop actors, and
> working on the storyline, rather than programming several different
> light sources, beds, chairs, etc.

TADS is pretty good at relieving you of that burden anyhow.

> I like what you're doing, and can't wait to see the finished project.


Thank you *very* much. I really appreciate this feedback. Of course, it
will be months before even a beta version is available. But, please keep
D/Ling the demos & telling me what you would like to see. Most replies
until now have come from seasoned TADSers, so input form anew user would
also be very helpful.

P.S IMHO, whatever you chose, you made the wrong career move :-)

if_...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
In article <862h95$6bi$2...@news.ycc.yale.edu>,

kar...@fermi2.chem.yale.edu wrote:
> R Blaylock <mrbla...@prodigy.net> wrote:
>
> > if_...@my-deja.com wrote:
>
> > Just downloaded and experimented with plugh. It seems pretty simple
and
> > straightforward to use, which would be perfect for someone like
myself.
>
> > Of course, I am not so naive to think that I will need no
programming
> > knowledge, but with a GUI such as this it will make the repetetive
> > programming of rooms and similar items much simpler, allowing me to
> > spend more time concentrating and learning how to develop actors,
and
> > working on the storyline, rather than programming several different
> > light sources, beds, chairs, etc.
>
> This is what I meant when I said I wasn't convinced, even if you are.
> If you're going to have several chairs, make one chair and use copy &
paste
> to get n chairs. That doesn't take fancy programming skill, and
probably
> takes less time than loading up a separate application and clicking
your
> way through various menus to use the copy function within the program
and
> then clicking through the various objects to change the couple of
> properties you want to change.
You're correct there.


> It's one thing to use a word processor because you want to know what
the
> output is going to look like. (E.g. that's IMO the main problem with
> TeX---you have to debug your equations using compile/fix cycles.
> <plug>Which is why I like LyX</plug>.) I can sort of see if's point
that
> being able to look at the map and access various rooms etc. from it is
> convenient.

I really need a cynic like you onboard. In any endevour, if everyone
just sings praises, no real progress is made. Also, I will need to do
much more to impress you, so this ought to bring a better product.
Please continue to contribute.


> But I don't really see how this will remove the tedium.

Well, if you find writing i-f tedious ..... :-)


p.s if you're a Brit & a Father Ted fan (I believe it's also on PBS in
the states, now - *must* see) ... "maybe I _like_ the tedium" :-) :-)

if_...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
I did a few hours coding last night & uploaded a new version. Please
note that you might get a few errors with this one too. I do not believe
that these will be bad coding, as everything runs fine on my machine. I
believe that the problem is that I have the development environment &
you do not (that's why I added those DLLS to the download).

I have just delved into the user manual & find that I know know how to
produce a standalone .EXE, so will try to get thet uploaded tonight
and, hopefully, any such problems will disappear.

I may not get much code done tonight, though, as I have an evening
class.

Last night's code added "new room" functionality via method B) [see
previous post]. When viewing a room on the room tab, click the
directions tab. For any direction, select a destination room from the
drop down list.

Unfortunately, I didn't have time to add the passage to the map. This is
trivial & will be done tonight, if my evening class allows, or tomorrow
at latest. Then follow room delete & room rename. Then, probably, "new
passage" via option A), "passage delete" & possibly moving one end of a
passage on the map (although, just deleting & recreating may be as
quick). Hmm,passage editing from the map? The same passge between the
same two rooms, but instead of going N<-->S it now goes NE<-->SW ?


I have been *very* impressed by the feedback, inclduing all criticism
(thanks, honestly). As I mentioned in one post, I have trawled usenet &
not found so much discussion on what a graphical development environment
should offer. So, in the unlikely event that I don't stay the course,
the next brave adventurer can pick up these scrolls and use them to
guide his way.

Now, I'd like to keep this thread near the top of the N.G, so that more
folk can see it & join. I'd also like to keep you guys motivated to give
guidance & feedback. That would seem to me to mean churning out small
increments every day or two. These would perforce be features which are
highly visible, but easier to code, leaving the tough stuff for later
(I'm sure that most of you code your i-f the same way).

Please let me know your feelings on this.

Also, there seems to be some trend towards getting the mapping done
first & then adding the rest. Again, what do you think?

I have created a mailing list. I will use this (when the frequency of
code release has dropped a bit) for announcing new versions. It is an
announcement _and_ discussion list. But, for the time being, I'd like to
keep the discussion in raif, to draw in more suckers (sorry, get more
feedback).

You can join the list at http://plugh.listbot.com/ or send a mail to
plugh-s...@listbot.com

I really appreciate this feedback & only hope that we can keep it up.
You may think that your comment hasn't been incorporated yet. But, if I
say here that it will be done, then it _will_ be done (eventually).
Would anyone like to see a To Do list on the web site, maybe with the
items prioritised? It might take some time when I could be coding to do
it, but it might help keep you motivated.

kar...@fermi2.chem.yale.edu

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
if_...@my-deja.com wrote:

>> And get your tabs ironed out. There's going to be a lot of text entry
>> going on, so making your app touch-typist friendly is key.
> will be done (but probably low priotiry, please see my later post
> today).

I agree that this is good. Clicking is nice for first-time users, but
anyone using this long enough to write a whole game will want lots of
keyboard shortcuts, just like people who've used word (or emacs or
whatever) for ages do most of their work without touching the mouse.

>> For typists, "n", "s", "e", "u", etc. aren't doing anything else, so
> why
>> not allow those keys to add rooms in those directions?
> sounds good (of course ALT+N, etc is much easier to implement - can you
> live with that - at least at first?).

I won't insist on tabs or any other specific character; just make it easy
to work without a mouse.

>> The properties simply *must* be extensible. A series of check boxes
>> isn't going to cut it. The author must be able to define room classes
>> and object classes.
> o.k, I ought to be able to do something with a list box & the standard
> colour selection tool. It sounds like a few people want a mapper first,
> then the rest of the functionality.

Well, that's because the map is the area where GUI most obviously helps
you. If you can show us ways that a GUI helps other aspects of game
creation, then by all means folks will want those features. But like I
said, going to the map, double clicking on a room to bring up the room
editing menu, clicking on one of the objects in that room to bring up the
object editing menu, and editing the ldesc isn't necessarily much better
than just editing objects/foo.t and typing sdesc=...

> I can colur code or annotate the passage, use a different arrow ehad, or
> a dotted arrow line, etc. But shouldn't doorways be shown as rooms in
> their own right anyway?

I don't think so. They should probably be big enough to click on, since
they are obstacles and hence objects of their own. However, they shouldn't
be as big as rooms because that'll mess up the intuitiveness of the map
looking like it would look in real life. You may not be able to keep that
illusion (due to ups and downs and ins and stuff) but to the extent you
can, it'll be better.

>> The bevel could be used to indicate higher and lower rooms, maybe.
> hmm, good idea, as long as it doiesn't interfere with the current room
> indication (maybe I can do that with the background colour of the box).

Why is that a good idea? How does it help the author? Despite what I wrote
just one paragraph ago, I think you want to minimize cosmetic details which
will just clutter up the interface. See my discussion about having blue for
water. Sure, it makes for pretty maps, but how does it help the author? (If
you want to have a separate module that lets you make pretty maps, or, say,
a map-making tool for people *playing* a game, then by all means put that
stuff in.)

-Amir

Daniel Barkalow

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
On Wed, 19 Jan 2000 if_...@my-deja.com wrote:

> Hmmm, you're absolutely correct of course. I'm not yet at save/restore,
> though it will come reasonably soon. I will save as a plain text file
> and make any Plugh specific stuff a TADS comment. Of course, if anyone
> messes with any of the comments, they will have a file which Plugh won't
> accept any more (but which TADS will). Hmmm, maybe I _should_ stick to
> a proprietary save file format and include an export function to spit
> out a plain text TADS file?

It's certainly worth letting people edit the TADS code and then put it
back into your GUI; that way people who usually are at their windows box
at home can tweak stuff when they log in remotely to their file server and
only have a text editor.

Ideally, you'd be able to deal with losing GUI-specific information,
probably by having it revert to some defaults. That way if someone messed
up the information, they would only have to recreate the GUI aspects, and
not start over.

kar...@fermi2.chem.yale.edu

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
if_...@my-deja.com wrote:

> Yes, that will be a bear. The major complaint about GUIs, when they have
> been suggested before, was that they won't offer enough flexibility. I
> intend to make most everything configurable.

Um, OK. It's certainly a nice idea to have your program be able to do
everything & just allow you to configure out most of it. However, (a) that
means you'll have to code that many more things, which will take more time
(b) there's a version of the combinatorial explosion working in your
program, where certain of these fancy features you want may mess up other
fancy features, (c) you may end up with a program that does so much it's
overwhelming (this has been my problem with word; it's hard to find any of
the commands because there are so many. It's just as easy to do Drop Caps
as to do Paste, even though one is probably done 4000 times more often than
the other.)

> Well, I'd like to see it (so that means that it probably makes the ToDo
> list <g>. If its easy enough to implement, why not? If you *don't* want
> to see it, I can let you configure it away).

See above.

> I think that it helps with the overview of the game. Then I'd better not
> just mark water/fire/oil sources, but places where it can be used (so
> that you can see if tehre is a puzzle/locked door/ticght squeeze/troll
> in-between).

> good point, I like to have mostly special rooms. Hmm, you're very anti


> this colour coding idea, aren't you :-) maybe the pop up tool tip would
> be enough - it'd certainly be much easier than colour coding. Of course,
> then you don't have the overview.

Hm. If you find answers to all of my questions, then I won't be against it.
I just feel like there are so many things you might want to put in that you
wouldn't be able to come up with any logical coloring scheme. Taking water
as an example, I have to imagine that probably 80% of games don't every use
water (even if there's a river for scenery, say). (I've only played maybe
20 IF games in my life, so maybe I'm wrong here.) Same thing only more so
for fire and oil. So why'd you pick those?

One thing you could do would be to let the user pick colors for various
things and put colored blobs or backgrounds or whatever in certain rooms
based on their own criteria. If you're not going to do that, it seems to me
that things will be too complicated unless you stick with using TADS
categories. Coloring a lockableDoorway differently than a regular doorway
makes a little sense, since that's a basic TADS tool, and it wouldn't have
gotten to be a basic TADS tool unless lots of people used it.


>> Define special! I just don't think it's worth it. Especially since
> after
>> they first map out the game, the authors will know (only too well)
> where
>> each puzzle etc. is.
> yes, but human nature almost guarantees that you'll forgetsomething in a
> complex system. This would keep it in your face (don't you hate that
> phrase?).

Agreed, but marking a room "special" isn't going to help that, is it, since
every room will be marked that way.

>> > 4) which leads me to ask if you want me to label the passages with
>> > directions? This could be user configurable, I may add it to the
> next
>> > demo, so that we can see how it looks.
>>
>> That's the point of using rectangles! So that the GUI map is
> intuitive. If
>> you have to read everything, why not use a text editor?
> I personally agree. But it won't work with colossal cave.

That's just one game. One good way to decide what you need for your program
would be to download, say, 100 games and play them. Anything that's common
to 50 of them would be a good thing to put into PLUGH. (And I'm not sure
you're right about CC. Are *all* the passages twisty, or just the maze(s)?)
If 90% of the map is going to be intuitive two-way passages, then the
default should be to create a two-way passages without asking you. If 70%
will be, then you need to ask, with a default.

Of course, playing 100 games might impinge on your free time for coding a
bit. Might also drive you completely insane if done over a short period.

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
R Blaylock <mrbla...@prodigy.net> wrote:

> I also agree with what you are saying, but, it doesn't take long before you
> have several pages in a word processor to sort thru to copy and paste each
> item.

Text editors have tools for doing this easily. WPs may or may not. Still, I
concede your point.

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to

> I really need a cynic like you onboard. In any endevour, if everyone
> just sings praises, no real progress is made. Also, I will need to do
> much more to impress you, so this ought to bring a better product.
> Please continue to contribute.

A new way to make millions! Cynical Cyber Consultants (Um, Cynical Cyber
Consultants.com, if I really want to make money. Or Cynical LINUX
Consultants.com.)

> p.s if you're a Brit & a Father Ted fan (I believe it's also on PBS in
> the states, now - *must* see) ... "maybe I _like_ the tedium" :-) :-)

If I were a Brit, I'd be criticising you, but I'm definitely criticizing.

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
if_...@my-deja.com wrote:

> I have been *very* impressed by the feedback, inclduing all criticism
> (thanks, honestly). As I mentioned in one post, I have trawled usenet &
> not found so much discussion on what a graphical development environment
> should offer. So, in the unlikely event that I don't stay the course,
> the next brave adventurer can pick up these scrolls and use them to
> guide his way.

I've been impressed with your acceptance of my cynical, SPAG-conspiracy,
"use text editors like our grandparents did!" kneejerk responses---um,
constructive feedback.

> Now, I'd like to keep this thread near the top of the N.G, so that more
> folk can see it & join. I'd also like to keep you guys motivated to give
> guidance & feedback. That would seem to me to mean churning out small
> increments every day or two. These would perforce be features which are
> highly visible, but easier to code, leaving the tough stuff for later
> (I'm sure that most of you code your i-f the same way).

Well, I need to warn you that I'm a theorist, not an engineer. Which means
I love criticizing your ideas but may not be much help once the program is
actually working. For example, I don't have windows so I couldn't run it.
Also I wouldn't have time to spend betatesting since I'm spending all my
time reading Usenet.

-Amir

okbl...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
In article <863ola$i69$1...@bgtnsc03.worldnet.att.net>,
"David Cornelson" <dcorn...@placet.com> wrote:
[stuff about what might be the coolest IF tool ever]

My cup overfloweth.

I only hope I live to see either of these tools come to life.
--
[ok]

T Raymond

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
if_...@my-deja.com spoke about :

>1) How to add passages? I see 2 possibilities. A) on the map, pop up
>menu, "new passgae", then click on two rooms to connect them, which pops
>up some selector box for directions. B) On the Room edit, choose the
>"directions" tab. You will see that for each direction there is a drop
>down menu containing all known rooms; you select from there.
[snip]

Ok, well first I'd suggest checking out how Informapper handles
things, although it sounds like you might already be familiar with it.
My main problem with this is that it was designed for play use (I
think), I need a mapper that I can use for development.

What does that mean? Well, personally I don't like the suggestion that
rooms are always rectangular. I'd like a mapper that gives you a few
other options. Even if that's only round, triangle, square.

I've got a project I've been working on that has two doors on the
north wall. They're set in the corners because that is the easiest way
to do it. But I think that is more of a TADS thing than a mapper thing
anyway.

Most mappers use some sort of grid to lay out rooms. it would be nice
if this grid could be customised by the user. If it's restricted to a
square grid, the user should be allowed to adjust the spacing. What
might be really cool is to allow a hexagonal grid. I have no clue if
it can be implemented, I'm just an idea person.

How about custom paths between rooms that are curved? That's one that
Informapper couldn't handle. It's a wish, I know that is hard to
implement.

>I could impelment all & have an option on the configuration panel, so

>that each user can set things to his own taste (I intend to make heavy


>use of the configuration panel (room default = lighted/dark, etc)).
>

>My idea is to implement B), to have it pop up a dialog box where
>escape/cancel would leave a uni-directional path & return would accpet
>the defaults. The dialog would name the current room & the linked to
>room & offer a choice of directions back, with already used directions
>greyed out & non-selectable.

Rooms generally are lit and don't have one way passages. I'd set a
default that way and give the option to change it to the user.
Informapper does this by a simple click on the passage. Also, have you
considered the problem of circular paths? Mazes aren't big these days,
but there's still the instance where "You're in a maze of twisty
passages, all the same..." and the user will need circular exits.

>3) (how) should I (colour) code the map? Should dark rooms be marked
>with black, water sources with blue, fire with red, etc? Should I mark
>locked doors & puzzles?

It might be useful for Dark rooms to be greyed or something like that.
The option to set room types and assign a colour to them might be
useful, but I think a secondary goal. Most games use indoor, outdoor,
light, and dark rooms.

This might be a place you can get the basics in and later add user
customisation to allow for something like this:

ADD Room Type -> Water
Room Colour -> Blue


OR

>I could then add a tools tip, such that when the user hovers the cursor
>over the room on the map, a little text box pops up showing what is
>special about the room (the box would automatically disappear when the
>cursor moves away from the room).

Actually this could be a very interesting addition. Combine it with
the thought on room type colours, and a configuration option to
display Type Colours/Tooltip/Both and you might keep mosst people
happy.

>I don't think that I want to let the map become too cluttered. What do
>you think?

Heh, well that sounds like me. I make cluttered maps and then cut them
apart. Which is another thought. The ability to mark several rooms and
cut/move them to another part of the map would be great. Might be
another wish, but hey, you asked for feedback and ideas.

I think that's it at the moment. I'll have to check out the demo later
in the week.

Tom

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond adk @ usa.net
"The original professional ameteur."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

okbl...@my-deja.com

unread,
Jan 19, 2000, 3:00:00 AM1/19/00
to
In article <8644qu$rsu$1...@nnrp1.deja.com>,

if_...@my-deja.com wrote:
>
> Ooops! of course, it works for me, cos I've got all the development
> environment on my machine. I've only just discovered how to produce a
> standalone .EXE and will upload one tonite (19th Jan, GMT +1). I am
> sure that exceptions are not because of bad code, rather because of
bad
> environment (but we'll know tomorrow, won't we <g> ?).

Well, I may not find out till tomorrow, er, the day-after-tomorrow in
the context of your message.

> I will look at this, it should be a flag somewhere. But, if Borland
> C++ builder/Windows doesn't offer this, then it might take a lot of
> work
> :-(

What if I got you a component that illustrated what I meant? Would that
make it easier?

> Well, I had thought that that was better - you have created a new
> room, so want to add at least a short description, if not a long
> description, a few items, etc.

Some people do indeed work that way. The more you force someone into a
particular style of working, however, the less enthusiastic they'll be.

> I suspect that creation is a personal thing. From what you write
later,
> I believe that you draw the whole map first before fleshing out the
> rooms, items, etc. I'll add an option to the configuration.

Actually in all my (unreleased) works, I start with a story, then do the
characters, then the map, and lastly the objects. This explains why all
my works are unreleased. :-)

> sorry about your Yuck :-) I see B) as a must & have already
> implemented it. If it's not there, many people will complain & demand
> it there.

OK. It's first important to simply have a way to do the thing.
Streamlining it can come later.

> It would require a mega work to add tabs as you suggest. I will only
do
> it if there is a lot of demand (sorry, honestly, its just that if I've
> got something working, I want to work on something else. Once I have a
> working version, I can afford teh time to tweak it. Hope you
> understand).

Then don't use tabs, use the other mouse button.

> sounds good (of course ALT+N, etc is much easier to implement - can
you
> live with that - at least at first?).

Sure.

> Didn't handle this last night - I would propose that I offer a list of
> directions with all used ones grayed out.

Good.

> Hmm, what do you suggest to replace it? I fear that it has to stay &
be
> extended & extended & extended.

You can't have the attributes hard-coded, period. Use a floating
notebook to display the properties and events for objects. If you can
*generate* TADS code, you should be able to *parse* TADS code, at least
as far as you need to to figure out what's what.

> Yeees. Mostly. It certainly shouldn't take longer. But I think that
> automation is bonus too.

Tip the scale in your favor as much as you can.

> I'll implement "North should go up, south should go down" (probably as
> another damned option <G>). Anything other than stright lines will
> require major work & is for a later phase.

Nah, don't make that an option. :-) Just make it easy to re-arrange the
map.

I believe C++ Builder has components for different line types, but I
agree that it's definitely later.

> o.k, I ought to be able to do something with a list box & the standard
> colour selection tool. It sounds like a few people want a mapper
first,
> then the rest of the functionality.

A mapper is a potentially useful tool all by itself. It's not really a
"proof of concept" because it's still going to be easier for someone who
knows just a little TADS/Inform to do create by hand. But even a good
mapping tool could change that, if it made contradictions/unusual things
visually apparent.

It also could encourage the author to pity the poor player, who must
visual the map. If it looks like spaghetti in the mapper, maybe it
needs to be simplified.

> I can colur code or annotate the passage, use a different arrow ehad,
or
> a dotted arrow line, etc.

Do that, and make each individual passage customizable.

> But shouldn't doorways be shown as rooms in
> their own right anyway?

Not typically. Generally, a doorway is no more than a theoretical space
for holding puzzles--a way to bar passage into the next room.

It does bring up an interesting point, though: Different sized
rectangles. All rooms are not the same size. If the GUI is to help
visualize the map, the rooms should be resiable.

> hmm, good idea, as long as it doiesn't interfere with the current room
> indication (maybe I can do that with the background colour of the
box).

I don't know if bevels to show height *is* a good idea, but I think it's
important to show--some way--different levels of a map. You should
also, at some point, allow for different maps. For example, if the
author is constructing a game set in a sky scraper, he's likely to want
to have the floors physically separate. Of course, that can be done by
stretching stair directions to an unused area of the main map, but it
might be visually cleaner to allow different maps.

> It sure does. I'd do this for myself anyway, but it might not proceed
at
> the same pace.

And, keep in mind that I'm simply trying to stoke the fire here. I
don't expect you to implement this all at once. (Or necessarily at
all.) But I'll keep downloading. :-)

--
[ok]

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
In article <Pine.LNX.4.21.000119...@iabervon.mit.edu>,
Daniel Barkalow <iabe...@iabervon.mit.edu> wrote:

> It's certainly worth letting people edit the TADS code and then put it
> back into your GUI; that way people who usually are at their windows
box
> at home can tweak stuff when they log in remotely to their file server
and
> only have a text editor.

o.k, I'm being slowly persuaded that this is the way to go.


> Ideally, you'd be able to deal with losing GUI-specific information,
> probably by having it revert to some defaults. That way if someone
messed
> up the information, they would only have to recreate the GUI aspects,
and
> not start over.

may come in a leter version. Somone (you?) requested that I be able to
parse an exsisting .t file. I suppose that I could & add all rooms,
passage, items, actors, etc to the Plugh data. But - it won't be in the
first version. Anything created in Plugh will run alone under TADS
(maybe export the save file, probably the savefile is plaintext, with
Plugh comments in it) in version 1. Import won't come before version 2
(or else version 1 will be delayed).

Thanx for the comment.

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
Hi amir, thanks for teh feedback,

In article <864pt7$laq$1...@news.ycc.yale.edu>,
kar...@fermi2.chem.yale.edu wrote:
> if_...@my-deja.com wrote:
>

[snip]

> I won't insist on tabs or any other specific character; just make it
easy
> to work without a mouse.

o.k, will do. In the first version, I will impose the hotkeys on you.
Later on, I can make them configurable.


[snip]


> Well, that's because the map is the area where GUI most obviously
helps
> you. If you can show us ways that a GUI helps other aspects of game
> creation, then by all means folks will want those features. But like I
> said, going to the map, double clicking on a room to bring up the room
> editing menu, clicking on one of the objects in that room to bring up
the
> object editing menu, and editing the ldesc isn't necessarily much
better
> than just editing objects/foo.t and typing sdesc=...

well, it's pretty much done now. But I may not work much more on that
sort of thing, because some folks seem to want mapping only (at least
for a first pass).


> > I can colur code or annotate the passage, use a different arrow
ehad, or
> > a dotted arrow line, etc. But shouldn't doorways be shown as rooms
in
> > their own right anyway?
>

> I don't think so. They should probably be big enough to click on,
since
> they are obstacles and hence objects of their own.

That's what I thought/meant. They are, in effect, a room, with apssages
in & out.


> However, they shouldn't
> be as big as rooms because that'll mess up the intuitiveness of the
map

Maybe I can find a way to show them 1/2 size. That's cosmetic, though,
so it gets added to the To Do list for the moment.


> >> The bevel could be used to indicate higher and lower rooms, maybe.
> > hmm, good idea,

[snip]


> Why is that a good idea? How does it help the author?

o.k, it's _not_ a good idea. One man's Mede is another man's Persian
(ought to get a cackle from the Yalies; doubt that MIT will laugh <g>).
That one is very low priority & wil anyway be configurable.


> Despite what I
wrote
> just one paragraph ago, I think you want to minimize cosmetic details
which
> will just clutter up the interface. See my discussion about having
blue for
> water. Sure, it makes for pretty maps, but how does it help the
author? (If
> you want to have a separate module that lets you make pretty maps, or,
say,
> a map-making tool for people *playing* a game, then by all means put
that
> stuff in.)

I, personally, believe that it will be useful to have a full overview &
see where fire/water/puzzles/actor starts, etc are. Some do, some don't.
Guess I'll make it all configurable.

> -Amir

thanks again.

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
wow, another long post. Thanx a 1,000,000.


In article <8657gd$mgm$1...@nnrp1.deja.com>,


okbl...@my-deja.com wrote:
> In article <8644qu$rsu$1...@nnrp1.deja.com>,
> if_...@my-deja.com wrote:
> >
> > Ooops! of course, it works for me, cos I've got all the development
> > environment on my machine. I've only just discovered how to produce
a
> > standalone .EXE and will upload one tonite (19th Jan, GMT +1). I am
> > sure that exceptions are not because of bad code, rather because of
> bad
> > environment (but we'll know tomorrow, won't we <g> ?).

double oops, it still don't work. I didn't have much time last night. I
hope to straighten this out today. It must be very frustaating for
anyone trying it out. It must also make you doubt my coding ability.


> What if I got you a component that illustrated what I meant? Would
that
> make it easier?

I lost the original contect of this, but a component for anything at all
is always welcome. I'm using Borland C++ Builder 4, but ought to be able
to use Delphi components too.

[snip]


> Some people do indeed work that way. The more you force someone into a
> particular style of working, however, the less enthusiastic they'll
be.

I will try to make almost everything configurable.


> OK. It's first important to simply have a way to do the thing.
> Streamlining it can come later.

I intend to do that - rush a version out quickly in order to keep
people's interest, then enhance it.


[snip stuff about putting tabs on the rroms on the map, labelled n,s,e,
etc & using teh mouse to draw a passage between two rooms]


> Then don't use tabs, use the other mouse button.

Already used for the pop up menu (which could go in a pinch & use only
the main menu). I use double click on a room to edit its properties.
Single click is still free. Single click 2 rooms, then pop up a dialog
asking for teh directions of teh passge ?


[I think you suggested here that I get rid of the configuration page]


> > Hmm, what do you suggest to replace it? I fear that it has to stay &
> be
> > extended & extended & extended.
>
> You can't have the attributes hard-coded, period. Use a floating
> notebook to display the properties and events for objects.

You mean like when I press F11 in C++ Builder/Delphi? I'll look into it,
if its time intensive, it gets delayed. A simple tool tip can show the
properties read-only & the user can x2 click the room to edit any
properties which he does not like.

> If you can
> *generate* TADS code, you should be able to *parse* TADS code, at
least
> as far as you need to to figure out what's what.

Not necessarilly. In the first version I will have either a binary save
file, with TADS export capability. Or an ascii .T file with Plugh stuff
as comments. But if anyone messes with that too much, it might not
import easilly. Someone else asked that I be able to import an exisitng
TADS file (know where I can find colossalCave.t ?). I think that won't
come until v2.

> I believe C++ Builder has components for different line types, but I
> agree that it's definitely later.

In fact, I am using a 3rd party freeware component for the passage
lines. That's probably what made the whole thing possible - the way that
you can drag the rooms & the passages follow. They only support 8
passages from one room though. So I guess that I'll have to extend it
sooner or later.


> A mapper is a potentially useful tool all by itself. It's not really
a
> "proof of concept" because it's still going to be easier for someone
who
> knows just a little TADS/Inform to do create by hand. But even a good
> mapping tool could change that, if it made contradictions/unusual
things
> visually apparent.

well, I think so too, but others don't want the map to be "cluttered".
So, I guess I'll just make everything configurable.

There does seem to be a preferance for a mapping tool, though. SO, that
might be v1.0.

> It also could encourage the author to pity the poor player, who must
> visual the map. If it looks like spaghetti in the mapper, maybe it
> needs to be simplified.

good point.


> > I can colur code or annotate the passage, use a different arrow
ehad,
> or
> > a dotted arrow line, etc.
> Do that, and make each individual passage customizable.

customizable? you mean directions. Anything else? Locked door,
uni-directional? Do I understand you?


> > But shouldn't doorways be shown as rooms in
> > their own right anyway?
>
> Not typically. Generally, a doorway is no more than a theoretical
space
> for holding puzzles--a way to bar passage into the next room.

but it _is_ an aobject/a type of room?


> It does bring up an interesting point, though: Different sized
> rectangles. All rooms are not the same size. If the GUI is to help
> visualize the map, the rooms should be resiable.

o.k, easy enough to do, but probably not till later.


> I don't know if bevels to show height *is* a good idea, but I think
it's
> important to show--some way--different levels of a map. You should
> also, at some point, allow for different maps. For example, if the
> author is constructing a game set in a sky scraper, he's likely to
want
> to have the floors physically separate. Of course, that can be done
by
> stretching stair directions to an unused area of the main map, but it
> might be visually cleaner to allow different maps.

Hmm, I agree. I just don't like it :-) I'm wondering how to represent
the connectors bewtween maps.


> And, keep in mind that I'm simply trying to stoke the fire here. I
> don't expect you to implement this all at once. (Or necessarily at
> all.) But I'll keep downloading. :-)

thanks a 1,000,000. That is *exactly* what I want to hear. Everyone
seems to be very understanding. I really want to get the requirements
clear while I have all of your attention, then I can hack the difficult
code. I can put out incremental versions with stuff that's easy to code,
but looks impressive, in order to keep yoiur attention.

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
Thanks again, Amir, you've certainly been busy :-)

In article <864ra0$laq$2...@news.ycc.yale.edu>,
kar...@fermi2.chem.yale.edu wrote:
[snip]


> Um, OK. It's certainly a nice idea to have your program be able to do
> everything & just allow you to configure out most of it. However, (a)
that
> means you'll have to code that many more things, which will take more
time
> (b) there's a version of the combinatorial explosion working in your
> program, where certain of these fancy features you want may mess up
other
> fancy features, (c) you may end up with a program that does so much
it's
> overwhelming (this has been my problem with word; it's hard to find
any of
> the commands because there are so many.

You may be right, but I see no choice. Apart from the fact that my
personal choice is for flexibility, if I don't make it all things to all
people, then I'll get a ton of complaints/suggestions for improvement.


> It's just as easy to do Drop
Caps
> as to do Paste, even though one is probably done 4000 times more often
than
> the other.)

say what now? What on earth is "Drop Caps" ?

[snip - colour coding stuff]


> One thing you could do would be to let the user pick colors for
various

> things and put colored blobs or backgrounds or whatever in certain


rooms
> based on their own criteria.

yes, I reckon that I'll do that. It ought to be relatively easy to
combine a standard listbox component with a colour selection component.


[snip - labelling passages with directions]


> > I personally agree. But it won't work with colossal cave.
>

> That's just one game. One good way to decide what you need for your
program
> would be to download, say, 100 games and play them. Anything that's
common
> to 50 of them would be a good thing to put into PLUGH.

Has anyone already done this sort of research? I suspect that in
'modern' i-f, fancy directions are passe & that > 90% going north does
let you return to teh south.


> (And I'm not
sure
> you're right about CC. Are *all* the passages twisty, or just the
maze(s)?)
> If 90% of the map is going to be intuitive two-way passages, then the
> default should be to create a two-way passages without asking you. If
70%
> will be, then you need to ask, with a default.
>
> Of course, playing 100 games might impinge on your free time for
coding a
> bit.

was goinng to be my point. I think I'll just hack something togetehr
first, then d/l & play the 100 games & tweak it later.


> Might also drive you completely insane if done over a short
period.

ermm, sorry to point out typos, but that's "insaneR".


>
> -Amir
thanx again.

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to

> > I personally agree. But it won't work with colossal cave.
>


>
> -Amir
thanx again.

>


no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
thanks for the post, Tom, much appreciated.


In article <864v53$184...@news.northnet.org>,
ar...@see.the.sig (T Raymond) wrote:

> [snip]
> Ok, well first I'd suggest checking out how Informapper handles
> things, although it sounds like you might already be familiar with it.

never heard of it. I did a search & came up with the page
http://www.ifarchive.org/if-archive/mapping-tools/Index I guess that I
will have to check them all out. I do not want to re-invent the wheel.

> My main problem with this is that it was designed for play use (I
> think), I need a mapper that I can use for development.

don't we all? :-)


> What does that mean? Well, personally I don't like the suggestion that
> rooms are always rectangular. I'd like a mapper that gives you a few
> other options. Even if that's only round, triangle, square.

that has been diagreed with. At least one other wants square rooms only.
Oh, well, something else to make user configurable, I guess. Of course,
it also is connected with the question of whether passages should be
fixed at certain points, should be labelled with directions, etc, etc.


> I've got a project I've been working on that has two doors on the
> north wall. They're set in the corners because that is the easiest way
> to do it. But I think that is more of a TADS thing than a mapper thing
> anyway.

yes, but you can't get to both of them with 'go north'. They should
probably be represented separately on the map & you would get to them
with something like "go through yellow door", "use red door", etc. AM I
correct?

> Most mappers use some sort of grid to lay out rooms. it would be nice
> if this grid could be customised by the user. If it's restricted to a
> square grid, the user should be allowed to adjust the spacing. What
> might be really cool is to allow a hexagonal grid. I have no clue if
> it can be implemented, I'm just an idea person.

hadn't thought of a grid. Maybe next version. I don't see hexagonal
would help, since there are 8 principle directions (and 4 akward ones).
Any discussion anyone?

> How about custom paths between rooms that are curved? That's one that
> Informapper couldn't handle. It's a wish, I know that is hard to
> implement.

It's wish (for me too) & shall be treated as such :-) Actually, it's
pretty tough to implement; maybe in a future version.


> Rooms generally are lit and don't have one way passages. I'd set a
> default that way and give the option to change it to the user.

agreed

> Also, have you
> considered the problem of circular paths? Mazes aren't big these days,
> but there's still the instance where "You're in a maze of twisty
> passages, all the same..." and the user will need circular exits.

yes. I use a 3rd party component for the rendition of the passage on the
map. It supports that if you drag one room, the connecting line
automatically follows. I don't _think_ that it supports connecting one
room (TPanel) to itself, but I'll check it out. I believe that this must
be supported, even if I show it some other way.


[snip - colour coding]


> >I could then add a tools tip, such that when the user hovers the
cursor
> >over the room on the map, a little text box pops up showing what is
> >special about the room (the box would automatically disappear when
the
> >cursor moves away from the room).
>
> Actually this could be a very interesting addition. Combine it with
> the thought on room type colours, and a configuration option to
> display Type Colours/Tooltip/Both and you might keep mosst people
> happy.

I think that this will almost certainly be included.

[snip]


> Which is another thought. The ability to mark several rooms and
> cut/move them to another part of the map would be great. Might be
> another wish,

tough, but I can see why it is desirable.


> but hey, you asked for feedback and ideas.

Thanx a 1,000,000. I am really getting some great feedback. I feel that
together we are specifying what such a tool should do.

>
> I think that's it at the moment. I'll have to check out the demo later
> in the week.
>
> Tom
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Tom Raymond adk @ usa.net
> "The original professional ameteur."
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
In article <864ri8$laq$4...@news.ycc.yale.edu>,
kar...@fermi2.chem.yale.edu wrote:

> if_...@my-deja.com wrote:
> > In article <862h95$6bi$2...@news.ycc.yale.edu>,
> > kar...@fermi2.chem.yale.edu wrote:
>
> A new way to make millions! Cynical Cyber Consultants (Um, Cynical
Cyber
> Consultants.com, if I really want to make money. Or Cynical LINUX
> Consultants.com.)
please let me in on the IPO :-)

> If I were a Brit, I'd be criticising you, but I'm definitely
criticizing.

excellent sense of homo(u)r! And from a Yalie too!


>
> -Amir

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to

> "use text editors like our grandparents did!" kneejerk responses---um,
> constructive feedback.
I saw my first computer at uni back during the big storm or '77. It was
a PDP8, with only a teletype attahced. It was another 3 years before I
saw a VDU (monochrome, on a VAX). During my time at uni & the beginning
of my programming career, I used teletypes, punched cards, punched paper
tape (which I would 'patch' with scissors & scotch tape. Honestly.). I
used 10 inch, then 8 inch 'floppies', the company moved up from a 12bps
to a 300bps modem. It was a long time till I saw a 10 meg hard drive.

[please insert contributions along the lines of Python's Yorkshiremen
here].
Aye, and you try telling the young people today that, and tehy won't
believe you!


> Well, I need to warn you that I'm a theorist, not an engineer. Which
means
> I love criticizing your ideas but may not be much help once the
program is
> actually working.

you're giving good enough feedback as it is.

> For example, I don't have windows so I couldn't run
it.

Borland have promised to port C++ Builder to Linux sometime last year.
So, hang on in there. In the meantime, I'll keep adding screen shots.

I find it fantastic, though, that you are contributing so much to a tool
which you may never be able to use. Thanx.


> Also I wouldn't have time to spend betatesting since I'm spending all
my
> time reading Usenet.

and posting.

no flames, please

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
well, last night I only had about 30 minutes to spare. Sorry.

I added code such that when a new passage is created it will now be
shown on the map.

*very sorry*, but I suspect that you may still have the "a required DLL
is missing" problem. This is extremely embarassing & doesn't help you
beleive that I am a good coder :-( Actually, I have written dozens of
things with C++ Builder, but only ever run them on my own machine.
Anyone else use it? I *must* get this straightened out asap, even if
investigating it means that I can't write any new code for a day.

Everyone seems to be very understanding. I really want to get the


requirements clear while I have all of your attention, then I can hack
the difficult code. I can put out incremental versions with stuff that's

easy to code, but looks impressive, in order to keep your attention.

From the feedback so far, I would say that it seems that you want me to
concentrate on a mapping tool, then do the rest of the stuff.
Agree/disagree?

I think that I will definitely have to make almost everything
configurable, in order to accomodate everyone (except for the guy who
hates hunting through configuration options).

What do you think about the map? Should it be one large map, which you
scroll around? Or do you want multiple map capability (as someone said,
to map the different floors of a skyscaper). I personally lean slightly
towards a multiple map, but will implement multiple if required. I'd
like to get it done at the start, though, rather than add it on.

Everyone seems to like the idea of a tooltip, where hovering the cursor
over a room on the map pops up more details of it. In addition, most
seem to like a user selectable colour coding for room properties (wtare,
fire, dark room, etc).

I will try over the coming weekend to condense this discussion & put it
into a To Do list on the web page, with some sort of timeline/priority,
so that you can have a clearer view (and so that Amir will know exactly
what to criticize <g>).

Is there any point in getting sophisticated & setting up some sort of
voting system at the web site? Maybe not, if I make evrything
configurable.

Another big point, after mapping is that in the full version, some folks
are quite adamant that the save file format must be .t Personally, I
find the argument that you might make a remote login to your home server
to update a file & only have a text editor available to be somewhat
tenuous. I have no doubt that at least one of you would like to do so,
since you posted that you did, but I don't see it as an everyday
occurence.

I would prefer in the first version to have a binary save file and an
option to export TADS code. That way I could until release 2 to export &
import TADS format files. Then version 2.5 or 3 could import TADS files
which weren't even created with Plugh!

It will be a right royal pain, though, to code s/w to parse every
possible persnoal coding style, so I'd rather put it off for a bit.

What do you think? Should I delay release in order to parse ascii TADS
files, or can you live with a proprietary save file format in the first
release.

Anything else? (please keep contributing & thanks again)

plugh!

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
to anyone following this thread in Deja, sorry if it's confusing - I,
plugh, posted with the nom de post "no flames, please". In fact, I had
set it in order to post another question asking which authoring system
is most widely used (hence the request for no flames).

In future my posts will be marked "plugh!".

okbl...@my-deja.com

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
In article <866ibc$llo$1...@nnrp1.deja.com>,

no flames, please <pl...@subdimension.com> wrote:
> wow, another long post. Thanx a 1,000,000.

About one thanks per ten words. ;-)

> double oops, it still don't work. I didn't have much time last night.
I
> hope to straighten this out today. It must be very frustaating for
> anyone trying it out. It must also make you doubt my coding ability.

I do get the impression of an apprentice programmer, just from your
messages. (This is not meant as an insult, I hope you realize.)

But actually, I couldn't download it yesterday because the link didn't
work.

> I lost the original contect of this, but a component for anything at
all
> is always welcome. I'm using Borland C++ Builder 4, but ought to be
able
> to use Delphi components too.

A friend of mine has assembled a few components (in Delphi) that might
help. Can you install a .DCU or do you need some other thing?

> I intend to do that - rush a version out quickly in order to keep
> people's interest, then enhance it.

Good plan.

> [snip stuff about putting tabs on the rroms on the map, labelled
n,s,e,
> etc & using teh mouse to draw a passage between two rooms]
> > Then don't use tabs, use the other mouse button.
> Already used for the pop up menu (which could go in a pinch & use only
> the main menu). I use double click on a room to edit its properties.
> Single click is still free. Single click 2 rooms, then pop up a dialog
> asking for teh directions of teh passge ?

I was thinking more like:

1. I have a building (a well house for a large spring).
2. I click and drag easterly (to the right) and release, Plugh! puts up
a room east from the building.

> You mean like when I press F11 in C++ Builder/Delphi? I'll look into
it,
> if its time intensive, it gets delayed. A simple tool tip can show the
> properties read-only & the user can x2 click the room to edit any
> properties which he does not like.

Yes, like the Object Inspector in those tools. I think even the most
hardened IF author would have to admit that having properties and events
for objects laid out would ultimately be easier than having to remember
them all.

> Not necessarilly. In the first version I will have either a binary
save
> file, with TADS export capability. Or an ascii .T file with Plugh
stuff
> as comments.

OK, some truth to that--*if* you provide a way for the author to add
properties, you could keep that notated in the comments as Plugh code
and only worry about exporting. That's not a bad start.

Ultimately, though, people are going to want to use their .T libraries.
If you can't import them directly, you'll want to make it easy for them
to be manually imported.

> But if anyone messes with that too much, it might not
> import easilly. Someone else asked that I be able to import an
exisitng
> TADS file (know where I can find colossalCave.t ?). I think that won't
> come until v2.

That's a significant project. I looked at doing something like that
(with similar motives as yours).

> In fact, I am using a 3rd party freeware component for the passage
> lines. That's probably what made the whole thing possible - the way
that
> you can drag the rooms & the passages follow. They only support 8
> passages from one room though. So I guess that I'll have to extend it
> sooner or later.

Was it meant to be a mapping tool?

> > A mapper is a potentially useful tool all by itself. It's not

> well, I think so too, but others don't want the map to be "cluttered".


> So, I guess I'll just make everything configurable.

The map will be as cluttered as the author wants it to be.

> There does seem to be a preferance for a mapping tool, though. SO,
that
> might be v1.0.

It's a good place to start.

> customizable? you mean directions. Anything else? Locked door,
> uni-directional? Do I understand you?

Not quite. You were referring to be able to annotate certain things and
I'm suggesting that this is a good idea--especially if the author can
add his own notes. Maybe they come up as "tool tips", as you call them.

> but it _is_ an aobject/a type of room?

An object--not a type of room.

> o.k, easy enough to do, but probably not till later.

Fair 'nuff.

> Hmm, I agree. I just don't like it :-) I'm wondering how to represent
> the connectors bewtween maps.

That's actually easier than representing relative height of rooms. Just
put a symbol like a big black arrow with "to map #6" on it. User clicks
on it--boom, he goes to that map.

> thanks a 1,000,000. That is *exactly* what I want to hear. Everyone
> seems to be very understanding. I really want to get the requirements
> clear while I have all of your attention, then I can hack the
difficult
> code. I can put out incremental versions with stuff that's easy to
code,
> but looks impressive, in order to keep yoiur attention.

Oh, look! A butterfly!! ;-)
--
[ok]

okbl...@my-deja.com

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
In article <85t873$tel$1...@nnrp1.deja.com>,
if_...@my-deja.com wrote:
>
> can download it & see some screenshots at
> http://plugh.tsx.org

I haven't been able to reach this link in the last couple of days.

T Raymond

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
no flames, please <pl...@subdimension.com> spoke about :

>http://www.ifarchive.org/if-archive/mapping-tools/Index I guess that I
>will have to check them all out. I do not want to re-invent the wheel.

It's in spanish. Let me know if you want a (mostly) translated version
to check out.

>don't we all? :-)

Well I don't know about everyone. There are some people who only *play* IF ;)

[room shapes snipped]


>that has been diagreed with. At least one other wants square rooms only.
>Oh, well, something else to make user configurable, I guess. Of course,
>it also is connected with the question of whether passages should be
>fixed at certain points, should be labelled with directions, etc, etc.

Well I'm thinking long range on this part. If at some point you can
design the map with the room shapes, you don't have to recreate in
another graphic program to print it out.

>> I've got a project I've been working on that has two doors on the
>> north wall. They're set in the corners because that is the easiest way
>> to do it. But I think that is more of a TADS thing than a mapper thing
>> anyway.
>yes, but you can't get to both of them with 'go north'. They should
>probably be represented separately on the map & you would get to them
>with something like "go through yellow door", "use red door", etc. AM I
>correct?

Well actually if I weren't a lazy programmer I could just key them as
both north doors and number or colour them and use TADS disambiguation
and player input to get them in the right one. Like I said, it's not
exactly something that's a problem for your project.

[grid and spacing ideas snipped]


>hadn't thought of a grid. Maybe next version. I don't see hexagonal
>would help, since there are 8 principle directions (and 4 akward ones).
>Any discussion anyone?

Well hexagonal is a throwbaack to D&D RPGs, I made heavy use of them.
And well, it'd make space IF easier to plot out as most any (somewhat)
realistic space station would have to be a rounded setup for
rotational gravity concepts. Oohhh theoretic debate material here ;)

>> How about custom paths between rooms that are curved? That's one that
>> Informapper couldn't handle. It's a wish, I know that is hard to
>> implement.
>It's wish (for me too) & shall be treated as such :-) Actually, it's
>pretty tough to implement; maybe in a future version.

Right. I know that's a difficult one. Like I said before... idea man
here :)

[default rooms properties, path ideas snipped]


>yes. I use a 3rd party component for the rendition of the passage on the
>map. It supports that if you drag one room, the connecting line
>automatically follows. I don't _think_ that it supports connecting one
>room (TPanel) to itself, but I'll check it out. I believe that this must
>be supported, even if I show it some other way.

I D/L the demo last night and checked it out. The way the Map
component is set up now it might negate seom of these ideas about grid
and such. It looked like you could pretty much freeform drop a room
anwhere. Maybe at some point add in the ability to use a grid for
lining up (similar to graphic design programs) would handle
everything.

>> Which is another thought. The ability to mark several rooms and
>> cut/move them to another part of the map would be great. Might be
>> another wish,

>tough, but I can see why it is desirable.

Well if you've ever started setting up a castle map and decided that
you had to extend the courtyard and garden area so that you could move
the tower to a more sensible location, it would make undeniable sense.
:)

>Thanx a 1,000,000. I am really getting some great feedback. I feel that
>together we are specifying what such a tool should do.

On a more general comment. When I tessted it out I noticed a minor
graphical problem. When I maximized the main window, it seemd that the
bottom edge of most of the tabs was obscured and any buttons that were
in that line. You might want to give a look to your margin settings
for the bottom edges.

T Raymond

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
no flames, please <pl...@subdimension.com> spoke about :
>well, last night I only had about 30 minutes to spare. Sorry.

Hey, progress is progress. Just think what'd happen if the government
would get one thing done in 30 minutes! *L*

>*very sorry*, but I suspect that you may still have the "a required DLL
>is missing" problem. This is extremely embarassing & doesn't help you
>beleive that I am a good coder :-( Actually, I have written dozens of
>things with C++ Builder, but only ever run them on my own machine.
>Anyone else use it? I *must* get this straightened out asap, even if
>investigating it means that I can't write any new code for a day.

I D/Led the full package and it ran on my machine ok.

>From the feedback so far, I would say that it seems that you want me to
>concentrate on a mapping tool, then do the rest of the stuff.
>Agree/disagree?

I think the majority would like a newer tool that helps with that part
of creating IF. After time doing so, you find a good editor, get some
macros, and other little tools that help with the other parts. At
least until somebody gets a decent system together that does it all.

I think the mapping component will require the most work. A code
editor/inserter is mostly and edit box with some features added to it.
While that's probably not a snap to put together, it's got to be
easier than a mapping tool. (Or I could be a raving non-programmer who
has no clue and both parts are equally as difficult!)

>What do you think about the map? Should it be one large map, which you
>scroll around? Or do you want multiple map capability (as someone said,
>to map the different floors of a skyscaper). I personally lean slightly
>towards a multiple map, but will implement multiple if required. I'd
>like to get it done at the start, though, rather than add it on.

Again I'd have to refer to my experience using Informapper. Multiple
maps for multiple floors, even though each map could handle many
locations. Handy for large projects where you work on one set of rooms
at a time, this would tie in with the room editor too:

Map2: SkyScraper Floor 2
Rooom 1: Foyer

Then when the Foyer room gets double-clicked it opens up the file
that has the floor 2 rooms in it and pops up Room 1 description.

>Another big point, after mapping is that in the full version, some folks
>are quite adamant that the save file format must be .t Personally, I
>find the argument that you might make a remote login to your home server
>to update a file & only have a text editor available to be somewhat
>tenuous. I have no doubt that at least one of you would like to do so,
>since you posted that you did, but I don't see it as an everyday
>occurence.
>
>I would prefer in the first version to have a binary save file and an
>option to export TADS code. That way I could until release 2 to export &
>import TADS format files. Then version 2.5 or 3 could import TADS files
>which weren't even created with Plugh!

I think that so long as you provide the option to export TADS code to
a file you can go with the binary save. The point in question is,
until the rest of the system is working, if you can't export the code,
it can't be compiled and used. That would tend to make the project an
interesting toy that can't help you much. At least I think that's the
point that was being made.

kar...@fermi2.chem.yale.edu

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
no flames, please <pl...@subdimension.com> wrote:
> Thanks again, Amir, you've certainly been busy :-)

>> It's just as easy to do Drop


> Caps
>> as to do Paste, even though one is probably done 4000 times more often
> than
>> the other.)
> say what now? What on earth is "Drop Caps" ?

Sorry. You know in books how the first word of a chapter is sometimes
really big and sort of "drops" into the next line or two (and may or may
not be in some fancy font)? That's a drop cap. My point is, it's an obscure
thing that word can do, which noone ever uses. The fact that you've never
heard of them just proves my point :)

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
no flames, please <pl...@subdimension.com> wrote:
> In article <864ri8$laq$4...@news.ycc.yale.edu>,
> kar...@fermi2.chem.yale.edu wrote:
>> if_...@my-deja.com wrote:

>> If I were a Brit, I'd be criticising you, but I'm definitely
> criticizing.
> excellent sense of homo(u)r! And from a Yalie too!

Just to show that you shouldn't judge a book by looking at its cover:

I'm a grad student at the University of Pennsylvania. My professor moved to
the University of Utah. I'm only working here because my wife's a
pediatrics resident. Which is to say, I don't even have a Yale ID, let
alone a love for Yale. In fact, I went to Harvard, so I have anything *but*
love for Yale. (At Harvard we had three different classes on humor!)

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
no flames, please <pl...@subdimension.com> wrote:

> [we had to lick the lake!]

> Aye, and you try telling the young people today that, and tehy won't
> believe you!

Luxury! When I was young we had to wake up half an hour before we went to
sleep and do all our programming on a wooden turing machine!

Actually (he said sheepishly), I'm only 27, my first computer was an Apple
][e, and I've never even used ed, let alone punch cards.

> I find it fantastic, though, that you are contributing so much to a tool
> which you may never be able to use. Thanx.

Don't be so sure. There's always WINE. But then, I program (TADS or
whatever) in VIM, so it's unlikely I'd use PLUGH anyway. (Though as I said
before, I'm willing to be convinced.)

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 20, 2000, 3:00:00 AM1/20/00
to
no flames, please <pl...@subdimension.com> wrote:

> From the feedback so far, I would say that it seems that you want me to
> concentrate on a mapping tool, then do the rest of the stuff.
> Agree/disagree?

Except that mapping tools already exist, don't they? I'd think you should
first concentrate on getting something that (a) works (i.e. outputs correct
TADS code) and (b) lets you do many of the things people want to do in a
TADS game. Even if I were convinced that having fire sources marked on the
map were useful, I wouldn't use a program that had that but didn't let you
edit objects, say. Or maybe I'm just saying this to annoy you.

> What do you think about the map? Should it be one large map, which you
> scroll around? Or do you want multiple map capability (as someone said,
> to map the different floors of a skyscaper). I personally lean slightly
> towards a multiple map, but will implement multiple if required. I'd
> like to get it done at the start, though, rather than add it on.

I didn't really get what ok (?) was saying about the "higher" levels on a
map. But he's definitely right: you need multiple maps for either multiple
regions or for multiple levels in one region where it would get too
confusing to put it all on one 2-D surface.

> I will try over the coming weekend to condense this discussion & put it
> into a To Do list on the web page, with some sort of timeline/priority,
> so that you can have a clearer view (and so that Amir will know exactly
> what to criticize <g>).

I HATE the To Do list!

Or is that not what you meant?

> Is there any point in getting sophisticated & setting up some sort of
> voting system at the web site? Maybe not, if I make evrything
> configurable.

I'd think a "send me mail" link would be plenty.

> Another big point, after mapping is that in the full version, some folks
> are quite adamant that the save file format must be .t Personally, I
> find the argument that you might make a remote login to your home server
> to update a file & only have a text editor available to be somewhat
> tenuous. I have no doubt that at least one of you would like to do so,
> since you posted that you did, but I don't see it as an everyday
> occurence.

But what about the argument that you might want to send your code to
someone who doesn't have (windows or) PLUGH? E.g. if you're collaborating
with someone. (Admittedly, that doesn't seem to happen *that* often, but
that could always change.)

> I would prefer in the first version to have a binary save file and an
> option to export TADS code. That way I could until release 2 to export &
> import TADS format files. Then version 2.5 or 3 could import TADS files
> which weren't even created with Plugh!

> It will be a right royal pain, though, to code s/w to parse every


> possible persnoal coding style, so I'd rather put it off for a bit.

That certainly could be hard. As someone who wrote a file import program
(LaTeX->LyX if you must know), I know how hard it is to satisfy everyone's
coding style.

The point here is that in order to get your game to compile, you have to be
able to write out TADS anyway. Why not make v1 save in TADS but only be
able to read TADS in exactly the format that PLUGH writes out? Just put all
the PLUGH stuff between /* */.

OK, I admit it's not quite that easy. (LyX, btw, doesn't save in LaTeX
format even though it writes out & compiles LaTeX. The reason is that they
need to save lots of GUI information. OTOH, their math editor uses exact
LaTeX.) For example, if the user is allowed to write arbitrary code, then
you'll have to flag that in the saved file, so that PLUGH knows not to try
parsing it.

> What do you think? Should I delay release in order to parse ascii TADS
> files, or can you live with a proprietary save file format in the first
> release.

People can live with just about anything. It's just that they like
complaining about just about anything, too. Given the usual release cycle
for programs (i.e., they never get released), I'd suggest that anything
that lets you release faster (without totally screwing up the internals)
you should do. Then let people complain about things.


-Amir


TenthStone

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
On Wed, 19 Jan 2000 10:09:28 GMT, if_...@my-deja.com wrote:

>In article <862k48$6bi$4...@news.ycc.yale.edu>,
> kar...@fermi2.chem.yale.edu wrote:

>> I'm strongly against this sort of policy. Can't you trust people just
>a
>> little bit? There's nothing wrong with putting a "#This file written
>by
>> PLUGH. PLEASE don't mess with it unless you know what you're doing!"
>at the
>> top of each file. But there are oh so many reasons to keep it ASCII:
>well, I agreed with the previous post & I agree with you. I would still
>like to have a propietary file format with the ability to spit out a an
>ascii, TADS only file. Is this an acceptable compromise. I'd just like
>to idiot proof it, cos - sure as eggs is eggs - someone will delete some
>of the Plugh commentary & it won't reload (you know yourself - all users
>are idiots (and that includes me)).

Just to let you know, this is not at all unprecedented; QuickBASIC has
just this sort of feature.

To work with Amir's point, I would advise some sort of "search and
replace through all the text strings in the game" feature.


T Raymond

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
okbl...@my-deja.com spoke about :

>I was thinking more like:
>
>1. I have a building (a well house for a large spring).
>2. I click and drag easterly (to the right) and release, Plugh! puts up
>a room east from the building.

Well that almost sounds like Informapper, except you click on the
desired direction point and it makes the connection and adds the room.
I still think that a study of how that program works will help in the
efforts of this new project.

T Raymond

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
kar...@fermi2.chem.yale.edu spoke about :

>no flames, please <pl...@subdimension.com> wrote:
>
>> From the feedback so far, I would say that it seems that you want me to
>> concentrate on a mapping tool, then do the rest of the stuff.
>> Agree/disagree?
>
>Except that mapping tools already exist, don't they? I'd think you should
>first concentrate on getting something that (a) works (i.e. outputs correct
>TADS code) and (b) lets you do many of the things people want to do in a
>TADS game. Even if I were convinced that having fire sources marked on the
>map were useful, I wouldn't use a program that had that but didn't let you
>edit objects, say. Or maybe I'm just saying this to annoy you.

Do you know of some mapping tools that we don't? I know there's an old
DOS program at GMD, and Informapper which I'm more familiar with. I
believe GUEmap could also be used but I haven't tried that one out at
all.

There may be many mapping tools available, but are there many IF
specific ones, I'm thinking not. Or somebody is holding out somewhere
;)

Dugan Chen

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
David Cornelson <dcorn...@placet.com> wrote in article
<863ola$i69$1...@bgtnsc03.worldnet.att.net>...
> VI will allow you to click on 'stone' and type in the description. It
will
> do the rest for you, including placing it in multiple locations using the
> found_in property.

I love the acronym ;).

plugh!

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
In article <867r2f$3t4...@news.northnet.org>,
ar...@see.the.sig (T Raymond) wrote:

> It's in spanish. Let me know if you want a (mostly) translated version
> to check out.

I'm sure I'll get by. If I'm stuck, I'll shout for help.


> [room shapes snipped]


> Well I'm thinking long range on this part. If at some point you can
> design the map with the room shapes, you don't have to recreate in
> another graphic program to print it out.

I reckon that it can be done without too much trouble. But a little
later on, though.


> [grid and spacing ideas snipped]
> >hadn't thought of a grid. Maybe next version. I don't see hexagonal
> >would help, since there are 8 principle directions (and 4 akward
ones).
> >Any discussion anyone?
>
> Well hexagonal is a throwbaack to D&D RPGs, I made heavy use of them.
> And well, it'd make space IF easier to plot out as most any (somewhat)
> realistic space station would have to be a rounded setup for
> rotational gravity concepts. Oohhh theoretic debate material here ;)

you *won't* see hexagonal. Sorry. Yes, at the moment, it is totaly
frehand. I personally prefer it that way, as it allows more control. I
suppose that I could try to add 'snap to grid' later. It was *never* my
intention to create a drawing program (why don't you all use Visio?),
but most folks here seem to want a mapper.

> [default rooms properties, path ideas snipped]

> I D/L the demo last night and checked it out. The way the Map
> component is set up now it might negate seom of these ideas about grid
> and such. It looked like you could pretty much freeform drop a room
> anwhere. Maybe at some point add in the ability to use a grid for
> lining up (similar to graphic design programs) would handle
> everything.

see above.


> >> Which is another thought. The ability to mark several rooms and
> >> cut/move them to another part of the map would be great. Might be
> >> another wish,
>
> >tough, but I can see why it is desirable.
>
> Well if you've ever started setting up a castle map and decided that
> you had to extend the courtyard and garden area so that you could move
> the tower to a more sensible location, it would make undeniable sense.
> :)

o.k, then I huess that it has to go in. But I *really* don't want to
implement a drawing package.

> On a more general comment. When I tessted it out I noticed a minor
> graphical problem. When I maximized the main window, it seemd that the
> bottom edge of most of the tabs was obscured and any buttons that were
> in that line. You might want to give a look to your margin settings
> for the bottom edges.

I will look into this.


thanks again, Tom. Please continue to post.

plugh!

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
In article <86845q$l9d$4...@news.ycc.yale.edu>,

kar...@fermi2.chem.yale.edu wrote:
> no flames, please <pl...@subdimension.com> wrote:
>
> > [we had to lick the lake!]
>
> > Aye, and you try telling the young people today that, and tehy won't
> > believe you!
>
> Luxury! When I was young we had to wake up half an hour before we went
to
> sleep and do all our programming on a wooden turing machine!
>
> Actually (he said sheepishly), I'm only 27, my first computer was an
Apple
> ][e, and I've never even used ed, let alone punch cards.
divn't mither thase'n, lad. If tha's a Unixer, tha's a real programmer.


> > I find it fantastic, though, that you are contributing so much to a
tool
> > which you may never be able to use. Thanx.
>
> Don't be so sure. There's always WINE. But then, I program (TADS or
> whatever) in VIM, so it's unlikely I'd use PLUGH anyway. (Though as I
said
> before, I'm willing to be convinced.)

well, as I posted elsewhere, Borland have promised to post C++ Builder
to Linux. Now *that* would set teh s/w world on fire (and would also
port Plugh).

plugh!

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
In article <867s4o$3t4...@news.northnet.org>,

ar...@see.the.sig (T Raymond) wrote:
> no flames, please <pl...@subdimension.com> spoke about :
> >well, last night I only had about 30 minutes to spare. Sorry.
>
> Hey, progress is progress. Just think what'd happen if the government
> would get one thing done in 30 minutes! *L*
Don't Congress generally manage to vote themselves a whopping pay rise
in less than 30 minutes (in the dead of night) ?

> >*very sorry*, but I suspect that you may still have the "a required
DLL
> >is missing" problem.

> I D/Led the full package and it ran on my machine ok.

wow! thanks for the feedback. Could you please check if you have
vcl40.bl - probabl in c:\windows\system ?

[snip - concentrate on mapper ]


> I think the majority would like a newer tool that helps with that part
> of creating IF. After time doing so, you find a good editor, get some
> macros, and other little tools that help with the other parts. At
> least until somebody gets a decent system together that does it all.

wouln;t something like Visio help?


> I think the mapping component will require the most work. A code
> editor/inserter is mostly and edit box with some features added to it.
> While that's probably not a snap to put together, it's got to be
> easier than a mapping tool. (Or I could be a raving non-programmer who
> has no clue and both parts are equally as difficult!)

If you are a non-programmer you have an intuitive grasp of what's easy &
what's difficult. Actually, if you can grasp the concept of classes,
inheritance (basing a new class on an existing one), etc, then you are
well on the way to being a C++ programmer.

[snip map ?]


> >What do you think about the map? Should it be one large map, which

> Again I'd have to refer to my experience using Informapper. Multiple
> maps for multiple floors, even though each map could handle many
> locations. Handy for large projects where you work on one set of rooms
> at a time, this would tie in with the room editor too:

looks like I'm going to have to bite the bullet & make it multi-floor.


> Map2: SkyScraper Floor 2
> Rooom 1: Foyer
> Then when the Foyer room gets double-clicked it opens up the file
> that has the floor 2 rooms in it and pops up Room 1 description.

O.K, then I can mark the Foyer in some special way/colour.


[snip - save file format]

> I think that so long as you provide the option to export TADS code to
> a file you can go with the binary save. The point in question is,
> until the rest of the system is working, if you can't export the code,
> it can't be compiled and used. That would tend to make the project an
> interesting toy that can't help you much. At least I think that's the
> point that was being made.

and well made it is too. Time to get hacking.

Thanks for the help. Please keep feeding back.

plugh!

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
In article <86851h$l9d$5...@news.ycc.yale.edu>,

kar...@fermi2.chem.yale.edu wrote:
> no flames, please <pl...@subdimension.com> wrote:
>
> > From the feedback so far, I would say that it seems that you want me
to
> > concentrate on a mapping tool, then do the rest of the stuff.
> > Agree/disagree?
>
> Except that mapping tools already exist, don't they? I'd think you
should
> first concentrate on getting something that (a) works (i.e. outputs
correct
> TADS code) and (b) lets you do many of the things people want to do in
a
> TADS game. Even if I were convinced that having fire sources marked on
the
> map were useful, I wouldn't use a program that had that but didn't let
you
> edit objects, say. Or maybe I'm just saying this to annoy you.
oh, thank you. thank you. Thank you, sweet sir. That is what I
personally want to do. It's just that I have to pander to my public &
they seemed to be clamouring for a mapper. I would much prefer to get a
first version which works & produces code, then add the bells &
whistles.


> I didn't really get what ok (?) was saying about the "higher" levels
on a
> map. But he's definitely right: you need multiple maps for either
multiple
> regions or for multiple levels in one region where it would get too
> confusing to put it all on one 2-D surface.

yes, most of you are saying this.


> > I will try over the coming weekend to condense this discussion & put
it
> > into a To Do list on the web page, with some sort of
timeline/priority,
> > so that you can have a clearer view (and so that Amir will know
exactly
> > what to criticize <g>).
> I HATE the To Do list!
> Or is that not what you meant?

well, since you haven't been formally introduced yet (given that the To
Do list is not yet extant), that sounds somewhat pre-judgemental. Hmm,
can "I hate" be constructed as criticism, or is it simply opinion? In
any case, criticsim, whether con- or de- structive is the goal.


> > Is there any point in getting sophisticated & setting up some sort
of
> > voting system at the web site? Maybe not, if I make evrything
> > configurable.
>
> I'd think a "send me mail" link would be plenty.

o.k, please see teh feedback page on teh web site. However, as I said
previously, it might be best to have the discussion ehere in public, so
that it might benefit future historians.
[big snip]


> > It will be a right royal pain, though, to code s/w to parse every
> > possible persnoal coding style, so I'd rather put it off for a bit.
>
> That certainly could be hard. As someone who wrote a file import
program
> (LaTeX->LyX if you must know), I know how hard it is to satisfy
everyone's
> coding style.

otoh, it is a compliable language, so does have a syntax & grammar, so
it looks like a bit of Lex & Yacc is called for.


> The point here is that in order to get your game to compile, you have
to be
> able to write out TADS anyway. Why not make v1 save in TADS but only
be
> able to read TADS in exactly the format that PLUGH writes out? Just
put all
> the PLUGH stuff between /* */.

as previously posted, someone (you know who you are) will inevitably
delete some Plugh comments or make a global change which inadvertantly
affects them. That's why I'd prefer not to import until a later version.

> > What do you think? Should I delay release in order to parse ascii
TADS
> > files, or can you live with a proprietary save file format in the
first
> > release.
>
> People can live with just about anything. It's just that they like
> complaining about just about anything, too.

Aaah, that Harvard cynicism. How true, how true.

> Given the usual release cycle
> for programs (i.e., they never get released), I'd suggest that
anything
> that lets you release faster (without totally screwing up the
internals)
> you should do. Then let people complain about things.

"So let it be written. So let it be done." (Ramses, I believe; much more
elegant than "make it so" <g>).

plugh!

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
In article <867nil$hkp$1...@nnrp1.deja.com>,

okbl...@my-deja.com wrote:
> In article <85t873$tel$1...@nnrp1.deja.com>,
> if_...@my-deja.com wrote:
> >
> > can download it & see some screenshots at
> > http://plugh.tsx.org
>
> I haven't been able to reach this link in the last couple of days.

well, it's just aforwarder to http://redrival.com/plugh/ so you can try
the direct link for now, but long term aim to use the tsx link in case I
change free service providers.

plugh!

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
Another late business dinner last night. Minor tweaking & U/Led v0.0.2
at midnight. I'll try to keep adding version #s in future.

This one should have add room fully functional, including the adding of
connecting passages.

I hope that you won't have any more run time errors but, if you do, d/l
the full package once & copy vcl40.bpl to your windows\system directory.

I ought to have some time over the weekend. I now know that I will ahve
to add multiple maps. If it looks easy I will push in that direction,
otherwise I will rush towards a first version with only a single map.


Now for somthing controversial. Did you see my post about teh porularity
of various development methods? This is past of one of the replies:
>But if the IF Comp is any indicator, I believe Inform is the most
widely
>used. TADS is second, and not a close second, but way ahead of any of
>the others.

Just for interest, the distribution was

19 Inform: 51%
12 TADS: 32%
3 MSDOS: 8%
2 Alan: 5%
1 Web-based: 3%

for a total of 37.


O.K,it's a fairly small sample & I personally prefer TADS. Any clamour
for Inform? I know that it will be tough in a future system to allow the
choice of either (and I am not going to maintain 2 versions of the
code).

Thanks once again for your help/opinions/criticisms/wit. Please keep
feeding back.

okbl...@my-deja.com

unread,
Jan 21, 2000, 3:00:00 AM1/21/00
to
In article <869d18$o5s$1...@nnrp1.deja.com>,

plugh! <pl...@subdimension.com> wrote:
>
> O.K,it's a fairly small sample & I personally prefer TADS. Any clamour
> for Inform? I know that it will be tough in a future system to allow
the
> choice of either (and I am not going to maintain 2 versions of the
> code).

One possibility would be...er...well, okay, I'll say it: one possibility
would be to develop a kind of generic output that got translated into
TADS or Inform (or Hugo or Alan or whatever).

You could then output Plugh! code--forget about TADS with comments--and
then write a Plugh!-to-TADS translator (which is essentialliy what
you're doing, anyway).

People could write modules for outputtiing any kind of code they wanted
from there. And, if people wanted parsing for a specific language, they
could write the parser for that language. There'd be futzing. The
Plugh! spec would have to be pretty fluid, especially at first.

A lot of these ideas could move from the theoretical to the practical if
you made Plugh! open. Your job would be improving Plugh! and futzing
with the specs. Others could maintain the language-specific elements.
--
[ok]

plugh!

unread,
Jan 22, 2000, 3:00:00 AM1/22/00
to
In article <86arot$rqc$1...@nnrp1.deja.com>,

an astonishing suggestion! I like it! of course, it would slow
development down. So, I'll probably go for a first version as foreseen,
then go for your suggestion next. I fear that it will require along
period of studying the documentation for a bunch of programming
languages & noting similarities & differences. So, that might take
quite a while. But I *do* like your idea.

Of course Plugh will be open. If you look under menu/copyright, you
will see that is released under the GNU public license. I just haven't
U/Led any source yet since it is such early days.

Thanks again.

T Raymond

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
plugh! <pl...@subdimension.com> spoke about :

>> I D/Led the full package and it ran on my machine ok.
>wow! thanks for the feedback. Could you please check if you have
>vcl40.bl - probabl in c:\windows\system ?

No actually it was in the directory I extracted it to. Works from
there too.

>wouln;t something like Visio help?

I haven't seen it actually. I'll go look it up and see what it does.

>If you are a non-programmer you have an intuitive grasp of what's easy &
>what's difficult. Actually, if you can grasp the concept of classes,
>inheritance (basing a new class on an existing one), etc, then you are
>well on the way to being a C++ programmer.

Well I use TADS so I have some clue. I just can't seem to put anything
really complex together and have it make sense.

>> I think that so long as you provide the option to export TADS code to
>> a file you can go with the binary save. The point in question is,
>> until the rest of the system is working, if you can't export the code,
>> it can't be compiled and used. That would tend to make the project an
>> interesting toy that can't help you much. At least I think that's the
>> point that was being made.

>and well made it is too. Time to get hacking.

I'll check it out again later this week and see what things look like.
Thanks for mentioning Visio, I'll check that out too.

R. Alan Monroe

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
In article <86845q$l9d$4...@news.ycc.yale.edu>, kar...@fermi2.chem.yale.edu wrote:
>> I find it fantastic, though, that you are contributing so much to a tool
>> which you may never be able to use. Thanx.

>Don't be so sure. There's always WINE.

Or even better, VMWARE.

Have fun
Alan

Ed Snible

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to if_...@my-deja.com
if_...@my-deja.com wrote:
> Please provide feedback & gelp keep me motivated:-)

if_gui-
I actually wrote a similar GUI-based editor many years ago, although it was
strictly for MUDs. I have some screen shots at
http://www.goodnet.com/~esnible/roomdia.htm
http://www.goodnet.com/~esnible/mobdia.htm
http://www.goodnet.com/~esnible/objdia.htm
unfortunately the map screenshot isn't on line. I designed this during the
days of Windows 3.1 and the GUI is dialog-based -- there isn't a nice map
which can be fully interacted with.

The "doors" section of the dialog is how I solved a similar problem. Users
would select "create" mode then chose directions and move with "go", creating
new rooms. This method allows fast entry of maps and is easy to implement,
but it isn't intuitive and graphically it doesn't look very pretty.

My tool supported Up/Down but not In/Out, but it supported them by drawing up
to be "NW" and Down to be "SE", because the MUD I was based on only supported
the four cardinal directions and U/D. I drew all the rooms on the map in the
same color, but I decorated them with icons to represent light/dark and the
terrain type (water, desert, etc.)

When the map becomes complicated it is very difficult to lay out the entire
map graphically, especially if there are "Twisty mazes" which can't be layed
out without crossing arcs in 2D. I thought I could come up with a good
general layout algorithm and spent many hundreds of hours looking for one.

I got burned out on the project looking for the algorithm. You won't find a
simple one. I did find an excellent paper on VLSI layout by Brian Kernighan
which is applicable to IF mapping, but his solution involves multiple complex
NP-complete sub-algorithms. ["A procedure for Placement of Standard-Cell VLSI
circuits", IEEE transactions on computer-aided design, Jan 1985.] My tool
avoids the problem of general layout by only displaying a tiny window over the
map. (I did have a simple algorithm that properly layed out full maps, but
only about 1/3 of DIKU MUD areas worked nicely -- the rest became tangled
messes.)

Although this tool is still downloaded and used in the MUD world I feel that
its design is poor. It automated the pencil-and-paper way I used to design
MUD zones, but after using it for many weeks I wanted a more flexible design
which wasn't based on my old manual procedures.

I thought of bringing this tool to the IF-world; it wouldn't be very hard. I
could easily write an Inform exporter, which would let users take zones from
DIKU MUDs and output an equivelent in Inform source. I decided not to do
that.

Why? Well, I am not sure that an easy map and object generator is a "good"
think. I suspect it might be harmful. I certainly have been struggling to
produce an IF work, and one of the reasons is that I'm still thinking in the
sort of simple mechanistic way of a MUD. GUI tools, in my experience, lead to
big, semi-interesting mazes and boring stories.

Ed Snible (Slash)
esn...@goodnet.com

PS: Download the tool from http://www.goodnet.com/~esnible/mzf.html. A
somewhat outdated list of other text and GUI-based MUD editors can is
http://www.goodnet.com/~esnible/mudother.html. Spend several hours with the
tools you like before embarking on your own project.

kar...@fermi2.chem.yale.edu

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
T Raymond <ar...@see.the.sig> wrote:
> kar...@fermi2.chem.yale.edu spoke about :

>>
>>Except that mapping tools already exist, don't they? I'd think you should
>>first concentrate on getting something that (a) works (i.e. outputs correct
>>TADS code) and (b) lets you do many of the things people want to do in a
>>TADS game. Even if I were convinced that having fire sources marked on the
>>map were useful, I wouldn't use a program that had that but didn't let you
>>edit objects, say. Or maybe I'm just saying this to annoy you.

> Do you know of some mapping tools that we don't?

Er, when I said, "don't they?", I meant, "I have no clue but it seems like
I've seen people talking about them and periodically seen posts announcing
new versions thereof. perhaps those aren't mappers like you're talking
about.

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
plugh! <pl...@subdimension.com> wrote:

> Now for somthing controversial. Did you see my post about teh porularity
> of various development methods? This is past of one of the replies:

[snippage]

> O.K,it's a fairly small sample & I personally prefer TADS. Any clamour
> for Inform? I know that it will be tough in a future system to allow the
> choice of either (and I am not going to maintain 2 versions of the
> code).


I'm sure people would love inform. However, I suspect this would be HARD.
(Which is even harder than "Hard".) Inform and TADS, though I know very
little about the former, do things in *very* different ways. Is Inform's
class methodology (or the equivalent) anything like TADS'? I think if they
were closely related, then someone would have by now written a program to
translate from one to the other.

I'd say this would be an awesome project, but you'll have your hands full
getting the GUI done, and the two projects are really totally separate.

-Amir

kar...@fermi2.chem.yale.edu

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
plugh! <pl...@subdimension.com> wrote:
> In article <86851h$l9d$5...@news.ycc.yale.edu>,
> kar...@fermi2.chem.yale.edu wrote:
>> I'd think you should first concentrate on getting something that (a)
>> works (i.e. outputs correct TADS code) and (b) lets you do many of the
>> things people want to do in a TADS game.

> oh, thank you. thank you. Thank you, sweet sir. That is what I


> personally want to do. It's just that I have to pander to my public &
> they seemed to be clamouring for a mapper. I would much prefer to get a
> first version which works & produces code, then add the bells &
> whistles.

Oh oh. It sounds like I'm not doing my criticism well enough. Um, how
about: your idea for a development model sucks! Also, your mother smells of
elderberries!

>> The point here is that in order to get your game to compile, you have to
>> be able to write out TADS anyway. Why not make v1 save in TADS but only
>> be able to read TADS in exactly the format that PLUGH writes out? Just
>> put all the PLUGH stuff between /* */.

> as previously posted, someone (you know who you are) will inevitably
> delete some Plugh comments or make a global change which inadvertantly
> affects them. That's why I'd prefer not to import until a later version.

OK. I'll just point out from my reLyXing experience that you're entirely
entitled to have a function that does "import of clean TADS". And by clean,
you would mean TADS-PLUGH that noone screwed up. You don't have to take
responsibility for people's mistakes. OTOH, if someone wants to change a
file a bit by hand, and can do it without messing things up, and you've
already got import capability in there, why not use it?

>> People can live with just about anything. It's just that they like
>> complaining about just about anything, too.
> Aaah, that Harvard cynicism. How true, how true.

Yup. We had classes on cynicism right before the Sneering workshops. Which
came just after the seminars on "How to be a Dead White Male."

> "So let it be written. So let it be done." (Ramses, I believe; much more
> elegant than "make it so" <g>).

Raameses or Yul Brunner?

Incidentally, this quote's in a Dan Bern song, too.

-Amir

plugh!

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
In article <86fjaa$2am$4...@news.ycc.yale.edu>,
I agree with you there. What do you think of teh suggestion that Plugh
is a fancy graphical tool which outouts in its own language &
translators are then written from that to TADS/Inform?

In any case, the most likely scenario for the first version is a binary
save file with TADS export capability.

plugh!

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
well, I didn't get so much done over the weekend. I am curerntly in
Munich, Germany, but probably leaving soon, so I want to revisit lots of
places for one last time. The snow was very heavy over the weekend, so
we went down to Neu Scwhanstein. If you every saw a fairy tale castle on
chocolate box - that's it. It's also the one which Snow White's castle
at Disney is based upon.

The result of that is that I didn't get much time for hacking. What I
did anyway was more to tidy up the code than to produce anything that
the user might notice when runing the program. I will try to put out a
new version in a day or 2. I would still like to have tham at least once
poer week, but can foresee a time when all the easy stuff is coded &
that slows down.

I also need to update thw web site.

In the meantime, here's a style preferance question for you. Do you
prefer to see a list box conatining only selectable items, or one with
all items, where the non-selectable ones are grayed out? The latter is
moe difficult to implement, but may look more pelasing when selecting
directions, etc.

Any other "how it should work" comments, no matter how trivial - please
submit.

I will submit news of any new versions here, along with any questrions
to the user community (all five of you <g>). No one seems to have joined
the mailing list yet, so I will let them know too :-)

Btw, does anyone want to design a fancy logo ?

plugh!

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
Hey ,Amir,

I love your sense of homo(u)r. Since you colonials want to set the
precedent of making instant citizens, maybe I can start a campaign to
make you an hono(u)rary brit? Of course, you may have to float over on
an inner-tube ...

With such wit, I may also ask you to write some of the documentation.
But first, of course, I'll have to get the code finished.

plugh!

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
ho hum,

another day, another minor increment to the s/w. Most of the new code
is hidden beneath the surface. I think that the only visible stuff is
the automatic suggestion of a return passage when you have chosen the
outgoing passage.

I have updated the web site ( http://plugh.tsx.org in case you forgot).
I have added a new menuing system, gotten rid of the problems with
viewing at screen resolutions less than 1024x768, started a history list
& updated the ToDo list. It may be worth a visit to the latter, if you
want to suggest priorities for me.

As previosuly stated, most of the easy stuff is now implemented. Next
comes the grind. Releases may not be coming quite so quickly.

I have a grand total of one (count 'em) mailing list member (you know
who you are!), so won't use that route to notify of new releases. I will
just post to the end of this thread, so please make sure to track it
(set your newsreader somehow, or use http://www.deja.com which allows
you to track a thread & will send you a mail when there is any new
activity on the thread).

Thanks again for the wonderful suggestions. Please continue to make
them.

Iain Merrick

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
plugh! wrote:

> ho hum,
>
> another day, another minor increment to the s/w. Most of the new code
> is hidden beneath the surface.

[...]


> I have a grand total of one (count 'em) mailing list member (you know
> who you are!), so won't use that route to notify of new releases. I will
> just post to the end of this thread, so please make sure to track it
> (set your newsreader somehow, or use http://www.deja.com which allows
> you to track a thread & will send you a mail when there is any new
> activity on the thread).

I don't want to sound snarky here, but do you really have to post here
for every minor update? It's bound to get a bit tedious for people who
aren't interested, or who couldn't run your program even if they were.

I'd suggest keeping minor updates to the mailing list and only posting
for major improvements in functionality. Minor updates to stable,
established programs are different, since they tend not to be updated
every couple of days.

You might want to tell people how to join the mailing list, of course.
I'm sure more than one person is interested. But by posting everything
here you're going to reach an awful lot of disinterested people too.

(Oh, and 'v 0.0.3' isn't a very helpful subject header.)

--
Iain Merrick
i...@cs.york.ac.uk

okbl...@my-deja.com

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
In article <388D94...@cs.york.ac.uk>,

Iain Merrick <i...@cs.york.ac.uk> wrote:
>
> I don't want to sound snarky here, but do you really have to post here
> for every minor update? It's bound to get a bit tedious for people who
> aren't interested, or who couldn't run your program even if they were.

It does sound snarky. It sounded *really* snarky before I noticed that
the thread header was v 0.0.3. (Deja had it all under "Want an I-F
Development GUI?", which is what I think M. Plugh is using.)

Apart from adding [plugh] to his message headers, I don't see why the
incremental changes made to Plugh! are any less relevant than various
similar threads for Inform, TADS, Alan, Hugo, Quest, glk, or any of
their associated libraries, which are *also* seen by people who largely
aren't interested, and some of which even commit the cardinal sin of
being in Windows.
--
[ok]

kar...@yale.edu

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
plugh! <pl...@subdimension.com> wrote:

> I love your sense of homo(u)r.

All the credit goes to my jokewriters.

> Since you colonials want to set the precedent of making instant citizens,
> maybe I can start a campaign to make you an hono(u)rary brit?

Don't even get me started. The latest news is that the reason Congress is
spending their time (and my money) on Insta-naturalization (tm -- just add
water!) is that (a) the Democrats want Congress to get nothing done this
year so that they can convince voters to elect more Democrats and win back
control of Congress, while (b) the Republicans want to get nothing done
because next year they hope to have a republican president (George Bush,
whom IIRC some six percent of voters in America want to elect because he
did such a good job of being president from '88-'92) and then they can
really make some laws.

Oops. You got me started. But I already started a jesus thread; I
probably shouldn't start a politics thread.

> With such wit, I may also ask you to write some of the documentation.
> But first, of course, I'll have to get the code finished.

Urk! (Or should I say, "Egad!" or "Blimey!"?) Probably a bad idea since (a)
I don't have windows, and (b) I'm already on the doc team for LyX, and I
haven't written anything for them in a long time.

-Amir

Roger Firth

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
okbl...@my-deja.com wrote:

Sorry, I'm with Iain here, and it's nothing to do with the platform being
Windows or whatever. It's about respecting the wider interests of a public
forum and recognising that a tiny percentage of the readership wants a blow
by blow account of what M. Plugh did last night. I wish the project all
success
but I really don't want to find half a dozen posts about it, day in and day
out.
Use email to liaise with the faithful, report back here on major progress
every few weeks or so. Please?

Cheers, Roger
--
========================================================================
Roger Firth

David Glasser

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
<okbl...@my-deja.com> wrote:

> Apart from adding [plugh] to his message headers, I don't see why the
> incremental changes made to Plugh! are any less relevant than various
> similar threads for Inform, TADS, Alan, Hugo, Quest, glk, or any of
> their associated libraries, which are *also* seen by people who largely
> aren't interested, and some of which even commit the cardinal sin of
> being in Windows.

Well, because most of the above are not in a continuously evolving state
of development while still unfinished.

It would be perfectly fine to post such announcements once Plugh is
semi-complete but it seems like it would be easier to set up a mailing
list (eGroups?) for development.

--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
rec.arts.int-fiction FAQ: http://www.davidglasser.net/raiffaq/
"So, is that superior artistry, or the easy way out?"
--TenthStone on white canvases as art, on rec.arts.int-fiction

Knight37

unread,
Jan 25, 2000, 3:00:00 AM1/25/00
to
i...@cs.york.ac.uk (Iain Merrick) wrote:

>I don't want to sound snarky here, but do you really have to post
>here for every minor update? It's bound to get a bit tedious for
>people who aren't interested, or who couldn't run your program even
>if they were.

I was kinda hoping he'd post what he had for breakfast in there too.
:)

--

Knight37

"From where you're standing you can't even imagine what the bottom
looks like. It's only after you've lost everything that you're truely
free to do anything." -- Tyler Durden

okbl...@my-deja.com

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to
In article <1e4yvjf.1rp1mjq1ivpksgN%gla...@iname.com>,

gla...@iname.com (David Glasser) wrote:
>
> Well, because most of the above are not in a continuously evolving
state
> of development while still unfinished.

The pattern of message posting that I've seen goes something like:

Announcement-flurry-announcepatchorrevision-flurette-announceotherpatcho
rfinalversion-postpost-optionallastversionforawhile.

This hasn't been *that* much different, except for a few more messages
from the author that "he hasn't done much with it today" which,
admittedly, he could cut down on.

> It would be perfectly fine to post such announcements once Plugh is
> semi-complete but it seems like it would be easier to set up a mailing
> list (eGroups?) for development.

Easier for whom? The guy who's investing all his spare time in an IF
project? Again, except for the "haven't done much" messages, a lot of
the discussion would apply to anyone considering the whole IF GUI thing.
It's not like we're discussing, you know, Christianity.

The thread's died down a lot since it started, and will presumably
settle down further (or die completely) in a little while, unless of
course we get into a flame war about whether or not it should be here.
:-)

David Glasser

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to
<okbl...@my-deja.com> wrote:

> In article <1e4yvjf.1rp1mjq1ivpksgN%gla...@iname.com>,
> gla...@iname.com (David Glasser) wrote:
> > It would be perfectly fine to post such announcements once Plugh is
> > semi-complete but it seems like it would be easier to set up a mailing
> > list (eGroups?) for development.
>
> Easier for whom? The guy who's investing all his spare time in an IF
> project? Again, except for the "haven't done much" messages, a lot of
> the discussion would apply to anyone considering the whole IF GUI thing.

Well, not only easier for those of us for whom Plugh doesn't apply, but
also for the developer(s). If his messages were on a private mailing
list, they'd only go to the people who care about the project, and so he
could feel less restrained about what to discuss, whereas here I'm sure
he doesn't post every teeny little detail because it would bore us.
Plus, you'd never send binaries to r*if but one could on a mailing list
if it was necessary.

Just my two cents.

"Maybe Glulxification will cause people to start using Scheme for IF. Or
maybe not. Anyhow, I just like saying 'Glulxification'." -andyf on ifMUD

J Walrus

unread,
Jan 26, 2000, 3:00:00 AM1/26/00
to

> What do you think of teh suggestion that Plugh
> is a fancy graphical tool which outouts in its own language &
> translators are then written from that to TADS/Inform?

Good idea, but a) what happens if no-one writes a translator? and b)
this might prevent you from using some of the more advanced features of
either language. If Plugh is still intended mainly as a mapping tool,
this approach would work fine, but if you're aiming to be able to write
a complete game using it it could take a lot of effort, even just to
devise the 'Plugh' output language. Having said that, I think it's a
great idea, so if you want to do it then don't be put off. Good luck.


JW

sg

unread,
Jan 29, 2000, 3:00:00 AM1/29/00
to
Iain Merrick <i...@cs.york.ac.uk> wrote:

>plugh! wrote:
>>[an update about the Plugh program developement]


>
>I don't want to sound snarky here, but do you really have to post here
>for every minor update? It's bound to get a bit tedious for people who
>aren't interested, or who couldn't run your program even if they were.

I'm rather disappointed that the daily updates about 'Plugh' seemed to
have ceased.

Though I'm interested in the theoretical discussion of IF IDE's I use
neither TADS nor a Win32 OS so Plugh is of no direct use to me.

Even so I was mildly interested in these blow-by-blow updates - like a
WebCam view into a software development project.

Also, the possibility existed that I might wade in some time with some
theoretical advice and Mr Plugh's purpose in posting frequently was, I
believe, to receive relevant and timely feedback during the project.

>[snip]


>(Oh, and 'v 0.0.3' isn't a very helpful subject header.)

I think this was Mr Plugh's only breach of Usenetiquette and seeing as
Deja doesn't start a new thread when the subject header changes it was
an understandable mistake. (This feature makes Deja's newsreader
'broken' don't you think?)

I suggest to Mr Plugh that if he wishes to continue to post frequent
Plugh development updates he consistently tag his posts with something
like [Plugh Diary].

This should soothe the lurking Snarkies who are sure to have
newsreaders that can filter messages by subject header.

And the mildly interested such as I can choose to read about Plugh or
not as already I do with [Inform] (etc, etc..) posts, depending on my
mood of the day.


--
SteveG.
(Remove the 'wrongbit' from my
address if replying via email.)

Paul de Valmency

unread,
Jan 30, 2000, 3:00:00 AM1/30/00
to
I'm with you "sg".

I think that the 'Snarkies' (where'd that come from?) should all just grow
up, cease belly-aching and just ignore anything from Plugh with 'V0.0.??' in
the header if they're not interested.

Correct me if I'm wrong, but this newsgroup is here for the benefit of the
IF community, and people should be praised and encouraged for their efforts
in moving IF forward, not torn down publicly and discouraged by flames from
those who have never done more that stick a few lines of Inform (or
whatever) together for their own amusement.

If you do have any criticism to dispense, I feel that it should be in
private, via direct e-mail, than in public. There is nothing more
humiliating and discouraging to have what you thought of as a good
contribution trashed before your very eyes in full view of all your peers.

Come on guys (and girls!!), try to be uplifting, eh? I wonder how many
potential Andrew Plotkins and Volker Lanz's there are out there who never
materialise because of the derisory comments that they see thrown at people
who are trying to make a difference.

In short, ease up and give the guy a break.

Paul.


sg <sgwro...@xtra.co.nz> wrote in message
news:3893479b...@news.xtra.co.nz...

David Glasser

unread,
Jan 30, 2000, 3:00:00 AM1/30/00
to
Paul de Valmency <pa...@jcls.freeserve.co.uk> wrote:

> Come on guys (and girls!!), try to be uplifting, eh? I wonder how many
> potential Andrew Plotkins and Volker Lanz's there are out there who never
> materialise because of the derisory comments that they see thrown at people
> who are trying to make a difference.

Wow, this is *raif* you're talking about? Wow.

Truth to be told, I may be one of the 'snarkies', but I think this Plugh
thing sounds great. I just think that the author could feel more free
to be verbose on a private list than on a public group, helping
everyone.

Iain Merrick

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
David Glasser wrote:

[...]


> Truth to be told, I may be one of the 'snarkies', but I think this Plugh
> thing sounds great. I just think that the author could feel more free
> to be verbose on a private list than on a public group, helping
> everyone.

That's exactly my position, in case I wasn't clear. I'm not saying
Plugh! is a bad idea; I just don't think raif is the best place for
posting daily progress reports.

Personally, I'm interested in the current status of TADS 3, Glulx
Inform, HTML-TADS for the Mac and half-a-dozen other IF-related projects
people are working on, but I don't think Mike Roberts, Andrew Plotkin
and the rest should post blow-by-blow accounts of what they're doing to
raif. Use e-mail and/or the web for this sort of thing.

--
Iain Merrick
i...@cs.york.ac.uk

okbl...@my-deja.com

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
In article <3895A8...@cs.york.ac.uk>,

Iain Merrick <i...@cs.york.ac.uk> wrote:
>
> Personally, I'm interested in the current status of TADS 3, Glulx
> Inform, HTML-TADS for the Mac and half-a-dozen other IF-related
projects
> people are working on, but I don't think Mike Roberts, Andrew Plotkin
> and the rest should post blow-by-blow accounts of what they're doing
to
> raif. Use e-mail and/or the web for this sort of thing.

It's a little different for established authors and projects with
existing audiences, don't you think?

Of course, since the last ten or so posts have all been about whether or
not these messages should be posted here and none have been about Plugh
itself....

Joe Mason

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
Iain Merrick <i...@cs.york.ac.uk> wrote:
>That's exactly my position, in case I wasn't clear. I'm not saying
>Plugh! is a bad idea; I just don't think raif is the best place for
>posting daily progress reports.

Why not? It's on-topic, we're low traffic so it's not glutting the group,
and the headers are consistent so its easy to killfile.

Joe

Paul de Valmency

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
I agree with the point about private lists, I just don't think that the guy
should get lambasted because he's posting a bit too often with not much to
report.

Some of the early posts were quite flaming, and my point was that instead of
crucifying the guy, someone should just send newcomers a quiet word on
'netiquette' and a suggestion hinting that they might like to do something
in a different manner.

We were all newbies once, and a little hand-holding for obvious newbies
wouldn't go amiss.

Paul.


David Glasser <gla...@iname.com> wrote in message
news:1e58f20.ctj5qk1cmmo74N%gla...@iname.com...


> Paul de Valmency <pa...@jcls.freeserve.co.uk> wrote:
>
> > Come on guys (and girls!!), try to be uplifting, eh? I wonder how many
> > potential Andrew Plotkins and Volker Lanz's there are out there who
never
> > materialise because of the derisory comments that they see thrown at
people
> > who are trying to make a difference.
>
> Wow, this is *raif* you're talking about? Wow.
>

> Truth to be told, I may be one of the 'snarkies', but I think this Plugh
> thing sounds great. I just think that the author could feel more free
> to be verbose on a private list than on a public group, helping
> everyone.
>

Gene Wirchenko

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
gla...@iname.com (David Glasser) wrote:

>Paul de Valmency <pa...@jcls.freeserve.co.uk> wrote:
>
>> Come on guys (and girls!!), try to be uplifting, eh? I wonder how many
>> potential Andrew Plotkins and Volker Lanz's there are out there who never
>> materialise because of the derisory comments that they see thrown at people
>> who are trying to make a difference.
>
>Wow, this is *raif* you're talking about? Wow.
>
>Truth to be told, I may be one of the 'snarkies', but I think this Plugh
>thing sounds great. I just think that the author could feel more free
>to be verbose on a private list than on a public group, helping
>everyone.

I'd rather have him post. It encourages others to try to do it
themselves instead of just sticking with the most popular systems. He
really doesn't post all that much: I can live with it.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

plugh!

unread,
Feb 2, 2000, 3:00:00 AM2/2/00
to
Hi folks,

I haven't followed this thread since my last post (I _guess_ about
jan 25), owing to personal problems. I should be back in the swing of
things early next week & will read & reply to those posts which need it
then. In the meantime, I have posted a v0.0.0.4 at http://plugh.tsx.org
The only new thing is a class hierachy diagram showing the class
inheritance tree for adv.t. In future versions, the user will be able
to define new classes for rooms, items, everything, based on exsiting
clasees.

Must stop now, more new week.

plugh!

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
point taken. Actually I *had* intentionally posted every minor update
soley in order to keep the thread near the top of the Deja News list. I
had hoped to get away with "if you aren't interested, don't read it",
but it looks like that won't work. As to subjects like "v0.0.0.3" and
"status Jan 20th", I had thought that they seemed o.k in the context of
the thread. Apparently your news reader shows them otherwise.

Don't expect to see anymore announcements of minor versions here.

Your sinoffensively, etc, etc ...


In article <388D94...@cs.york.ac.uk>,


Iain Merrick <i...@cs.york.ac.uk> wrote:
> plugh! wrote:
>
> > ho hum,
> >
> > another day, another minor increment to the s/w. Most of the new
code
> > is hidden beneath the surface.
> [...]
> > I have a grand total of one (count 'em) mailing list member (you
know
> > who you are!), so won't use that route to notify of new releases. I
will
> > just post to the end of this thread, so please make sure to track it
> > (set your newsreader somehow, or use http://www.deja.com which
allows
> > you to track a thread & will send you a mail when there is any new
> > activity on the thread).
>

> I don't want to sound snarky here, but do you really have to post here
> for every minor update? It's bound to get a bit tedious for people who
> aren't interested, or who couldn't run your program even if they were.
>

> I'd suggest keeping minor updates to the mailing list and only posting
> for major improvements in functionality. Minor updates to stable,
> established programs are different, since they tend not to be updated
> every couple of days.
>
> You might want to tell people how to join the mailing list, of course.
> I'm sure more than one person is interested. But by posting everything
> here you're going to reach an awful lot of disinterested people too.
>

> (Oh, and 'v 0.0.3' isn't a very helpful subject header.)
>

> --
> Iain Merrick
> i...@cs.york.ac.uk

plugh!

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
Hi guys,

as I previously posted, I have been away dealing with a personal
matter. I have now returned & can devote some more time to the
development of Plugh.

I was a little dissapointed by the do we/don't we want a blow by
commmentary discussion, but have a solutions to propose.

Firstly, a little background. I am not a newbie, having been a
professional s/w engineer for 20 years now (plus a few years previously
at uni). I was posting to usenet long before there was an interweb
thingy. Long ago, when we had 120b.p.s modems, there were similar
threads concerning bandwidth usage & on/off topic posts which were
probably valid at the time (although the discussions themselves were
generally the greatest consumers of bandwidth). I presonally do not
findsuch concerns to to be valid nowadays - you are entitled to your own
opinion. You will see that I respect that opion shortly, so please do
not post anymore on that subject.

As to changing topics creating new threads, I admit to not considering
that. I was, in fact, trying to be helpful, as I thought that a thread
is a thread is a thread and could be followed as such, the new headers
merely marking sub-threads. I was wrong there & it won't happen again.

I don't regret any posts, as discussion originally was confined to the
functional requirements for the program. I have gathered enough opinion
now to allow me to produce an Alpha version of the program.

I agree that such things can also be discussed on a separate mailing
list (as can everything on r.a.i.f) and intend to confine discussion
there in the future. I just looked at the web page & see that I don't
have a link to the mailing list. I will add one tonight.

I had thought it advantageous to discuss here, so as to make raif-ies
aware of Plugh. Since I am moving the discussion to a private list, I
feel that I must tout the existance of this list on raif. Expect a
posting once per month or so, with a title beggining [Plugh] informing
the n.g of the existance of Plugh, its website & its mailing list. The
snarkies can filter this out.

Hopefully this is acceptable to everyone. You all appear to be
reasonably intelligent young men, many postings come for university
addresses. Please, both sides, do me the favo(u)r of not following up to
this post or perpetuating a flame war. You surely have more constructive
things to do with your time.

p.s since I still haven't come up with a satisfactory mnemonic for
Plugh, perhaps I could change the program's name to Snark. Any
suggestions as to what it might stand for? That way, if the program ever
gets off the ground, we can expect a spate of threads in future years,
enquiring how the program got its name :-)

p.p.s please wait 24 hours, then check out the web site & sign up for
the mailing list. Thanx.

Neil K.

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
plugh! <if_...@my-deja.com> wrote:

> [...] You all appear to be


> reasonably intelligent young men, many postings come for university

> addresses. [...]

Golly! I don't even know where to begin there.

- Neil K.

--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca

plugh!

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to

what? only 99 posts in this thread? surely it can make 3 digits?

/plugh

a hollow voice says "snark!"

It is loading more messages.
0 new messages