Map editor
Matthew Crosby
Every now an again someone asks on these newsgroups for more visual adventure
authoring tools. So, in the interests of experimenting with this idea, I've
started developing some.
I have just uploaded to ftp.gmd.de the first part of that. It is a Tk/Tcl
based map editor, that lets you place rooms, connect them, etc etc. Right
now, it is still mostly player oriented--and is quite useful for that. I've
been using it while I play games, and it does make it easy to generate nice
maps quickly. It should be trivial, however, to convert the output to Tads or
Inform. With a filter, the programmer can lay out a map, enter in room
descriptions and so forth and generate the skeleton code. There will, of
course, still be a whole pile of coding to be done to get anything interesting
done.
What I'm looking for now is ideas. I've been thinking about more things
to be added. A palette of standard objects, for instance, so you can just
select a room, select eg: a brass lantern and have it in there with the
behaviour one expects from a brass lantern. I suspect this may not be
general enough. Any thoughts? What else do people want to see in something
like this? How about those that just want to draw pretty maps?
Anyway, please take a look at it.
Its currently in ftp.gmd.de in /incoming/if-archive-ifmap.tar.gz
I expect volker will probably put it in the /if-archive/mapping-tools section.
You can see screen shots and things on
http://ugrad-www.cs.colorado.edu/~crosby/ifmap/IFMap.html
Should definately run on any Unix box, and anything else that Tk/Tcl runs
on.
--
Matthew Crosby cro...@cs.colorado.edu
Disclaimer: It was another country, and besides, the wench is dead.
Greg Ewing
Matthew Crosby wrote:
> I have just uploaded to ftp.gmd.de the first part of that. It is a Tk/Tcl
> based map editor, that lets you place rooms, connect them, etc etc.
This sounds very interesting. I once started a project like
that myself, using Alan as the target language, but it
didn't get very far.
> With a filter, the programmer can lay out a map, enter in room
> descriptions and so forth and generate the skeleton code.
May I make a suggestion here before you get too far:
Be very careful how you design this part! The
automatically generated code and the code the author
has to write must be kept separate.
If you generate a file that must be edited by hand, it
won't be possible to use the graphical tool on it any more
after it's been edited, which would be a serious drawback.
So I suggest that you don't think in terms of generating
"skeleton" code, but of generating code, period. The
author should not have to touch the generated code;
any additions should be able to be placed in a
separate file. I know that this won't be easy to
achieve, but I feel it is important to get this right.
> Anyway, please take a look at it.
I will!
> Matthew Crosby cro...@cs.colorado.edu
Greg
Greg Ewing
Matthew Crosby wrote:
> select a room, select eg: a brass lantern and have it in there with the
> behaviour one expects from a brass lantern. I suspect this may not be
> general enough. Any thoughts?
If the author can add new class names to this list, he can
define his own brass lantern class elsewhere, and use the
GUI tool to place instances of it.
> Matthew Crosby cro...@cs.colorado.edu
Greg
Greg Ewing
I've tried out your editor, and it looks like a good start.
I hacked in a procedure for writing out Tads code, and I
can now create working adventures with it (although
they're a bit boring - all you can do is wander around
and look!)
L.J. Wischik <ljw...@thor.cam.ac.uk> has written to me:
> In article <31AA68...@cosc.canterbury.ac.nz> you write:
>> The author should not have to touch the generated code;
> With respect, I think this is wrong.
> (I've already emailed the original posters my comments, and they don't
> seem appropriate to the newsgroup, so I'm not mailing them there).
I don't see why not -- r.a.i-f is where IF development
tools are discussed, and this is an IF development tool,
so it seems entirely appropriate to me. (I've taken out
rec.games.int-fiction, however.)
> I can write a program source
> code, switch to the graphical thing, switch back to source code, and I
> can keep going backwards and forwards.
I think we're in agreement about the main goal, which is
that adding hand-written code should not prevent further
use of the graphical tool. It's not so important how this
is achieved.
I still think, however, that it would be better not to have
to touch any part of the GUI-edited file with a text editor.
One reason is that I would feel somewhat uncomfortable
tampering with such code lest I accidentally mess up
something that the GUI tool needs in order to understand
it.
Another reason is that it would cause problems in my usual
working environment, where I like to have my source files open
all the time I am working on them. Two independent editors
making changes to the same file at the same time would
lead to chaos.
I would much rather there were a way to enter extra pieces
of code through the GUI tool. For example, the room editing
window could provide a pane for entering arbitrary
code to be included in the room class along with the
generated code. It would be saved with suitable comments
delimiting it so that it could be sorted out again the
next time the file is loaded into the GUI.
This is essentially the same idea that L.J. Wischik mentions:
> The best mechanism is to have certain objects that the graphical bit
> can recognise, demarked by comments
> //
> // TADSGUI stuff
> // (automatically generated)
> //
The only difference is that all the editing is done through
the GUI tool, so that the programmer never needs to deal
with the text file directly.
Note that this mechanism would only be needed for pieces of
code that need to be intimately interspersed with the GUI
created code. The programmer would also be able to write
separate text-only code files to be linked in.
Something to think about,
Greg
Hans Persson
> The only difference is that all the editing is done through
> the GUI tool, so that the programmer never needs to deal
> with the text file directly.
This sounds like a *bad* idea, unless you feel like including emacs as
the editor inside the graphical tool.
A workable way might be for the GUI thingy to provide a number of
predefined hooks (routines that are called if present). By writing
these, a programmer could modify the behaviour of certain rooms.
--
+----------------------------------------------------------------------------+
| Hans Persson http://www.lysator.liu.se/~unicorn/ |
| uni...@lysator.liu.se Play Enhanced from SophistiChaos Game Design! |
+----------------------------------------------------------------------------+
John Wood
In article: <31AA68...@cosc.canterbury.ac.nz>
>
> Matthew Crosby wrote:
> > I have just uploaded to ftp.gmd.de the first part of that. It is a Tk/Tcl
> > based map editor, that lets you place rooms, connect them, etc etc.
Sadly, I don't have (easy) access to Unix so I can't try it out. 8-(
> > With a filter, the programmer can lay out a map, enter in room
> > descriptions and so forth and generate the skeleton code.
>
> May I make a suggestion here before you get too far:
> Be very careful how you design this part! The
> automatically generated code and the code the author
> has to write must be kept separate.
True, but they can be in the same file - see below.
> If you generate a file that must be edited by hand, it
> won't be possible to use the graphical tool on it any more
> after it's been edited, which would be a serious drawback.
Not necessarily - again, see below.
> So I suggest that you don't think in terms of generating
> "skeleton" code, but of generating code, period. The
> author should not have to touch the generated code;
> any additions should be able to be placed in a
> separate file. I know that this won't be easy to
> achieve, but I feel it is important to get this right.
It is *very* important to get this right, but you can allow more
flexibility than Greg proposes.
At work, I use Visual C++, which has a tool called ClassWizard to help
define window-based classes. When you create a class using this, it
does indeed create a skeleton. However, most of this is hand editable,
with the blocks that must be preserved preceeded by a specially-
formatted comment and with a similar comment at the end. It's only if
you edit these blocks that you run into trouble (and even then, not
always). When ClassWizard rereads these files, it looks for the special
comments that tell it what to handle and what to leave alone - it will
only adjust these blocks (or append stuff to the end of the file).
It can also "import" classes from previously-created files.
You can do something similar with languages such as TADS or Inform.
Here's a made-up example in Inform (based on `RUINS') from a utility
called InfoMapper, which handles the direction properties either as
other objects or user-entered text, but no other properties or
attributes. This is obviously a very simple example.
Object Forest "Dark Forest"
with description
"In this tiny clearing, the pine-needle carpet is broken by \
stone-cut steps leading down into darkness. Dark olive \
trees crowd in on all sides, the air steams with warm recent \
rain, midges hang in the air.",
!{BEGIN InfoMapper Directions: Forest}
d_to Square_Chamber,
u_to "The trees are spiny and you'd cut your hands to ribbons trying \
to climb them.",
!{END InfoMapper Directions: Forest}
cant_go "The rainforest-jungle is dense, and you haven't hacked \
through it for days to abandon your discovery now. Really, \
you need a good few artifacts to take back to civilization \
before you can justify giving up the expedition.",
has light;
Note that this is still a compromise solution, but it is simple enough
to allow for output in a variety of languages with only a small quantity
of built-in information about each language. If writing for only one
language it would be possible to go a lot further by parsing the input
and dividing it up into parts which are or aren't handled by the tool,
so that the changes can be "merged" with the old version. I suspect
that such a tool would be a larger project than Matthew is proposing.
John
John Wood
In article: <vtbuj5p...@tiny.lysator.liu.se>
>
> > The only difference is that all the editing is done through
> > the GUI tool, so that the programmer never needs to deal
> > with the text file directly.
>
> This sounds like a *bad* idea, unless you feel like including emacs as
> the editor inside the graphical tool.
One way round this is to be able to run the user's favourite text
editor as a sub-process (or whatever the technical term is 8-), using
(possibly temporary) files with the text to be edited.
> A workable way might be for the GUI thingy to provide a number of
> predefined hooks (routines that are called if present). By writing
> these, a programmer could modify the behaviour of certain rooms.
I'm not quite sure I understand this. Do you mean the user provides
a text "script" which modifies how the tool generates the room, or
passages of text that replace the "standard room output" at certain
points?
John
Andrew C. Plotkin
John Wood <jo...@elvw.demon.co.uk> writes:
> > A workable way might be for the GUI thingy to provide a number of
> > predefined hooks (routines that are called if present). By writing
> > these, a programmer could modify the behaviour of certain rooms.
>
> I'm not quite sure I understand this. Do you mean the user provides
> a text "script" which modifies how the tool generates the room, or
> passages of text that replace the "standard room output" at certain
> points?
The tool generates source code which keeps calling HookN() routines.
(Or whatever.) Many calls to routines, but the routines themselves are
not generated. The programmer can then write a second source file
which implements the routines, or leaves them out, if he doesn't want
to add code at that point.
In Inform, this would involve a lot of Stub statements.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
bonni mierzejewska
On Sat, 08 Jun 1996 12:35:18 GMT, John Wood <jo...@elvw.demon.co.uk> wrote:
>> Matthew Crosby wrote:
>> > I have just uploaded to ftp.gmd.de the first part of that. It is a Tk/Tcl
>> > based map editor, that lets you place rooms, connect them, etc etc.
>[snip]
>
>Sadly, I don't have (easy) access to Unix so I can't try it out. 8-(
I run Linux at home, so I tried it out. It didn't work. :-( Basically,
it can't seem to find itself. I always get: ./ifmap: No such file or
directory. And yes, the script is executable. **sigh**
bonni
coming soon - 1996 IF Competition entry
C++ Turbo Vision archive: http://brooks.wvn.wvnet.edu/tvhome
__ __
IC | XC | bonni mierzejewska "The Lone Quilter"
---+--- | u6...@wvnvm.wvnet.edu
NI | KA | Kelly's Creek Homestead, Maidsville, WV
Greg Ewing
In article: <vtbuj5p...@tiny.lysator.liu.se>
uni...@lysator.liu.se (Hans Persson) writes:
>
> This sounds like a *bad* idea, unless you feel like including emacs as
> the editor inside the graphical tool.
The pieces of code I envisage adding in this way
would be quite short. For anything substantial enough
that you feel the lack of fancy text editing features,
you would have the option of writing a procedure or class
in a separate file using your favourite editor,
and just inserting a reference to it through
the GUI.
Of course some people would argue that the entire
thing should be implemented as an emacs mode :-)
Greg
Greg Ewing
John Wood wrote:
>
> with the blocks that must be preserved preceeded by a specially-
> formatted comment and with a similar comment at the end.
A reasonable idea. It does mean that the tool must be
capable of reading as well as writing the code file,
which might be harder to implement than if it only
needs to read its own private format, which can be
designed for easy reading as well as writing.
> John
Greg
Matthew Amster-Burton
John Wood <jo...@elvw.demon.co.uk> wrote:
>> > I have just uploaded to ftp.gmd.de the first part of that. It is a Tk/Tcl
>> > based map editor, that lets you place rooms, connect them, etc etc.
>Sadly, I don't have (easy) access to Unix so I can't try it out. 8-(
Tcl/Tk is available for Windows and Macintosh as well as Unix. I got
ifmap to run fine on Win 3.1. Try ftp.smli.com in /pub/tcl.
Matthew
Larry Smith
John Wood wrote:
> > Matthew Crosby wrote:
> > > I have just uploaded to ftp.gmd.de the first part of that. It is a Tk/Tcl
> > > based map editor, that lets you place rooms, connect them, etc etc.
> Sadly, I don't have (easy) access to Unix so I can't try it out. 8-(
TCL/Tk runs on Unix, Macs _and_ Windows. Programs written with it that
do not use system-specific extensions - like the editor, from the sound
of it - will run unmodified in any of the three environments.
John Wood
It's intended as a "halfway house" suggestion - not as complex
as parsing TADS or Inform files, but more so than just writing.
I think the benefits the user would gain from this would more
than outweigh the extra work involved for the tool's author.
Mind you, I'm not volunteering to write it, so I may be
biased... 8-)
John