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,