The ultimate i-f design tool
Plugh!
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
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
> 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
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
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
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
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
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
>
> 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
news:uf4Xb.2489$WW3...@newsread2.news.pas.earthlink.net...
Perhaps http://www.iflibrary.com/default.aspx?pageid=Home&contentid=15 ?
Uli Kusterer
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
> "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.
>
> Perhaps
> http://www.iflibrary.com/default.aspx?pageid=Home&contentid=15 ?
>
> Cheers, Roger
That's it exactly! Thanks, Roger.
Jess K
Plugh!
> > Gotcha! I knew that that title would snare a few in :-)
>
> Should I read the rest of this post? Second opinions, please.
>
Plugh!
> 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?
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!
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!
>
> 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!
> 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
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
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
> 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!
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
> 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
> 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
> 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
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
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
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
> 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
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
> 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
> 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).
>
> 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!
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.)
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!
> 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?
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
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
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
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
> 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
> > 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
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
> 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
> 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!
[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!
> 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.
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
> > 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
> > 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
> 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
> 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
> 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!
> not the hard bit of writing IF. Filling in room and object details is
> simple; one can always copy from a template object.
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
> > 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
[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
"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
>
> 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!
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!
> 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!
> 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 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
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).
> >
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.
To achieve that you'll have to make it *behave* like a text-editor
if that's what the user wants. There are places where the easiest
way to get the code you want is to write/edit it yourself, and it's
important that your tool isn't perceived as getting in the way of
that. However well-designed a tool is, there will always be times
when a user wants to do something in a way the tool-author didn't
quite anticipate, at which point the tool can feel like it's getting
in the way by being too obstinate/helpful (like that blasted
paperclip that pops up every time I write "Dear Mr Smith" in
MS-Word, or my experience of finding that it can quickly become
easier to edit raw HTML than wrestle with a well-meaning WYSISYG
html editor). I suppose what I'm getting at is that if you want
people never to leave your tool, it'll need a text-editing mode.
>
> 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
Yes, I can see the sense of that. Of course it would also be no bad
thing if your tool also helped organize source files in a logical
fashion.
>
> > (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.
That sounds good. As you say, its my prerogative if I choose to
screw up badly, but I'd rather take that responsibility than not be
allowed to do what I want to do with my own source code, and I
expect most users would feel the same. A tagged comments approach
sounds a good way to go.
> > 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
Sure, I was simply trying to make the point with a simple (but
perhaps less than ideally apposite) example about being careful in
assumptions about what's generic to all I-F languages.
> > To make
> > your project practical you'll probably need to decide on a
target
> > list of IF languages you want to support ...
> 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.
If we're just aiming at TADS 2, TADS 3 and Inform then that makes a
decently-defined group. I doubt TADS 4 will be coming along in a
hurry (quite apart from anything else, after all the work he's been
putting into it I can't imagine Mike Roberts wanting to make TADS 3
obsolete as soon as he's written it!). However, given the
differences between TADS 3 and TADS 2 I doubt we'd be able to
anticipate what a TADS 4 might look like at this stage anyway. All
you can do is work with known quantities.
>
> >
> > 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.
Thanks - no doubt you'll be publishing details of your website once
it's up and running, so I'm sure I'll have no difficulty finding it.
I'll put a couple of thoughts into a separate post, since this one
is probably long enough.
-- Eric
Eric Eve
> > 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.
Well, one thought that occurred to me after my *very* rapid play
with Plugh! (it would be longer but from the fact that I'm rather
heavily into some TADS 3 documentation projects at the moment, and
don't really need a tool that generates TADS 2 code) concerned
another function it would be nice to have when laying out maps. At
the moment Plugh appears to allow you to connect to *existing*
rooms, but it would be useful if the new tool yet you connect to a
room you hadn't yet defined (rather than having to return to your
definition of Room A to add the link to Room B after you'd defined
Room B). I appreciate that if you then go and define Room B it will
add a reciprocal link from A to B if you define one from B to A, but
I suppose the way my mind works I'd like to be able to connect from
A to B straight away, if that's what I know I want to do.
To try to make sense of this, I'll give an example (using TADS 3
syntax). Suppose in the course of developing my map I've arrived at
a Bedroom, with an exit to (an already defined) passage to the east,
and a (yet to be defined) bathroom to the north. At its most
skeletal:
bedroom : Room 'Master Bedroom'
"The master bedroom has a door leading out to a passage to the
east and another into an en-suite bathroom to the north. "
east = mainPassage
...
;
Now, I know I want a bathroom to the north, so I use your new tool
to create a link to the north and click a button that says new room,
perhaps at that point simply entering the new name and class,
whereupon your tool generates a skeleton definition:
/* ##incomplete## */
bathroom : Room 'Name'
"Desc"
south = bedroom
;
This code will compile fine, but the /* ##incomplete## */ tag (or
whatever you call it) can be used by your tool to remind me that
I've got a room definition I need to finish off at some stage. In
this example this may not seem much easier than defining the bedroom
and then going on to the bathroom, but if I were defining, say, a
hall with exits to North, South, East, Southeast, West, Up and Down
(when none of these other locations had yet been created) being able
to do something like this might be a real boon.
In TADS 3 one quite often doesn't connect one room directly to
another, but quite often uses TravelConnector objects (often in
their anonymous nested form), and we'll have to devise a way for
your tool to deal with them. Leaving most of the details of that
aside, I'll give one more example of a particular kind of
TravelConnector that's likely to have an analogue in other I-F
languages, the door. My bedroom mentioned a door into the bathroom,
and if I wanted to implement that properly I'd need to code:
bedroom : Room 'Master Bedroom'
"The master bedroom..."
north = bedroomDoorNorth
;
+ bedroomDoorNorth : Door 'bathroom door' 'bathroom door';
bathroom : Room 'Bathroom'
"This plush bathroom... "
south = bathroomDoorSouth
;
+ bathroomDoorSouth ->bedroomDoorNorth : Door 'door' 'door' ;
Although the TADS 3 template syntax minimizes the grunt work here
as much as it can, this is the sort of case where your proposed tool
could reduce it quite a bit more, e.g. by allowing the user simply
to say he wants a door between the two rooms and doing the rest
automatically (including assigning names to the door objects).
Well, maybe this kind of thing is so standard that you've already
worked out how Son-of-Plugh will eat it for breakfast; so let me
introduce a complication. Suppose that in another room, say a large
hall, I have three doors to the north and four to the west. At
present TADS 3 offers no standard solution to this, but I've devised
my own custom ChoiceConnector class to deal with it. The syntax is
something like (I'm simplifying things a bit):
hall : Room 'Imposing Grand Hall'
"The north wall of this imposing, oak-panelled hall boasts three
doors, while no less than
four doors grace the western wall ..."
north : ChoiceConnector { "There are three doors to the north" }
west : ChoiceConnector { "There are four doors to the west" }
;
+ hallNorthDoor1 'left hand left-hand door' 'left-hand door';
etc.
The idea is that when the player types NORTH the game responds with
"There are three doors to the north, which do you want to use? ", to
which the player can just type LEFT DOOR and be taken through it.
My point here is that this is (at least currently) a non-standard
mechanism within TADS 3, but the sort of mechanism the language
rather encourages authors to devise. Would it completely defeat your
map-laying-out tool? Would this be a case where the author would be
forced to abandon your tool (which can hardly anticipate what
cunning new mechanisms an author might devise) and go into text
editor mode?
I'm *not* trying to be negative here, I'm just trying to draw your
attention to the sort of issues you're going to have to face (at
least in TADS 3).
-- Eric
Uli Kusterer
"Eric Eve" <eric...@NOSPAMhmc.ox.ac.uk> wrote:
> "Plugh!" <pl...@plugh.info> wrote in message
> news:68bd0e8.04021...@posting.google.com...
>
> In TADS 3 one quite often doesn't connect one room directly to
> another, but quite often uses TravelConnector objects (often in
> their anonymous nested form), and we'll have to devise a way for
> your tool to deal with them.
The easy way to chicken out here would probably be to just treat
TravelConnectors as another room. I.e. If there is a travelConnector
leading from room A to room B to its north, the travelConnector would be
considered to be the immediate room north of room A, with an exit
leading north again to the room it leads to.
> bedroom : Room 'Master Bedroom'
> "The master bedroom..."
> north = bedroomDoorNorth
> ;
>
> + bedroomDoorNorth : Door 'bathroom door' 'bathroom door';
>
> bathroom : Room 'Bathroom'
> "This plush bathroom... "
> south = bathroomDoorSouth
> ;
>
> + bathroomDoorSouth ->bedroomDoorNorth : Door 'door' 'door' ;
Ah: TravelConnectors are inside their room? Well, then it would probably
be easier to just make them a special case and "attach" any travel
connectors found to their corresponding exit. I.e. they'd just be an
icon printed on the line, or something like that.
> My point here is that this is (at least currently) a non-standard
> mechanism within TADS 3, but the sort of mechanism the language
> rather encourages authors to devise. Would it completely defeat your
> map-laying-out tool? Would this be a case where the author would be
> forced to abandon your tool (which can hardly anticipate what
> cunning new mechanisms an author might devise) and go into text
> editor mode?
Well, the nice part about how I imagine the mapping tool is that it
really remembers the physical position of various items on the map. When
you first open the game, it tries to lay all rooms out according to how
their exits connect them. After that, you can drag them around on the
map, just like in a drawing program like FreeHand.
In this case, "north" would point to a string, so the mapper would
simply not see the connection, and you would have to manually position
the rooms. However, you can always select a few rooms and tell it to
only position those relative to each other. So, you can have the
auto-mapping, and where it fails you would be able to manually move them
around as you wish.
> I'm *not* trying to be negative here, I'm just trying to draw your
> attention to the sort of issues you're going to have to face (at
> least in TADS 3).
Thank you for the information, it will definitely figure into our
design. IMHO we probably won't be able to handle such complex cases
(mapping is an NP-complete problem, after all, even with only four or
eight exits) in the auto-mapping cases, but if I get my way, we'll
implement mapping in a fashion so it doesn't get in the way. I.e. if you
need to, you can just manually lay out the rooms on the map. Or you can
choose to auto-layout part, and manually position others etc.
Obviously, this would be a practical application of the 80/20 rule. As
long as 80% of the people can do 80% of the game with it easily and
quickly, they won't be annoyed if they have to do the remaining 20% the
old fashioned way.
Uli Kusterer
"Eric Eve" <eric...@NOSPAMhmc.ox.ac.uk> wrote:
> However well-designed a tool is, there will always be times
> when a user wants to do something in a way the tool-author didn't
> quite anticipate, at which point the tool can feel like it's getting
> in the way by being too obstinate/helpful (like that blasted
> paperclip that pops up every time I write "Dear Mr Smith" in
> MS-Word,
1. Agree. Which is why I plan to look at every feature under the aspect:
What if you don't want it? I'll make sure you can easily turn off any
helpful features that may get in the way.
2. *psychopathic look* DO YOU WANT TO CREATE A TABLE????
> I suppose what I'm getting at is that if you want
> people never to leave your tool, it'll need a text-editing mode.
True. I think I've convinced Plugh to make all the text that is output
editable and customizable on a per-object basis. That's not quite as
good as a text editor, but at worst should let the user override most
stupid things the editor might do. Of course, there may still be
occasions where they'll need a text editor, but if we keep them few and
far between, and allow re-importing stuff after that, it may be close
enough not to matter.
> Yes, I can see the sense of that. Of course it would also be no bad
> thing if your tool also helped organize source files in a logical
> fashion.
:-) I'm not mad! YESSSS!!!! :-)
> Sure, I was simply trying to make the point with a simple (but
> perhaps less than ideally apposite) example about being careful in
> assumptions about what's generic to all I-F languages.
Well, we'll need to make assumptions about the number of exits and what
directions are available when writing the map layouting code, but as
long as the user can decide what exit is displayed where (with sensible
defaults being "north", "east", "south" and "west", obviously), we
should be pretty safe.
> If we're just aiming at TADS 2, TADS 3 and Inform then that makes a
> decently-defined group.
Any volunteers who'd like to help us with Inform? I've used a lot of T2
and I made an attempt at a T3 game, but I only have vague knowledge of
Inform from back when evaluating the different languages. I'm really not
qualified to make sensible assumptions about Inform, and I'd hate if we
made design decisions that precluded making this work for Inform as well.
Uli Kusterer
> 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
That would be sort of close in the grander scheme of things.
> where there could be multiple UI layers, and there would definitely be
> multiple language connectors (one for each language / library).
If the "Model-View-Controller" paradigm is a term that you're familiar
with, that's how I envision the connection between the GUI and the rest.
This would both provide a very clean division between the
platform-specific and platform-independent code, as well as easily allow
having multiple windows displaying the same game in radically different
ways (i.e. map view, list view, object inspectors, tree views...).
> 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?
That's the part about which I'm not quite sure. I think it would be
very convenient to have pluggable building blocks, but OTOH, I'd prefer
to avoid having to have more than one language connector.
The way I see it right now is that one would have a generic "data
model" that is basically language-agnostic (it just deals in objects and
their properties), and this data model would be displayed and edited by
the various pluggable building blocks. Then there'd be special building
blocks that take this model and generate the code from it in a
particular language.
Where this falls down is if part of the operation of a plugin requires
generating some code and not just modifying properties. In that case,
we'd probably need language connectors for those individual modules as
well. I'm not happy about this, but I'm afraid there's no way around
this.
But at least we'd be able to generate a number of language-agnostic
plugins and only the more advanced ones would have their own connectors.
> > 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?
Basically, what I called "variants" of a plugin would be individual
"plugin <--> language connector" pairs. I'm just not sure whether
they'll really be plugins, or whether parts of these shouldn't rather be
modules. A module in this case would appear to be part of the plugin
(or if a plugin is a module, it would be part of the application) as far
as the user is concerned, while a plugin could be "ripped out" by the
user simply by moving the plugin's file out of the application's
"plugins" folder, or whatever.
HTH,
-- Uli
http://www.zathras.de
Uli Kusterer
> 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).
This is a part where - should I find an algorithm that works, that is -
one can help avoid gameplay bugs. E.g. what if you could mark one object
as requiring several others? Then the game could automatically detect if
there's a circular dependency that makes the game unwinnable. Moreover,
one could probably "eliminate" objects from the game (or mark two
objects as mutually exclusive) and then the computer could tell you
whether any of the requirements would no longer be satisfiable.
In the ideal case, you'd establish the dependencies with a casual click
while coding the game, then you'd have a special-object for each ending
for the game, and what it requires, and then the computer would tell you
whether the game is winnable, or an ending is unreachable or whatever.
Of course, the ideal case isn't really easy to achieve, (in some very
complex games even impossible), but if we can avoid even a few stupid
bugs in the game, wouldn't that already be a reason to use Plugh's
successor instead of a text editor?
> 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"?
I've added a section for tracking gotchas to the discussion section of
the Wiki, so it's available once it's reachable for everyone. I've added
the one I mentioned above and your "Fire and Water" example.
Thanks for all the input, and as Johnny Five would say:
More INPUT! :-)
Uli Kusterer
r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> 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.
The question is, what do you do more often? Mirrored passages, or
passages that only go in one direction, or come out elsewhere than they
go in? If you do a maze-style game, you'd obviously want to turn that
off, but otherwise it might be less work to remove the mirrored passage
in those three cases than to add it manually in the other 25.
As long as the underlying editor model is flexible enough to model what
the code can to a sufficient degree, and as long as it doesn't get in
the way and you can turn off any "helpful" features while they're not
needed, the editor would actually gain you something.
> 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.
Of course, it could look at the sdesc and flag objects that contain the
word "table" and aren't static, or that only inherit from lockable and
not from item, or whatever.
> > 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?
FIXME is nice if it is handled like Eclipse does it: On startup, it
creates a list of all comments starting with "TODO" and shows them in a
to-do list window. That way, you have everything that needs to be done
in one nice, centralized list, and a double click on an entry takes you
there.
> > 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.
You definitely have a point, but this probably depends as much on the
size of your screen as it depends on your work style, and how organized
you are. Very organized people might not encounter many of the problems
we're trying to solve.
The advantage of the computer is that you don't have to redo the whole
map manually (or tape another piece of paper to the sheet, or whatever)
when you realize you miscalculated the positions and run out of paper.
And zooming and other niceties will also alleviate the problem somewhat.
And the computer also has prettier handwriting, can generate the map
from the code of the partially finished game (or the other way round,
can generate the code from the map), lets you effortlessly move entire
sections of the map around when you realize that house A and house B
should be on opposite sides of the street or when you want to try out
different configurations etc.
> > 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.
The compiler probably *could* detect certain errors (or at least flag
them up as warnings), but right now most compilers don't. At least
IF-language compilers. Also, you can give the IDE meta-information that
the compiler discards. I hope the examples I made in this and other
postings help somewhat in explaining this.
> If an object is potentially flammable, shouldn't it derive from a
> flammable class, which has all this code inside?
Yes. But if it did, it wouldn't be an error ;-)
Maybe the author forgot to make it also inherit from the "flammable"
class? Imagine an object may *become* flammable. So the author
initializes isFlammable to false and forgets to make it inherit from the
flammable class. The IDE could check object properties, find out that
the base class already has isFlammable set to false and issue a warning.
The author could then say: "no, that's ok" to get rid of this particular
warning, or cold realize this shouldn't be the case and notice the
missing mixin or wrong base class.
> 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.
There are some cases where it may not be as clear as in the case of
breakable objects. E.g. what about TADS 2's verSomething() handlers. If
verSomething() is there, but doSomething() isn't implemented (maybe
because you went off for dinner in the middle of the work and forgot),
it could notice that there's a verSomething() method but no
doSomething() and warn you. Or the other way round: If the default
verSomething() prohibits an action, the IDE could detect doSomething()
methods and tell you that you need a verSomething() method that lets it
through. Heck, it could even offer to write one for you.
> 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.
Fine with me. We're not trying to force anyone to use this. It's an
offer. And I'm definitely happy that you're taking the time to even
consider this and read my long rants (and Plugh's shorter ones). All
issues you have raised so far are definitely worth thinking about, and
some even gave me ideas for new features. Even if you don't use it, your
input may someday save the users of this IDE a lot of work.
> 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.
Mind you, we're not writing ClickScript here. You will still be able to
write code. However, just like with RAD tools, which save you from the
chores of having to manually encode the coordinates of each button and
write the code to create it and add it to a window, we hope to someday
to give IF authors the opportunity to focus more on the logic specific
to their game and spend less time on the stuff that is the same in every
game.
Thanks for all the food for thoughts,
-- Uli
http://www.zathras.de
Plugh!
hi, Eric,
thanks very much for taking the time to reply.
Feel free to address both Plugh and its possible successor. If
necessary, I will reply individually.
> Well, one thought that occurred to me after my *very* rapid play
> with Plugh! concerned
> another function it would be nice to have when laying out maps. At
> the moment Plugh appears to allow you to connect to *existing*
> rooms, but it would be useful if the new tool yet you connect to a
> room you hadn't yet defined
Yes, I have that in mind & any new one would probably do that too.
I envisage the "new passage" dialog having an extra entry in the
"destination room" field, which would allow the user to create the
passage and the room
simultaneously.
[snip]
> This code will compile fine, but the /* ##incomplete## */ tag (or
> whatever you call it) can be used by your tool to remind me that
> I've got a room definition I need to finish off at some stage.
Wow, that's a neato idea. It will be added.
> In TADS 3 one quite often doesn't connect one room directly to
> another, but quite often uses TravelConnector objects (often in
> their anonymous nested form), and we'll have to devise a way for
> your tool to deal with them. Leaving most of the details of that
> aside, I'll give one more example of a particular kind of
> TravelConnector that's likely to have an analogue in other I-F
> languages, the door.
I have been meaning to add a doorway wizard to Plugh. There should be
one in the new project - but maybe, from what you say, more generic
than just doors.
> Although the TADS 3 template syntax minimizes the grunt work here
> as much as it can, this is the sort of case where your proposed tool
> could reduce it quite a bit more
It is exactly such cases which we seek - please keep them coning.
> Well, maybe this kind of thing is so standard that you've already
> worked out how Son-of-Plugh will eat it for breakfast;
It is rather straightforward.
> so let me
> introduce a complication. Suppose that in another room, say a large
> hall, I have three doors to the north and four to the west. At
> present TADS 3 offers no standard solution to this,
a perennial FAQ, the many-doored corridor.
> but I've devised
> my own custom ChoiceConnector class to deal with it. The syntax is
> something like (I'm simplifying things a bit):
>
> hall : Room 'Imposing Grand Hall'
> "The north wall of this imposing, oak-panelled hall boasts three
> doors, while no less than
> four doors grace the western wall ..."
> north : ChoiceConnector { "There are three doors to the north" }
> west : ChoiceConnector { "There are four doors to the west" }
> ;
>
> + hallNorthDoor1 'left hand left-hand door' 'left-hand door';
>
> etc.
>
> The idea is that when the player types NORTH the game responds with
> "There are three doors to the north, which do you want to use? ", to
> which the player can just type LEFT DOOR and be taken through it.
>
> My point here is that this is (at least currently) a non-standard
> mechanism within TADS 3, but the sort of mechanism the language
> rather encourages authors to devise. Would it completely defeat your
> map-laying-out tool?
As it stands, yes. Anything where the destination is not just a room
name will (e.g code or a function call). But, read on...
> Would this be a case where the author would be
> forced to abandon your tool (which can hardly anticipate what
> cunning new mechanisms an author might devise) and go into text
> editor mode?
No, it is possibly in Plugh today to add the code to the user code
section of a room, without resorting to a text editor. The problem is
that it doesn't show on the map (and nor do magic words, passages
created at run time, etc)
What we _could_ do, would be to add a new map symbol. Currently all
rooms are rectangles. If I draw a circle between two rooms, that could
mean that there is some code there; clicking it could allow the user
to edit that code. They only potential nastiness is that the user
somehow has to tell the tool where the potential destinations of the
code are, and that may get out of synch.
We do need to address this, though. But, hopefully, it is solvable.
> I'm *not* trying to be negative here, I'm just trying to draw your
> attention to the sort of issues you're going to have to face (at
> least in TADS 3).
I don't see it as negative. "There's no such thing as bad ….
feedback". We will shortly have a web site up for the proposed new
project (we *did* already have the site up, but when the registrar,
GoDaddy, saw that my address was in China, they cried "fraud" and
pulled the site. I will give them a few days to clear the matter up,
or will register it elsewhere), we will have discussion areas for
topics just like this and, although I appreciate that you are
otherwise very busy, some insight from a TADS3 guru would be
invaluable.
Please watch for announcement of the web site. And, thanks again.
Plugh!
Eric Eve
represent physical game objects like doors or staircases, but not if
they are abstract programming objects. For example, if you want to
display a message when travelling from the roomA to roomB you'd use
a TravelMessage connector, which you *could* use like this:
roomA : Room 'Room A'
"Room A is remarkable for its lack of features..."
north = aToBConnector
;
aToBConnector : TravelMessage
destination = roomB
travelDesc = "You march steadfastly into Room B"
;
room B : Room 'Room B'
..
;
But what you'd *actually* write, taking advantage of template and
anoynmous nested object syntax is:
roomA : Room 'Room A'
"Room A is remarkable for its lack of features..."
north : TravelMessage { ->roomB "You march steadfastly into Room
B" }
;
roomB : Room ...
-- Eric
Richard Bos
> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<4033852a....@news.individual.net>...
>
> > - 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.
This is my program. All paths are valid if I say they are.
> No biggy with a text editor if you group all your direction stuff
> together and it's all of the form n=someRoom.
How else would you do it?
> 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.
Good grief. If you do that, you need to learn to program.
No, not just to code. To program. A consistent design and layout are
part of being able to program. How the blazes are you going to find
_anything_ if you just tack on source lines wherever they land?
> > > 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.
I've never found it to be so except in the most trivial, compiler-
detectable ways. But perhaps you have some examples?
> > 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)
No. The computer _cannot_ know that this table should be carryable and
that table should not, unless you tell it so. And if you do, well, you
tell it so by _making_ it uncarryable.
> > > 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?
What has that got to do with the price of cake? Searchable notes in your
code help you write solid code and remember where you left holes, CP/M
does not (except that it probably was more stable than Windows...).
> > 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.
Well, as I said, there may be people for whom a Plugh-like tool is just
the thing, but not for me. I _like_ my paper notes.
> > > 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.
I was a C programmer ten years ago, too. Believe me, Lint was far from
indispensable.
> > > 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.
Sure. But those are design and algorithm problems, very hard to make
easier using just a GUI.
> > 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.
Myeah. Which is usually something I do not need or want.
Still, de gustibus...
Richard
Richard Bos
> In article <4033852a....@news.individual.net>,
> r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>
> > 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.
>
> The question is, what do you do more often? Mirrored passages, or
> passages that only go in one direction, or come out elsewhere than they
> go in? If you do a maze-style game, you'd obviously want to turn that
> off, but otherwise it might be less work to remove the mirrored passage
> in those three cases than to add it manually in the other 25.
Only if you find drag-and-drop easier than find-and-type, which I don't.
> > 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.
>
> Of course, it could look at the sdesc and flag objects that contain the
> word "table" and aren't static,
Exactly. So... you forgot to make an object static which should've been.
And the compiler, to solve this, looks for items which aren't static,
but should've been. But how does it know which items should be static?
> or that only inherit from lockable and not from item,
That makes no sense in an Inform context, which is the only IF
programming language I know.
Anyway, if being lockable requires being an item, why does the lockable
_class_ not derive from item?
> > > 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?
>
> FIXME is nice if it is handled like Eclipse does it: On startup, it
> creates a list of all comments starting with "TODO" and shows them in a
> to-do list window.
Blech - pop-up windows. FIXME works fine without gizmos in any decent
programmer's editor.
> > > 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.
>
> You definitely have a point, but this probably depends as much on the
> size of your screen as it depends on your work style, and how organized
> you are. Very organized people might not encounter many of the problems
> we're trying to solve.
Not only that, but some people - me, for one - actually find it easier
to design on paper than to design on a screen.
> > > 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.
>
> The compiler probably *could* detect certain errors (or at least flag
> them up as warnings), but right now most compilers don't.
Eh? Inform detects detectable errors just fine.
> > If an object is potentially flammable, shouldn't it derive from a
> > flammable class, which has all this code inside?
>
> Yes. But if it did, it wouldn't be an error ;-)
_Exactly_.
> Maybe the author forgot to make it also inherit from the "flammable"
> class? Imagine an object may *become* flammable. So the author
> initializes isFlammable to false and forgets to make it inherit from the
> flammable class. The IDE could check object properties, find out that
> the base class already has isFlammable set to false and issue a warning.
So could a compiler, but in most cases, that would be a popcorn warning,
so it would tend to be ignored. No difference between an IDE and a
normal compiler, here.
> > 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.
>
> There are some cases where it may not be as clear as in the case of
> breakable objects. E.g. what about TADS 2's verSomething() handlers. If
> verSomething() is there, but doSomething() isn't implemented
I have no idea what those functions do, but if they really do depend on
another, the TADS compiler really should detect their absence. Just as,
for example, Inform detects a missing ActionSub if you have defined a
grammar line using Action.
Defective compilers aren't really a point in a GUI's favour - rather,
they should be an incentive to develop a correct, fully-functional
compiler _first_, and then see what tools you can add.
Richard
Plugh!
> > > <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.
>
> This is my program. All paths are valid if I say they are.
already have an exit to the north, then north isn't in the drop down
list of possible exits.
> > 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.
>
> Good grief. If you do that, you need to learn to program.
*I* don't, but there have to be people out there who do.
> > > > 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.
>
> I've never found it to be so except in the most trivial, compiler-
> detectable ways. But perhaps you have some examples?
If it's drudgery, or prhaps I should say "orutine", you don't
concentrate on it. That's when C programmers assign when they meant to
compare - if (x = 0)
However, I don't want to get religious on this. I think so, you don't.
We agree on enough other things.
> > > > 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?
>
> What has that got to do with the price of cake? Searchable notes in your
> code help you write solid code and remember where you left holes, CP/M
> does not (except that it probably was more stable than Windows...).
Sorry, I must stop being flippant. As I sais elsewhere, I
occassionally insert FIMXEs in my code, by mistake. I just thought
that a nice GUI based to-do list, with priorities, name of responsible
person, due date, etc might look nice. Nothing wrong with looking
nice? Sure, we can put all that in comments, but the more text you
have, the easier it is to mistype (and I am king of the mistypers),
and then not find again when searching.
No biggy, though. If the feature is in teh program, you don't have to
use it. You can still use fixmes.
Btw, I am thinking of a checkbox in one corner of the room/actor/item,
etc screen which the author can check to say that this item is
completely coded. Then we can have an easy overview of what still
needs some work done.
> > > 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.
>
> Well, as I said, there may be people for whom a Plugh-like tool is just
> the thing, but not for me. I _like_ my paper notes.
Sigh, sounds like the program isn't for you, then. Of course, I know
that it won't be for everyone, especially the most advanced authors;
which is why I sigh, because those are exactly the people who can help
us spec this tool. Even if they think it only for newbies, I hope that
the experienced ones will give us the benefit of their opinion of what
might be useful (thanks for your contributions so far).
> > > > 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.
>
> Sure. But those are design and algorithm problems, very hard to make
> easier using just a GUI.
I totally agree, but just because it's hard, doesn't meant we
shouldn't think about trying. Besides, we're just kicking ideas about
at this stage, so I don't rule anything out.
> > > 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.
But I want to show your deign graphically. Think of it as UML for
i-f.
> > Plugh attempts to show your design somewhat graphically.
> Myeah. Which is usually something I do not need or want.
>
> Still, de gustibus...
Thanks, Richard. I appreciate the feedback.
Plugh!
> TravelConnectors are not always inside their room; they are if they
> represent physical game objects like doors or staircases, but not if
> they are abstract programming objects. For example, if you want to
> display a message when travelling from the roomA to roomB you'd use
> a TravelMessage connector
In either case, we can show them on the map & have the user click them
to edit them.
When creating a passage from one room to the next, in addition to
n,s,e,w, etc, we can have an option for "via travelconnector" and an
appropriate travelConnector definition form.
Plugh!
> 1. Agree. Which is why I plan to look at every feature under the aspect:
> What if you don't want it? I'll make sure you can easily turn off any
> helpful features that may get in the way.
I am a major fan of full customizability (if there is such a word)
> True. I think I've convinced Plugh to make all the text that is output
> editable and customizable on a per-object basis.
Convinced me, huh? I'd like to hope that I always thought that way. Of
course, I don't always allow the user to change N to S, I can offer
him the chance to choose North from a drop down list, rather than
South.
> That's not quite as good as a text editor,
It ought to be - else we haven't designed our tool correctly.
> but at worst should let the user override most
> stupid things the editor might do.
We will design it to do nothing stupid :-)
> Of course, there may still be
> occasions where they'll need a text editor,
*Need*? "Need" is *not* acceptable. And even "want" to use a text
editor makes me cringe. If that's the case, then the tool isn't good
enough.
> but if we keep them few and
> far between, and allow re-importing stuff after that, it may be close
> enough not to matter.
Since we will support i-f text import, the authout can screw about
with the code with a text editor, but that shouldn't be the preferred
way.
> > Sure, I was simply trying to make the point with a simple (but
> > perhaps less than ideally apposite) example about being careful in
> > assumptions about what's generic to all I-F languages.
We still need an Inform guru on board to help us determine that.
> Well, we'll need to make assumptions about the number of exits and what
> directions are available when writing the map layouting code, but as
> long as the user can decide what exit is displayed where (with sensible
> defaults being "north", "east", "south" and "west", obviously), we
> should be pretty safe.
>
> > If we're just aiming at TADS 2, TADS 3 and Inform then that makes a
> > decently-defined group.
I think that we, with possibly Hugo too (or at least look to Hugo for
a future release)
Plugh!
> make
> > it so that there is no point where you *want* to abandon it for a
> text editor.
>
> To achieve that you'll have to make it *behave* like a text-editor
> if that's what the user wants. There are places where the easiest
> way to get the code you want is to write/edit it yourself, and it's
> important that your tool isn't perceived as getting in the way of
> that.
if he, for instance wants to change the directionof a passage, or the
location of an object, then he has to use the GUI. I do not see this
as being evil and am reluctant to change it. Maybe a concrete example
will convince me. But, until then, I want to keep it that way (that's
not meant to sound confrontational, btw).
> However well-designed a tool is, there will always be times
> when a user wants to do something in a way the tool-author didn't
> quite anticipate, at which point the tool can feel like it's getting
> in the way by being too obstinate/helpful
I can see that happening. Or, at least, I can't claim to have
anticipated everything. My solution, should such an eventuality arise,
is to change the tool to do it right.
> I suppose what I'm getting at is that if you want
> people never to leave your tool, it'll need a text-editing mode.
It's doable, of course, if the user is reluctant to choose an object's
lcoation from a drop down list of currently defined rooms &
containers, then the tool can open a window with the generated code
for that object and allow the user to edit it.
BUT - 1) it's extra work for me to implement this (some quite hairy
code) 2) I'm still not convinced of the need for it 3) it is error
prone. When the tool offers a list of defined rooms + containers,
there is no chance for the author to make a typo.
> > 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
>
> Yes, I can see the sense of that. Of course it would also be no bad
> thing if your tool also helped organize source files in a logical
> fashion.
For stuff generated entirely within the tool, yes we can/will. For
imported stuff, we have no control (of course, we could offer to
restructure the imported code :-)
We are now agreed upon this.
> > > 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.
>
> Thanks - no doubt you'll be publishing details of your website once
> it's up and running, so I'm sure I'll have no difficulty finding it.
> I'll put a couple of thoughts into a separate post, since this one
> is probably long enough.
>
> -- Eric
Thanks again, Eric.
Eric Eve
That's good. You'll need to bear in mind that there are the two
different syntactical constructs that users might want to use with
TravelConnectors, either:
north = travelConnectorObj
Where the travelConnectorObj is seperately defined as an independent
named object, or
north : TravelConnectorClass { /* definition here */ }
Where the short form is usable. Which construction to use can
generally, but probably not always, be deduced from the particular
class of TravelConnector (a RoomConnector, for example, might be
used either way depending on the preference of the programmer - I'd
tend to do it the first way but I think I've seen Mike Roberts
recommend the second).
Note that another reasonable common thing that it can be useful to
do (certainly in TADS 3 and I strongly suspect TADS 2 and Inform
too) is to allow a direction property to be an evaluated expression.
In my own code I often do this kind of thing:
insideBoat : OutdoorRoom 'Inside the Boat'
"This small rowing boat..."
out = (boat.location)
;
-- Eric
Uli Kusterer
r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> > The question is, what do you do more often? Mirrored passages, or
> > passages that only go in one direction, or come out elsewhere than they
> > go in? If you do a maze-style game, you'd obviously want to turn that
> > off, but otherwise it might be less work to remove the mirrored passage
> > in those three cases than to add it manually in the other 25.
>
> Only if you find drag-and-drop easier than find-and-type, which I don't.
Who said anything about drag and drop? Although that will probably be
an option in cases where it makes sense. The advantage of our GUI tool
would be that, e.g. instead of doing a Find for "myChair" and having to
go through three files that use myChair, we can offer a "Go to Room" or
"Go to definition" menu item where you just enter myChair and get the
definition on the first go.
Graphical User Interface in no way implies that we're going to "turn
off the keyboard", or that there won't be shortcuts for menu items.
> > Of course, it could look at the sdesc and flag objects that contain the
> > word "table" and aren't static,
>
> Exactly. So... you forgot to make an object static which should've been.
> And the compiler, to solve this, looks for items which aren't static,
> but should've been. But how does it know which items should be static?
The IDE can rarely really "know" what the author intends in cases of an
error. However, it *can* mark places that look like something's wonky.
In the above example, I thought that there may be a list of words (which
you can adjust to your personal needs) that may be in the object's
display name (to avoid the TADS-specific word "sdesc") or in its
vocabulary words.
If one of these words are found, and a particular property doesn't have
a particular value, the IDE would add mention of that in a "possible
errors" window, and the author would just check that list and tell the
IDE: a) Ignore this one, that's an exception b) Ignore this in the
entire game, because here all ducks are 20 feet in size and can't be
carried or c) Show me the object where you noted the error so I can fix
it or d) Just fix that error.
It is just an aid, an offer. You don't *have* to use it, but it would
be a great way to catch potential errors. And every time someone catches
an error that could be caught by this, they could add it to the list,
and they could send it to us so we can include it in the next version's
list.
> > or that only inherit from lockable and not from item,
>
> That makes no sense in an Inform context, which is the only IF
> programming language I know.
lockable is a mix-in class, a weak class that only implements the
method for locking an object. item is a class that implements all
actions you can perform on an object, even though it simply disavows
some that don't make sense in all items (like locking it).
You usually have any object inherit either from item, room, prop or
Actor, and then you add some features to it by e.g. also inheriting from
lockable. But only inheriting from lockable would leave you with half an
object, so it's very likely an error which the TADS can't complain
about, because it's part of the library design and not of the language.
But our IDE could for example check such requirements as well.
> Anyway, if being lockable requires being an item, why does the lockable
> _class_ not derive from item?
Because then if you wanted to have an object that is lockable and
pushable, it would inherit item twice, if both of these inherited from
item, or if one of them didn't people would accidentally create another
of these objects without adding "item" to the list, which would cause
the same problem.
> > FIXME is nice if it is handled like Eclipse does it: On startup, it
> > creates a list of all comments starting with "TODO" and shows them in a
> > to-do list window.
>
> Blech - pop-up windows. FIXME works fine without gizmos in any decent
> programmer's editor.
I never said anything of popup windows (I suppose you mean something
like the icons and tool tips Eclipse has in its left border ... that's a
useful extra for quickly reviewing error messages while you're fixing
them, but of no use for FIXMEs).
It's a regular window. Just like you have a "Find" menu item that shows
a dialog for entering what to look for, there'd be a "To-do list" menu
item that shows a window that lists all FIXMEs and TODOs in the source
code. Use it, or ignore it, just as you please.
> > You definitely have a point, but this probably depends as much on the
> > size of your screen as it depends on your work style, and how organized
> > you are. Very organized people might not encounter many of the problems
> > we're trying to solve.
>
> Not only that, but some people - me, for one - actually find it easier
> to design on paper than to design on a screen.
However, that may -- in part -- be due to the fact that the tools that
are available right now are just too awkward to use for designing a game
(or rather, not really awkward, but more awkward than just using a pen
and paper). Of course, sometimes I just design stuff on paper because I
don't want to sit in front of a computer screen for another two hours,
in that case, even the best tool wouldn't bring me to doing the design
on the computer.
I'm not saying everyone will embrace a tool like this, but there is
definitely room for improving the tools that are available.
> > The compiler probably *could* detect certain errors (or at least flag
> > them up as warnings), but right now most compilers don't.
>
> Eh? Inform detects detectable errors just fine.
Syntax errors, yes. Even some semantic errors. But there are still
enough ways to get bugs into a program which compilers don't catch. I
can't promise we'll catch all of them (some probably just can't be
caught by a computer because they're specific to a particular game or a
particular puzzle in that game or whatever). But since compilers are
restricted to catching language-specific errors and many compilers can
be used with several libraries, one niche where our IDE could help is
catching library-specific semantic errors.
Also, many compilers can tell you where an error is, but don't fix it.
Again, it would be a tall order to claim this is possible for all
errors, but for some of the most common or most stupid errors, we could
have a "Fix it" button, which attempts to fix the error. Of course, we'd
apply a "temporary" fix in that case, and only actually apply it to the
code if the user agrees with it (Kind of like the link in Google where
it asks 'did you perhaps mean "Zaphod Beeblebrox" instead of "Zap
Beeblox"'? but shows you the results for the initial search anyway).
> > Maybe the author forgot to make it also inherit from the "flammable"
> > class? Imagine an object may *become* flammable. So the author
> > initializes isFlammable to false and forgets to make it inherit from the
> > flammable class. The IDE could check object properties, find out that
> > the base class already has isFlammable set to false and issue a warning.
>
> So could a compiler, but in most cases, that would be a popcorn warning,
> so it would tend to be ignored. No difference between an IDE and a
> normal compiler, here.
No difference, yes. Which is why many compilers have "warning levels".
In the final phase of development, you'd want to build with all the
warnings on, and go over them just in case one of them actually catches
something you missed. I'm not saying a compiler couldn't do these
things, but many compilers don't, and our app could do it for them. It
could even let users easily customize warnings.
Yes, you *can* do something similar with canned searches, but why not
let the IDE do it for you?
> > There are some cases where it may not be as clear as in the case of
> > breakable objects. E.g. what about TADS 2's verSomething() handlers. If
> > verSomething() is there, but doSomething() isn't implemented
>
> I have no idea what those functions do, but if they really do depend on
> another, the TADS compiler really should detect their absence. Just as,
> for example, Inform detects a missing ActionSub if you have defined a
> grammar line using Action.
> Defective compilers aren't really a point in a GUI's favour - rather,
> they should be an incentive to develop a correct, fully-functional
> compiler _first_, and then see what tools you can add.
verXXX methods are a first line of defense for denying that a certain
action isn't possible. They are, however, implemented completely in the
library, and not in the language. Since you can at this point use at
least two completely different libraries with TADS, it would be kind of
stupid to make the compiler bitch about adv.t related errors when
compiling games that use WorldClass, or whatever that other language was
called.
There very likely are similar errors that are commonly made in Inform,
but sadly I'm not familiar enough with the language that I could come up
with a good example.
Uli Kusterer
"Eric Eve" <eric...@NOSPAMhmc.ox.ac.uk> wrote:
> TravelConnectors are not always inside their room; they are if they
> represent physical game objects like doors or staircases, but not if
> they are abstract programming objects. For example, if you want to
> display a message when travelling from the roomA to roomB you'd use
> a TravelMessage connector, which you *could* use like this:
>
> [snip]
>
> But what you'd *actually* write, taking advantage of template and
> anoynmous nested object syntax is:
>
> [snip]
Okay, my statement was probably a little inaccurate. But this would
still be fairly easy to parse.
Plugh!
>
> Who said anything about drag and drop? Although that will probably be
> an option in cases where it makes sense. The advantage of our GUI tool
> would be that, e.g. instead of doing a Find for "myChair" and having to
> go through three files that use myChair, we can offer a "Go to Room" or
> "Go to definition" menu item where you just enter myChair and get the
> definition on the first go.
the enclosing room)
> Graphical User Interface in no way implies that we're going to "turn
> off the keyboard", or that there won't be shortcuts for menu items.
Although I like GUIs, I am rodent-phoobic. So, lots & lots of keyboard
shortcuts.
Russell Wallace
wrote:
>In the ideal case, you'd establish the dependencies with a casual click
>while coding the game, then you'd have a special-object for each ending
>for the game, and what it requires, and then the computer would tell you
>whether the game is winnable, or an ending is unreachable or whatever.
>Of course, the ideal case isn't really easy to achieve, (in some very
>complex games even impossible), but if we can avoid even a few stupid
>bugs in the game, wouldn't that already be a reason to use Plugh's
>successor instead of a text editor?
To toss in my two cents' worth:
I personally wouldn't have a use for a program that just echoes back
to me what I've already told it; I'd probably just stick to using
UltraEdit. What I definitely _would_ have a use for, though, is an
intelligent assistant program that can figure things out.
For example, I'd like to know if there's a way to make the game
unwinnable. To figure that out, the program should start at the
beginning and search through the possible sequences of actions and
states reachable thereby, looking for a state from which there is no
path to winning.
I'd jump at the chance to use a program that could do that.
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
http://www.esatclear.ie/~rwallace
Uli Kusterer
wallacet...@eircom.net (Russell Wallace) wrote:
> I'd jump at the chance to use a program that could do that.
Well, the general idea of my suggestion was to approximate something
like that. The problem is, though, that there really *is* no way to do
that except running the program and trying all the possible
permutations. And *that*, in turn, is simply not practicable.
Russell Wallace
wrote:
>Well, the general idea of my suggestion was to approximate something
>like that. The problem is, though, that there really *is* no way to do
>that except running the program and trying all the possible
>permutations. And *that*, in turn, is simply not practicable.
But it gets done anyway, because it's a non-negotiable requirement.
The problem is that the way it gets done at the moment is by throwing
large amounts of human labor at it; it strikes me as greatly
preferable to be able to even partly automate it.
Of course, not all things humans do can be automated with present day
technology. But the simple question of "can this program reach
unwinnable states" does not strike me as one that'd need sentient AI
to answer. I'd guess some form of pruned tree search with a collection
of appropriate heuristics would handle enough cases to be useful.
(While I'm not offering to actually join the project - I'm up to my
eyes in my own work at the moment - I'd be happy to offer helpful
how-to suggestions from the back seat if someone wants to have a go at
implementing this sort of feature.)
Adam Thornton
Russell Wallace <wallacet...@eircom.net> wrote:
>Of course, not all things humans do can be automated with present day
>technology. But the simple question of "can this program reach
>unwinnable states" does not strike me as one that'd need sentient AI
>to answer. I'd guess some form of pruned tree search with a collection
>of appropriate heuristics would handle enough cases to be useful.
I bet that to answer that question definitively, for an arbitrary
Inform, TADS2, TADS3, or Hugo program, is NP-complete. At least.
Adam
Uli Kusterer
wallacet...@eircom.net (Russell Wallace) wrote:
> >except running the program and trying all the possible
> >permutations. And *that*, in turn, is simply not practicable.
>
> But it gets done anyway, because it's a non-negotiable requirement.
I think I do not quite understand what you mean here. If how I
understand your statement above is correct, you're overlooking that even
human beta testers don't try every permutation of a game. That is why
games have bugs, and why some bugs aren't discovered until way after
release; it is statistically highly unlikely for the betas to find every
bug.
> The problem is that the way it gets done at the moment is by throwing
> large amounts of human labor at it; it strikes me as greatly
> preferable to be able to even partly automate it.
The problem is, to automate this, you would have to make the computer
behave like a human. After all, humans will in the end be playing the
game, so the heuristics have to simulate how a human would very likely
use the game. And since simulating a human is a problem that hasn't
really been solved in a sufficient fashion yet, the option of just
"throwing large amounts of human labor at it" is more practicable.
Otherwise, what would the simulation have to do? It would have to parse
any game output and approximate what the user may want to do with it,
and then try that. Even worse, if there are several logical options (I
don't even want to begin considering the illogical ones in this
message), you would have to follow every possible branch. If you're
lucky, you have the traveling salesman problem. If you're not, you have
an NP-complete combinatorial explosion.
> Of course, not all things humans do can be automated with present day
> technology. But the simple question of "can this program reach
> unwinnable states" does not strike me as one that'd need sentient AI
> to answer.
I vaguely remember from CompSci class that actually this problem has
not been solved yet: You'd basically end up proving the correctness of
the implementation of the game. But even if I'm wrong, you'd still have
to feed the game much of the meta-information I mentioned. You'd have to
tell the game what constitutes "winning the game".
> I'd guess some form of pruned tree search with a collection
> of appropriate heuristics would handle enough cases to be useful.
That comes very close to what I was trying to convey when I voiced I'd
want "to approximate something like that". But it is definitely not as
easy as just using a tree and running all permutations. There are just
too many of them. The hard part is defining suitable heuristics.
Computer-based proof isn't really my specialty, though, so maybe I'm
missing some of the constraints that turn this into a much smaller
problem?
> (While I'm not offering to actually join the project - I'm up to my
> eyes in my own work at the moment - I'd be happy to offer helpful
> how-to suggestions from the back seat if someone wants to have a go at
> implementing this sort of feature.)
Actually, you don't need to code to join the project. The hard part in
a project like this is coming up with suitable algorithms for the more
complex parts, working out the specification. In the end, implementation
can be done by monkeys with typewriters like me. We're working on
getting a Wiki set up for the project (actually, it's already there, but
we're still waiting for the domain name to clear).
Everybody who thinks they have something of value to contribute is
invited to have a look at it when we post the URL here.
So, I'd love if you took the time to let us know. It sounds like you
are pretty knowledgeable in this area, and we'd definitely love to have
your "suggestions from the back seat". On this thread, via e-mail, or on
the Wiki, whatever suits you best. (note that the e-mail I'm posting
from is spamfodder, use the contact page on my web site to get my
address)
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
Mike Roberts
In fact, I believe it amounts to a restatement of the halting problem. An
unwinnable state could be defined as a state of the machine (i.e., game)
such that no subsequent sequence of inputs will reach a given final state
(i.e., a winning condition); this seems to map trivially to the halting
problem. If so, it's worse than NP-complete; it's actually undecidable.
Even if it doesn't map so directly to the halting problem, which I think it
does, the similar argument can be made that it is in general undecidable
whether or not a given state is "unwinnable," because the subsequent
sequence of inputs from any given state is infinite: given any sequence of
inputs, I can create another by adding "GO NORTH" to the end of it. Since
the set of possible inputs is infinite, it's impossible to exhaustively test
that set. The best you could say is "unwinnable in N turns." I'm sure even
that more limited statement is still computationally intractable given the
large number of possible inputs for each individual move. My extremely
conservative estimate would be on the order of 1e6 (100 verbs * 100 direct
objects * 100 indirect objects) possibilities per move for well-formed
input, and more like 1e30 (36 alphanumeric characters ^ 20 characters) if we
consider the more comprehensive range of what the player could type, which
one might reasonably include for many games because of passwords,
combination locks, etc. Remember, to exhaustively search this space, you're
not talking about multiplying options-per-turn times the number of moves,
you're talking about options-per-turn raised to the power of the number of
moves. In a smallish game that can be completed in, say, 100 turns, the
conservative estimate would be 1e6^100, or about 1e600. Maybe you could
reduce the search space using "tree pruning and heuristics," but I'm
skeptical; the nature of the problem doesn't seem to lend itself to the kind
of position-strength analysis possible in those games where tree-pruning has
actually been applied (Chess, for example).
--Mike
mjr underscore at hotmail dot com
Andrew Plotkin
> "Adam Thornton" <ad...@fsf.net> wrote:
> > Russell Wallace <wallacet...@eircom.net> wrote:
> >
> > I bet that to answer that question definitively, for an arbitrary
> > Inform, TADS2, TADS3, or Hugo program, is NP-complete.
> > At least.
>
> In fact, I believe it amounts to a restatement of the halting problem. An
> unwinnable state could be defined as a state of the machine (i.e., game)
> such that no subsequent sequence of inputs will reach a given final state
> (i.e., a winning condition); this seems to map trivially to the halting
> problem. If so, it's worse than NP-complete; it's actually undecidable.
One big advantage of using Z-code is that, with only 64K of writable
memory, there are only a finite number of states. This makes the
winnability problem trivially decidable!
--Z (for mathematician's values of "big" and "trivial")
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Russell Wallace
wrote:
>I bet that to answer that question definitively, for an arbitrary
>Inform, TADS2, TADS3, or Hugo program, is NP-complete. At least.
To answer it _definitively_ in the worst case for a Turing-complete
language is of course incomputable (and exptime-hard for non-Turing
complete systems such as the z-machine). In practice, therefore, we
settle for the best answers we can get, accepting that they won't be
definitive - see my other followup for lengthier discussion.
Russell Wallace
wrote:
[about checking a game for unwinnable conditions and other errors]
> I think I do not quite understand what you mean here. If how I
>understand your statement above is correct, you're overlooking that even
>human beta testers don't try every permutation of a game. That is why
>games have bugs, and why some bugs aren't discovered until way after
>release; it is statistically highly unlikely for the betas to find every
>bug.
That's exactly my point. We need the question answered; since it's
impossible for humans to answer it definitively either, we settle for
the best we can get, so the fact that a machine can't answer it
definitively doesn't mean a partial solution won't be valuable.
> The problem is, to automate this, you would have to make the computer
>behave like a human. After all, humans will in the end be playing the
>game, so the heuristics have to simulate how a human would very likely
>use the game. And since simulating a human is a problem that hasn't
>really been solved in a sufficient fashion yet, the option of just
>"throwing large amounts of human labor at it" is more practicable.
>
> Otherwise, what would the simulation have to do? It would have to parse
>any game output and approximate what the user may want to do with it,
>and then try that.
If it had to treat the game as a black box - only being able to see
the output - I'd agree even a partial solution wasn't feasible with
today's technology. But the computer has a huge advantage: whereas a
human has to _guess_ (based on the output text) what actions have
nontrivial responses coded for them, the computer can look at the code
and directly see what things are worth trying.
>Even worse, if there are several logical options (I
>don't even want to begin considering the illogical ones in this
>message), you would have to follow every possible branch. If you're
>lucky, you have the traveling salesman problem. If you're not, you have
>an NP-complete combinatorial explosion.
But travelling salesman and other NP-complete problems are solved
every day. The trick is to realize you can't get a _guaranteed
perfect_ solution, and try for a good-enough one.
Game tree search is a good analogy. A chess program looks at the moves
it could make, the possible responses to those, the possible responses
in turn... an exponentially large search tree. It's made tractable by
cutting off lines of possible moves, using heuristics to guess which
ones to cut off and when. The result is that Deep Blue couldn't play
perfect chess, but it could play well enough to beat the human
champion.
Even if the program discussed here couldn't _outperform_ a good human
beta tester, it would still be valuable if it saved labor by finding
the obvious problems first. It might also find obscure problems
resulting from things a human would do only once in a blue moon - and
that a human beta tester might therefore miss.
> I vaguely remember from CompSci class that actually this problem has
>not been solved yet
In terms of a perfect solution, no. But there are lots of partial
solutions to exponential search problems.
>But even if I'm wrong, you'd still have
>to feed the game much of the meta-information I mentioned. You'd have to
>tell the game what constitutes "winning the game".
Inform has a specific status code to define this. Does TADS have
something similar?
>> I'd guess some form of pruned tree search with a collection
>> of appropriate heuristics would handle enough cases to be useful.
>
> That comes very close to what I was trying to convey when I voiced I'd
>want "to approximate something like that". But it is definitely not as
>easy as just using a tree and running all permutations. There are just
>too many of them.
Agreed, that's why you need heuristics to guide the program towards
paths that are likely to be worth exploring.
>The hard part is defining suitable heuristics.
Yep. It won't be trivial, but it would be worthwhile - and, I'll point
out, a lot more fun than fiddling with the messy GUI code to implement
the point-and-click stuff ^.^
>Computer-based proof isn't really my specialty, though, so maybe I'm
>missing some of the constraints that turn this into a much smaller
>problem?
You may have missed the fact that the program can look at the set of
coded responses rather than having to guess at sequences of alphabetic
characters for input - that, I think, should turn the problem into
something closer to chess than "monkeys typing the works of
Shakespeare".
>> (While I'm not offering to actually join the project - I'm up to my
>> eyes in my own work at the moment - I'd be happy to offer helpful
>> how-to suggestions from the back seat if someone wants to have a go at
>> implementing this sort of feature.)
>
> Actually, you don't need to code to join the project. The hard part in
>a project like this is coming up with suitable algorithms for the more
>complex parts, working out the specification. In the end, implementation
>can be done by monkeys with typewriters like me. We're working on
>getting a Wiki set up for the project (actually, it's already there, but
>we're still waiting for the domain name to clear).
Great! Maybe I can of some help, then.
> So, I'd love if you took the time to let us know. It sounds like you
>are pretty knowledgeable in this area, and we'd definitely love to have
>your "suggestions from the back seat". On this thread, via e-mail, or on
>the Wiki, whatever suits you best. (note that the e-mail I'm posting
>from is spamfodder, use the contact page on my web site to get my
>address)
Thanks, will do! This thread seems okay until the Wiki is up and
running.
Esa A E Peuha
> One big advantage of using Z-code is that, with only 64K of writable
> memory, there are only a finite number of states. This makes the
> winnability problem trivially decidable!
>
> --Z (for mathematician's values of "big" and "trivial")
If only! However, the state of Z-code is not completely contained in
the writable memory; there's the instruction pointer (which is finite)
and the stack(s) (which can theoretically be infinite), so there are
(theoretically) infinite number of states. Of course, any _actual_
implementation of the Z-machine can only have a finite number of states
(because the hardware running the implementation can only have a finite
amount of memory), but still the winnability problem is not practically
decidable.
--
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/
Andrew Plotkin
> Andrew Plotkin <erky...@eblong.com> writes:
>
> > One big advantage of using Z-code is that, with only 64K of writable
> > memory, there are only a finite number of states. This makes the
> > winnability problem trivially decidable!
> >
> > --Z (for mathematician's values of "big" and "trivial")
>
> If only! However, the state of Z-code is not completely contained in
> the writable memory; there's the instruction pointer (which is finite)
> and the stack(s) (which can theoretically be infinite),
The Z-spec has a minimum recommended stack size, which suggests that a
game should treat that limit as the *maximum* available stack size.
Thus finite.
> Of course, any _actual_
> implementation of the Z-machine can only have a finite number of states
> (because the hardware running the implementation can only have a finite
> amount of memory), but still the winnability problem is not practically
> decidable.
Practical? Practical? What is this Earth humor?
--Z
Matthew Russotto
Well, for a Turing-equivalent language it's basically the halting
problem.
However, a better way of demonstrating that it probably DOES require
AI to do it in reasonable time is to note that solving the problem
requires building a general-purpose game solver.
--
Matthew T. Russotto mrus...@speakeasy.net
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue." But extreme restriction of liberty in pursuit of
a modicum of security is a very expensive vice.
Matthew Russotto
Andrew Plotkin <erky...@eblong.com> wrote:
>
>One big advantage of using Z-code is that, with only 64K of writable
>memory, there are only a finite number of states. This makes the
>winnability problem trivially decidable!
>
>--Z (for mathematician's values of "big" and "trivial")
I think Z-machines are best modeled as push-down automata, not
"simple" 256^65536 state machines. Unfortunately, the problem of
deciding whether or not a push-down automaton will halt was not one
covered in my CS classes, but I'd be very surprised if it was not at
least NP-hard.
Russell Wallace
(Matthew Russotto) wrote:
>However, a better way of demonstrating that it probably DOES require
>AI to do it in reasonable time is to note that solving the problem
>requires building a general-purpose game solver.
Nope, just a game cheater :) (The program can "cheat" by looking at
the code to see what actions are implemented.)
Matthew Russotto
Russell Wallace <wallacet...@eircom.net> wrote:
>On Thu, 26 Feb 2004 09:41:22 -0600, russ...@grace.speakeasy.net
>(Matthew Russotto) wrote:
>
>>However, a better way of demonstrating that it probably DOES require
>>AI to do it in reasonable time is to note that solving the problem
>>requires building a general-purpose game solver.
>
>Nope, just a game cheater :) (The program can "cheat" by looking at
>the code to see what actions are implemented.)
That reduces the problem by a few orders of magnitude, but I believe
it remains intractable.
Uli Kusterer
wallacet...@eircom.net (Russell Wallace) wrote:
> On Thu, 26 Feb 2004 09:41:22 -0600, russ...@grace.speakeasy.net
> (Matthew Russotto) wrote:
>
> >However, a better way of demonstrating that it probably DOES require
> >AI to do it in reasonable time is to note that solving the problem
> >requires building a general-purpose game solver.
>
> Nope, just a game cheater :) (The program can "cheat" by looking at
> the code to see what actions are implemented.)
But if it looks at the code, wouldn't it not even try doing things that
aren't implemented? And many of the bugs come from having the game not
implement certain functionality.
Though I guess I'm drifting off the current discussion thread of
"proving the winnability of a game", as this really has nothing to do
with that...
-- Uli
http://www.zathras.de
Uli Kusterer
wallacet...@eircom.net (Russell Wallace) wrote:
> >it is statistically highly unlikely for the betas to find every
> >bug.
>
> That's exactly my point. We need the question answered; since it's
> impossible for humans to answer it definitively either, we settle for
> the best we can get, so the fact that a machine can't answer it
> definitively doesn't mean a partial solution won't be valuable.
Okay, I guess we were basically saying the same thing in different
colors. I have no problem with, to put it in my terminology,
approximating a check whether a game is winnable, i.e. finding a
heuristic that matches. In fact, what I've tried to offer so far were
some heuristics for special cases (like tracking object dependencies and
thus easily finding out whether some obscure combination results in a
loop).
> > Otherwise, what would the simulation have to do? It would have to parse
> >any game output and approximate what the user may want to do with it,
> >and then try that.
>
> If it had to treat the game as a black box - only being able to see
> the output - I'd agree even a partial solution wasn't feasible with
> today's technology. But the computer has a huge advantage: whereas a
> human has to _guess_ (based on the output text) what actions have
> nontrivial responses coded for them, the computer can look at the code
> and directly see what things are worth trying.
I'm not sure it'll be that easy. That way, a computer can at most
determine whether a person using a walkthrough could still win the game.
However, what is a trivial response to the computer, may be the vital
clue needed to find out what to do next for the human.
E.g. while the keypad for entering an access code may be accessible
from the beginning in a game (thus making it winnable from round 1), the
user may not be told what code to enter until the final moment. (S)he
would probably be told in a very simple "print" statement (if it isn't
randomized). The computer would thus discard this as being trivial, and
never notice that the moment the player kills the snitch, he's never
going to get the access code.
So, we'd have to include at least some kind of explicit mark-up of
important statements in our heuristic as well, to prevent the engine
from missing this. And as soon as we need explicit mark-up in some
cases, we should require it for the others, lest the user assume the
engine always gets it right and never notice this unwinnability.
> Even if the program discussed here couldn't _outperform_ a good human
> beta tester, it would still be valuable if it saved labor by finding
> the obvious problems first. It might also find obscure problems
> resulting from things a human would do only once in a blue moon - and
> that a human beta tester might therefore miss.
This is actually a pretty nice mission statement for our program, and
exactly the reason why we're going GUI: Because if you don't require the
user to enter things that the computer already knows, but rather let
them pick them from a menu or equivalent structure, you avoid typos and
you can intercept syntax errors at the time they are entered. Like "live
spell checking" in modern word processors.
> >But even if I'm wrong, you'd still have
> >to feed the game much of the meta-information I mentioned. You'd have to
> >tell the game what constitutes "winning the game".
>
> Inform has a specific status code to define this. Does TADS have
> something similar?
At least TADS 2 doesn't. Usually you just have one or more rooms
without exits that you take the player to when they win that displays
"you have won" or "you suck" or whatever as the room description. So, I
guess we'd have a "get here and win" or "get this item and win" checkbox
on objects, and for Inform it would automatically be set for any method
that sets the status code.
> >The hard part is defining suitable heuristics.
>
> Yep. It won't be trivial, but it would be worthwhile - and, I'll point
> out, a lot more fun than fiddling with the messy GUI code to implement
> the point-and-click stuff ^.^
Actually, it's been a while since I actually had to write much code to
get a GUI working. You simply drag and drop, hook up a few outlets and
actions, and then write your program-specific logic.
But to get back on topic: What suggestions do you have for such
heuristics? Don't worry if they only apply to Inform, I'm sure once
Plugh and I grasp the general idea, we'd be able to devise similar
schemes for TADS.
My first heuristic was to have the user specify some knowledge about
objects in the game (like "get here and you have completed the game",
"get here and you have won", "object A depends on having object B"), and
based on that the IDE could draw some graphs and perform circular
dependency checks and thus determine whether a game is winnable.
As an improvement to that, I would have attempted to find some ways to
have the program gather this knowledge automatically, so it could offer
some sensible defaults. (like looking for moveInto() calls for objects
that have "nil" as their location by default, which would allow
detecting where a player may get an object from) Then the user could go
and manually override what the program got wrong.
This is of course very crude. But it would have been able to help
people developing complex games to avoid some obvious mistakes, and it
is very easy and efficient to implement.
Eager to hear some of your ideas,
-- Uli
http://www.zathras.de
mad...@bmrb.wisc-antispam.edu
:Here, Mike Roberts <mjrUND...@hotmail.com> wrote:
:> "Adam Thornton" <ad...@fsf.net> wrote:
:> > Russell Wallace <wallacet...@eircom.net> wrote:
:> >
:> > I bet that to answer that question definitively, for an arbitrary
:> > Inform, TADS2, TADS3, or Hugo program, is NP-complete.
:> > At least.
:>
:> In fact, I believe it amounts to a restatement of the halting problem. An
:> unwinnable state could be defined as a state of the machine (i.e., game)
:> such that no subsequent sequence of inputs will reach a given final state
:> (i.e., a winning condition); this seems to map trivially to the halting
:> problem. If so, it's worse than NP-complete; it's actually undecidable.
:
:One big advantage of using Z-code is that, with only 64K of writable
:memory, there are only a finite number of states. This makes the
:winnability problem trivially decidable!
Not really. That doesn't help the infinite loop problem. There are
two problems with trying to determine if an NP-complete program
is 'stuck' - one is that the memory is theoretically infinite, and
the other is that the TIME is theoretically infinite. You've solved
the memory problem, but not the time one. To determine if a loop of
states is infinite or not, using another program to test your program,
your testing program would itself have to take an infinite amount of
time.
Mike Roberts
> To determine if a loop of states is infinite or not, using
> another program to test your program, your testing program
> would itself have to take an infinite amount of time.
This actually has practical applicability to IF, too. You could imagine a
game where the winning conclusion is reached by typing GO NORTH 1,000,001
times in a row, and every time but the 1,000,001st, the response to GO NORTH
is "You can't go that way." (It wouldn't be a very fun game, but it's still
a possible game.) If an automated winnability evaluator were given a limit
of a million turns, it would incorrectly call the state unwinnable.
mad...@bmrb.wisc-antispam.edu
True. But, it could be possible to write a tool that can detect if
a game is "reasonably" winnable, for some definitin of "reasonable"
that includes a max number of times a player is willing to perform
the same actions.
David Thornley
<mad...@bmrb.wisc-antispam.edu> wrote:
>
>True. But, it could be possible to write a tool that can detect if
>a game is "reasonably" winnable, for some definitin of "reasonable"
>that includes a max number of times a player is willing to perform
>the same actions.
>
some definition of "reasonable" that requires less than the current
world computational resources for less than a human lifetime. At
a rough estimate, the average number of possible commands in an IF
game is greater than the average number of possible moves in a chess
position, and the length of most IF games is longer than the length
of most chess games. This means that the "reasonable" IF winnability
problem requires more computation than a 100-move lookahead chess
program.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David Thornley
>> I bet that to answer that question definitively, for an arbitrary
>> Inform, TADS2, TADS3, or Hugo program, is NP-complete.
>> At least.
>
>In fact, I believe it amounts to a restatement of the halting problem. An
>unwinnable state could be defined as a state of the machine (i.e., game)
>such that no subsequent sequence of inputs will reach a given final state
>(i.e., a winning condition); this seems to map trivially to the halting
>problem. If so, it's worse than NP-complete; it's actually undecidable.
>
Define the winning states as halting states, with any other ending
defined as a non-halting state (going directly into an infinite loop,
say). That is the halting problem.
In other words, the only fault I can find with your statement is that
you aren't certain enough of it.
Seebs
Russell Wallace <wallacet...@eircom.net> wrote:
>Of course, not all things humans do can be automated with present day
>technology. But the simple question of "can this program reach
>unwinnable states" does not strike me as one that'd need sentient AI
>to answer.
Well, in the general case, it doesn't, in that sentient AI can't do it
either. I think you've reached the halting problem.
>I'd guess some form of pruned tree search with a collection
>of appropriate heuristics would handle enough cases to be useful.
Enough to be useful, probably.
-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/
Andrew Plotkin
> Andrew Plotkin <erky...@eblong.com> wrote:
> :
> :One big advantage of using Z-code is that, with only 64K of writable
> :memory, there are only a finite number of states. This makes the
> :winnability problem trivially decidable!
>
> Not really. That doesn't help the infinite loop problem. There are
> two problems with trying to determine if an NP-complete program
> is 'stuck' - one is that the memory is theoretically infinite, and
> the other is that the TIME is theoretically infinite. You've solved
> the memory problem, but not the time one. To determine if a loop of
> states is infinite or not, using another program to test your program,
> your testing program would itself have to take an infinite amount of
> time.
Not true. No loop of states can be infinite, because there are only N
possible machine states. By the pigeonhole principle, no loop can have
more than N steps before it either repeats a state or terminates.
But I didn't even need to tell you that. Any problem which asks a
yes-or-no question over a finite set of inputs *must* be decidable.
This is easy to prove.
Now I have explained my very small joke, and I shall retire.
--Z
David Thornley
Russell Wallace <wallacet...@eircom.net> wrote:
>On Thu, 26 Feb 2004 02:56:12 +0100, Uli Kusterer <wit...@t-online.de>
>wrote:
>
>[about checking a game for unwinnable conditions and other errors]
>
>impossible for humans to answer it definitively either, we settle for
>the best we can get, so the fact that a machine can't answer it
>definitively doesn't mean a partial solution won't be valuable.
>
the question can be answered. If you say that we need that
functionality, so this project is not worth doing without it,
then you seem to be saying that this project isn't worth doing.
I don't think a useful partial solution is doable.
If you have some concrete idea how we can find a useful partial
solution, please contribute it. Right now, you seem to be asking
for somebody else to do the impossible, and I don't think it
seemly to insist on it at length.
>If it had to treat the game as a black box - only being able to see
>the output - I'd agree even a partial solution wasn't feasible with
>today's technology. But the computer has a huge advantage: whereas a
>human has to _guess_ (based on the output text) what actions have
>nontrivial responses coded for them, the computer can look at the code
>and directly see what things are worth trying.
>
Remember that "nontrivial response", in this case, includes actions
with absolutely standard printed responses. In particular, picking
up or dropping objects very often gives nothing but a standard
response, and it does change the game state. It is very common
to require certain combinations of objects in order to win.
Moreover, as pointed out elsewhere, this approach fails if something
like passwords or access codes are used. Suppose the game involves
accessing an NPC's account on a computer, and the password is
"gasometer" (for example). Suppose that the programmer has
written up a slip of paper with the password on it, and a
book that the PC can find. Suppose the programmer has somehow
omitted the code that makes the slip of paper appear when the
book is read. The game is effectively unsolvable, but the
computer will have no way of realizing this.
>>Even worse, if there are several logical options (I
>>don't even want to begin considering the illogical ones in this
>>message), you would have to follow every possible branch. If you're
>>lucky, you have the traveling salesman problem. If you're not, you have
>>an NP-complete combinatorial explosion.
>
>But travelling salesman and other NP-complete problems are solved
>every day. The trick is to realize you can't get a _guaranteed
>perfect_ solution, and try for a good-enough one.
>
NP-complete problems are normally "solved" in one of two ways.
1. A specially designed algorithm for the specific purpose, such
as expanding the minimum spanning tree for the TSP.
2. By starting with a solution, and refining it with something
like simulated annealing or a genetic algorithm. It's easy
to find a solution to the TSP if one doesn't care about the cost,
and there are ways to start with a bad solution and find a better
one.
Neither of these looks applicable to me.
>Game tree search is a good analogy. A chess program looks at the moves
>it could make, the possible responses to those, the possible responses
>in turn... an exponentially large search tree. It's made tractable by
>cutting off lines of possible moves, using heuristics to guess which
>ones to cut off and when. The result is that Deep Blue couldn't play
>perfect chess, but it could play well enough to beat the human
>champion.
>
Right. This is possible because Deep Blue has a position evaluation
function that tells it who probably has the advantage in any given
position. The equivalent in a winnability tester would be a
function that would evaluate how likely it was that the position
is winnable. At this point, we're going in circles.
>> I vaguely remember from CompSci class that actually this problem has
>>not been solved yet
>
>In terms of a perfect solution, no. But there are lots of partial
>solutions to exponential search problems.
>
The partial solutions I'm aware of are limited to specific problem
areas, whereas IF games are Turing-complete.
>>But even if I'm wrong, you'd still have
>>to feed the game much of the meta-information I mentioned. You'd have to
>>tell the game what constitutes "winning the game".
>
Not a problem. The author can easily flag winning states. The
problems lie elsewhere.
>>The hard part is defining suitable heuristics.
>
>Yep. It won't be trivial, but it would be worthwhile - and, I'll point
>out, a lot more fun than fiddling with the messy GUI code to implement
>the point-and-click stuff ^.^
>
It isn't necessary to get into the messy parts of things in order to
suggest heuristics. Feel free to take the fun part of the job.
>> Actually, you don't need to code to join the project. The hard part in
>>a project like this is coming up with suitable algorithms for the more
>>complex parts, working out the specification. In the end, implementation
>>can be done by monkeys with typewriters like me. We're working on
>>getting a Wiki set up for the project (actually, it's already there, but
>>we're still waiting for the domain name to clear).
>
>Great! Maybe I can of some help, then.
>
Go for it. I think it's impossible, so if you can come up with something
you have the extra enjoyment of making me look foolish.
Joe Mason
> This actually has practical applicability to IF, too. You could imagine a
> game where the winning conclusion is reached by typing GO NORTH 1,000,001
> times in a row, and every time but the 1,000,001st, the response to GO NORTH
> is "You can't go that way." (It wouldn't be a very fun game, but it's still
> a possible game.) If an automated winnability evaluator were given a limit
> of a million turns, it would incorrectly call the state unwinnable.
*** Annoyotron IV: Affrontotron ***
has just been uploaded to the incomig directory of an IF-Archive mirror
near you! Either I've implemented the game Mike describes above... or I
haven't! Is it winable? You decide!
Watch for it in if-archive/unprocessed soon...
(No fair decompiling it - that's cheating!)
Joe