The ultimate i-f design tool

12 views
Skip to first unread message

Plugh!

unread,
Feb 12, 2004, 11:53:55 PM2/12/04
to
Gotcha! I knew that that title would snare a few in :-)

In 1996 I first posted to r.a.if positing a GUI based program to
facilitate i-f development. If memory serves, Emily was encouraging,
most others disparaging and the technical challenge too great with the
then current technology.

Four years later, I began work on Plugh! (http://plugh.info) and, four
years after that, the program is 90% complete (the first 90% of the
code takes the first 90% of the time – and the remaining 10% of the
code takes the other 90% of the time). v1.0 is expected to be complete
"real soon now" (tm), although the fact that I am currently consulting
in Shanghai doesn't help matters any as I seem to be much more
interested in exploring Shanghai of an evening than I am in hacking
code.

Feeling reflective in the shower this morning I started musing along
the lines of "if only I knew then what I know now". If I had known,
then Plugh! would be long since complete, but the fact is that it
evolved, rather than being planned and various major changes required
major rewrites.

As a professional software developer, I should know better – and that
brings me (at last) to my point …

might it not be worthwhile to formally specify what would be desirable
from such a program? To invite suggestions from the community here on
r.a.i.f, to codify these and to make a complete and proper design
specification?

I would imagine that we would have to prioritize features and add them
over several releases of the software, but I would *strongly*
recommend that all design be complete before any coding begins.

Then, if we can get a few volunteers, we could modularize the design
and share the code load (maybe via Source Forge?).

I'd rather not hear from the nay-sayers. You may have valid points,
but they would just blur the signal. If you must, please use another
thread – thank you for your consideration.

To kick off, here's some suggestions (I have made a MS Word doc
covering these in more detail, if anyone is interested):

The tool shall simplify the process of creating i-f whilst not
hampering the creative process. Its prime goal is to automate
repetitive tasks, reduce the risk from error prone sequences and to
automate routine housekeeping tasks, freeing the user to be creative.
We seek nothing less than the ultimate r.a.i.f FAQ section 4.10
killer.

It is a design goal that as little code as possible need be hand
crafted, with as much as possible being generated as a result of user
manipulation of the GUI.

Despite this, the user shall be able to achieve anything with the tool
which could be achieved with a plain text editor; using the tool shall
impose no insurmountable restrictions or constraints.

The program should be able to run natively on as many platforms as
possible, but at a very minimum on Windows, Linux and Mac - more if
possible.

Where possible source code should be freely available and GPLed, but
this should not preclude the use of 3rd party components, especially
where they save considerable development time. Such components should
preferably be free of charge.

The tool should be extensively configurable, especially with respect
to confirmation of user actions, such as deletion; but also with
regard to operation and appearance.

Support for multiple i-f languages is greatly desirable, preferably as
plug ins

Import of existing i-f, whether created by the tool or not

Syntax highlighting of user written code

Multi-document interface, with data centric view

Compilation from within the tool

Multiple map view (possibly with zoom)

Both literal and freehand mapping

Perhaps embed properties in rooms definitions which would allow a
suitably tweaked interpreter to unveil the map as the player explores

Option to act as a mapping only tool, rather than a design tool, for
use by players of i-f

User defined class tree

Objects (rooms/items/actors) derived from the classes

Ability to clone objects and psrts of maps

Global code

General design notes

To-do list

Wizards

A plot development tool, showing a sort of time line (i.e. the order
of dependence of the puzzles).

Conversation trees?

What about some way to select a class and see everything which is of
that class or derived from that class?

Borland Delphi (and C++ Builder) style property editors ?

Comprehensive documentation, tutorials and HTML help file

So … any suggestions? And anyone interested? Over the years there have
been many attempts at such a tool and they all failed, for one of
several reasons:
- no proper design before starting
- one man effort not enough for the huge task (the size of which only
became apparent later because fo the lack of design)

I believe that such a program, although extremely ambitious, is
feasible – and desirable. I hope that some of you agree.

Susan Davis

unread,
Feb 13, 2004, 12:17:26 AM2/13/04
to
> So … any suggestions?

Do it as an Eclipse plug-in? Your requirements list seems to be
pointing in that direction, and it'd give you a fair chunk of them
for free, or for relatively little code. And it'd run on most
modern platforms.

--
Susan Davis <s...@sue.net>

Andrew Plotkin

unread,
Feb 13, 2004, 12:41:21 AM2/13/04
to
Here, Plugh! <pl...@plugh.info> wrote:
> Gotcha! I knew that that title would snare a few in :-)

Should I read the rest of this post? Second opinions, please.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

Roger Firth

unread,
Feb 13, 2004, 3:45:34 AM2/13/04
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:c0ho21$88t$1...@reader2.panix.com...

> Here, Plugh! <pl...@plugh.info> wrote:
> > Gotcha! I knew that that title would snare a few in :-)
>
> Should I read the rest of this post? Second opinions, please.


The poster proposes a collaborative exercise to specify and then
implement an all-embracing cross-platform multi-engine IF development
environment, of which he states "I believe that such a program,
although extremely ambitious, is feasible - and desirable."

He also says "I'd rather not hear from the nay-sayers. You may have


valid points, but they would just blur the signal. If you must, please

use another thread - thank you for your consideration.".

Perhaps that's enough to answer your question?

Cheers, Roger
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
You'll find my Cloak of Darkness, Parsifal, Informary
and more at http://www.firthworks.com/roger/


Uli Kusterer

unread,
Feb 13, 2004, 6:03:57 AM2/13/04
to
In article <c0ho21$88t$1...@reader2.panix.com>,
Andrew Plotkin <erky...@eblong.com> wrote:

> Here, Plugh! <pl...@plugh.info> wrote:
> > Gotcha! I knew that that title would snare a few in :-)
>
> Should I read the rest of this post? Second opinions, please.

Definitely.

Cheers,
-- Uli
http://www.zathras.de

Uli Kusterer

unread,
Feb 13, 2004, 6:18:40 AM2/13/04
to
In article <pan.2004.02.13....@sue.net>,
Susan Davis <s...@sue.net> wrote:

> > So … any suggestions?
>
> Do it as an Eclipse plug-in? Your requirements list seems to be
> pointing in that direction, and it'd give you a fair chunk of them
> for free, or for relatively little code. And it'd run on most
> modern platforms.

Ummm... I don't think that'd be that useful an approach. E.g. on Mac
Eclipse has ridiculously high system requirements, and it is rather
slow. Not to mention that most of Eclipse's features are geared towards
Java, and the application is simply *huge*, and takes ages to install.
At least that's how it was when we used it for a programming project
last year. IMHO a clearly-designed host application would be a better
option, especially if the GUI and the actual "model" were clearly
separated.


Concrete example for this separation:

As an example, I recently implemented a simple, stupid mapping algorithm
(already sent it to Plugh). Here's the premise: Every room is simply a
box of a certain fixed size, with up to four exits that lead to another
room. A room has a position specified as a point in X and Y coordinates.

Then, I wrote a C++ class that takes a list of such rooms and lays them
out. It simply does the mathematical calculations needed to determine
the position of each room. That would be the platform-independent part.

Then I wrote a "view" class (in Objective C, which is what most people
use on Mac these days) that iterates over the list of rooms, and draws
them, allows clicking at one of these rooms to select them etc. This
class uses functions in the C++ class to actually layout the map, to
find the room to the left or right of a particular (the selected) room
when someone presses one of the arrow keys etc.

The important part here is: All the maths basically happen in the C++
class, which is the same on all platforms. All drawing, event handling
and the main program flow control happens in platform-specific code,
however.

I.e., Plugh 2.0 would simply be a collection of useful C++ classes that
implement algorithms for the core functionality, while the actual user
interface would be completely handled by platform-specific code.


This seems like lots of work at first, but since *any* development
environment that can talk to a C++ class could be used, one could use
any Rapid Application Design tool to actually implement the GUI. One
could even write a thin "plain C" wrapper around the C++ class, stuff
the entire thing in a DLL, and then use Kylix, Visual Basic or whatever
strikes your fancy to write the GUI around the DLL.

What do you think?
-- Uli
http://www.zathras.de

Uli Kusterer

unread,
Feb 13, 2004, 6:56:21 AM2/13/04
to
In article <68bd0e8.04021...@posting.google.com>,
pl...@plugh.info (Plugh!) wrote:

> I would imagine that we would have to prioritize features and add them
> over several releases of the software, but I would *strongly*
> recommend that all design be complete before any coding begins.

Well, this is definitely a goo idea. Though there are ways to design a
system in ways that later easily allow for extension, it would
definitely help if there was a project lead (i.e. you) who has the big
picture in their head, knows about the list of features and can make
objections if a change is offered that would break anything else.

> Then, if we can get a few volunteers, we could modularize the design
> and share the code load (maybe via Source Forge?).

Generally, yes. Though I have to say I'm kind of a CVS-analphabet. I've
used it in the past a couple of times, but I need someone to hold my
hand and walk me through it occasionally.

> To kick off, here's some suggestions (I have made a MS Word doc
> covering these in more detail, if anyone is interested):

Any chance of making this a more readable format, like RTF, or even
better a plain-text version? Come to think of it, maybe you'd want to
put up a page with that and (in the future) other stuff related to this
project on plugh.info somewhere?

> The tool shall simplify the process of creating i-f whilst not
> hampering the creative process. Its prime goal is to automate
> repetitive tasks, reduce the risk from error prone sequences and to
> automate routine housekeeping tasks, freeing the user to be creative.
> We seek nothing less than the ultimate r.a.i.f FAQ section 4.10
> killer.
>
> It is a design goal that as little code as possible need be hand
> crafted, with as much as possible being generated as a result of user
> manipulation of the GUI.
>
> Despite this, the user shall be able to achieve anything with the tool
> which could be achieved with a plain text editor; using the tool shall
> impose no insurmountable restrictions or constraints.
>
> The program should be able to run natively on as many platforms as
> possible, but at a very minimum on Windows, Linux and Mac - more if
> possible.

A mission statement!

> Where possible source code should be freely available and GPLed, but
> this should not preclude the use of 3rd party components, especially
> where they save considerable development time. Such components should
> preferably be free of charge.

This may be a little of a problem. Before any significant number of
contributors joins, you need to have decided on a license. I've heard
that the GPL required an entire program to be GPL, which may make it
hard to use 3rd party components. IANAL, but you'll definitely want to
be careful in choosing a license. You'll probably want to look at the
various licenses on fsf.org and creative-commons.org and carefully pick
one. The FSF folks also have an e-mail addy for license questions where
a very helpful RMS hangs out who can probably help you massage the GPL
in some way to allow doing certain things you may want to do.

> The tool should be extensively configurable, especially with respect
> to confirmation of user actions, such as deletion; but also with
> regard to operation and appearance.

Just a personal gripe: Warning the user before deleting is nice in
theory, but in practice actually allowing the user to undo a deletion is
a much more convenient method. Undo could be something we'd want to
implement in the portable layer (but in a way that allows it to be
replaced with platform-specific code easily, as e.g. the Mac has very
nice undo support already built in).

> Support for multiple i-f languages is greatly desirable, preferably as
> plug ins

Since you're using C++, one word of warning: You can't really share C++
objects between a host application and its plugins. While it is
possible, it has many pitfalls, and the usual solution is to make the
plugin API itself plain C. Most languages can interface with plain C
functions these days, and you stay more flexible to change objects'
sizes.

> Import of existing i-f, whether created by the tool or not

This could be one of the most involved features.

> Syntax highlighting of user written code

As this needs to interact with the text system on a particular
platform, this also needs to be designed carefully. On some platforms,
there already are pre-existing syntax-colored text edit fields. But
since we want to support multiple languages, we'd probably need a
cross-platform way of specifying what is to be colored in a very
flexible way.

Moreover, on some platforms there may be nobody available who can write
such a text field, so we should keep it modular, so the author can
choose to color known identifiers, but can leave out advanced things
like correctly coloring strings (which can be rather complicated e.g. in
TADS if you want to separately color the parts of "foo <<code>> bar").

> Multi-document interface, with data centric view

I think this should be left to implementors on a particular platform.
IIRC a Single Document Interface on Windows is the recommended design
these days, but of course on Mac there is no such thing as SDI, so an
MDI should definitely be supported by the underlying design. Not sure
how it's done in KDE, GTK, Qt or other Linux GUI kits these days.

> Compilation from within the tool

That'd definitely be nifty, and should be fairly straightforward to do.
Though it may again involve platform-specific code, at least for Windows.

> Multiple map view (possibly with zoom)
>
> Both literal and freehand mapping
>
> Perhaps embed properties in rooms definitions which would allow a
> suitably tweaked interpreter to unveil the map as the player explores

It'd probably be smart to write a generic "IF model" that defines the
base characteristics of an object. I.e. every object has a map position,
a name, one or more superclasses and a list of named properties, that
may contain either code (in text form), text, a reference to another
object, an integer, a boolean or a list. And a property can be marked as
"design only" or "include in game"

On top of that, we'd add a modular "plugin scheme" that allows adding
various features, like having NPCs walk on a track or whatever is the
feature of the day. There would be some "built-in" plugins, of course,
but the advantage of this modular design would be that it'd be easy to
replace a feature, or to e.g. load a different module based on the
target language. I admit that this sounds a little vague right now. I
could elaborate when needed.

> Option to act as a mapping only tool, rather than a design tool, for
> use by players of i-f

This could probably be easily done by just not loading most of the other
plugins.

> A plot development tool, showing a sort of time line (i.e. the order
> of dependence of the puzzles).

Anybody have any concrete ideas for this? I agree that this sounds like
a really great thing. But I haven't the smallest clue how this would
actually look/behave/be implemented ... ?

> Conversation trees?

Don't really know about those enough to offer any clues. Anybody can
give me a link to a definition, or the Reader's Digest version?

> What about some way to select a class and see everything which is of
> that class or derived from that class?

Should be easy. We'd probably need something like that internally
already to allow changes to a superclass to automatically remove
properties that no longer exist from subclasses. Just a simple search
over the "object database".

> Borland Delphi (and C++ Builder) style property editors ?

Any screen shots for the non-Windows people? Last Windows IDE I used
was Watcom C++, shortly after they renamed it Optima++...

> Comprehensive documentation, tutorials and HTML help file

Any takers? I'm not a native speaker, though although I can fake my way
through a conversation, I just lack the skills.

> So … any suggestions? And anyone interested? Over the years there have
> been many attempts at such a tool and they all failed, for one of
> several reasons:

I'd definitely be interested. Though of course that is pending any RL
issues (like maths exams coming up in a month ...), but I should be
available to help in design and contribute the odd bit of code.

Fredrik Ramsberg

unread,
Feb 13, 2004, 7:10:12 AM2/13/04
to
Interesting subject! I know it's come up before, but the ultimate IF
design tool hasn't.

I think the user should be able to move freely between using the tool
and using a plain text editor. If the tool needs to remember any settings
that are connected to the code, but aren't in the code, it should store
these settings either in comments in the code, or as a separate file that
can go with the code. The reason for this is that the user may want to
temporarily work on a platform for which the tool isn't available, or
want to have someone else write or debug some part of the code.

Any information the tools needs to store should be in plain text format,
so that if the tool makes a mistake and stops working with that stored
information, the user stands a reasonable chance to see what's wrong and
fix it.

Also, there may be a need for other kinds of support for developing the
story. The map defines spatial relationships, while the timeline defines
temporal relationships. How about adding an editor for all other kinds of
relationships, such as emotional, legal, "used-for" (for puzzles) etc?
Such an editor could be used to map whatever the author needs for that
specific game. Each entity can have an optional connection to an object
in the game. For one-room games, the map editor is rather useless, but an
editor for mapping how objects interact may come in handy.

The map editor could also include a path editor and/or an area editor.
This could aid in defining paths along which objects move, as well as
different areas where certain objects are allowed to move around.

/Fredrik

Jess Knoch

unread,
Feb 13, 2004, 8:25:46 AM2/13/04
to
Plugh! wrote:
>
> might it not be worthwhile to formally specify what would be
> desirable from such a program? To invite suggestions from the
> community here on r.a.i.f, to codify these and to make a complete
> and proper design specification?

I would have bet money that I'd seen such a list online before. It
was an all-encompassing, thorough and specific set of
requirements/desires. It may be useful to do it over again to get a
new sense of what it is people want, but it would also be useful to
see an already-made list. Has anyone else seen it? Was I dreaming?

--
Jess K., not a nay-sayer, just trying to help.


Roger Firth

unread,
Feb 13, 2004, 8:33:08 AM2/13/04
to
"Jess Knoch" <jessic...@mindspring.com> wrote in message
news:uf4Xb.2489$WW3...@newsread2.news.pas.earthlink.net...


Perhaps http://www.iflibrary.com/default.aspx?pageid=Home&contentid=15 ?

Uli Kusterer

unread,
Feb 13, 2004, 9:46:21 AM2/13/04
to
In article <witness-A73FA2...@news.t-online.com>,
Uli Kusterer <wit...@t-online.de> wrote:

> IMHO a clearly-designed host application would be a better
> option, especially if the GUI and the actual "model" were clearly
> separated.

Uh, sorry, meant to say "a cleanly designed host application", as in
"hand-crafted" or "more lightweight than Eclipse".

And in my first posting, it was of course "good idea" not "goo idea"...

Apologies,
-- Uli
http://www.zathras.de

Jess Knoch

unread,
Feb 13, 2004, 9:52:26 AM2/13/04
to
Roger Firth wrote:
> "Jess Knoch" <jessic...@mindspring.com> wrote...

>> Plugh! wrote:
>>>
>>> might it not be worthwhile to formally specify what would be
>>> desirable from such a program? To invite suggestions from the
>>> community here on r.a.i.f, to codify these and to make a
>>> complete and proper design specification?
>>
>> I would have bet money that I'd seen such a list online before.

>

That's it exactly! Thanks, Roger.

Jess K


Plugh!

unread,
Feb 13, 2004, 11:01:42 AM2/13/04
to
Andrew Plotkin <erky...@eblong.com> wrote in message news:<c0ho21$88t$1...@reader2.panix.com>...
> Here, Plugh! <pl...@plugh.info> wrote:
> > Gotcha! I knew that that title would snare a few in :-)
>
> Should I read the rest of this post? Second opinions, please.
>
Yes, please, Andrew, you should. I value your opinion.

Plugh!

unread,
Feb 13, 2004, 11:07:20 AM2/13/04
to
> He also says "I'd rather not hear from the nay-sayers. You may have
> valid points, but they would just blur the signal. If you must, please
> use another thread - thank you for your consideration.".
>
> Perhaps that's enough to answer your question?
Sorry, Roger, what I really meant, and believe that I said, is that
nay-sayers would "blur the signal". We all know that religious wars
can easily bog things down. I have no objection to nay-sayers, on a
separate thread. In that spirit, I will kick them off said thread
myself.

Really, honestly, truly, I do believe this to be a worthwhile project,
but, much more imnportantly, I believe it to be feasible. This isn't
just a"what if" dream, but rather a serious hope for something
concrete.

Plugh!

unread,
Feb 13, 2004, 10:35:02 PM2/13/04
to
one more point, Roger, Andrew,

as 'pillars of the community', your opinion counts for quite a lot
around here, so if you disparage the idea, it could be finished before
it even gets off the ground.

Furthermore, you two have extensive knowledge which could really be of
help. Ok, I admit, this thing might never come to anything - so many
have tried & failed before, but if you could suspend disbelief for a
moment and treat this as just a mental exercise, I would really,
really appreciate your input.

Thanks

Plugh!

unread,
Feb 13, 2004, 11:07:41 PM2/13/04
to
"Roger Firth" <ro...@firthworks.com> wrote in message news:<10766791...@dyke.uk.clara.net>...

>
> Perhaps http://www.iflibrary.com/default.aspx?pageid=Home&contentid=15 ?
>
Hmmm, how did I let that one slip by me. Yes, the vast majority of
that is an ideal specification, although there are one or two small
points where I could quibble and quite a few additional features which
I would like to add.

Here's a quick opinion on the spec:

2.1 Code access
My first reaction was to disagree. I feared that the code which is
generated by the tool could get out of synch if the user tinkered with
it. That is one of the reasons that the original; Plugh! had a binary
file format.

However, if the tool is to be able to import existing code which has
written by a plain text editor, then I have to concede on this point -
which opens some 55 gallon drums of worms.

2.2 Syntax highlighting, formatting, and checking
100% agree - this is a requirement

2.3 Object and syntax foreknowledge
highly desirable

2.4 Multiple and Single file editing
100% agree - this is a requirement

2.4.1 Single file editing with include files
highly desirable

2.4.1.1 Viewing and Locating
sounds good

2.4.1.1 Viewing and Locating
sounds good

2.4.2 Multiple file editing
complex - but nice

2.5 Cross platform
100% agree - this is a requirement

2.6 Instant compile/debugging
100% agree - this is a requirement

2.7 Inline Debugging
100% agree - this is a requirement

2.8 Context sensitive help
100% agree - this is a requirement

2.9 Base Library foreknowledge
I'll think I'll disagree on this one ... I have hard coded knowledge
of the TADS adv.t in Plugh!, but intend to remove that in v2.0.

I want to treat system files just as any other file in the project and
import them and analyze them. Maybe a user config option to mark some
files as read-only? Ototh, some (poor, twisted, misinformed :-) folks
out there actually like to edit the standard libraries.

2.10 Spellchecker
100% agree - this is a requirement

2.11 Default Library Response Tracker
I'll need to think about that and come back to you.

2.12 Annotations
Sounds great, but very difficult to implement. Perhaps if we specify
it in more detail, the implementation will become clearer.

2.13 Combinatorial Calculator
Presumably included for completeness? It is a "wish" list, after all.
I doubt that this can be specified in enough detail to enable it to be
implemented.

2.14 Version control
good idea

2.15 Description Capture
I'd like to discuss this more

2.16 Mapping Tool
You see this as minor and I see it as quite central. This is a
requirement, 110%

2.17 Code linking
100% agree - this is a requirement


So, all in all, I think the spec is an excellent foundation, even if I
have slight issues with a few minor points. I'd also like to add much
more to it.

I have one minor quibble, though ... The spec seems to be file based
and I am not sure that I see it that way. I'd rather view it more
functionally, probably in terms of the GUI.

However, the bottom line is that the user should have complete control
and the whole thing should be completely configurable.

Plugh!

unread,
Feb 13, 2004, 11:15:52 PM2/13/04
to
f...@mail.com (Fredrik Ramsberg) wrote in message news:<ab01df60.04021...@posting.google.com>...

> Interesting subject! I know it's come up before, but the ultimate IF
> design tool hasn't.
Think big :-)

>
> I think the user should be able to move freely between using the tool
> and using a plain text editor. If the tool needs to remember any settings
> that are connected to the code, but aren't in the code, it should store
> these settings either in comments in the code

Of course, this can be dangerous. But, if the user screws up, he has
only himself to blame.


> The reason for this is that the user may want to
> temporarily work on a platform for which the tool isn't available,

I would expect it to be available on all major and many minor
platforms. Hopefully, this won't happen.


> or want to have someone else write or debug some part of the code.

I'd prefer this other user to also use the tool. But again, it's at
the user's risk.


> Any information the tools needs to store should be in plain text format,
> so that if the tool makes a mistake and stops working with that stored
> information, the user stands a reasonable chance to see what's wrong and
> fix it.

Agreed. I started with a binary file, but was persuaded to change to
plain text for this reason. It also makes it easier for new versions
to be backwards compatible.

> How about adding an editor for all other kinds of
> relationships, such as emotional, legal, "used-for" (for puzzles) etc?

If you can specify it, I can implement it. The problem is that we have
to define how such an editor should work.


> Such an editor could be used to map whatever the author needs for that
> specific game. Each entity can have an optional connection to an object
> in the game.

Yes, that is highly desirable.


> For one-room games, the map editor is rather useless, but an
> editor for mapping how objects interact may come in handy.

Nice idea. Can you give more details?

> The map editor could also include a path editor and/or an area editor.
> This could aid in defining paths along which objects move, as well as
> different areas where certain objects are allowed to move around.

Also nice, although the underlying i-f language would have to support
such constraints (c.f TADS actor tracks).

Thanks for the input.

Arjun

unread,
Feb 14, 2004, 2:47:13 AM2/14/04
to
Umm...I'm perhaps being a little dense, but er..why is Plughs
suggestion being met with skepticism? It does sound too good to be
true, but I'm not sure it's entirely unfeasible either (but then i'm
not aware of the technicalities, so that's a bother). Or am I missing
something entirely?

BTW, Plugh, just how much of this tool has been implemented already
and how much of it works as expected? I presume you would have done
some experimentation already otherwise you wouldn't have put it forth
as a feasible idea.

matteo.desimone

unread,
Feb 14, 2004, 4:10:28 AM2/14/04
to
Plugh! wrote:
> 2.1 Code access
> My first reaction was to disagree. I feared that the code which is
> generated by the tool could get out of synch if the user tinkered with
> it. That is one of the reasons that the original; Plugh! had a binary
> file format.

XML? Is a human readable format but rigid grammar-rule based format: the
user cannot break the structure or loose main structural information.

by
matteo!

Plugh!

unread,
Feb 14, 2004, 7:33:11 AM2/14/04
to
arjun_...@lycos.com (Arjun) wrote in message news:<79c237cd.04021...@posting.google.com>...

Ah, now there you have me ... this topic is a FAQ indeed. Most who ask
haven't implemented anything. I have a little something, which I will
come to in a moment, but I certainly started with nothing implemented,
and I started by posing a similar question (admittedly, quite not so
broad in scope). One thing seems clear to me - don't produce something
in isolation, then expect raif to accept it; the better way is to
solicit requests, then try to meet them.

How far have I come? you tell me .. please visit http://plugh.info,
look around, download and play around with the program.

I believe that I am "95% complete", but that is an insider phrase. I
am a professional software engineer, forty-harumph years old, and I
see now the mistakes that I made with Plugh! I honestly believe that
anything, and certainly such a thing, is perfectly feasible - *if it
is developed in a professional manner*.

That means, firstly collect the requirements, then produce the
requirements specification. When that is complete, work on a detailed
design specification and – only then – begin to code. If we approach
the task professionally, we can modularise the task and divide the
work. Kiddies' play – I've been professionally screwing this sort of
thing up for nigh on 25 years :-)

The coding should be the least of our worries. The *major* challenge
is to adequately specify what we want to achieve. We start at a
logical level, describing in non-technical terms – e.g, support
multiple languages/round trip editing/compile & debug from within the
tool/etc, etc and – only when we have a full requirements list – we
make a high level functional design, then a detailed design, including
specifying the major data structures and – finally – we hack some
code.

I do *honestly* believe that any software project is feasible so long
as it is fully specified. I could do it myself, although that would
take time. The more volunteers, the quicker implemented (I would
personally recommend a phased approach, but only with everything fully
spec'd before we begin. I had several major reworks of Plugh! because
I let the program grow organically, rather than designing first).

There is- naturally – scepticism – and I can understand that. Maybe I
should first have produced something concrete (Plugh! V1.0) and then
asked for suggestion as to the great successor. In any case, I will
finish Plugh!, hopefully within the next few months, if only
to show that such a thing is both feasible and useful.

So, if you have any suggestions to offer – either to Plugh or the
suggested project – please contribute. Don't worry if you don't know
how to implement it, we will start with a wish list.

Thank you very much for taking the time to post.

Sam Denton

unread,
Feb 14, 2004, 8:05:04 AM2/14/04
to
pl...@plugh.info (Plugh!) wrote in message news:<68bd0e8.04021...@posting.google.com>...

> Here's a quick opinion on the spec:
>
> 2.1 Code access
> My first reaction was to disagree. I feared that the code which is
> generated by the tool could get out of synch if the user tinkered with
> it. That is one of the reasons that the original; Plugh! had a binary
> file format.
>
> However, if the tool is to be able to import existing code which has
> written by a plain text editor, then I have to concede on this point -
> which opens some 55 gallon drums of worms.

This reply should maybe go in the other thread, but this is why I
write things that aren't the "ultimate i-f design tool". I instead
aim for the 80/20 rule.

My goal is that the 'easy' 80% of the code can be generated by my
tools, the other 20% is 'hard' and gets done by hand, along with the
actual glueing together of the components. My tools (yes, I have two
of them now) take text input written in a domain-specific language and
produce Inform code that can then be included (via the Include
command, not cut-n-paste) in the main file.

The first tool is one I've talked about here before, 'log2inf.pl'.
It's "domain-specific language" is transcript file and it generates
room and prop objects. In my current project, it generates a
'citymap.inf' file with about two dozen locations and an equal number
of props and scenery objects. In terms of line count, it is already
creating 80% of my final code, and I find that my descriptions of
things flow better if I'm not worrying about Inform syntax.

The second tool is a digression from my current project, 'rap2inf.pl'.
It's taken several days, but I've finally wrapped my head around Nate
Cull's RAP code. I plan to use it in my next project, but for several
reasons, I consider it unusable in its original form. So I'll be
creating '.rap' files that look like this, instead of Nate's
'rapplan.h':
goal DoggyFun(actor, unused1, unused2)
done never, ! because puppies never want to stop having fun
plan is
be Inscope(actor, ball, 0), ! be in the same location as the
ball
do PlayWith(actor, ball, 0); ! play with the ball

As I said, integration of the output of these tools is someting that I
do by hand. My current project, Kemerovo, has a 'main' file that
pretty much looks like this:
Include ">classes.inf"; ! nothing but class defs, hopefully
reusable
Include ">citymap.inf"; ! output of 'log2inf.pl citymap.log'
Include ">hotel.inf"; ! hand-crafted code
Include ">salon.inf"; ! hand-crafted code
Include ">telco.inf"; ! hand-crafted code
[ Initialize ;
print "intro text^";
objectloop (x provides Init) {x.Init()}; ! thanks to OnyxRing
for this
location = Room522;
];

Rick Clark

unread,
Feb 14, 2004, 9:01:13 AM2/14/04
to
Plugh! wrote:
> How far have I come? you tell me .. please visit http://plugh.info,
> look around, download and play around with the program.

Well, I have been playing with the program and I find it interesting.
Frankly, I don't think you need to make it the end-all of IF IDEs.
Regardless of how many features you add, people are still going to tweak
the resultant code. It is in the nature of most accomplished IF authors.
:) I think if you can do two things you can claim success:

1) Put enough features in the program so that a newbie IF author can
produce a playable game. It may not have everything an experienced IF
author would put in her or his game, but it should have all the basics:
rooms, doors, items, some NPC interaction, etc.

2) By doing 1), you will help with 2): Help facilitate the planning and
design of the game. For example, creating a visual mapping program would
go a long way in offsetting the tedium of planning out the game. Again,
the map doesn't have to cover possible instance (magic word or random
rooms, or some other arcane and rare instance); if it covers 80% to 90%
of what you find in a game, I would find that acceptable and it would be
a big help. Again, an accomplished author is going to tweak the code no
matter how good the program is, so automate the drugery and you will
have a good program.

Well, my .02.

Rick Clark

Andrew Plotkin

unread,
Feb 14, 2004, 9:50:50 AM2/14/04
to
Here, Plugh! <pl...@plugh.info> wrote:
> one more point, Roger, Andrew,
>
> as 'pillars of the community', your opinion counts for quite a lot
> around here, so if you disparage the idea, it could be finished before
> it even gets off the ground.

I am not disparaging the idea. But you said that nay-sayers should not
participate in this thread, and then your follow-up "negative" post
was dismissive as well. (I, like others, failed to realize you
intended that part as a joke.)

When I write Inform code, the easy 80% of the code takes 20% of my
time. So a visual IDE is not attractive to me. I am, literally, a
nay-sayer. I can't "suspend my disbelief" because that's suspending my
judgement of what would be a useful tool.

Uli Kusterer

unread,
Feb 14, 2004, 10:03:07 AM2/14/04
to
In article <102sahm...@corp.supernews.com>,
Rick Clark <rickc...@yahoo.com> wrote:

> :) I think if you can do two things you can claim success:
>
> 1) Put enough features in the program so that a newbie IF author can

> produce a playable game. (...)


>
> 2): Help facilitate the planning and
> design of the game. For example, creating a visual mapping program would
> go a long way in offsetting the tedium of planning out the game. Again,
> the map doesn't have to cover possible instance (magic word or random
> rooms, or some other arcane and rare instance); if it covers 80% to 90%
> of what you find in a game, I would find that acceptable and it would be

> a big help. (...)

I would suggest the same, except for the all-important #3, which I would
actually make #1:

3) The program shouldn't get in the way.

Let me elaborate: It is e.g. nice to have a tool that lets you generate
a skeleton and then modify that to suit your needs. However, often
development is iterative; the author creates the skeleton, adds some
code of their own, ships it out to a tester, and the tester uncovers a
gameplay flaw. The author goes back and has to re-arrange some rooms etc.

Now, the program shouldn't require the author to re-apply all changes
made to the game code afterwards. Instead, the program should be built
with the knowledge that, no matter how good your program is, users
*will* want to edit the code. Ideally, it should almost "encourage"
people to edit the code.

OTOH, I don't think it'd be wise to assume that importing code into the
app and then generating code from that again was the solution to this
problem. Just look at how many HTML editors still screw up the order of
tags. It is still a while until we'll be able to write editors that can
losslessly import/export code repeatedly.

So, IMHO, it'd be better if importing was a one-time action. The
resulting Plugh++ file would be in a format that can be edited easily in
a text editor (I'm not sure XML would be the solution -- most XML I see
these days is not half as readable as HTML used to be) for those cases
where people don't have the program around and want to make a quick fix.

But for all intents and purposes, the Plugh++ file would be "the source
code", and would be flexible enough to allow the user to even change
predefined objects. E.g. if there is an NPC module, and I know I want
all my actors to be named with proper nouns instead of regular ones like
"the janitor", it should be possible to modify the generated code to
automatically set theDesc and aDesc of the object to the shortDesc.

How would one do that? I'll elaborate on that in a separate message.

Uli Kusterer

unread,
Feb 14, 2004, 10:35:51 AM2/14/04
to
Okay, here's how I would allow ultimate customabizability for the tool,
as described briefly in a previous posting.

Note that with the current goals of Plugh++ as being multi-language,
this may actually become a little more involved than we'd want, but
maybe someone else has an idea how to work around that.

To be able to customize even the code generated by the program itself,
game programmers would need to be able to modify the code that actually
does the code generating. Since generating code is simply outputting
text, IF languages seem predestined for this purpose. And since the
authors already know their IF language of choice, it only seems sensible
to use Inform to generate the Inform code, and TADS to generate the TADS
code, etc.

The trouble would be mixing that code with the GUI, since most IF
languages today offer very limited control over GUI. But since the
program is already built to interface with the compiler and interpreter,
I suspect we could just use them. As long as all interpreters allow us
to have them simply give us the output of the "game", we could probably
just write a pseudo-game that would output code instead of game text.
From what I've seen T3 and Inform are flexible enough for this, other
engines' authors may be convinced to add support for it.

Now, what do we have now? We have an object hierarchy, where some
objects contain of constant data, i.e. they have a few methods saved as
text, and they have properties containing text strings, numbers, or
names of other objects.

In addition to that, we have "smart" objects that have properties, too,
but whose actual code is generated from the data in those properties by
a chunk of TADS or Inform code, which in turn generates the text form of
the entire object's definition.

Now, on the outside, these objects look exactly the same. And they can
be used in the same ways by the user. The user can go and subclass one
of the smart objects, and add a function of their own. Heck, we could
even go as far as using a collection of scripts. One for each property
or method the object has. That way, a user could say: 'I want that smart
NPC object, but the way it generates the "adesc" for my actor doesn't
fit. I'll just plug in my own code to generate the TADS code for the
adesc.' Of course, the user could also just replace that auto-generated
code with their own "static" code.

See where I'm headed? By using such a flexible foundation, everything
built on top would immediately be customizable. Moreover, it would be
customizable by people who know an IF language, and it wouldn't require
a C programmer or other geek to do so.

Comments? Suggestions? Flaws?
-- Uli
http://www.zathras.de

Seebs

unread,
Feb 14, 2004, 1:49:36 PM2/14/04
to
In article <79c237cd.04021...@posting.google.com>,

Arjun <arjun_...@lycos.com> wrote:
>Umm...I'm perhaps being a little dense, but er..why is Plughs
>suggestion being met with skepticism? It does sound too good to be
>true, but I'm not sure it's entirely unfeasible either (but then i'm
>not aware of the technicalities, so that's a bother). Or am I missing
>something entirely?

I'm not yet sure how it would help me. I just mapped a house out for a
new game, and it didn't take long at all. I was putting in rooms and
connecting entrances while talking about the design of the game with my
coauthor. In any practical sense, it took no time at all. :)

-s
--
Copyright 2004, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/

Sam Denton

unread,
Feb 14, 2004, 2:24:57 PM2/14/04
to
Uli Kusterer <wit...@t-online.de> wrote in message news:<witness-F33BDE...@news.t-online.com>...

> 3) The program shouldn't get in the way.
>
> Let me elaborate: It is e.g. nice to have a tool that lets you generate
> a skeleton and then modify that to suit your needs. However, often
> development is iterative; the author creates the skeleton, adds some
> code of their own, ships it out to a tester, and the tester uncovers a
> gameplay flaw. The author goes back and has to re-arrange some rooms etc.
>
> Now, the program shouldn't require the author to re-apply all changes
> made to the game code afterwards. Instead, the program should be built
> with the knowledge that, no matter how good your program is, users
> *will* want to edit the code. Ideally, it should almost "encourage"
> people to edit the code.

Ditto.

I've described elsewhere my tool for creating rooms and fixtures from
transcripts. The next tool that I plan to create (after I finish my
RAP tool) will be one that takes two files containing objects and
intellegently merges them together. For example, my 'log2inf' tool
might generate this:
Room Living_Room "Living Room"
with
description "here you are",
n_to Kitchen,
w_to Front_Yard;

Now, assume that I have another file, created by hand or perhaps some
future tool, that contains this:
Room Living_Room "Living Room"
with
before [ SitOn: "You'd better not, the furniture all has plastic
slipcovers and your maiden aunt will get mad."];

I want the output of the merge process to contain a single Living_Room
object with both sets of properties (and similarly combining actions
inside of 'before', 'life', etc, as needed). This way, my mapping
tool can do what it does best, I or some hypothetical tool can do our
things, and since there's no need to manually merge the results, I can
rerun each process as many times as I like.

Scott Forbes

unread,
Feb 14, 2004, 10:36:14 PM2/14/04
to
In article <c0lcka$b96$1...@reader2.panix.com>,
Andrew Plotkin <erky...@eblong.com> wrote:

> When I write Inform code, the easy 80% of the code takes 20% of my
> time. So a visual IDE is not attractive to me. I am, literally, a
> nay-sayer. I can't "suspend my disbelief" because that's suspending my
> judgement of what would be a useful tool.

...and this is why asking for input from the Andrew Plotkins of the IF
community is unlikely to produce a useful result, in my not-so-humble
opinion. It's like asking an Olympic swimmer to help design water
wings, or polling Stephen King, Michael Crichton and Tom Clancy to see
what features of Microsoft Word they use most often. The results of
those surveys are not representative of the tool's most likely users.

I'm the author of Yonk, an Inform IDE for the Mac (or, at least, a
humble start in that direction), and a complete amateur in the world of
actually writing interactive fiction. I've done what everyone does when
playing with IF for the first time, which is to build a map of my
apartment and implement my living room furniture, but I've never
proceeded from there to produce an actual IF work with storyline and
plot and all those other details. Instead I've digressed into writing a
tool which will make authoring easier for me, and then digressed further
into writing essential building blocks (e.g., a full Undo/Redo system)
which will help me build that IF-writing tool.

(For the curious, the fruits of my toolsmithing, such as they are, can
be downloaded from <http://www.ravenna.com/~forbes/yonk/>.)

As the author of Yonk, I'm not trying to write the "ultimate i-f design
tool" -- I'll be happy if my app just delivers a marginal improvement
over BBEdit, and if I can eat my own dog food (that is, I can use the
application I've written for its intended purpose) and not dislike the
taste. Today Yonk can do a few simple things well: It can read a file
containing Inform source code, allow the user to edit and manipulate
that code, and write a source file that the compiler can play with. It
displays a hierarchical list of declarations and objects, allows you to
"walk around" on a simplified map, and takes care of some details of
Inform syntax for you.

Yonk isn't going to be useful for Andrew Plotkin (this in spite of the
fact that he uses a Mac, which in theory makes him a prime candidate for
my only-game-in-town IDE), because it doesn't offer any real help for
writing exotic movement systems (ala "Hunter, in Darkness") or a complex
one-room game (e.g., "Shade"). Andrew is not in my target audience. My
target audience is entry-level IF authors, who are still struggling with
the code that Andrew refers to as the "easy 80%" -- because he's written
that code enough times that it's second nature to him now, and it would
disrupt his workflow and be counterproductive to introduce a tool that
assists with that part.

Plugh! and I have had offline conversations along these lines before; my
strongest recommendation for any IF authoring tool is that it should
provide a very basic, fundamental set of features -- specifically, the
ability to read existing source files and manipulate them -- before
proceeding to rest of the wishlist. If I can't import my existing
half-baked IF project into your tool, then I can't assess whether your
tool will help me unless I write off my efforts to date and start over;
to me, this is a greater barrier to entry than whether Andrew or Adam
Cadre would use the tool I'm writing. (Meaning no offense to Andrew or
Adam, whose works I greatly enjoy -- but clearly you two are getting
along just fine, without the benefit of any IF authoring tools that
don't already exist today.)

--
Scott Forbes for...@ravenna.com

Andrew Plotkin

unread,
Feb 15, 2004, 6:59:23 AM2/15/04
to
Here, Scott Forbes <for...@ravenna.com> wrote:
> In article <c0lcka$b96$1...@reader2.panix.com>,
> Andrew Plotkin <erky...@eblong.com> wrote:
>
> > When I write Inform code, the easy 80% of the code takes 20% of my
> > time. So a visual IDE is not attractive to me. I am, literally, a
> > nay-sayer. I can't "suspend my disbelief" because that's suspending my
> > judgement of what would be a useful tool.
>
> ...and this is why asking for input from the Andrew Plotkins of the IF
> community is unlikely to produce a useful result, in my not-so-humble
> opinion. It's like asking an Olympic swimmer to help design water
> wings, or polling Stephen King, Michael Crichton and Tom Clancy to see
> what features of Microsoft Word they use most often. The results of
> those surveys are not representative of the tool's most likely users.

That's kind of a weird analogy. Two different analogies which are
weird for different reasons.

I don't actually have anything to add to that, except to agree with
the point, which is that I'm not the target audience for an IDE.

(I used CodeWarrior, which was the pre-eminent Mac IDE for C/C++
development through most of the Classic era (OS 7.5 to OS 9 days).
Eventually I noticed I'd rather reboot into Linux and bury myself in
Emacs and Makefiles than touch the damn Codewarrior environment. I
still haven't started doing OSX-native programming, and it's largely
because the idea of running XCode or Interface Builder makes me sad.
Especially since Emacs and make are *on* this thing now.)

Richard Northedge

unread,
Feb 15, 2004, 3:05:50 PM2/15/04
to
> I do *honestly* believe that any software project is feasible so long
> as it is fully specified. I could do it myself, although that would
> take time. The more volunteers, the quicker implemented (I would
> personally recommend a phased approach, but only with everything fully
> spec'd before we begin. I had several major reworks of Plugh! because
> I let the program grow organically, rather than designing first).
>
> There is- naturally ? scepticism ? and I can understand that. Maybe I

> should first have produced something concrete (Plugh! V1.0) and then
> asked for suggestion as to the great successor. In any case, I will
> finish Plugh!, hopefully within the next few months, if only
> to show that such a thing is both feasible and useful.

It's certainly possible to write a useful IDE for IF languages. I am
just at the point of releasing version 1.5 of Imaginate, the code
editor for TADS/Alan/Inform. I'd be happy to share the insights I
have from working for a few years on Imaginate.

Others in the thread have talked about code generation facilities. I
wonder if one approach to multi-IF language code generation would be
to create an API with interfaces on 2 sides - one side would hook up
to a GUI, and let the user specify their design in terms of the API,
then the other side would plug in "connectors" for each of the
supported IF languages. Then a connector would need to be written for
each IF language, that would translate from the generic API to the
actual IF code.

I'm guessing the middle layer that I'm talking about would work in
terms of rooms, objects, etc.

> So, if you have any suggestions to offer ? either to Plugh or the
> suggested project ? please contribute. Don't worry if you don't know


> how to implement it, we will start with a wish list.

As I say, I'm happy to contribute suggestions, but one thing in your
specification makes it very unlikely I would be able to contribute to
the actual coding: the cross-platform application. I am not skilled a
programming language that will create GUI applications that work on
non-Windows platforms. Unless you count C# with Mono etc.



> Thank you very much for taking the time to post.

Cheers,

Richard

Plugh!

unread,
Feb 15, 2004, 9:20:25 PM2/15/04
to
Andrew Plotkin <erky...@eblong.com> wrote in message news:<c0lcka$b96$1...@reader2.panix.com>...

even gets off the ground.
>
> I am not disparaging the idea. But you said that nay-sayers should not
> participate in this thread, and then your follow-up "negative" post
> was dismissive as well. (I, like others, failed to realize you
> intended that part as a joke.)
Sorry, that's teh problem with text based interafces. I forgot that
you guys culdn't see me chuckling.


> When I write Inform code, the easy 80% of the code takes 20% of my
> time. So a visual IDE is not attractive to me. I am, literally, a
> nay-sayer. I can't "suspend my disbelief" because that's suspending my
> judgement of what would be a useful tool.

Of course, I respect your right to your opinion. In some respects, I
even agree with what what you say about the usefulness of such a tool.

To be very honest, I started Plugh because I wanted to give something
back to the community which has given me so much pleasure and that was
all that I could think of at the time. So, if there's some other tool
which you think would be useful, I don't mind having a crack at that
instead.

Plugh!

unread,
Feb 15, 2004, 10:46:57 PM2/15/04
to
Uli Kusterer <wit...@t-online.de> wrote in message news:<witness-74C798...@news.t-online.com>...

> In article <68bd0e8.04021...@posting.google.com>,
> pl...@plugh.info (Plugh!) wrote:
> > To kick off, here's some suggestions (I have made a MS Word doc
> > covering these in more detail, if anyone is interested):
>
> Any chance of making this a more readable format, like RTF, or even
> better a plain-text version? Come to think of it, maybe you'd want to
> put up a page with that and (in the future) other stuff related to this
> project on plugh.info somewhere?
Good, idea. I'll convert it to HTML and upload it regularly. Hmm, if
we could agree on a name for this project, I could give it it's own
web site. As I mentioned in an e-mail, I'd like to make the design a
WiKi.


> This may be a little of a problem. Before any significant number of
> contributors joins, you need to have decided on a license.

A very good point. Any recommendation?

> > Support for multiple i-f languages is greatly desirable, preferably as
> > plug ins
>
> Since you're using C++, one word of warning: You can't really share C++
> objects between a host application and its plugins. While it is
> possible, it has many pitfalls, and the usual solution is to make the
> plugin API itself plain C. Most languages can interface with plain C
> functions these days, and you stay more flexible to change objects'
> sizes.

We will discuss this more when the time comes. Maybe that will be your
first area of design responsibility :-)


> > Import of existing i-f, whether created by the tool or not
>
> This could be one of the most involved features.

Yes, I know. But from so many of the other posts, it seems clear that
it is desired. Btw, you gave me some nice code once for parsing TADS 2
files. Do you know if T3 is a superset of T2? That is, if I can handle
T3, do I automatically have T2 support?

Btw, for TADS, I once considered taking the code of the interpreter
and tweaking that.

So long as we design it will and make it modular, we don't have to do
it immediately.


> > Syntax highlighting of user written code

[snip]


> Moreover, on some platforms there may be nobody available who can write
> such a text field, so we should keep it modular, so the author can
> choose to color known identifiers, but can leave out advanced things
> like correctly coloring strings (which can be rather complicated e.g. in
> TADS if you want to separately color the parts of "foo <<code>> bar").

Yes, done properly, it is much more that just colo(u)ring a few
keywords. Oh, well, so long as it can be specified, it can be
implemented.

> > Multi-document interface, with data centric view
>
> I think this should be left to implementors on a particular platform.
> IIRC a Single Document Interface on Windows is the recommended design
> these days, but of course on Mac there is no such thing as SDI, so an
> MDI should definitely be supported by the underlying design. Not sure
> how it's done in KDE, GTK, Qt or other Linux GUI kits these days.

One of the things that I don't like about Plugh is that I can only
work on one thing at a time. Sure, this helps concentrate my effort &
makes sure things don't get left 1/2 done. But I can see how it would
be nice to have a map (or 2) open, which working on an NPC and some
treasures, etc


> It'd probably be smart to write a generic "IF model" that defines the
> base characteristics of an object. I.e. every object has a map position,
> a name, one or more superclasses and a list of named properties, that
> may contain either code (in text form), text, a reference to another
> object, an integer, a boolean or a list. And a property can be marked as
> "design only" or "include in game"
>
> On top of that, we'd add a modular "plugin scheme" that allows adding
> various features, like having NPCs walk on a track or whatever is the
> feature of the day. There would be some "built-in" plugins, of course,
> but the advantage of this modular design would be that it'd be easy to
> replace a feature, or to e.g. load a different module based on the
> target language. I admit that this sounds a little vague right now. I
> could elaborate when needed.

I hope that you will... ;-)


> > A plot development tool, showing a sort of time line (i.e. the order
> > of dependence of the puzzles).
>
> Anybody have any concrete ideas for this? I agree that this sounds like
> a really great thing. But I haven't the smallest clue how this would
> actually look/behave/be implemented ... ?

Just a mini-drawing package, I guess. Drag & drop some icons
representing puzzles, etc, maybe onto a time-line. We're just at the
wish list stage here, but will, obviously, have to fully specify
everything before development begins.


> > Conversation trees?
>
> Don't really know about those enough to offer any clues. Anybody can
> give me a link to a definition, or the Reader's Digest version?

often asked for by others. Not 100% cure myself. But, basically, I
think it's just a sort of decision tree as to how an NPC converses
with you, given your replies.


> > What about some way to select a class and see everything which is of
> > that class or derived from that class?
>
> Should be easy. We'd probably need something like that internally
> already to allow changes to a superclass to automatically remove
> properties that no longer exist from subclasses. Just a simple search
> over the "object database".

Or an option - if property is removed form superclass, it could also
be declared in any sub-class which actually uses it.


> > Borland Delphi (and C++ Builder) style property editors ?
>
> Any screen shots for the non-Windows people? Last Windows IDE I used
> was Watcom C++, shortly after they renamed it Optima++...

Something like this http://www.hallamshire.com/hsbim/1.1/programmersguide/mpsw.gif
the idea is that the editor knows the type of each property & can
offer the appropriate input mechanism (integer, string, memo, etc
also, for bools & enums, can restrict input to valid values).


>
> > Comprehensive documentation, tutorials and HTML help file
>
> Any takers? I'm not a native speaker, though although I can fake my way
> through a conversation, I just lack the skills.

You could fool me. The length of your mails & posts shows just how
good your English is. No, my friend, you don't get off of the hook
that easily :-) (besides which, your spelling is so much better than
mine)


> > So ? any suggestions? And anyone interested? Over the years there have


> > been many attempts at such a tool and they all failed, for one of
> > several reasons:
>
> I'd definitely be interested. Though of course that is pending any RL
> issues (like maths exams coming up in a month ...), but I should be
> available to help in design and contribute the odd bit of code.

Thanks, Uli, then we'll make a start on it, even if there are only two
of us.

Uli Kusterer

unread,
Feb 16, 2004, 12:30:42 AM2/16/04
to
In article <c31c7fe7.04021...@posting.google.com>,
rnort...@hotmail.com (Richard Northedge) wrote:

> I'm guessing the middle layer that I'm talking about would work in
> terms of rooms, objects, etc.

That is basically the design I would use for the internals of such an
application. However, adding yet another language doesn't sound too
useful IMHO. After all, most people pick one language (out of the
existing ones) because they like the syntax, the structure of the
library, the feature set or whatever. They'd completely lose most of
that if they started writing in a special Plugh-Language.

> As I say, I'm happy to contribute suggestions, but one thing in your
> specification makes it very unlikely I would be able to contribute to
> the actual coding: the cross-platform application. I am not skilled a
> programming language that will create GUI applications that work on
> non-Windows platforms. Unless you count C# with Mono etc.

Actually, programming for cross-platform deployment isn't that hard if
you do it right. But to do that, you have to realize that the
cross-platform GUI tools do not really create "native" GUIs for the
platform they're ported to. Rather, they create "cross-platform GUIs".
I.e., whether you run your Java application on a Mac, on Windows or on
Linux, it will always look like a Java application. A Qt application
always looks like a Qt application -- unless you explicitly design it to
look like a Mac application, but then it'll only look and behave the way
users expect it on a Mac.

So, what you should really do is to *not* make the GUI itself portable.
Write the logic in a portable language like C or C++, and then use a
platform-specific tool to wrap the actual GUI around that. In most
cases, this is done by designing a central library with the program's
unique functionality.

E.g. I wrote a mapping module in C++ which does

-> keep track of a list and rooms, their position (as coordinates) and
their connections (exits)
-> calculate how to lay out these rooms by changing their position
-> Determine whether a coordinate lies inside the dimensions of a
particular room
-> Determine the room that would be visually to the left, right, above
or below another

Note that this module does no drawing, no click handling. I have a
module of Mac-specific code that uses this mapping module:

-> It loops over all the rooms and draws them at their coordinates,
draws their names and connections.
-> When the Mac-specific code is notified of a mouse-click, it takes the
click coordinate and lets the mapping module tell it whether a room was
hit, and remembers it as being the selected room.
-> When the user hits one of the arrow keys, it asks the mapping module
for the room next to the selected room in that direction, and selects
that one.

The platform-specific module is stupidly simple. Just a piece of sample
code filled out with calls to the mapping module, and a little drawing
code that simply uses coordinates already computed by the mapping module.

In the days of Kylix, Delphi and Cocoa, it is almost trivial to build a
GUI around a code library. The only part about this that still is
complicated, is the part the computer can't do: Pick the right names for
the menus and menu items, do sensible logical groupings etc.

My 0.02c (which makes what I've said so far on this topic exceed the $10
barrier, I guess...)
-- Uli
http://www.zathras.de

Uli Kusterer

unread,
Feb 16, 2004, 12:44:43 AM2/16/04
to
In article <3c863a7a.04021...@posting.google.com>,
deja...@email.com (Sam Denton) wrote:

> I've described elsewhere my tool for creating rooms and fixtures from
> transcripts. The next tool that I plan to create (after I finish my
> RAP tool) will be one that takes two files containing objects and
> intellegently merges them together. For example, my 'log2inf' tool
> might generate this:
> Room Living_Room "Living Room"
> with
> description "here you are",
> n_to Kitchen,
> w_to Front_Yard;

Hey,

any plans on making a TADS version of your tool? Or to at least
abstract away the backend that actually generates the tool from the
front-end that turns the logfile into rooms, so someone else can do that
more easily?

I personally think this tool is a nice idea, even if it's probably not
the way I'd write a game, simply because it doesn't help much if you
have multiple exclusive branches in your game. But then again, I'm not
really a writer, and this seems more like a writers' approach.

What language did you say it was written in again? If it's not Perl as
I seem to remember, but rather a readable language, I might want to have
a go at TADSifying it. Heck, I could probably get my mind enough around
Perl again to make it output a little TADS source code if I had the
Inform part as an example.

> I want the output of the merge process to contain a single Living_Room
> object with both sets of properties (and similarly combining actions
> inside of 'before', 'life', etc, as needed). This way, my mapping
> tool can do what it does best, I or some hypothetical tool can do our
> things, and since there's no need to manually merge the results, I can
> rerun each process as many times as I like.

This code *definitely* sounds like it would be useful as a
general-purpose code module. For *any* IDE that generates code and needs
to incorporate changes from users. It might even avoid the "loss" that
can be caused by exporting and re-importing code repeatedly. One would
re-import solely the changed portions and merge them back into the
entire whole.

Sounds promising,
-- Uli
http://www.zathras.de

Uli Kusterer

unread,
Feb 16, 2004, 12:49:15 AM2/16/04
to
In article <402e6dc0$0$441$3c09...@news.plethora.net>,
se...@plethora.net (Seebs) wrote:

> I'm not yet sure how it would help me. I just mapped a house out for a
> new game, and it didn't take long at all. I was putting in rooms and
> connecting entrances while talking about the design of the game with my
> coauthor. In any practical sense, it took no time at all. :)

It probably depends on how elaborate your maps are. For something like
Colossal Cave, the map is very important, and such a tool would come in
very handy.

OTOH, if you just have a house with three rooms, a street and another
house with three rooms, it will probably be less critical.

But having a display of the map in the game (when it can be
auto-layouted, that is) with maybe some icons indicating various puzzles
can help. Especially if you can have the whole map open in one window,
and the description for a room in the other. Then you can e.g. refer to
another room that you realize from the map should be visible from this
one, etc.

Arjun

unread,
Feb 16, 2004, 3:11:58 AM2/16/04
to
>
> How far have I come? you tell me .. please visit http://plugh.info,
> look around, download and play around with the program.
>

Thanks for the patient reply Plugh. I'm currently checking out your
IDE and shall be happy to give you whatever feedback that I can. Just
don't expect any major soul-revealing quality feedback of the order
that you might expect from some of the more experienced veterans here.
:)

-Arjun

Uli Kusterer

unread,
Feb 16, 2004, 3:48:21 AM2/16/04
to

> > This may be a little of a problem. Before any significant number of
> > contributors joins, you need to have decided on a license.
> A very good point. Any recommendation?

Not really. Might be useful to check out:

<http://www.fsf.org/licenses/license-list.html>

and

<http://creativecommons.org/>

One of the noncommercial share-alike licenses would be something that I
would have chosen, like: <http://creativecommons.org/licenses/by-nc-sa/1.0/> though I have to admit this still wouldn't solve the problem of
incorporating other code (it only mentions a single author) or
proprietary code. E.g. I don't really want to release my Mac code
editing window class under such a license, but my class is free for use
in non-commercial or in-house apps.

Since the portable part would probably make a nice library, the LGPL
also sounds like a feasible approach. That would ensure that the actual
library stays open, while allowing it to be incorporated in applications
under different licenses. But the GPL variants all allow selling the
apps (though anyone who has them can legally copy them for free). I'm
not quite comfortable with other people making money off selling my
work. If I create a tool and others create something using that tool,
sure, they did the work (i.e. they can sell games they generate). But I
don't like it if that happened with the code I write.

> > Since you're using C++, one word of warning: You can't really share C++
> > objects between a host application and its plugins. While it is
> > possible, it has many pitfalls, and the usual solution is to make the
> > plugin API itself plain C. Most languages can interface with plain C
> > functions these days, and you stay more flexible to change objects'
> > sizes.
> We will discuss this more when the time comes. Maybe that will be your
> first area of design responsibility :-)

Yaay! Designing plugin interfaces is fun. :-) I love screwing with poor
defenseless third-party developers.

> Yes, I know. But from so many of the other posts, it seems clear that
> it is desired. Btw, you gave me some nice code once for parsing TADS 2
> files. Do you know if T3 is a superset of T2? That is, if I can handle
> T3, do I automatically have T2 support?

Not for certain, but I think methods and functions are declared more
like in C in T3 than in T2. I really haven't used T3 too much to say for
certain anymore.

> Yes, done properly, it is much more that just colo(u)ring a few
> keywords. Oh, well, so long as it can be specified, it can be
> implemented.

Just make the code a separate module, stick to the STL, and factor out
any code that concerns itself with actually accessing/modifying styles.
Then it should be portable.

> One of the things that I don't like about Plugh is that I can only
> work on one thing at a time. Sure, this helps concentrate my effort &
> makes sure things don't get left 1/2 done. But I can see how it would
> be nice to have a map (or 2) open, which working on an NPC and some
> treasures, etc

One of these days I should send you the "Model-View-Controller" blues
:-) But if I remember how SDI works correctly, you could still have
several views open for the same document.

> I hope that you will... ;-)

I guess you'll want to get the Wiki up and running, then...

> > > A plot development tool, showing a sort of time line (i.e. the order

> Just a mini-drawing package, I guess. Drag & drop some icons
> representing puzzles, etc, maybe onto a time-line. We're just at the
> wish list stage here, but will, obviously, have to fully specify
> everything before development begins.

Reminds me of that timeline-manager for novel authors I wanted to write
once... *sighs* well, first get my programming language finished, and
then we'll see... But I guess this one could be a lot simpler.

The timeline would be simply linear, with time on the X-axis, and
branches (i.e. decisions) on the Y-axis or so. Though that would be a
pretty pointless thing, IMHO. Some sort of "puzzle dependency" graph
that marks circular dependencies would probably be nice.

So, "mini-drawing package" probably means like an UML modeling
application in this case, right? Where you can drag any game object into
the view (as well as any objects specially created for this graph) and
you get a box with that name, some info etc.? That'd work. Though it'd
be a lot of platform-specific code in there, I guess, because it's 90%
clicking and mouse-tracking and text-editing. Even less actual algorithm
behind it than in the mapping module.

> > > Conversation trees?


> often asked for by others. Not 100% cure myself. But, basically, I
> think it's just a sort of decision tree as to how an NPC converses
> with you, given your replies.

Something like T3's TopicItems? Where you have kind of a menu system
that produces different "conversation modes"?

> > Should be easy. We'd probably need something like that internally
> > already to allow changes to a superclass to automatically remove
> > properties that no longer exist from subclasses. Just a simple search
> > over the "object database".
> Or an option - if property is removed form superclass, it could also
> be declared in any sub-class which actually uses it.

Whether it's optional or not isn't really relevant right now. If it's
possible to look up a class's subclasses we need to write the code once,
and we can reuse it. If the user deletes a superclass, we wouldn't want
the subclasses to still point to it, so we need to be able to do this to
ensure consistency.

But yes, I'd also have added a dialog here that asks: "You just deleted
the isStupid property from this class. Delete it from any derived
classes as well?"

> > > Borland Delphi (and C++ Builder) style property editors ?

> the idea is that the editor knows the type of each property & can
> offer the appropriate input mechanism (integer, string, memo, etc
> also, for bools & enums, can restrict input to valid values).

Oh well... they're not really pretty enough. I think it'd improve
usability if we had actual hand-crafted editors for many properties.
With e.g. a room list popup (or something like that) for "north",
"east", "south" etc.

But for user-defined properties, a list like this would probably be
useful. Hmmm... could we dynamically build a GUI? I could imagine a
simple GUI description language would go a long way to let us define
simple cross-platform GUIs for property editors (e.g. with a compass for
the directional properties) that can then be plugged into the right
places of the platform-specific GUI. After all, a list of text fields on
the Mac doesn't differ too much from one on Windows...

> > > Comprehensive documentation, tutorials and HTML help file
> >
> > Any takers? I'm not a native speaker, though although I can fake my way
> > through a conversation, I just lack the skills.
> You could fool me. The length of your mails & posts shows just how
> good your English is. No, my friend, you don't get off of the hook
> that easily :-) (besides which, your spelling is so much better than
> mine)

I'd be willing to work on some more technical parts and reference
documentation, but a tutorial would better be written by a native
speaker. I do comment my code excessively, so that would probably help
anyone who had to write the docs.

Arjun

unread,
Feb 16, 2004, 4:01:13 AM2/16/04
to
>
> How far have I come? you tell me .. please visit http://plugh.info,
> look around, download and play around with the program.
>

Thanks for the patient reply Plugh. I'm currently checking out your

Richard Northedge

unread,
Feb 16, 2004, 6:40:23 AM2/16/04
to
Uli Kusterer <wit...@t-online.de> wrote in message news:<witness-265308...@news.t-online.com>...

> In article <c31c7fe7.04021...@posting.google.com>,
> rnort...@hotmail.com (Richard Northedge) wrote:
>
> > I'm guessing the middle layer that I'm talking about would work in
> > terms of rooms, objects, etc.
>
> That is basically the design I would use for the internals of such an
> application. However, adding yet another language doesn't sound too
> useful IMHO. After all, most people pick one language (out of the
> existing ones) because they like the syntax, the structure of the
> library, the feature set or whatever. They'd completely lose most of
> that if they started writing in a special Plugh-Language.

Yeah, I was thinking of internals - I was expecting the user would use
a UI that would talk to the middle layer, then the middle layer would
translate to the actual code. I think we're agreeing here that that's
a sensible design.

The disadvantage I can see is that if super new IF language #56
creates great new functionality that wasn't anticipated in the middle
layer design, then there's no way that new language's special
functionality could be used from the middle layer without extending
the middle layer's API (and then updating the UI or UIs that interface
with it). Can't see any way round this problem though.

Talking of "languages", as well, I guess you really need to target
libraries not languages - rather than writing out Inform code, you
need to know if you are targetting the standard Inform library, or the
OnyxRing library, or the Platypus library, etc. This increases the
work of writing connectors quite a bit.

Richard

Plugh!

unread,
Feb 16, 2004, 8:37:18 AM2/16/04
to
Uli Kusterer <wit...@t-online.de> wrote in message news:<witness-A16E34...@news.t-online.com>...
[snip]

> But having a display of the map in the game (when it can be
> auto-layouted, that is) with maybe some icons indicating various puzzles
> can help. Especially if you can have the whole map open in one window,
> and the description for a room in the other. Then you can e.g. refer to
> another room that you realize from the map should be visible from this
> one, etc.

I like it - but I thought that preferred Single Document Interface?

Plugh!

unread,
Feb 16, 2004, 8:41:41 AM2/16/04
to
Uli Kusterer <wit...@t-online.de> wrote in message news:<witness-265308...@news.t-online.com>...

> Actually, programming for cross-platform deployment isn't that hard if
> you do it right. But to do that, you have to realize that the
> cross-platform GUI tools do not really create "native" GUIs for the
> platform they're ported to. Rather, they create "cross-platform GUIs".
> I.e., whether you run your Java application on a Mac, on Windows or on
> Linux, it will always look like a Java application. A Qt application
> always looks like a Qt application -- unless you explicitly design it to
> look like a Mac application, but then it'll only look and behave the way
> users expect it on a Mac.
>
> So, what you should really do is to *not* make the GUI itself portable.
> Write the logic in a portable language like C or C++, and then use a
> platform-specific tool to wrap the actual GUI around that. In most
> cases, this is done by designing a central library with the program's
> unique functionality.
I think that I want to disgree there. I want it to look the same on
all platforms. Especially because I want to use only one framework.
Otherwise, I fear too many problems where the Mac framework supports
something that can't be easilly implemented in Windows, etc.

Framework is one of the major decisions - e.g, C++ cross platform
framework, or compiled Java, etc


> In the days of Kylix, Delphi and Cocoa, it is almost trivial to build a
> GUI around a code library. The only part about this that still is
> complicated, is the part the computer can't do: Pick the right names for
> the menus and menu items, do sensible logical groupings etc.

Well, Kylix would cover windows + Linux. If we do use different
approaches for all platforms, is there something equievalent & free
for the Mac?

> My 0.02c (which makes what I've said so far on this topic exceed the $10
> barrier, I guess...)

Let's spend it on beer.

Uli Kusterer

unread,
Feb 16, 2004, 12:27:31 PM2/16/04
to

> > So, what you should really do is to *not* make the GUI itself portable.
> > Write the logic in a portable language like C or C++, and then use a
> > platform-specific tool to wrap the actual GUI around that. In most
> > cases, this is done by designing a central library with the program's
> > unique functionality.
> I think that I want to disgree there. I want it to look the same on
> all platforms. Especially because I want to use only one framework.
> Otherwise, I fear too many problems where the Mac framework supports
> something that can't be easilly implemented in Windows, etc.

That won't really be the case, as the actual core functionality will be
part of the portable code. And the advantage is exactly that if some
feature doesn't exist 1:1 on one of the platforms, you can provide
equivalent behavior as used on that platform.

> Framework is one of the major decisions - e.g, C++ cross platform
> framework, or compiled Java, etc

I *hate* Java. Had to use it several times at Uni, and even though it
has extensive libraries, it's just not a well-designed language, IMHO.
And I've yet to see a cross-platform framework that generates usable
applications. I really wouldn't want to use one. In Qt, all sizes are
wrong, wxWindows has lots of extra borders around items, GTK+ also
"feels" weird and brittle. Trust me on this: If you want to create a
useable application, you can't use a cross-platform framework. There are
just too many opposing philosophical differences between Windows and
MacOS for something like that to work.

> Well, Kylix would cover windows + Linux. If we do use different
> approaches for all platforms, is there something equievalent & free
> for the Mac?

Well, on the Mac I'd just use Cocoa. It's the most powerful and easiest
API there. Although Cocoa uses Objective C, it would be very easy to
incorporate C++ code (Apple has a special Objective C++ compiler that
lets you mix the two languages).

> > My 0.02c (which makes what I've said so far on this topic exceed the $10
> > barrier, I guess...)
> Let's spend it on beer.

*gulp*gulp*gulp* Mmmmmmmmhhhhhhhhh :-)

Here's looking at you,
-- Uli
http://www.zathras.de

Uli Kusterer

unread,
Feb 16, 2004, 12:30:36 PM2/16/04
to

> > But having a display of the map in the game (when it can be
> > auto-layouted, that is) with maybe some icons indicating various puzzles
> > can help. Especially if you can have the whole map open in one window,
> > and the description for a room in the other. Then you can e.g. refer to
> > another room that you realize from the map should be visible from this
> > one, etc.
>
> I like it - but I thought that preferred Single Document Interface?

You're the Windows specialist. I just wanted to offer flexibility. And
I do think SDI still allows several windows, doesn't it? It only allows
one *document*, but that needn't imply one window, or did MS publish
some guideline against this?

Uli Kusterer

unread,
Feb 16, 2004, 12:45:44 PM2/16/04
to
In article <c31c7fe7.04021...@posting.google.com>,
rnort...@hotmail.com (Richard Northedge) wrote:

> Yeah, I was thinking of internals - I was expecting the user would use
> a UI that would talk to the middle layer, then the middle layer would
> translate to the actual code. I think we're agreeing here that that's
> a sensible design.

Yes, that would be necessary. However, the middle layer would contain
certain code snippets simply as plain text, I guess.

> The disadvantage I can see is that if super new IF language #56
> creates great new functionality that wasn't anticipated in the middle
> layer design, then there's no way that new language's special
> functionality could be used from the middle layer without extending
> the middle layer's API (and then updating the UI or UIs that interface
> with it). Can't see any way round this problem though.

Well, the way I envision it, most of these things could be added by
adding a new plugin, and at worst a few more API calls to the plugin
interface. Of course, if some language was radically different, that
wouldn't suffice, but that's always a possibility.

> Talking of "languages", as well, I guess you really need to target
> libraries not languages - rather than writing out Inform code, you
> need to know if you are targetting the standard Inform library, or the
> OnyxRing library, or the Platypus library, etc. This increases the
> work of writing connectors quite a bit.

Good point. I guess we'd definitely want to include the library name in
the name of the plugin that is responsible for generating the code.

Or rather the plugins, because I think we'd need variants of each
plugin specifically tailored for each language, i.e. each plugin would
have a main module that handles the GUI for the particular feature
(which would be shared by all languages) and a language/library-specific
part that generates the code. There would need to be a clear interface
*inside* the plugin to make sure changes to the shared part can be
changed independently from the backend.

Thoughts, comments?
-- Uli
http://www.zathras.de

Richard Bos

unread,
Feb 17, 2004, 11:25:31 AM2/17/04
to
arjun_...@lycos.com (Arjun) wrote:

> Umm...I'm perhaps being a little dense, but er..why is Plughs
> suggestion being met with skepticism? It does sound too good to be
> true, but I'm not sure it's entirely unfeasible either (but then i'm
> not aware of the technicalities, so that's a bother). Or am I missing
> something entirely?

In my case, it's because IME the things a GUI interface does for you is
not the hard bit of writing IF. Filling in room and object details is
simple; one can always copy from a template object. Writing the text is
hard. Getting the logic of non-standard puzzles is harder. And those are
exactly the things a computer cannot do for you.
IOW, IME the difficult bit of programming is not the coding; it's the
design. Programs like Plugh fail to interest me for the same reason that
programming languages like LOGO do: they were designed to "make
programming easy for the beginner", but they forget that what they make
easier is not that which was hard to begin with.

Richard

Richard Northedge

unread,
Feb 17, 2004, 2:57:47 PM2/17/04
to
Uli Kusterer <wit...@t-online.de> wrote in message news:<witness-11CF97...@news.t-online.com>...

> In article <c31c7fe7.04021...@posting.google.com>,
> rnort...@hotmail.com (Richard Northedge) wrote:
>
> > Yeah, I was thinking of internals - I was expecting the user would use
> > a UI that would talk to the middle layer, then the middle layer would
> > translate to the actual code. I think we're agreeing here that that's
> > a sensible design.
>
> Yes, that would be necessary. However, the middle layer would contain
> certain code snippets simply as plain text, I guess.

This is where is feel the need for something to draw a diagram on. I
was thinking of an architecture like this:

user interface layer <---> common IF modeling API <---> language
connector <---> code

where there could be multiple UI layers, and there would definitely be
multiple language connectors (one for each language / library).

[snip]

> Well, the way I envision it, most of these things [extra language features] could be added by

> adding a new plugin, and at worst a few more API calls to the plugin
> interface. Of course, if some language was radically different, that
> wouldn't suffice, but that's always a possibility.

Are you suggesting here that instead of a monolithic "modeling API"
(as I've rather grandly called it above), there would actually be a
series of pluggable building blocks, each with its own set of language
connectors?

[snip]


> Or rather the plugins, because I think we'd need variants of each
> plugin specifically tailored for each language, i.e. each plugin would
> have a main module that handles the GUI for the particular feature
> (which would be shared by all languages) and a language/library-specific
> part that generates the code. There would need to be a clear interface
> *inside* the plugin to make sure changes to the shared part can be
> changed independently from the backend.

I get the impression from this that you have a different conception of
how the modules would be split up. What are the advantages /
disadvantages of each approach? I would need to think more on this,
do you have any thoughts?

Richard

Plugh!

unread,
Feb 18, 2004, 3:43:26 AM2/18/04
to
> In my case, it's because IME the things a GUI interface does for you is
> not the hard bit of writing IF. Filling in room and object details is
> simple; one can always copy from a template object.
True, but internal consistency, like changing both directions of a
passage in one fell swoop, is easier to automate - not the most
marvellous thing in the world, I agree, and hardly worthy of the
sobriquet "ultimate i-f design tool". But, as much as can be automated
should, IMO. And routine drudgery is a prime candidate, thus freeing
the author to be creative.

Besides, drudgery can be error prone precisely because it *is*
drudgery.


> Writing the text is
> hard. Getting the logic of non-standard puzzles is harder. And those are
> exactly the things a computer cannot do for you.

100% Agreed. But, housekeeping aids to the creative process can help
ensure completeness. For instance, a to-do list - "code the tea-house
puzzle; there's probably a solution using the panda", which allows the
user to click on "tea-house" and "panda" to edit them.

Or a timeline tool for puzzles – you can't solve the tea-house puzzle
until you befriend the panda – and you can't befriend him until you
find him – and you can't find the panda without the aid of the Geisha
(who for some mysterious reason has left Japan and moved to China).

Or a tool showing interaction of the various objects.

What I'm getting at is the wide accepted premise in the software
industry that the earlier in the software life cycle you catch
problems, the easier they are to fix. So, if the tool can do some
auto-checking, or warn of potential pitfalls, the author will catch
these before giving his work to beta testers.

Hmmm, does anyone know Lint? It catches common programming errors
which the compiler might miss – variable used before being assigned,
pointer referenced after being freed, etc? Can we do such a thing for
common "gotchas"?

For instance, what about those old favorites, fire and water? If an
object is potentially flammable (isPaper or isClothing property,
etc?), could the tool not flag that it has no "burn" code associated
with it? (Sure, the default ‘may' be acceptable, but why not flag a
warning? (and allow the user to select "yeah, I know", aka "don't warn
me of this again").

This sounds like a prime candidate for such a tool – if it is feasible
(and what all those glass objects without "break" handlers, etc, etc)


> IOW, IME the difficult bit of programming is not the coding; it's the
> design. Programs like Plugh fail to interest me for the same reason that
> programming languages like LOGO do: they were designed to "make
> programming easy for the beginner", but they forget that what they make
> easier is not that which was hard to begin with.

Actually, Plugh wasn't designed to make programming easier for the
beginner, although that might be a side benefit. The prime driving
force is automation – remove the drudgery, does the housekeeping and
leave the author free to be creative. Checking of common errors
wouldn't be a bad thing either.

Thanks for the input. If there is anything which you think might be
useful in such a tool, even if not to yourself, please let us know.
Thanks.

Richard Bos

unread,
Feb 18, 2004, 11:20:45 AM2/18/04
to
pl...@plugh.info (Plugh!) wrote:

> > In my case, it's because IME the things a GUI interface does for you is
> > not the hard bit of writing IF. Filling in room and object details is
> > simple; one can always copy from a template object.

> True, but internal consistency, like changing both directions of a
> passage in one fell swoop, is easier to automate - not the most
> marvellous thing in the world, I agree, and hardly worthy of the
> sobriquet "ultimate i-f design tool".

In fact, not nearly always desired - who is to say that a passage should
be straight, or even two-way, the computer or I? - and even then,
<shift-ctrl-right> <ctrl-F> <enter> is quicker, to me, than, say,
dragging a line about the screen.

> Besides, drudgery can be error prone precisely because it *is*
> drudgery.

Is it? IME, most "simple" errors are things like forgetting to make an
object static, which a computer can hardly help with since it doesn't
know, e.g., which table should be carryable and which shouldn't.

> > Writing the text is
> > hard. Getting the logic of non-standard puzzles is harder. And those are
> > exactly the things a computer cannot do for you.
> 100% Agreed. But, housekeeping aids to the creative process can help
> ensure completeness. For instance, a to-do list - "code the tea-house
> puzzle; there's probably a solution using the panda", which allows the
> user to click on "tea-house" and "panda" to edit them.

What happened to good old FIXME?

> Or a timeline tool for puzzles – you can't solve the tea-house puzzle
> until you befriend the panda – and you can't befriend him until you
> find him – and you can't find the panda without the aid of the Geisha
> (who for some mysterious reason has left Japan and moved to China).
>
> Or a tool showing interaction of the various objects.

Both of the above can easily be done on paper, and in fact IME a
decent-sized sheet of paper gives you a better overview than a computer
screen, and a better feel for the design.

> What I'm getting at is the wide accepted premise in the software
> industry that the earlier in the software life cycle you catch
> problems, the easier they are to fix.

I fail to see how an integrated environment would catch errors which the
compiler doesn't catch for me.

> Hmmm, does anyone know Lint?

I'm a C programmer, so yes. I've never had it catch a real error which
wasn't caught by my compiler as well; I have seen whole reams of Lint
output containing "errors" which weren't errors at all.

> For instance, what about those old favorites, fire and water? If an
> object is potentially flammable (isPaper or isClothing property,
> etc?), could the tool not flag that it has no "burn" code associated
> with it?

If an object is potentially flammable, shouldn't it derive from a
flammable class, which has all this code inside?

> This sounds like a prime candidate for such a tool – if it is feasible
> (and what all those glass objects without "break" handlers, etc, etc)

And how does the GUI know which objects are breakable and which aren't?
Oh, you set a flag... well, then, at the same time you do so, you add
the breaking code. Errors like this, IME, are errors where you forget to
set the flag _at all_, not where you give an object one part of the
property, but not the other.

AFAICT, Plugh might be of use to some people, but not to me. Perhaps
Plugh is for those people who also prefer a graphical IDE to a
command-line compiler and make. Me, I like to know what I'm working on,
directly. I like code. Code, to me, is a translation of my design, not
some arcane stuff that happens when I click a button.
I know there are other people out there, who disagree with that
preference. That's why I don't think Plugh should stop. If there are
other designers who like to hide their code behind a click list, fine by
me. I just don't expect to gain much from it, myself.

Richard

Daryl McCullough

unread,
Feb 18, 2004, 12:43:49 PM2/18/04
to
Plugh! says...

[Arguments in favor of an IDE]

I think you are right, that a lot of the organization and
bookkeeping involved in programming could in practice be
automated. My complaint about IDEs is that they are never
quite useful *enough*. There is almost always a point where
I abandon an IDE in favor of a text editor together with
a command line compiler. (For example, I started Java
programming in Symantec's Visual Cafe, which I liked
pretty well to start, but found it inadequate in the long
run.)

Maybe that just means I haven't seen the *right* IDE yet.

--
Daryl McCullough
Ithaca, NY

Eric Eve

unread,
Feb 18, 2004, 1:24:29 PM2/18/04
to

"Plugh!" <pl...@plugh.info> wrote in message
news:68bd0e8.04021...@posting.google.com...

> Yes, I know. But from so many of the other posts, it seems clear
that
> it is desired. Btw, you gave me some nice code once for parsing
TADS 2
> files. Do you know if T3 is a superset of T2? That is, if I can
handle
> T3, do I automatically have T2 support?

Not really; TADS 3 is not straightforwardly a superset of TADS 2, it
does quite a few things rather differently. I think you'd be better
off regarding TADS 2 and TADS 3 as quite distinct systems that
happen to have some generic similarities (at least from the point of
designing your tool).

If you're thinking of the libraries as well as the language (I
assume your tool would have to deal with both) then you're really
talking about two different systems with two different sets of
classes, property names and so forth.

-- Eric


Eric Eve

unread,
Feb 18, 2004, 1:45:56 PM2/18/04
to

"Plugh!" <pl...@plugh.info> wrote in message
news:68bd0e8.04021...@posting.google.com...
> Gotcha! I knew that that title would snare a few in :-)
>

> So . any suggestions? And anyone interested? Over the years there


have
> been many attempts at such a tool and they all failed, for one of
> several reasons:

> - no proper design before starting
> - one man effort not enough for the huge task (the size of which
only
> became apparent later because fo the lack of design)
>
> I believe that such a program, although extremely ambitious, is
> feasible - and desirable. I hope that some of you agree.

I'll offer a few random thoughts on this, if I may (having followed
the discussion in this thread with some interest).

(1) I'm sure it will be possible to produce some such tool as
you're describing, and that such a tool could be useful. ISTM though
that one design decision that needs to be taken quite early on is
whether it's basically a code-generating tool or basically a
code-editing tool with intelligent support for helping with
grunt-work. The former would present an interface more like Plugh
(which I've taken a very quick look at), where you fill in various
fields in various dialogue boxes and have the program generate code
at the click of a button; the latter would be more like a
programming editor with lots of advanced features (including
facilities for some automatic code generation). I suspect that the
latter might be more useful as something people might use throughout
a project, rather than simply to get a project started. I have in
mind a tool that presents an Imaginate-like interface by default but
can bring up a more Plugh-like interface on demand to generate code
segments which can then be edited in the Imaginate-like interface,
allowing as much switching between modes as the author wants.

(2) Ideally your tool would be most useful, I think, if it didn't
need any files of its own, but simply used the files native to the
IF language it was working with (e.g. the source files, header
files, makefiles etc. that the IF's compilers already uses). My
thinking here is that (as I think someone else in this thread has
already noted) your proposed tool will be more usable if one can
switch between using it and some other editor and back again. (This
doesn't preclude your tool using its own files for convenience
purposes - it's just that they shouldn't be essential for working on
the project).

(3) I suspect that one of the toughest parts of the design phase
may lie in isolating what parts of your tool need to be IF-language
specific and which can go in the common/generic part. For example,
you may assume that you can all IF languages provide room
connections in the eight compass points, in, out, up and down - and
then find that you hadn't left scope for the fact that TADS 3 allows
PORT, STARBOARD, FORE and AFT directions in ShipboardRooms. To make
your project practical you'll probably need to decide on a target
list of IF languages you want to support and then do some very
thorough research into what constitutes generic as opposed to
language-specific features. I'm not sure there's any way of ensuring
that your "ultimate i-f tool" will be compatible with any future IF
language that may be written - but perhaps that's just stating the
obvious.

I may come back with some more specific suggestions for useful
features later.

-- Eric


Plugh!

unread,
Feb 18, 2004, 11:45:23 PM2/18/04
to
da...@atc-nycorp.com (Daryl McCullough) wrote in message news:<c1088...@drn.newsguy.com>...
Maybe you have now - the difference betwwen this one ans Symantec's is
that Syumantec didn't consult you. If you want to make this IDE useful
for you, then please help us to specify it. Tell us what you want and
we will implement it.

Plugh!

unread,
Feb 19, 2004, 12:14:07 AM2/19/04
to
r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<4033852a....@news.individual.net>...

> In fact, not nearly always desired - who is to say that a passage should
> be straight, or even two-way, the computer or I?

Well, I personally am a "maze of twisty little passages, all
different" kind of guy. But modern i-f seems to be more conventional.
Many folks ask for this sort thing. As I implemented it in Plugh, the
return passage *defaults* to the opposite direction, so just hit
return to accept but, of course, it's easy to change (from a drop down
combo box). We can also make it a configuration option - check the box
once to always have a conventional layout.

> - and even then,
> <shift-ctrl-right> <ctrl-F> <enter> is quicker, to me, than, say,
> dragging a line about the screen.

Yes, but the GUI can offer a selection of only valid paths. No biggy
with a text editor if you group all your direction stuff together and
it's all of the form n=someRoom. but in a very big room definition,
when each new entry just goes at the end, or at the start, after the
room name, or if you have n=<some very long & complex code> then it is
is possible to oversee the fact that you have 2 exits to the north.

Look, I agree that that is not major, but enough small things together
can add up to ... well, a big thing.


> > Besides, drudgery can be error prone precisely because it *is*
> > drudgery.
>
> Is it?

Yes it is (imo), which in no way negates your next statement of stuff
which is also error prone.


> IME, most "simple" errors are things like forgetting to make an
> object static, which a computer can hardly help with since it doesn't
> know, e.g., which table should be carryable and which shouldn't.

Very true - can you think of any way in which we can automate some
checks to prevent that sort of thing? (I can't, just at the moment)


> > > Writing the text is
> > > hard. Getting the logic of non-standard puzzles is harder. And those are
> > > exactly the things a computer cannot do for you.
> > 100% Agreed. But, housekeeping aids to the creative process can help
> > ensure completeness. For instance, a to-do list - "code the tea-house
> > puzzle; there's probably a solution using the panda", which allows the
> > user to click on "tea-house" and "panda" to edit them.
>
> What happened to good old FIXME?

whatever happened to good old cp/m? To be honest, I use fixme in my
own code, even in IDEs which offer such to-do lists, but that's just
me (and you). Some folks might like a to-do list (which can be
prioritised, given due dates, auto-checked for overdue, etc). And,
besides, with my abysmal typing, I inevitably miss a few FIMXEs :-)


> Both of the above can easily be done on paper, and in fact IME a
> decent-sized sheet of paper gives you a better overview than a computer
> screen, and a better feel for the design.

On topic at the start of Plugh was that it was going to replace
innumerable scraps of paper. At least it should be easier to lay out
a map with such a tool, and not to keep resorting to an eraser.


> > What I'm getting at is the wide accepted premise in the software
> > industry that the earlier in the software life cycle you catch
> > problems, the easier they are to fix.
>
> I fail to see how an integrated environment would catch errors which the
> compiler doesn't catch for me.

Then I am not doing my job properly, because that's what I'm trying to
explain. Besides which, there's a lot more to it than compiling (I
once worked wit a guy in Holland whose sig reflected what he thought
of as the company motto - "It compiles - ship it").

> > Hmmm, does anyone know Lint?
>
> I'm a C programmer, so yes. I've never had it catch a real error which
> wasn't caught by my compiler as well; I have seen whole reams of Lint
> output containing "errors" which weren't errors at all.

20 years ago, hell, even 10, it was indispensable. Agreed, compilers
have become better, but I only mentioned it in order to establish a
frame of reference.

> > For instance, what about those old favorites, fire and water? If an
> > object is potentially flammable (isPaper or isClothing property,
> > etc?), could the tool not flag that it has no "burn" code associated
> > with it?
>
> If an object is potentially flammable, shouldn't it derive from a
> flammable class, which has all this code inside?

It has default behaviour inside, sure, and sometimes that's the
problem. Over the year there have been some very interesting, learned
discussion in what happens when you admit so much as a single match or
glass of water into i-f. Surprisingly many things become possible and
surprisingly many objects shouldn't take the default action. I just
wondered aloud if we could somehow indicate & control this - but I
don't have a concrete suggestion yet.



> > This sounds like a prime candidate for such a tool ? if it is feasible


> > (and what all those glass objects without "break" handlers, etc, etc)
>
> And how does the GUI know which objects are breakable and which aren't?
> Oh, you set a flag... well, then, at the same time you do so, you add
> the breaking code. Errors like this, IME, are errors where you forget to
> set the flag _at all_, not where you give an object one part of the
> property, but not the other.

ok, maybe that was a lousy idea - but we're at the ideas stage now &
they can't all be winners, but that doesn't automatically make the
whole premise worthless.

> AFAICT, Plugh might be of use to some people, but not to me. Perhaps
> Plugh is for those people who also prefer a graphical IDE to a
> command-line compiler and make. Me, I like to know what I'm working on,
> directly. I like code. Code, to me, is a translation of my design, not
> some arcane stuff that happens when I click a button.

Plugh attempts to show your design somewhat graphically.


> I know there are other people out there, who disagree with that
> preference. That's why I don't think Plugh should stop. If there are
> other designers who like to hide their code behind a click list, fine by
> me. I just don't expect to gain much from it, myself.

Thanks for your feedback, Richard. I'm fairly old school myself. I
started with C on a PDP 8, teletype only, also did punched card &
paper tape stuff. I was coding for 3 years before I ever saw a
monitor, or even suspected that such a thing could exist. Somewhere
along the way, I seem to have embraced new technology, although not
just technology for technology's sake - it has to offer me something -
quite a big premium, in fact, to woo me away from the tried & trusted.

In this case, I hope that enough savings & improvements, mall though
they may be, can combine to make a compelling case. besides, I need a
hobby & this seems as good as any.

Btw, although you wouldn't use it, you can still make suggestions for
the benefit of others.

Thanks again.

Plugh!

unread,
Feb 19, 2004, 2:00:12 AM2/19/04
to
"Eric Eve" <eric...@NOSPAMhmc.ox.ac.uk> wrote in message news:<c10bt7$qni$1...@news.ox.ac.uk>...

> I'll offer a few random thoughts on this, if I may (having followed
> the discussion in this thread with some interest).
>
> (1) I'm sure it will be possible to produce some such tool as
> you're describing, and that such a tool could be useful. ISTM though
> that one design decision that needs to be taken quite early on is
> whether it's basically a code-generating tool or basically a
> code-editing tool with intelligent support for helping with
> grunt-work.
Absolutely spot on - this is crucial.

> The former would present an interface more like Plugh
> (which I've taken a very quick look at), where you fill in various
> fields in various dialogue boxes and have the program generate code
> at the click of a button; the latter would be more like a
> programming editor with lots of advanced features (including
> facilities for some automatic code generation).

I have gone for the former, although we could always consider the
later when designing, with code re-use in mind.

> I suspect that the
> latter might be more useful as something people might use throughout
> a project, rather than simply to get a project started.

You are no the only one to have voiced this, but I want the Plugh-like
tool to be used throughout. Even as it stands, there is no point where
you *need* to abandon in for a text editor - now we only have to make
it so that there is no point where you *want* to abandon it for a text
editor.


> I have in
> mind a tool that presents an Imaginate-like interface by default but
> can bring up a more Plugh-like interface on demand to generate code
> segments which can then be edited in the Imaginate-like interface,
> allowing as much switching between modes as the author wants.

We have had a discussion on this - in fact it is still ongoing. I
can't say which way we will lean, but your stated preference will
influence it.

Purely personally, I feel too many people are thinking file-centric
thoughts and I don't think the tool should look at adv.t, rooms.t,
ncp.t, castle.t, toen.t, treasures.t, etc but at logical groupings
like mps, rooms, items, npcs, class tree, vocabulary, etc


> (2) Ideally your tool would be most useful, I think, if it didn't
> need any files of its own, but simply used the files native to the
> IF language it was working with (e.g. the source files, header
> files, makefiles etc. that the IF's compilers already uses). My
> thinking here is that (as I think someone else in this thread has
> already noted) your proposed tool will be more usable if one can
> switch between using it and some other editor and back again. (This
> doesn't preclude your tool using its own files for convenience
> purposes - it's just that they shouldn't be essential for working on
> the project).

We are strongly tending that way too. Of course, that allows the user
to screw things up badly, but that is his prerogative. We will
probably go for tagged comments in the source code for any toll
specific stuff.



> (3) I suspect that one of the toughest parts of the design phase
> may lie in isolating what parts of your tool need to be IF-language
> specific and which can go in the common/generic part.

I have posted to raif regarding that, but have received no replies. So
far we are all TADS folks; we desperately need an Inform-guy.

> For example,
> you may assume that you can all IF languages provide room
> connections in the eight compass points, in, out, up and down - and
> then find that you hadn't left scope for the fact that TADS 3 allows
> PORT, STARBOARD, FORE and AFT directions in ShipboardRooms.

Good point, but there will always be special cases, like SSW, NNE,
magic words, etc

> To make
> your project practical you'll probably need to decide on a target
> list of IF languages you want to support and then do some very
> thorough research into what constitutes generic as opposed to
> language-specific features. I'm not sure there's any way of ensuring
> that your "ultimate i-f tool" will be compatible with any future IF
> language that may be written - but perhaps that's just stating the
> obvious.

A good point, nevertheless (ototh, will there ever be a serious
contender to the big 2? I think we are just talking future evolution
of those – but that's enough – look at the differences between TADS 2
& 3.


>
> I may come back with some more specific suggestions for useful
> features later.

I really hope that you will. We are putting a web site together now
and you can join us there, if you wish. You will be warmly welcomed.

Eric Eve

unread,
Feb 19, 2004, 2:05:59 PM2/19/04