[Inform] Map creation utility

5 views
Skip to first unread message

Brian Payne

unread,
Dec 7, 2001, 5:46:31 PM12/7/01
to

Hi. :)

I'm new to the I-F scene, not counting my Zork infatuation back in the 80's
(actually, I thought IF -- or text adventures, as I thought of them -- were
dead!). I've been poking around, lurking quite a bit, and mostly sticking
to myself while I plotted and played around with Inform, for several months
now.

And now, I'm realizing that I'm particularly poor at writing games. :) But,
I enjoy creating *tools*.

What I'm wondering is, would anyone -- once I get it rolling, of course --
be willing to betatest an Inform map creation utility?

What it boils down to is, I got REALLY frustrated while working with Inform
and map/room creation. It's actually pretty simple, but it's also somewhat
tedious, and I'm very bad at mentally picturing how a map is laid out.

Looking at it, I don't see *too* much difficulty (I know, I know, FLW) in
creating a visual map that generated Inform code -- JUST for room
definitions, and so on. For me, at least, it'd be VERY useful, since I
could then forget the tedium associated with many of the rooms in a typical
map and just let the util generate the code for them.

Note that I'm not talking complex code, or anything -- you'd still have to
work with some things manually to get the right effect out of your game --
but I'm thinking that anything that takes you from the concept stage to the
testing/improving stage faster is worthwhile.

Quick caveat: once I get the time, I'm intending to develop this in C
(likely using DJGPP, but that's not a guarantee) so it'll be portable.
During the prototyping phase, though, I'll be using Visual Basic (ugh!), so
you'll need either a Windows system or an emulator if you want to test (WINE
will likely work, for example).

(Actually, there's more to it than that, but I don't want to bore people.
If you want to know more, just email me [or post, I suppose] and I'll
happily discuss it. :)

So... anyone interested?

Brian Payne
sofaspud at sofaspud dot org


M. D. Krauss

unread,
Dec 7, 2001, 7:22:04 PM12/7/01
to
I'm more than happy to do some beta testing on Linux / WINE. Just let me
know when your ready.

Your intended approach is just what GUI dev. tools are good for -- filling
out the boring tedious bits so you can get to the real coding :)

But are you sure you want to use VB? What on earth for? I mean, even
initially; I don't consider VB particularly good for prototyping. Why not
try Python or something?

-M


--
To email me convert my address to something resembling reason

Robotboy8

unread,
Dec 7, 2001, 9:28:04 PM12/7/01
to
I think their is at least one out on the Archive, but my experiences with it
were, if I remember correctly, not so great... Love the idea, though. I
always hate coding something large (like a house) and trying to remember if the
living room leads east to the porch or the kitchen or whatever. If the target
isn't Windoze users, though, I would reccommend a program for Gnome called
GLADE. It works sort of like VB but generates C/C++ code which _might_ be
ported to Windoze. I say might because it may well rely on gtk+. I'm not
sure, it's been several months since I last used it.

--
Sanity is a sure sign of a lazy mind.

T Raymond

unread,
Dec 8, 2001, 12:31:37 AM12/8/01
to
Brian Payne was overheard typing about:

>
> Hi. :)

Welcome!

> What I'm wondering is, would anyone -- once I get it rolling, of
> course -- be willing to betatest an Inform map creation utility?

Why would it be specific to Inform? Something like this should be
reasonably portable to be usable by any interested IF developers.



> What it boils down to is, I got REALLY frustrated while working
> with Inform and map/room creation. It's actually pretty simple,
> but it's also somewhat tedious, and I'm very bad at mentally
> picturing how a map is laid out.

Graph paper does wonders! ;)



> Looking at it, I don't see *too* much difficulty (I know, I know,
> FLW) in creating a visual map that generated Inform code -- JUST
> for room definitions, and so on. For me, at least, it'd be VERY
> useful, since I could then forget the tedium associated with many
> of the rooms in a typical map and just let the util generate the
> code for them.

I guess you can ignore my question above. Mentioning code generation
answers that. I was hoping for a graphical map design similar to
Informapper, but more updated. *one of thes days*

Tom
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond af956 AT osfnDOTorg
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Scott Forbes

unread,
Dec 8, 2001, 5:53:25 AM12/8/01
to
In article <10077650...@sidehack.sat.gweep.net>,
"Brian Payne" <sofa...@sofaspud.org> wrote:

> Looking at it, I don't see *too* much difficulty (I know, I know, FLW) in
> creating a visual map that generated Inform code -- JUST for room
> definitions, and so on. For me, at least, it'd be VERY useful, since I
> could then forget the tedium associated with many of the rooms in a typical
> map and just let the util generate the code for them.

I've written a utility that does something similar to this (Yonk 1.0b1
for the Macintosh), but it displays the map one room at a time -- in the
Map Viewer there's a button for each direction, allowing you to explore
the game's map, and in the Object Editor the direction buttons have
pop-up menus which allow you to assign exits.

I found it difficult to code a full-screen display of a game's map,
though. Building a map for anything other than a simple grid becomes
challenging; you have to deal with compass directions like "up" and "in"
(or, in the worst case, "left" or "starboard" or whatever fever dream
the author came up with to replace the library directions), and trying
to display the "maze of twisty little passages" in ADVENT will tie a
knot in your screen.

There's also the case where the author writes an Inform subroutine for
an exit, which Yonk handles by simply displaying the subroutine; a
full-fledged mapping program would have to interpret the code somehow
(and would possibly require an AI smart enough to play the game).

You didn't say what platform you were writing on, but if you're using
Windows you may want to see whether IF-IDE or Inform Explorer helps any;
looking at their web pages I'm not sure whether they have the features
you're looking for -- but hey, at least they *have* web pages, which is
more than I can say for Yonk at the moment. :-)

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

Adam Biltcliffe

unread,
Dec 9, 2001, 2:42:40 PM12/9/01
to
The petroleum revolution is coming to an end! Over to our correspondent
Robotboy8:

> If the target
> isn't Windoze users, though, I would reccommend a program for Gnome called
> GLADE. It works sort of like VB but generates C/C++ code which _might_ be
> ported to Windoze. I say might because it may well rely on gtk+. I'm not
> sure, it's been several months since I last used it.

I don't know anything about GLADE, but it's maybe worth mentioning that
a program requiring gtk+ does not necessarily preclude its being ported
to Windows.


jw

Brian Payne

unread,
Dec 9, 2001, 7:10:20 PM12/9/01
to

"T Raymond" <ar...@see.the.sig> wrote in message
news:Xns9171892A...@209.25.157.130...

> Why would it be specific to Inform? Something like this should be
> reasonably portable to be usable by any interested IF developers.

Well, that's the intended goal, eventually. What I'm designing is a
sort of two-stage approach: the GUI mapper and a 'compiler', if you will,
that generates code for platform X. Since Inform is the only one I feel
comfortable with right now, that's what I'm aiming at. However, there
(technically) should be no difficulty in creating a module that generates,
say, TADS code, instead. Or, for that matter, AGT, HUGO, etc etc etc.

>
> I guess you can ignore my question above. Mentioning code generation
> answers that. I was hoping for a graphical map design similar to
> Informapper, but more updated. *one of thes days*

Informapper? *web scrounge*

Oh. Well, whaddya know. Someone's already gone and done something
similar to what I'm envisioning.

The idea behind what I'm doing *is*, in fact, graphical map design.
First beta will likely *not* include such concepts as, say, doors or one-way
passages, but the idea is that eventually I'll get it to the point where the
only things it won't recognize are designer-coded events and such... which
it'll just ignore. :)

Brian Payne

unread,
Dec 9, 2001, 7:18:17 PM12/9/01
to

"M. D. Krauss" <MDKraus...@home-nospam.com-nospam> wrote in message
news:20011207192204.48ca...@home-nospam.com-nospam...

> I'm more than happy to do some beta testing on Linux / WINE. Just let me
> know when your ready.
>
> Your intended approach is just what GUI dev. tools are good for -- filling
> out the boring tedious bits so you can get to the real coding :)

Exactly!

>
> But are you sure you want to use VB? What on earth for? I mean, even
> initially; I don't consider VB particularly good for prototyping. Why not
> try Python or something?

Hmm... well, the most obvious reason is that I don't know Python. :)

What it all boils down to is, I use Windoze pretty much exclusively,
since my Linux box gave up the ghost quite a while back, and it's easiest
for me to develop in something that I'm already set up for. Besides, the
actual GUI portion is (so far) pretty simple; porting it to C won't be
difficult at all, and that's the intended goal.

Thanks for offering to beta, btw; I really appreciate that. :)

T Raymond

unread,
Dec 9, 2001, 11:57:50 PM12/9/01
to
Brian Payne was overheard typing about:

[I said]


>> I guess you can ignore my question above. Mentioning code
>> generation answers that. I was hoping for a graphical map design
>> similar to Informapper, but more updated. *one of thes days*
>
> Informapper? *web scrounge*
>
> Oh. Well, whaddya know. Someone's already gone and done
> something
> similar to what I'm envisioning.
>
> The idea behind what I'm doing *is*, in fact, graphical map
> design.

Ok, I'll hold out some hope. i'd love to see something similar to
informapper, with the ability to input different shaped rooms. That's
something that I miss from it when I use it for map designing. That
and linking to another map layer from within the editor.

Just a couple of suggestions if you happen to want them. Hmm good
reminder, I need to upload the version of Informapper I've got with
english menus.

Plugh!

unread,
Dec 10, 2001, 8:09:27 AM12/10/01
to
Good luck to you Byan, you'll need it (and time, patience &
perseverance).

Many, many, many have set off down the road upon which you are about
to take your first step. Very, very, very few have reached their
destination.

I will at this point disclose an interest and say that I am invloved
in developing a tool with a little more scope for TADS - see
http://plugh.cjb.net

You might first want to see what is already available in the way of
mapping tools at http://www.ifarchive.org/indexes/if-archiveXmapping-tools.html

As a professional sowftware developer, I can assure you that the #1
most important aspect of any software development project is
specifying it. Believe me, you will make your life a *lot* easier if
you first decide exacly what you want to implement, rather than
beginning coding and deciding 1/2 way through that you'd like to
handle the rooms contents too (item, actors & scenery).

So, do yourself a big favo(u)r and ask your potential users what sort
of a tool they would like to see. My biggest nightmare is that I go
away & hack code for a year, announce the result to r.a.i.f and
discover that everyone wants it to work differently. Canvas users up
front, write a design specification, then (finally) start coding.

Are you going to have a fixed grid? Will North always go up the screen
& south downwards? How would that handle Colossal Cave, where you can
go North from A to B and return by going North?

Someone else in this thread rightly mentioned directions like in/out.
What about ssw, etc? or magic words which move you from one room to
the next?

I decided that I would have to offer totally flexibility otherwise
there would be bound to be some unsatisfied customers. D/L my current
work in progress & see how I handled it. But you *must* have this sort
of thing decided *before* you write your first line of code.
Otherwsise, it will all end in tears.A good idea would be to post the
design here for critique & feedback.

If you decide to do more than just the map, there was a promising
project called Visual Inform, which I think may no longer be in
development - see http://www.iflibrary.org/VInform/ - perhaps you
could take over the reins of that?

Now, as to programming langauge ... you want something with gui GUI
capabilities and preferably something cross platform (although a
windoze solution, used with Wine would help Linux users, but not Mac
users). Java sounds the obvious solution, if you don't think that it
would run too slowly. I believe that Borland do a good free Java IDE.

Personally, I use Borland's C++ Builder. If you don't like C++, but
feel that you could handle Pascal, then Borland's Delphi for Windows
would be perfect and they give away a free version, named Kylix, for
Linux. Code written for one should pretty much run unchanged on the
other (I'm awaiting the release of the Linux C++ IDE).

Although my project is for TADS, I would be more than happy to point
out potential pitfalls, share design tips, etc

But, first, ask your self if you really have the time & energy to
devote to such a thankless project.

Brian Payne

unread,
Dec 10, 2001, 12:22:34 PM12/10/01
to

"Plugh!" <pl...@subdimension.com> wrote in message
news:98ef019f.0112...@posting.google.com...

> As a professional sowftware developer, I can assure you that the #1
> most important aspect of any software development project is
> specifying it. Believe me, you will make your life a *lot* easier if
> you first decide exacly what you want to implement, rather than
> beginning coding and deciding 1/2 way through that you'd like to
> handle the rooms contents too (item, actors & scenery).

As a professional software developer myself, I completely and utterly
agree with you. :) I have been down the unspecified road far too many times
to want to set foot on it again, especially for something that will likely
draw more fire than praise. :)

>
> So, do yourself a big favo(u)r and ask your potential users what sort
> of a tool they would like to see. My biggest nightmare is that I go
> away & hack code for a year, announce the result to r.a.i.f and
> discover that everyone wants it to work differently. Canvas users up
> front, write a design specification, then (finally) start coding.
>

Well, now that you've mentioned it, what would YOU like to see? I think
what I'll do is post the general design that I've come up with so far, and
let folks tear into it.

And, now that I think about it, I should probably ask for name
suggestions, since I'm drawing a blank on that end.

> Are you going to have a fixed grid? Will North always go up the screen
> & south downwards? How would that handle Colossal Cave, where you can
> go North from A to B and return by going North?

Fixed grid BAD. Ugh, no.

As for North always being up... well, yes. In the case of Colossal
Cave, though, you'd see something like this (pardon my horrible ASCII art):

+--------------------+
| |
| |
A B


or (more complex):

+-----+ +-----+
| \ / |
A x B <-- lines do not join at the x
| / \ |
+-----+ +-----+


You see? In either case, North from A takes you to B, and North from B
takes you to A. The only difference is the, ah, entry vector. :) Which,
unless there's a door involved, doesn't matter, really.

>
> Someone else in this thread rightly mentioned directions like in/out.
> What about ssw, etc? or magic words which move you from one room to
> the next?

For the first beta, at any rate, stuff like that would be undefined by
the GUI mapper. Simply put, this is intended as a tool to help you get to
the enhancement stage faster -- ie, to let you breeze through the
generalized map layout and room creation, and THEN go back (by hand) and add
in the niftiness.

>
> I decided that I would have to offer totally flexibility otherwise
> there would be bound to be some unsatisfied customers. D/L my current
> work in progress & see how I handled it. But you *must* have this sort
> of thing decided *before* you write your first line of code.
> Otherwsise, it will all end in tears.A good idea would be to post the
> design here for critique & feedback.

Good call. I'm still working on the initial spec, and testing my
concept of graphics routines (if I'm going to make this portable, I can't
rely on, say, Windows event calls to determine when the user has moved the
pointer over a room, for example), but I'll post a 'features list' for
everyone to review in the near future -- later today, maybe (depends on my
work schedule).

>
> If you decide to do more than just the map, there was a promising
> project called Visual Inform, which I think may no longer be in
> development - see http://www.iflibrary.org/VInform/ - perhaps you
> could take over the reins of that?

I looked at it, but it's a bit beyond the scope of something that I'd
have time for as a hobby project. Besides which, I always find it harder to
take over someone else's project (even assuming that they'd let me) than to
build my own.

If it turns out that I do have time later on, though, and Visual Inform
is still under development, I may offer my services as a UI designer.
That's what I specialise in during my day job, and what I enjoy the most.

>
> Now, as to programming langauge ... you want something with gui GUI
> capabilities and preferably something cross platform (although a
> windoze solution, used with Wine would help Linux users, but not Mac
> users). Java sounds the obvious solution, if you don't think that it
> would run too slowly. I believe that Borland do a good free Java IDE.

I'd be better able to debate this is if I knew more about Java; however,
from my experience (admittedly, not much), Java wouldn't be too slow, but
it'd incur a much longer development cycle.

However, I *will* be releasing the source once I've gotten something put
together to release ;), and if anyone wants to port it to Java, they're more
than welcome to -- I'll even help, as much as I can. :)

>
> Personally, I use Borland's C++ Builder. If you don't like C++, but
> feel that you could handle Pascal, then Borland's Delphi for Windows
> would be perfect and they give away a free version, named Kylix, for
> Linux. Code written for one should pretty much run unchanged on the
> other (I'm awaiting the release of the Linux C++ IDE).

I like Borland (always have, since Turbo C 2.0 ;), I use Microsoft at
work, and since I'm just a poor broke lil programmer, I use DJGPP at home.
:)

I've never used Delphi, but it sounds like I may have to check it out.

>
> Although my project is for TADS, I would be more than happy to point
> out potential pitfalls, share design tips, etc
>
> But, first, ask your self if you really have the time & energy to
> devote to such a thankless project.

Quick answer? No, of course not. Who does? But I'm still going to. I
have *fun* doing this sort of thing -- you could, assuming you knew her, ask
my fiancee about it: I've been bouncing off the walls at home the past week
while ironing out the most glaring of the problems I've defined for myself.

Heh. This is *fun*... and fun is something that I can never get enough
of.

Brian Payne

unread,
Dec 10, 2001, 8:18:52 PM12/10/01
to

(Replying to my own post to keep this from annoying TOO many folks. :))

I've drafted up a very loose definition of the map creation utility
discussed in this thread (hereafter named 'IFDesigner', unless someone can
give me a reason not to :), and am including it below.

This is a -draft-, it is not set in stone. Any suggestions, criticisms, and
so on would not only be appreciated, but welcome. If you want a specific
feature, request it -- I may not choose to implement it, but I'll give it
fair consideration.

Finally, unless it's acceptable to the group at large, I'd suggest keeping
this to private email, so I don't get yelled at. :)

Thank you, everyone who replied (publicly and privately). I'll be sending
out a beta just as soon as I can.

The draft document is below my .sig.

Brian Payne
sofaspud at sofaspud dot org

------------------------------------

IFDesigner
A world-creation utility for Interactive Fiction.


There will be two main parts to the entire IFDesigner system. They are the
editor, and the generator.


The Editor:
This is what the user will be working with. It is intended to show a full,
complete, and flexible map of the game 'world', including all rooms, the
pathways between them, and doors (if applicable). By using color and other
indicators, all potential directions from or to a room can be accounted for.
In addition, allowing the user to specify and/or replace directions will
provide for maximum flexibility.

Editor Features:
* create rooms, pathways between them, and doorways with a visual interface

* assign properties to rooms and doorways

* list of properties can be changed by the user

* graphics options include zooming and scrolling of the game map (3D
is -not- supported!), customizable color schemes, and so on

* pathways (represented by lines) can be segmented to allow for unorthodox
movement ("North from A leads to B; North from B leads to A", for example),
or simply for greater clarity

* user-selectable and definable grid system, with the standard
snap-to-grid/free placement options

* multiple generator support


Suggested Features:
* Arbitrary room geometry
- Currently, the editor defines (will define?) rooms as a square, and show
them as such on the map (though you can -describe- it however you like!);
changing this, while certainly do-able, seems hardly necessary, and could
lead to potential confusion. Thoughts?

* Map rotation
- Rotating the map is technically a somewhat trivial matter, since it's
nothing more than a collection of polygons and lines in memory space, but is
it something -needed-, or just wanted?

* Room-within-a-room
- Oh, boy, this could be a hard one. Not to display, or even to edit, but
because the code generation for this may not be possible with some systems.
I know Inform can do it, and I -think- TADS can, but what about HUGO, for
example? Maybe allow this as a selectable option, a la a checkbox in an
options screen, perhaps?

* 3D design (not first-person, just perspective)
- Yikes. Well, could I do it? ... Yeah, I think so. It would certainly
clarify up/down pathways. However, the substantially longer development
time and headache factor makes me want to avoid this one. If enough people
want it -- and I mean REALLY want it, not just "hey, that'd be nifty" but "I
MUST HAVE THIS", then I might look at it for version 2... assuming people
besides myself actually use this beastie. :)

The Generator:
This is the behind-the-scenes part of the system. Here, it will take an
IFDesigner object file generated by the editor and parse through it,
generating code for the target platform that represents what the user
created. Currently, the only platform I'm targeting is Inform, because
that's the one I feel most comfortable with. So there. :) However, the
editor is deliberately designed to be somewhat dense (ie, you can't do much
beyond the basics), so as to make the generator's job easier, and hopefully
more portable.

Generator Features (somewhat Inform-specific):
* two-way: it can not only generate an Inform source file from an
IFDesigner map, it can parse through an Inform source file and generate a
basic IFDesigner map from it. Only those things that the editor understands
will be included, but nothing will be lost (if there's a conflict, it's the
editors job to warn the user).

* customizable indentation: you can define how you want your code indented
(ie, K&R, ANSI, 3-space, whatever)

* meta-code: included in the generator output is notation to itself about
the map layout and other such niceties, safely tucked away behind comment
symbols where Inform won't care about it. If they're removed or changed,
the generator won't care; they're just to make it's job easier should it
have to re-create the IFDesigner file from Inform source.


Where It All Comes Together:
The idea is that the editor (from whatever platform -- Windows, Mac, Linux,
etc) produces a file that any generator can read, and the generator can then
create code for whatever platform (Inform, TADS, etc) that it's targeted at.
In addition, this should be invisible to the user -- when they say, "Create
it" (through a button, a hot-key, whatever), all the app will do is ask
"Where do you want me to put it?"


Comments, suggestions, and everything else can be directed to me at
sofa...@sofaspud.org

------------------------------

Arcum Dagsson

unread,
Dec 11, 2001, 2:01:03 AM12/11/01
to
In article <10080334...@sidehack.sat.gweep.net>,
"Brian Payne" <sofa...@sofaspud.org> wrote:

> (Replying to my own post to keep this from annoying TOO many folks. :))
>
> I've drafted up a very loose definition of the map creation utility
> discussed in this thread (hereafter named 'IFDesigner', unless someone can
> give me a reason not to :), and am including it below.
>
> This is a -draft-, it is not set in stone. Any suggestions, criticisms, and
> so on would not only be appreciated, but welcome. If you want a specific
> feature, request it -- I may not choose to implement it, but I'll give it
> fair consideration.
>
> Finally, unless it's acceptable to the group at large, I'd suggest keeping
> this to private email, so I don't get yelled at. :)
>

That shouldn't be a problem. This is very much on topic...

I've got a few suggestions, mainly on things to implement to make things more
customizable, and things to wait on...

>
> IFDesigner
> A world-creation utility for Interactive Fiction.
>
>
> There will be two main parts to the entire IFDesigner system. They are the
> editor, and the generator.
>
>
> The Editor:
> This is what the user will be working with. It is intended to show a full,
> complete, and flexible map of the game 'world', including all rooms, the
> pathways between them, and doors (if applicable). By using color and other
> indicators, all potential directions from or to a room can be accounted for.

Sounds good.

> In addition, allowing the user to specify and/or replace directions will
> provide for maximum flexibility.
>

I'd wait till you've got the base of the editor working before adding this. It'd
be nifty afterwards, though.

> Editor Features:
> * create rooms, pathways between them, and doorways with a visual interface
>
> * assign properties to rooms and doorways
>
> * list of properties can be changed by the user
>
> * graphics options include zooming and scrolling of the game map (3D
> is -not- supported!), customizable color schemes, and so on
>

I'd save some of the customizability till later, while designing it so it can be
expanded in that direction after the main coding is done.

> * pathways (represented by lines) can be segmented to allow for unorthodox
> movement ("North from A leads to B; North from B leads to A", for example),
> or simply for greater clarity
>
> * user-selectable and definable grid system, with the standard
> snap-to-grid/free placement options
>
> * multiple generator support
>
>

Don't forget room descriptions. You could probably just have another window that
shows you the description of the currently selected room and lets you edit it.

Also, while you probably won't want it in the first couple versions, I'd leave
room to add objects with properties and descriptions to the rooms, to allow you
to build a full skeleton of the game.

Oh, and aside from game-specific properties, you'll probably want the lists of
properties to be in sets, corresponding to the different languages the generator
writes code for.

Also, how about provisions for "magic words" that move you elsewhere (xyzzy, for
example). And keep stairs in mind.

> Suggested Features:
> * Arbitrary room geometry
> - Currently, the editor defines (will define?) rooms as a square, and show
> them as such on the map (though you can -describe- it however you like!);
> changing this, while certainly do-able, seems hardly necessary, and could
> lead to potential confusion. Thoughts?
>

A rectangle should be fine, provided you can change the sizes.



> * Map rotation
> - Rotating the map is technically a somewhat trivial matter, since it's
> nothing more than a collection of polygons and lines in memory space, but is
> it something -needed-, or just wanted?
>

I'd put it aside till the bulk of the other features are added. (I'm saying this
a lot, aren't I? It's still a good idea, though)



> * Room-within-a-room
> - Oh, boy, this could be a hard one. Not to display, or even to edit, but
> because the code generation for this may not be possible with some systems.
> I know Inform can do it, and I -think- TADS can, but what about HUGO, for
> example? Maybe allow this as a selectable option, a la a checkbox in an
> options screen, perhaps?
>

Maybe later.



> * 3D design (not first-person, just perspective)
> - Yikes. Well, could I do it? ... Yeah, I think so. It would certainly
> clarify up/down pathways. However, the substantially longer development
> time and headache factor makes me want to avoid this one. If enough people
> want it -- and I mean REALLY want it, not just "hey, that'd be nifty" but "I
> MUST HAVE THIS", then I might look at it for version 2... assuming people
> besides myself actually use this beastie. :)
>

I'd suggest coding support for multiple layers in the editor, then only
displaying one layer in the window, but having clicking on a up or down stairs
icon on the room go to the appropriate layer (as might, say, a popup menu).
Mind, I would wait till version two, and have some of the other things I
mentioned waiting on be version three or four...

>
>
> The Generator:
> This is the behind-the-scenes part of the system. Here, it will take an
> IFDesigner object file generated by the editor and parse through it,
> generating code for the target platform that represents what the user
> created. Currently, the only platform I'm targeting is Inform, because
> that's the one I feel most comfortable with. So there. :) However, the
> editor is deliberately designed to be somewhat dense (ie, you can't do much
> beyond the basics), so as to make the generator's job easier, and hopefully
> more portable.
>

My main suggestion here: use XML for the IFDesigner object file format! This
would allow the generated file to be easily human-readable, and would probably
simplify adding more features to the file format later, and translating it to
various languages. It also allows you to easily test the generator code without
having the editor totally working properly yet...

> Generator Features (somewhat Inform-specific):
> * two-way: it can not only generate an Inform source file from an
> IFDesigner map, it can parse through an Inform source file and generate a
> basic IFDesigner map from it. Only those things that the editor understands
> will be included, but nothing will be lost (if there's a conflict, it's the
> editors job to warn the user).
>

Sounds tricky. Start with IFDesigner -> Inform, and add the reverse later, as a
seperate add-on. Turning a transcript into a map file is difficult enough (and
should also be on the "might be nice - someday" list).

> * customizable indentation: you can define how you want your code indented
> (ie, K&R, ANSI, 3-space, whatever)
>

Should be easy enough. If you code the generator right, you could have it read
some sort of language template in, then substitute in all the right bits from
the IFDesigner file, and then it'd simply be a matter of choosing the template
with the formatting you want.



> * meta-code: included in the generator output is notation to itself about
> the map layout and other such niceties, safely tucked away behind comment
> symbols where Inform won't care about it. If they're removed or changed,
> the generator won't care; they're just to make it's job easier should it
> have to re-create the IFDesigner file from Inform source.
>

Soulds good. Set a bit in the template to add all the bits of XML that don't
pertain to the code generation in comments, and make sure you put some sort of
flag that the generator could pick up later, but Inform will ignore.

>
> Where It All Comes Together:
> The idea is that the editor (from whatever platform -- Windows, Mac, Linux,
> etc) produces a file that any generator can read, and the generator can then
> create code for whatever platform (Inform, TADS, etc) that it's targeted at.
> In addition, this should be invisible to the user -- when they say, "Create
> it" (through a button, a hot-key, whatever), all the app will do is ask
> "Where do you want me to put it?"
>

Sounds good. If I seem to have a bunch of ideas on this subject, it's partially
because I'd thought in the past how useful a editor/generator approach would be,
and that XML would make for a rather clear markup language for sketching out the
basics of a text adventure map and objects, and then converting it to the
language of your choice. It'd simplify a lot of the broad design work involved
the the game, and allow you to pay attention to all the details and fiddly bits.

The only trouble is you might see a rash of games that have minimal programming
beyond the generated bits. It's worth it, though.

--
--Arcum Dagsson
"Pink valleys, hermaphrodite tables, these were all natural stages through which
one had to pass on the path to true enlightenment..."

Plugh!

unread,
Dec 11, 2001, 3:15:10 AM12/11/01
to
"Brian Payne" <sofa...@sofaspud.org> wrote in message news:<10080048...@sidehack.sat.gweep.net>...

> "Plugh!" <pl...@subdimension.com> wrote in message
> news:98ef019f.0112...@posting.google.com...
>
> > As a professional sowftware developer, I can assure you that the #1
> > most important aspect of any software development project is
> > specifying it.
[snip]

> As a professional software developer myself, I completely and utterly
> agree with you. :) I have been down the unspecified road far too many times
> to want to set foot on it again, especially for something that will likely
> draw more fire than praise. :)

Aaah! a kinred spirit; a soul brother; a fellow idiot.

Sorry for statin' the bleedin' obvious, but whilst I am impeccably
professional by day, I tend to jump right in & hack code by night (and
most non-pros don't even know about the concept of design).

It's not helped any by RAD tools like VB, Delphi, etc where you can
knock up a quick GUI, just to mull over some ideas and then find that
that becomes your 'design'.

> > So, do yourself a big favo(u)r and ask your potential users what sort
> > of a tool they would like to see.

[snip]

> Well, now that you've mentioned it, what would YOU like to see?

I'd like to see my bloody tool finished, that's what (see
http://plugh.cjb.net )! And then maybe I'd have a life again.

I have had several raif threads regarding design, the first & longest
of which is at http://groups.google.com/groups?hl=en&threadm=8642gh%24qaq%241%40nnrp1.deja.com&rnum=59&prev=/groups%3Fq%3Dplugh%26start%3D50%26hl%3Den%26rnum%3D59%26selm%3D8642gh%2524qaq%25241%2540nnrp1.deja.com

see also
http://groups.google.com/groups?hl=en&threadm=867n51%24hec%241%40nnrp1.deja.com&rnum=95&prev=/groups%3Fq%3Dplugh%26start%3D90%26hl%3Den%26rnum%3D95%26selm%3D867n51%2524hec%25241%2540nnrp1.deja.com

and just generally search raif for "plugh". Most of what was said to
me will be equally valid for you, I am sure.

My advice is to gather as much input/feedback as possible before
writing a lick o' code. Boil it down, itemize it, propritize it &
offer that back to the community for feedback, then dive in.

> I think
> what I'll do is post the general design that I've come up with so far, and
> let folks tear into it.

By far the best way to do it.

> And, now that I think about it, I should probably ask for name
> suggestions, since I'm drawing a blank on that end.

Yeah, tough one, ins't it. I want something as nihilisticly simplistic
as TWAIN (tool without an interesting name), but I'm stuck with Plugh,
since no-one else offered any suggestions.

Why not call it Brian? or Harold?

Btw, when you have fixed on a name, post with titles beggining with it
in [] e.g "[NANCY] some obscure twiddly point of interest only to the
developer", then others can filter it out or likewise ignore it. This
was pointed out to me when I first posted.


> > Are you going to have a fixed grid?

[snip]


> Fixed grid BAD. Ugh, no.

Great decision. Now, I haven't yet seen you say that the user will be
allowed to think "hmm, you know, I think the torture room would look
better over by the milk bar" and drag the room to a new location (you
did think of that, didn't you?). And, when he does, your connecting
lines will have to redraw themselves (if you use any Borland product
to develop, I have a nice freeware VCL line which will do that).

Did it occur that some folks like to draw multiple maps (think 'pieces
of paper')? Bet it didn't ;-) how're you gonna do that then?? Don't
ask me, I know I can code it, but no-one yet specified how it should
look in my GUI. I'd advise you, though, to make your project MDI from
the start.

> As for North always being up... well, yes. In the case of Colossal
> Cave, though, you'd see something like this (pardon my horrible ASCII art):
>
> +--------------------+
> | |
> | |
> A B
>
>
> or (more complex):
>
> +-----+ +-----+
> | \ / |
> A x B <-- lines do not join at the x
> | / \ |
> +-----+ +-----+
>
>
> You see? In either case, North from A takes you to B, and North from B
> takes you to A. The only difference is the, ah, entry vector. :) Which,
> unless there's a door involved, doesn't matter, really.

Hmm, I'll reserve judgemement until I see a screen shot on your web
page (you do have a web page for the project, don't you? I mean, you
do want us to to take you seriously? ;-)

Also, when someone, inevitably, snarks that you are wasting bandwidth
on raif, you might have to go to a private mailing list (although this
will cut off much potential feedback). I would suggest that you trawl
for suggestions, then [ANNOUNCE] a preliminary version & get more
feedback from that, etc, etc

> > Someone else in this thread rightly mentioned directions like in/out.
> > What about ssw, etc? or magic words which move you from one room to
> > the next?
>
> For the first beta, at any rate, stuff like that would be undefined by
> the GUI mapper. Simply put, this is intended as a tool to help you get to
> the enhancement stage faster -- ie, to let you breeze through the
> generalized map layout and room creation, and THEN go back (by hand) and add
> in the niftiness.

Believe me, you *are* going to have to handle them, or your tool will
be of no use to hard core i-f developers & they will tell you so in no
uncertain terms (I still have the ego-bruises ;-). Again, I wish that
I had practised in the evening what I preach throughout the day and
considered the features of v3.0 when designing v0.01.

> > If you decide to do more than just the map, there was a promising
> > project called Visual Inform, which I think may no longer be in
> > development - see http://www.iflibrary.org/VInform/ - perhaps you
> > could take over the reins of that?
>
> I looked at it, but it's a bit beyond the scope of something that I'd
> have time for as a hobby project.

Depends how long you want to spend. I wanted something that was going
to keep me away from TV & various Sid Meiers games for more than just
a month or two.

> Besides which, I always find it harder to
> take over someone else's project (even assuming that they'd let me) than to
> build my own.

Damn right there!

> If it turns out that I do have time later on, though, and Visual Inform
> is still under development, I may offer my services as a UI designer.
> That's what I specialise in during my day job, and what I enjoy the most.

Aha! so that's why you want to do a mapper only (more on which later).

> > Now, as to programming langauge ... you want something with gui GUI
> > capabilities and preferably something cross platform

[snip]


> I'd be better able to debate this is if I knew more about Java; however,
> from my experience (admittedly, not much), Java wouldn't be too slow, but
> it'd incur a much longer development cycle.

And add a new skill to your CV? what do you code professionally?

> I like Borland (always have, since Turbo C 2.0 ;), I use Microsoft at
> work, and since I'm just a poor broke lil programmer, I use DJGPP at home.
> :)

I often use MSVC (what on earth does the V stand for?) at work, but I
buy Borland products for my own use.

> I've never used Delphi, but it sounds like I may have to check it out.

Highly recommended. Since you know VB, you'll be impressed with it.
Ditto the C++ Version. As I stated earlier, the Linux version is free
& there's a 60 day demo version of Delphi avalable for download (which
you wouldn't be so unscrupulous as to crack, would you?). You can
generally pick up a copy cheaply on eBay, or buy a student discount
version, or some magazines give away the previous full version free on
the cover CD in the hope that you'll upgrade.

> > But, first, ask your self if you really have the time & energy to
> > devote to such a thankless project.
>

[snip]


> Heh. This is *fun*... and fun is something that I can never get enough
> of.

belive me, Brian, it's fun when you're at the "kicking about ideas"
stage. Not so much as the interest begins to wane & the mailing list
dries up & you're on your own in your lonely garret wishing you'd
designed the fundementals better so that you can add just one more
feature which is minimal to the user, but maximal in terms of coding
required.

More in your next post ...

Plugh!

unread,
Dec 11, 2001, 8:02:36 AM12/11/01
to
"Brian Payne" <sofa...@sofaspud.org> wrote in message news:<10080334...@sidehack.sat.gweep.net>...

> (Replying to my own post to keep this from annoying TOO many folks. :))
The best way to get an intelligent response.

Well, I wrote a long reply, then went to a meeting & came back to find
out that Google had timed me out & I lost it, so here's a summarized
highlight...

> I've drafted up a very loose definition of the map creation utility
> discussed in this thread (hereafter named 'IFDesigner', unless someone can
> give me a reason not to :),

- because Micro$oft still wants us to stick to 8.3 names?
- because Nancy is a better name, if you can only think of an acronym?
- because it clashes with the InternetForms Designer
www.iwayforms.com/dutch/products/ifdesigner.htm ? or apparently
clashed with something in the oscilloscope world
...SchoolofMedicine,UniversityofWashington,PrivateCommunication,1976Mini-Circuits,"RF/IFDesigner'sGuideandHandbook",Mini-Circuits,Brooklyn,1997
Neukomm,PA ?? !


Well, when the name is finalized, you'll be able to post to raif with
[NANCY] or whatever and get replies from non-Inform(ed) folk.

> This is a -draft-, it is not set in stone.

You'd better believe that. Two weeks from now, the design's own mother
(you) won't recognize it.

> Any suggestions, criticisms, and
> so on would not only be appreciated, but welcome. If you want a specific
> feature, request it -- I may not choose to implement it, but I'll give it
> fair consideration.

I'd advise you not to bin anything. Keep it all in a big list & just
give some stuff low priority, that way you don't lose anything (you
never know when you'll need it).

> Finally, unless it's acceptable to the group at large, I'd suggest keeping
> this to private email, so I don't get yelled at. :)

I advise against pr1vate 1 on 1 mails with you. Much better is to keep
it here, on this thread, or on raif until you do get shouted at, or to
start a mailing list. The point is to let all interested parties see
all comments and that way you will reach a concensus much more
quickly.

[snip]

> The Editor:
> This is what the user will be working with. It is intended to show a full,
> complete, and flexible map of the game 'world', including all rooms, the
> pathways between them, and doors (if applicable). By using color and other
> indicators, all potential directions from or to a room can be accounted for.

but not in the first version, eh ?

What about directions like ssw, magic words, user provided code,
random number generator - if the user is to eschew scrpas of paper &
use only your tool, he'll want to see such things marked on the map;
even if you don't generate any code for them.

I also think you'll find that users will insist on seeing the
locations of NCPs, treasures & other items. I have allowed the user to
select properties to be colo(u)r coded on the map, so that he can see
at a glance which rooms contain NCPs/treasure/puzzles/darkness/etc

> In addition, allowing the user to specify and/or replace directions will
> provide for maximum flexibility.
>
> Editor Features:
> * create rooms, pathways between them, and doorways with a visual interface

And NCPs & objects? believe me, they'll want 'em.

> * assign properties to rooms and doorways
>
> * list of properties can be changed by the user

So that he can add/rename/remove/copy, but only those which he
defined, not the built in ones. In TADS this became difficult. If I'm
looking at something, say a room, of class F, which derived from
classes D & E, where D derives from B and and C derives from A and the
user deletes one of those intervening classes, I have to consider the
effect on all derived classes (e.g remove the inflatable property from
Class A, does it affect objects of Class F?).

Better get this nailed down up front, it's not easy to shoehorn in
later.

> * graphics options include zooming and scrolling of the game map (3D
> is -not- supported!), customizable color schemes, and so on

good.

> * pathways (represented by lines) can be segmented to allow for unorthodox
> movement ("North from A leads to B; North from B leads to A", for example),
> or simply for greater clarity

good.

> * user-selectable and definable grid system, with the standard
> snap-to-grid/free placement options

I didn't bother with a grid (yet). Free form is so much simpler & you
can argue that it's a power user feature ;-)

> * multiple generator support
May well have to be dropped after you realize the enormity of what
you're letting yourself in for, with only Inform ;-)


>
> Suggested Features:
> * Arbitrary room geometry
> - Currently, the editor defines (will define?) rooms as a square, and show
> them as such on the map (though you can -describe- it however you like!);
> changing this, while certainly do-able, seems hardly necessary, and could
> lead to potential confusion. Thoughts?

Very, very, very low priority. However, I am still waiting for users
to tell me how multiple maps (say multiple floors of a building)
should operate, but I can envision using circles to represent rooms
with a link to another map.

> * Map rotation
> - Rotating the map is technically a somewhat trivial matter, since it's
> nothing more than a collection of polygons and lines in memory space, but is
> it something -needed-, or just wanted?

probably neither. It does, however, imply that you are drawing your
GUI pixel by pixel. If you used VB, surely you'd use a Panel to
represent each room? That wouldn't rotate so easilly.

> * Room-within-a-room
> - Oh, boy, this could be a hard one. Not to display, or even to edit, but
> because the code generation for this may not be possible with some systems.
> I know Inform can do it, and I -think- TADS can, but what about HUGO, for
> example? Maybe allow this as a selectable option, a la a checkbox in an
> options screen, perhaps?

Sorry, gotta be done, or no-one will take you seriously. I pushed it
to a later version & have only just completed it. I regret not having
it planned in from the start.

Consider special rooms. In TADS, a vehicle is a room (and I can carry
my bicycle around with me, when not riding it).

Think of a doll's house, or small cage which is a room which I can
order an NCP to enter & perform some action. It can be located inside
an object, like a desk, or even in the pouch of an NCP kangaroo (which
teh player has in inverntory at the star of the game).

This can get hairy.

> * 3D design (not first-person, just perspective)
> - Yikes. Well, could I do it? ... Yeah, I think so. It would certainly
> clarify up/down pathways. However, the substantially longer development
> time and headache factor makes me want to avoid this one. If enough people
> want it -- and I mean REALLY want it, not just "hey, that'd be nifty" but "I
> MUST HAVE THIS", then I might look at it for version 2... assuming people
> besides myself actually use this beastie. :)
hey, that'd be nifty


> The Generator:
> This is the behind-the-scenes part of the system. Here, it will take an
> IFDesigner object file generated by the editor and parse through it,
> generating code for the target platform that represents what the user
> created. Currently, the only platform I'm targeting is Inform, because
> that's the one I feel most comfortable with. So there. :) However, the
> editor is deliberately designed to be somewhat dense (ie, you can't do much
> beyond the basics), so as to make the generator's job easier,

You'll regret that. I wanted to keep everything simple, but feedback
convinced me otherwise. Follow the first 48 post thread of my naive
saga at http://groups.google.com/groups?hl=en&threadm=862k48%246bi%244%40news.ycc.yale.edu&rnum=1&prev=/groups%3Fq%3Dwho%2Bwants%2Ban%2Bif%2Bgui%26hl%3Den%26group%3Drec.arts.int-fiction%26rnum%3D1%26selm%3D862k48%25246bi%25244%2540news.ycc.yale.edu


> Generator Features (somewhat Inform-specific):
> * two-way: it can not only generate an Inform source file from an
> IFDesigner map, it can parse through an Inform source file and generate a
> basic IFDesigner map from it. Only those things that the editor understands
> will be included, but nothing will be lost (if there's a conflict, it's the
> editors job to warn the user).

<can o' worms>

Do you know much about file parsing? I'd recommend Lex/Yacc (of
Flex/Bison) (and only wish I could afford Visual Parse++
http://www.sand-stone.com/).

- what if the user has multiple input files (or uses libraries)?
You'll have to remember which file everything came from.

- even if only a single file, he'll want it reconstituted in the same
order, so you'll have to remember where everything you parse came
from.

- user comments generally belong to the immediately following
declaration - but not always.

That's if you are adding code/comments to his input files. Maybe you
can just generate your stuff in a new file(s).

</can o' worms>


> * customizable indentation: you can define how you want your code indented
> (ie, K&R, ANSI, 3-space, whatever)

nice, but low priority.


> * meta-code: included in the generator output is notation to itself about
> the map layout and other such niceties, safely tucked away behind comment
> symbols where Inform won't care about it. If they're removed or changed,
> the generator won't care; they're just to make it's job easier should it
> have to re-create the IFDesigner file from Inform source.

Implying that you have a different format of project save file (?). I
started with a proprietary binary format, until users bullied me into
an ascii format. So, now I use the windows .INI file format, since
it's easy to read/write.

It's also much easier to make backwards compatible, as you add new
entries for new fucntionality; and to rescue something from if a code
bug is generating invalid files.

> Where It All Comes Together:
> The idea is that the editor (from whatever platform -- Windows, Mac, Linux,

You need to mail down your IDE. If you use Java, you cover everything.
If you use Delphi/Kylix, you cover Windoze & Linus and alienate Mac
users, but don't worry about that - they're used to it.


Hmm, this isn't even a 1/3rd of the length of what I wrote & lost
earleir, but at least it's less cynical. I was trying to get through
to you the enormity of the project we're not the first to try, few
have been very successfull. Maybe you'll get some ideas from reading
that thread or earching for [PLUGH] or groups.google.com

I'm with you all the way & will help as much as I can. Can you tell me
- what IDE/lnaguage you plan to use
- if you intend to support NPC and objects
- whether you will support multiple maps
- where's your web page/mailing list
- save file format
- whether you really intend to parse input files (and what you do when
a room in the input file which you parse has a passage to one in your
project's save file)
- what exactly you inend to display on the map (treasures & puzzles
to)
- etc

I'd advise you not to write a lick o' code until this (and more) is
all nailed down.

You, and everyone else reading this, could do you (and me) a favo(u)r
by visitng http://plugh.cjb.net and looking at my effort and
sugegsting ides for you to 'borrow' and new ideas for me to
incorporate. Thanks.

I look forward to more...

Plugh!

unread,
Dec 11, 2001, 8:36:16 AM12/11/01
to
> > Finally, unless it's acceptable to the group at large, I'd suggest keeping
> > this to private email, so I don't get yelled at. :)
> That shouldn't be a problem. This is very much on topic...
We'll see, ther are some rather snarky folks around here. Still, if we
keep it to one thread, we should be ok.


>
> I've got a few suggestions, mainly on things to implement to make things more
> customizable, and things to wait on...

> I'd wait till you've got the base of the editor working before adding this. It'd
> be nifty afterwards, though.

> I'd save some of the customizability till later, while designing it so it can be
> expanded in that direction after the main coding is done.

> I'd put it aside till the bulk of the other features are added. (I'm saying this

> a lot, aren't I? It's still a good idea, though)

As I said to Brian, it is important that he knows up front what all
desired features are. It is much simpler this way, than to try to add
tehm later. He shoudl collect a big feature list & prioritize it. So,
please post all of your suggestions now, rather than holding back.


> Don't forget room descriptions. You could probably just have another window that
> shows you the description of the currently selected room and lets you edit it.

That wasn't forseen. Are you sugegesting that he generate code? If so,
the user shouldn't be constrained to providing only plain text, but
should also be able to provide code - e.g some rooms have a different
descriprion the first time that you wvisit them than from subsequent
times.

> Also, while you probably won't want it in the first couple versions, I'd leave
> room to add objects with properties and descriptions to the rooms, to allow you
> to build a full skeleton of the game.

He, he, told you so, Brian. Muh ha ha ha!!!

(please visit http://plugh.cjb.net and give me some advice/feedback
too. Maybe I can do the TADS version & Brian the Inform version).


> Oh, and aside from game-specific properties, you'll probably want the lists of
> properties to be in sets, corresponding to the different languages the generator
> writes code for.
>
> Also, how about provisions for "magic words" that move you elsewhere (xyzzy, for
> example). And keep stairs in mind.

"You know. I think we should put some mountains here. Otherwise, what
are all the characters going to fall off of? And what about stairs?
Yodellayheehoo."

[snip]

> I'd suggest coding support for multiple layers in the editor, then only
> displaying one layer in the window, but having clicking on a up or down stairs
> icon on the room go to the appropriate layer (as might, say, a popup menu).

Nice idea. I wonder how practical it is though? I always put ideas to
the Colossal Cave test. Someone will always make a map whose geometry
doesn't quite fit.

> Mind, I would wait till version two, and have some of the other things I
> mentioned waiting on be version three or four...

So long as they're planned & Considered from the start ;-)


> My main suggestion here: use XML for the IFDesigner object file format! This
> would allow the generated file to be easily human-readable, and would probably
> simplify adding more features to the file format later, and translating it to
> various languages. It also allows you to easily test the generator code without
> having the editor totally working properly yet...

Sounds like an idea. Do you have any "teach yourself XML in 24 hours"
URLs? (must look on code monkey)

[snip]

> Sounds good. If I seem to have a bunch of ideas on this subject, it's partially
> because I'd thought in the past how useful a editor/generator approach would be,
> and that XML would make for a rather clear markup language for sketching out the
> basics of a text adventure map and objects, and then converting it to the
> language of your choice. It'd simplify a lot of the broad design work involved
> the the game, and allow you to pay attention to all the details and fiddly bits.
>
> The only trouble is you might see a rash of games that have minimal programming
> beyond the generated bits. It's worth it, though.


Some good sound comments there. I hope you'll give me some too ;-)

Brian Payne

unread,
Dec 11, 2001, 2:26:17 PM12/11/01
to

"Plugh!" <pl...@subdimension.com> wrote in message
news:98ef019f.01121...@posting.google.com...

> "Brian Payne" <sofa...@sofaspud.org> wrote in message
news:<10080334...@sidehack.sat.gweep.net>...

> > I've drafted up a very loose definition of the map creation utility


> > discussed in this thread (hereafter named 'IFDesigner', unless someone
can
> > give me a reason not to :),
> - because Micro$oft still wants us to stick to 8.3 names?

So? :)

> - because Nancy is a better name, if you can only think of an acronym?
> - because it clashes with the InternetForms Designer

This is the only one I'm even remotely worried about. IFBuilder,
perhaps, instead?

> www.iwayforms.com/dutch/products/ifdesigner.htm ? or apparently
> clashed with something in the oscilloscope world

> ...SchoolofMedicine,UniversityofWashington,...

Yup, but I hardly think I'll have to worry about it, since the name
doesn't appear to be trademarked AND it's going to see very limited
distribution (the IF community is probably -it-).


> > Any suggestions, criticisms, and
> > so on would not only be appreciated, but welcome. If you want a
specific
> > feature, request it -- I may not choose to implement it, but I'll give
it
> > fair consideration.
> I'd advise you not to bin anything. Keep it all in a big list & just
> give some stuff low priority, that way you don't lose anything (you
> never know when you'll need it).

Yup. I hang on to everything, I just might not -use- everything. At
least right away. :)

>
> > Finally, unless it's acceptable to the group at large, I'd suggest
keeping
> > this to private email, so I don't get yelled at. :)
> I advise against pr1vate 1 on 1 mails with you. Much better is to keep
> it here, on this thread, or on raif until you do get shouted at, or to
> start a mailing list. The point is to let all interested parties see
> all comments and that way you will reach a concensus much more
> quickly.

Well... yes, that'd be nice. But I don't want to wear out my welcome on
the group, either. I guess we'll see how things go.


> [snip]
>
> > The Editor:
> > This is what the user will be working with. It is intended to show a
full,
> > complete, and flexible map of the game 'world', including all rooms, the
> > pathways between them, and doors (if applicable). By using color and
other
> > indicators, all potential directions from or to a room can be accounted
for.
> but not in the first version, eh ?

Actually, everything listed here is intended for the first version.
I've already developed the logic structures to handle this stuff, with room
for expansion.

>
> What about directions like ssw, magic words, user provided code,
> random number generator - if the user is to eschew scrpas of paper &
> use only your tool, he'll want to see such things marked on the map;
> even if you don't generate any code for them.

I'd like to handle oddball directions; however, it may cause portability
issues. I know you can do it in Inform, by any of several means. What
about TADS? Or any of the other systems?

The way I'm designing the editor is that the generator decides what's
allowed. So if I can make an Inform generator that can allow for
user-defined directions (which I -think- I can), then the editor will allow
it. If, for example, TADS does not allow this sort of behavior, then the
TADS generator won't allow the editor to use anything except the standard
directions.

Notes can be jotted and attached to any object (forgot to mention that,
dangit!); they're treated like comments and marked as such in the final
Inform code.

Magic words are a bit more of a sticky problem. Somewhat like
directions, they'll have to be handled by the generator first -- else
there's no point in allowing the editor to do it.

>
> I also think you'll find that users will insist on seeing the
> locations of NCPs, treasures & other items. I have allowed the user to
> select properties to be colo(u)r coded on the map, so that he can see
> at a glance which rooms contain NCPs/treasure/puzzles/darkness/etc

Probably. I'm not against the idea, mind you.

I need to work up a more technical draft and post it, I think, since
apparently we're not quite on the same page yet. In brief, the plan is for
the generator to define what's allowed in the editor. Say we have a TADS
generator and an Inform generator. TADS allows for Widget A, but Inform
does not. The user would, at run-time, select which type of output he'd
like to generate, and the editor would then query the generator about what's
allowed, the attributes and/or properties and/or classes etc etc etc, and
build a data structure for itself that only contains that which is allowed.

For maximum cross-platform compatibility, of course, each generator will
have a strictly limited set of ... well, call them attributes for now ...
that are common across all systems, so that there's ALWAYS a base for the
editor to work from. This base would be pretty restrictive, since it has to
guarantee that EVERY generator will be able to convert it to [platform X]
code... but what I likely see happening is someone develops a game for their
system of choice, and chooses to use the generator's full abilities to make
it easier on themselves.

And of course, the point is NOT to create a full-fledged visual IDE --
it's to create a utility that let's you avoid the drudgery of creating a
game and get right to creating the nifty features -- NPC's, random events,
daemons, etc.


> > Editor Features:
> > * create rooms, pathways between them, and doorways with a visual
interface
> And NCPs & objects? believe me, they'll want 'em.

See above. :)


> > * list of properties can be changed by the user
> So that he can add/rename/remove/copy, but only those which he
> defined, not the built in ones. In TADS this became difficult. If I'm
> looking at something, say a room, of class F, which derived from
> classes D & E, where D derives from B and and C derives from A and the
> user deletes one of those intervening classes, I have to consider the
> effect on all derived classes (e.g remove the inflatable property from
> Class A, does it affect objects of Class F?).

Actually, parsing class heirarchies isn't all that difficult. It's
convoluted, but not difficult. A simple cumulative tree structure (don't
know if that's what it's supposed to be called, but that's what it does)
would do the trick.

> > * user-selectable and definable grid system, with the standard
> > snap-to-grid/free placement options
> I didn't bother with a grid (yet). Free form is so much simpler & you
> can argue that it's a power user feature ;-)

I like grids myself, but only if I can ignore it when I want to. :)

>
> > * multiple generator support
> May well have to be dropped after you realize the enormity of what
> you're letting yourself in for, with only Inform ;-)

Hmm... see the generator/editor discussion above. Believe me, I've
thought about this. :)

> > Suggested Features:
> > * Arbitrary room geometry
> > - Currently, the editor defines (will define?) rooms as a square, and
show
> > them as such on the map (though you can -describe- it however you
like!);
> > changing this, while certainly do-able, seems hardly necessary, and
could
> > lead to potential confusion. Thoughts?
> Very, very, very low priority. However, I am still waiting for users
> to tell me how multiple maps (say multiple floors of a building)
> should operate, but I can envision using circles to represent rooms
> with a link to another map.

This, I'll admit, is one that I'd missed. However, to me, the obvious
solution would be to use layers. I can even do some tricks with colors and
patterns to show that -this- layer is above -that- one (ie, grey out the
bottom layer(s), make the current one black, and don't show any that are
above the current one)

>
> > * Map rotation
> > - Rotating the map is technically a somewhat trivial matter, since
it's
> > nothing more than a collection of polygons and lines in memory space,
but is
> > it something -needed-, or just wanted?
> probably neither. It does, however, imply that you are drawing your
> GUI pixel by pixel. If you used VB, surely you'd use a Panel to
> represent each room? That wouldn't rotate so easilly.

Actually, no, since this isn't intended to be a VB app. I'm using VB
to -prototype- it, to get a beta out and make sure I've got something that's
worthwhile (and also to test the GUI, since, well, that's the whole point of
the system). Once I've got a green light from betatesters, I'll be
switching to C.

Right now, I'm aiming at using C (via DJGPP) and the free Allegro game
library for the graphics handling, since it's been ported to almost every
major OS (and the code for the system itself -should- be as close to
platform independent as you can get). Also, it handles everything I'd need,
which admittedly isn't all that much.

>
> > * Room-within-a-room
> > - Oh, boy, this could be a hard one. Not to display, or even to edit,
but
> > because the code generation for this may not be possible with some
systems.
> > I know Inform can do it, and I -think- TADS can, but what about HUGO,
for
> > example? Maybe allow this as a selectable option, a la a checkbox in an
> > options screen, perhaps?
> Sorry, gotta be done, or no-one will take you seriously. I pushed it
> to a later version & have only just completed it. I regret not having
> it planned in from the start.

Well... actually, there's no worry about it from one point of view: the
initial generator, for Inform, can provide for this. My only worry is for
other IF systems.


> > * 3D design (not first-person, just perspective)
> > - Yikes. Well, could I do it? ... Yeah, I think so. It would
certainly
> > clarify up/down pathways. However, the substantially longer development
> > time and headache factor makes me want to avoid this one. If enough
people
> > want it -- and I mean REALLY want it, not just "hey, that'd be nifty"
but "I
> > MUST HAVE THIS", then I might look at it for version 2... assuming
people
> > besides myself actually use this beastie. :)
> hey, that'd be nifty

Grrr....

> > Generator Features (somewhat Inform-specific):
> > * two-way: it can not only generate an Inform source file from an
> > IFDesigner map, it can parse through an Inform source file and generate
a
> > basic IFDesigner map from it. Only those things that the editor
understands
> > will be included, but nothing will be lost (if there's a conflict, it's
the
> > editors job to warn the user).
>
> <can o' worms>
>
> Do you know much about file parsing? I'd recommend Lex/Yacc (of
> Flex/Bison) (and only wish I could afford Visual Parse++
> http://www.sand-stone.com/).

Yup. As I mentioned, I'm a professional software developer -- but
that's not all my company does. We're (shh -- whisper it) consultants, and
are called upon to do just about anything you can imagine. Security,
networking, data recovery, etc.

So, back to file parsing. One of the hats we wear is database
development. Relational database design and conversion of old data to the
new system. Well, lemme tell ya, once you've developed code to parse
through thousands of ancient export files from antiquated flat-file database
systems, each containing hundreds of thousands of related (but not
relational, if you get my drift) records, and then insert those records into
a modern relational database so that they still -work- correctly... well,
once you've done that, parsing a *text* file just isn't that daunting. :)


>
> - what if the user has multiple input files (or uses libraries)?
> You'll have to remember which file everything came from.
>
> - even if only a single file, he'll want it reconstituted in the same
> order, so you'll have to remember where everything you parse came
> from.
>
> - user comments generally belong to the immediately following
> declaration - but not always.
>
> That's if you are adding code/comments to his input files. Maybe you
> can just generate your stuff in a new file(s).

That's the idea. Parse the existing file, generate the IFDesigner
object map, and then -- when he's done mucking about with it -- create a new
file with the generated contents. First backing up his original, of course.

>
> </can o' worms>
>
>
> > * customizable indentation: you can define how you want your code
indented
> > (ie, K&R, ANSI, 3-space, whatever)
> nice, but low priority.

Yeah. It's a simple thing (remember, the GENERATOR decides what you're
allowed to do, so we're talking about a fixed set of rules, here).

> > * meta-code: included in the generator output is notation to itself
about
> > the map layout and other such niceties, safely tucked away behind
comment
> > symbols where Inform won't care about it. If they're removed or
changed,
> > the generator won't care; they're just to make it's job easier should it
> > have to re-create the IFDesigner file from Inform source.
>
> Implying that you have a different format of project save file (?). I
> started with a proprietary binary format, until users bullied me into
> an ascii format. So, now I use the windows .INI file format, since
> it's easy to read/write.

Oh, it'll be a text format. The suggestion of XML (different post) is
probably a good one; I'll have to look into that.


> > Where It All Comes Together:
> > The idea is that the editor (from whatever platform -- Windows, Mac,
Linux,
> You need to mail down your IDE. If you use Java, you cover everything.
> If you use Delphi/Kylix, you cover Windoze & Linus and alienate Mac
> users, but don't worry about that - they're used to it.

That's why I'm using C for the internal workings (easily portable), and
the Allegro library for the graphics (has ports to most major OS's, and a
Mac port is in alpha testing). If you -- or anyone -- can recommend a
better graphics lib (that's easy to use; friendliness is a big winner with
me), I don't mind giving it a try. Free and/or cheap is a must, though;
I've got a kid and a mortgage, so spending much on a hobby is right out. :)

(I mean, hell, it's not like I'm needing to render 3 quadrillion
abstract polygons to the screen every few microseconds, or something. I'm
working with 2D, flat-plane graphics, and could probably get by with a
64-color palette -- or less -- if necessary.)


> I'm with you all the way & will help as much as I can. Can you tell me
> - what IDE/lnaguage you plan to use

Prototyping: Visual Basic (no third-party components)
Public release: ANSI C (via DJGPP, using RHIDE or, more likely,
TextPad), and the Allegro Game Library
(http://www.talula.demon.co.uk/allegro/index.html , www.allegro.cc )

> - if you intend to support NPC and objects

I'd *like* to; however, this does depend on how much I can make a
generator support. For Inform, almost definitely; for other systems I can't
say.

> - whether you will support multiple maps

By multiple maps, do you mean layered maps, or seperate physical areas,
or multiple windows? Or something else?

> - where's your web page/mailing list

Not created yet. When I do create it (probably this weekend or sooner)
it'll be at my domain somewhere. Probably www.sofaspud.org/ifdesigner, but
I dunno for sure yet.

> - save file format

Text, possibly XML, if not then likely something resembling INI
structure.

> - whether you really intend to parse input files (and what you do when
> a room in the input file which you parse has a passage to one in your
> project's save file)

??? This I'm not sure I understand. Yes, I intend to parse an existing
source file and generate the map from that. If the user imports a source
containing a nonexistent link (say, ne_to BigScaryRoom, where BigScaryRoom
hasn't been defined yet), the map will show a broken pathway, and the user
can then create BigScaryRoom and connect it.

Or am I misunderstanding your question?

> - what exactly you inend to display on the map (treasures & puzzles
> to)
> - etc

Rooms, pathways, doorways, notes, room descriptions (likely as a
pop-up), and whatever else the generator can handle.

Again, I should have been more clear. The generator will tell the
editor what it can support, and the editor then tailors itself to only show
that subset.

>
> I'd advise you not to write a lick o' code until this (and more) is
> all nailed down.

Yup. Oh, I'm working on some quick modules -- f'r'instance, I need to
be able to detect when the user clicks on an area of the screen -- but
that's all easily ported stuff and is something that, no matter where this
goes, I need to do anyway. :)

>
> You, and everyone else reading this, could do you (and me) a favo(u)r
> by visitng http://plugh.cjb.net and looking at my effort and
> sugegsting ides for you to 'borrow' and new ideas for me to
> incorporate. Thanks.

Will do.

Robotboy8

unread,
Dec 11, 2001, 10:03:27 PM12/11/01
to
>(Replying to my own post to keep this from annoying TOO many folks. :))
Always a good idea.

>I've drafted up a very loose definition of the map creation utility
>discussed in this thread (hereafter named 'IFDesigner', unless someone can
>give me a reason not to :), and am including it below.

Nice name. Very imaginative. (Note sarcasm.) But it's not too bad...

>This is a -draft-, it is not set in stone. Any suggestions, criticisms, and
>so on would not only be appreciated, but welcome. If you want a specific
>feature, request it -- I may not choose to implement it, but I'll give it
>fair consideration.

Fair consideration? More than I get from most teachers :).

>Finally, unless it's acceptable to the group at large, I'd suggest keeping
>this to private email, so I don't get yelled at. :)

I like the suggestion of posting all related posts as "[IFDESIGNER] Subject
blah blah blah", for the simple reason that I have a strange phobia about
mail-lists.

>Thank you, everyone who replied (publicly and privately). I'll be sending
>out a beta just as soon as I can.

Email me a copy or I may well shoot you.

>IFDesigner
>A world-creation utility for Interactive Fiction.
>
>
>There will be two main parts to the entire IFDesigner system. They are the
>editor, and the generator.

A very good idea, for reasons you mention later.

>The Editor:
>This is what the user will be working with. It is intended to show a full,
>complete, and flexible map of the game 'world', including all rooms, the
>pathways between them, and doors (if applicable). By using color and other
>indicators, all potential directions from or to a room can be accounted for.
>In addition, allowing the user to specify and/or replace directions will
>provide for maximum flexibility.

Just how would you use colors, and just what are these "other indicators"?

>Editor Features:
> * create rooms, pathways between them, and doorways with a visual interface
>
> * assign properties to rooms and doorways

Just which properties might these be?

> * list of properties can be changed by the user

!!!

> * graphics options include zooming and scrolling of the game map (3D
>is -not- supported!), customizable color schemes, and so on
>
> * pathways (represented by lines) can be segmented to allow for unorthodox
>movement ("North from A leads to B; North from B leads to A", for example),
>or simply for greater clarity

Neatness! I worship you!

> * user-selectable and definable grid system, with the standard
>snap-to-grid/free placement options
>
> * multiple generator support
>
>
>Suggested Features:
> * Arbitrary room geometry
> - Currently, the editor defines (will define?) rooms as a square, and show
>them as such on the map (though you can -describe- it however you like!);
>changing this, while certainly do-able, seems hardly necessary, and could
>lead to potential confusion. Thoughts?

Sounds good, as long as you allow a room to be, say, really long and thin
(takes 3 squares by 1 square instead of the usual 1x1)

> * Map rotation
> - Rotating the map is technically a somewhat trivial matter, since it's
>nothing more than a collection of polygons and lines in memory space, but is
>it something -needed-, or just wanted?

Unnecessary.

> * Room-within-a-room
> - Oh, boy, this could be a hard one. Not to display, or even to edit, but
>because the code generation for this may not be possible with some systems.
>I know Inform can do it, and I -think- TADS can, but what about HUGO, for
>example? Maybe allow this as a selectable option, a la a checkbox in an
>options screen, perhaps?

Well, put it in with a message that, when read by the generator, will give a
warning if you're not outputting to a language that supports this. BTW, I
believe HUGO does and I know TADS does (see Glowgrass.)

> * 3D design (not first-person, just perspective)
> - Yikes. Well, could I do it? ... Yeah, I think so. It would certainly
>clarify up/down pathways. However, the substantially longer development
>time and headache factor makes me want to avoid this one. If enough people
>want it -- and I mean REALLY want it, not just "hey, that'd be nifty" but "I
>MUST HAVE THIS", then I might look at it for version 2... assuming people
>besides myself actually use this beastie. :)

Oh, I'll use it. Don't know about anyone else but I know I'd use it.

>The Generator:
>This is the behind-the-scenes part of the system. Here, it will take an
>IFDesigner object file generated by the editor and parse through it,
>generating code for the target platform that represents what the user
>created. Currently, the only platform I'm targeting is Inform, because
>that's the one I feel most comfortable with. So there. :) However, the
>editor is deliberately designed to be somewhat dense (ie, you can't do much
>beyond the basics), so as to make the generator's job easier, and hopefully
>more portable.

Would this be multiple generators (one for each language) or one generator with
plugin files for multi-output support?

>Generator Features (somewhat Inform-specific):
> * two-way: it can not only generate an Inform source file from an
>IFDesigner map, it can parse through an Inform source file and generate a
>basic IFDesigner map from it. Only those things that the editor understands
>will be included, but nothing will be lost (if there's a conflict, it's the
>editors job to warn the user).

!!!!YAY!!!!

> * customizable indentation: you can define how you want your code indented
>(ie, K&R, ANSI, 3-space, whatever)

You have just thoroughly trounced any previous editors in my mind.

> * meta-code: included in the generator output is notation to itself about
>the map layout and other such niceties, safely tucked away behind comment
>symbols where Inform won't care about it. If they're removed or changed,
>the generator won't care; they're just to make it's job easier should it
>have to re-create the IFDesigner file from Inform source.

So would you need these to port back? I would assume not. But if not, then
how do they make things easier when porting back to IFD?

>Where It All Comes Together:
>The idea is that the editor (from whatever platform -- Windows, Mac, Linux,
>etc) produces a file that any generator can read, and the generator can then
>create code for whatever platform (Inform, TADS, etc) that it's targeted at.
>In addition, this should be invisible to the user -- when they say, "Create
>it" (through a button, a hot-key, whatever), all the app will do is ask
>"Where do you want me to put it?"

Are you suggesting that there will be multiple different generator types?

Plugh!

unread,
Dec 12, 2001, 5:14:45 AM12/12/01
to
> > > I've drafted up a very loose definition of the map creation utility
> > > discussed in this thread (hereafter named 'IFDesigner', unless someone
> can
> > > give me a reason not to :),
> > - because it clashes with the InternetForms Designer
>
> This is the only one I'm even remotely worried about. IFBuilder,
> perhaps, instead?
http://www.mit.edu/afs/athena/system/sgi_62/os/usr/share/src/MolInventor/converters/mi2iv/IfBuilder.c++
Copyright (c) 1991-95 Silicon Graphics, Inc.

(I still like "Nancy" ;-)

[snip]


> > > Finally, unless it's acceptable to the group at large, I'd suggest
> keeping
> > > this to private email, so I don't get yelled at. :)

> Well... yes, that'd be nice. But I don't want to wear out my welcome on
> the group, either. I guess we'll see how things go.

I got yelled at, in my day; admittedly I was posting weekly progress
reports in separate (marked) threads & it was only one guy who
complained, but my delicate ego made me retreat to a mailing list &
that's when the contributions tailed off. Keep this thread running as
long as you can.

> Actually, everything listed here is intended for the first version.
> I've already developed the logic structures to handle this stuff, with room
> for expansion.

But the trick is knowing what's going to expand in there. Not so much
in the data structures, as in the logic.

> > What about directions like ssw, magic words, user provided code,

> I'd like to handle oddball directions; however, it may cause portability
> issues. I know you can do it in Inform, by any of several means. What
> about TADS? Or any of the other systems?

No problem in TADS. Such things are basically just a method of the
object. e.g

in = In_Awkward_Sloping_E_W_Canyon
up = In_Awkward_Sloping_E_W_Canyon
west = In_Awkward_Sloping_E_W_Canyon
xyzzy = Inside_Building

the user could also do some fancy code conatining
self.moveInto(<location>);

As I mentioned before, if you expect the user to abandon scraps of
paper in favor of your tool, you'll have to allow him to at least
annotate the map to indicate these things.

> The way I'm designing the editor is that the generator decides what's
> allowed. So if I can make an Inform generator that can allow for
> user-defined directions (which I -think- I can), then the editor will allow
> it. If, for example, TADS does not allow this sort of behavior, then the
> TADS generator won't allow the editor to use anything except the standard
> directions.

Hmm, sounds good, but I think you're adding extra work if the editor
queries the generator. I know that it's flexible, but I'd be tempted
to just 'know' the capabilities & hard code the possibilites in the
editor. Believe me, you are already being exceedingly ambitious,
especially consdering that you were looking for a project to keep you
busy for a few months.

> Notes can be jotted and attached to any object (forgot to mention that,
> dangit!); they're treated like comments and marked as such in the final
> Inform code.

Sounds good. Will this be a pop-up, when the cursor hovers over it on
the map, or a separate form? Why not allow the user to enter code
here, which you output transparently, then you might be able to avoid
the hybrid approach where your tool is only used for part of the job.

> Magic words are a bit more of a sticky problem. Somewhat like
> directions, they'll have to be handled by the generator first -- else
> there's no point in allowing the editor to do it.

You'll be booed & hissed at. See my comment above as to why you'll at
least have to allow the user to mark them on the map.

> > I also think you'll find that users will insist on seeing the
> > locations of NCPs, treasures & other items. I have allowed the user to
> > select properties to be colo(u)r coded on the map, so that he can see
> > at a glance which rooms contain NCPs/treasure/puzzles/darkness/etc
> Probably. I'm not against the idea, mind you.

Notice yet how it's blowing out into a full fledged, can do anything,
sort of tool? That's what happened to me.

> I need to work up a more technical draft and post it, I think, since
> apparently we're not quite on the same page yet.

Sounds good. I'd be happy to reveiw it.

> The user would, at run-time, select which type of output he'd
> like to generate, and the editor would then query the generator

I really believe it's easier for the editor to know, based on the
user's input, rather than to query the generator.

> For maximum cross-platform compatibility, of course, each generator will
> have a strictly limited set of ... well, call them attributes for now ...
> that are common across all systems, so that there's ALWAYS a base for the
> editor to work from.

OK, I see why you want to offer full flexibility, but this is going to
be a massive effort.

> And of course, the point is NOT to create a full-fledged visual IDE --

Not yet it isn't, but I'll be saying "I told you so" soon enough ;-)

And, anyway, why not?


> it's to create a utility that let's you avoid the drudgery of creating a
> game and get right to creating the nifty features -- NPC's, random events,
> daemons, etc.

That's all that I wanted to do. Did you read the thread whose URL I
posted, showing how I was gradually cagoled & coerced into the full
blown thing?


> > > Editor Features:
> > > * create rooms, pathways between them, and doorways with a visual
> interface
> > And NCPs & objects? believe me, they'll want 'em.
> See above. :)

you too :-)


> Actually, parsing class heirarchies isn't all that difficult. It's
> convoluted, but not difficult. A simple cumulative tree structure (don't
> know if that's what it's supposed to be called, but that's what it does)
> would do the trick.

Everything's simple with recursion ;-)

Mine was a little tricker because in addition to allowing the user to
define the properties of a class, I allow him to define new classes
(with new properties).

> > > * multiple generator support
> > May well have to be dropped after you realize the enormity of what
> > you're letting yourself in for, with only Inform ;-)
> Hmm... see the generator/editor discussion above. Believe me, I've
> thought about this. :)

I'd say about 18 months to 2 years at 2-3 hours a night, five evenings
a week. What's your feel for it?

> > Very, very, very low priority. However, I am still waiting for users
> > to tell me how multiple maps (say multiple floors of a building)
> > should operate, but I can envision using circles to represent rooms
> > with a link to another map.
> This, I'll admit, is one that I'd missed. However, to me, the obvious
> solution would be to use layers. I can even do some tricks with colors and
> patterns to show that -this- layer is above -that- one (ie, grey out the
> bottom layer(s), make the current one black, and don't show any that are
> above the current one)

Nice, but only for regular layouts.


---------------------------------------------
| first floor
| |--------| |--------- |----------
| | room 1 | | room 2 | | room 3 |
| | up to |<--->| up to |--->| south to|
| | room 5 | | room 5 | | room 4 |
| --------| ---------- -----------
|
|---------------------------------------------


---------------------------------------------
| second floor
| |--------| |--------- |----------
| | room 4 | | room 5 | | room 6 |
| | up to |<----| down to|<-->| xyzzy to|
| | room 5 | | room 1 | | room 1 |
| --------| ---------- -----------
|
|---------------------------------------------

I could have made it more convoluted, but that's enough. If you don't
allow it, someone will bitch. I foresee seprate forms (MDI), not
overlayed (but how to show the connections?). Over to you ...

> Actually, no, since this isn't intended to be a VB app. I'm using VB
> to -prototype- it, to get a beta out and make sure I've got something that's
> worthwhile (and also to test the GUI, since, well, that's the whole point of
> the system). Once I've got a green light from betatesters, I'll be
> switching to C.

Sounds like a round about road for a shortcut. I'd use VB as far as a
few screen shots & no further. Certainly not for beta. Save yourself a
heap o' rework.

> Right now, I'm aiming at using C (via DJGPP) and the free Allegro game
> library for the graphics handling, since it's been ported to almost every
> major OS (and the code for the system itself -should- be as close to
> platform independent as you can get). Also, it handles everything I'd need,
> which admittedly isn't all that much.

Very sensible. I can't actually pick any holes in that. DJGPP is fine
and so is Allegro (hmm, Qt became free last year or so).

By using a Windozs + emulator or Windoze + Linux approach (are there
any windows emulators for the Mac?), I've gotten an awful lot for free
though. You mention later determining whether the user has clicked on
a room - I have my onClick() method of my TPanel automagically called.
I also get a (huge) lot of graphical stuff, etc for free (the whole
GUI, really, menus, buttons, list boxes, edit boxes, etc as well as
timers & other stuff (does Allegro offer these?)).

You would also get this with Java. If you can C++, you can Java and if
you can't you can VB, which is OO and C, so there are no foreign
concepts to Java. Borland gives away a free RAD Java IDE.

> > > * Room-within-a-room
> > > - Oh, boy, this could be a hard one.

> > Sorry, gotta be done, or no-one will take you seriously. I pushed it
> > to a later version & have only just completed it. I regret not having
> > it planned in from the start.
> Well... actually, there's no worry about it from one point of view: the
> initial generator, for Inform, can provide for this. My only worry is for
> other IF systems.

Rooms within rooms within rooms within objects within rooms within
NPCs within rooms within NPCs within inventory? TADS can.

> > hey, that'd be nifty
> Grrr....

glad you like my sense of humo(u)r.

> > > Generator Features (somewhat Inform-specific):
> > > * two-way: it can not only generate an Inform source file from an
> > > IFDesigner map, it can parse through an Inform source file and generate
> a
> > > basic IFDesigner map from it.

> So, back to file parsing. One of the hats we wear is database
> development. Relational database design and conversion of old data to the
> new system. Well, lemme tell ya, once you've developed code to parse
> through thousands of ancient export files from antiquated flat-file database
> systems, each containing hundreds of thousands of related (but not
> relational, if you get my drift) records, and then insert those records into
> a modern relational database so that they still -work- correctly... well,
> once you've done that, parsing a *text* file just isn't that daunting. :)

I'm sure that they weren't free format, though, bet they had a fixed
layout ;-) Parsing a programming language is a mighty undertaking.
What's your effort estimate on that (ballpark)?

> > - what if the user has multiple input files (or uses libraries)?
> > You'll have to remember which file everything came from.
> >
> > - even if only a single file, he'll want it reconstituted in the same
> > order, so you'll have to remember where everything you parse came
> > from.
> >
> > - user comments generally belong to the immediately following
> > declaration - but not always.
> >
> > That's if you are adding code/comments to his input files. Maybe you
> > can just generate your stuff in a new file(s).
>
> That's the idea. Parse the existing file, generate the IFDesigner
> object map, and then -- when he's done mucking about with it -- create a new
> file with the generated contents. First backing up his original, of course.

File ... or fileS.

So, does your generated stuff (from what he created in your proggie)
go into an existing file, or a new one? If a new one, rememeber not to
treat it as 'existing' when the program is next run. If he defines the
map in 20 sessions, you don't want 20 generated files lying about.

I think that this and your fully flexible "editor queries the
generator for properties" ideas are two major undertakings which will
take up the bulk of your effort (v2.0 ?).

> > Implying that you have a different format of project save file (?).

> Oh, it'll be a text format. The suggestion of XML (different post) is
> probably a good one; I'll have to look into that.

So, when next running the proggie & reading in all source files, you
can ignore any which were purely generated by the editor, because you
have the info in a more trustworthy form in the save file (?).

> > You need to mail down your IDE. If you use Java, you cover everything.
> > If you use Delphi/Kylix, you cover Windoze & Linus and alienate Mac
> > users, but don't worry about that - they're used to it.
> That's why I'm using C for the internal workings (easily portable), and
> the Allegro library for the graphics (has ports to most major OS's, and a
> Mac port is in alpha testing). If you -- or anyone -- can recommend a
> better graphics lib (that's easy to use; friendliness is a big winner with
> me), I don't mind giving it a try. Free and/or cheap is a must, though;
> I've got a kid and a mortgage, so spending much on a hobby is right out. :)

I still recommend Kylix & Delphi (or Java). If you don't have $25 for
an eBay copy of Delphi, I can mail you an old copy. Do you have a
Linux box?

> (I mean, hell, it's not like I'm needing to render 3 quadrillion
> abstract polygons to the screen every few microseconds, or something. I'm
> working with 2D, flat-plane graphics, and could probably get by with a
> 64-color palette -- or less -- if necessary.)

No, it's not the graphics, it's all the free o/s abstraction stuff.

> Prototyping: Visual Basic (no third-party components)
> Public release: ANSI C (via DJGPP, using RHIDE or, more likely,
> TextPad), and the Allegro Game Library
> (http://www.talula.demon.co.uk/allegro/index.html , www.allegro.cc )

Acceptable, but probably leading to extra effort. Btw, it only just
occurred to me. You say C, not C++. Since most i-f languages are OO
(well, the big 2 anyway), you'll find them much easier to model in OO.
Why not consider an OO language? C++ gives you free linked list
support, etc right in the langauge and OO just seems easier/more
natural than C.

> > - if you intend to support NPC and objects
> I'd *like* to; however, this does depend on how much I can make a
> generator support. For Inform, almost definitely; for other systems I can't
> say.

he he. And the effort rises...

> > - whether you will support multiple maps
> By multiple maps, do you mean layered maps, or seperate physical areas,
> or multiple windows? Or something else?

Remember that you're replacing scraps of papaer. I think the user will
want one 'map' per piece of paper, be it floors of a building,
inside/outside, texas/alabama/timbuktu, prologue/middle/endgame or
whatever.

> > - where's your web page/mailing list
> Not created yet. When I do create it (probably this weekend or sooner)
> it'll be at my domain somewhere. Probably www.sofaspud.org/ifdesigner, but
> I dunno for sure yet.

Don't forget to let us know.

> > - save file format
> Text, possibly XML, if not then likely something resembling INI
> structure.

There's plenty of support for .INI, even if you stick to DJGPP.

> > - whether you really intend to parse input files (and what you do when
> > a room in the input file which you parse has a passage to one in your
> > project's save file)
> ??? This I'm not sure I understand. Yes, I intend to parse an existing
> source file and generate the map from that. If the user imports a source
> containing a nonexistent link (say, ne_to BigScaryRoom, where BigScaryRoom
> hasn't been defined yet), the map will show a broken pathway, and the user
> can then create BigScaryRoom and connect it.

Not broken links (although that's a possibility, with your hybrid
approach). Since you do have a hybrid approach, some rooms could be in
a text editor generated input file and some in your project's save
file. Not really a problem, just some extra code to join them (maybe -
maybe not. Just an area with potential. Some thought required).

> Or am I misunderstanding your question?

I think that I was.

> > - what exactly you inend to display on the map (treasures & puzzles
> > to)
> > - etc
> Rooms, pathways, doorways, notes, room descriptions (likely as a
> pop-up), and whatever else the generator can handle.

"whatever else the generator can handle" could include treasures &
puzzles, etc?

> > I'd advise you not to write a lick o' code until this (and more) is
> > all nailed down.
> Yup. Oh, I'm working on some quick modules -- f'r'instance, I need to
> be able to detect when the user clicks on an area of the screen --

I don't see why you'd need that in a VB beta... oh, well, never mind,
I'm sure you know what you're doing

> > You, and everyone else reading this, could do you (and me) a favo(u)r
> > by visitng http://plugh.cjb.net and looking at my effort and

> > suggesting ides for you to 'borrow' and new ideas for me to
> > incorporate. Thanks.
> Will do.
I look forward to your comments ;-)

Peter Ketting

unread,
Dec 12, 2001, 10:49:59 AM12/12/01
to

"Brian Payne" <sofa...@sofaspud.org> wrote in message:

<snip>

Check out a program called ZMud. It is a client for playing Muds but it has
an exelent mapping ability. Maybe it could give you some more ideas.

Cheers,
Peter

Robotboy8

unread,
Dec 12, 2001, 10:15:21 PM12/12/01
to
>> If the target
>> isn't Windoze users, though, I would reccommend a program for Gnome called
>> GLADE. It works sort of like VB but generates C/C++ code which _might_ be
>> ported to Windoze. I say might because it may well rely on gtk+. I'm not
>> sure, it's been several months since I last used it.
>
>I don't know anything about GLADE, but it's maybe worth mentioning that
>a program requiring gtk+ does not necessarily preclude its being ported
>to Windows.

I understand that. However, it all depends on how _easily_ portable it should
be, not how just how potentially portable. And from what I've heard, GTK+
would be much harder to port than, say, OpenGL.

Sam Dennis

unread,
Dec 13, 2001, 1:47:59 AM12/13/01
to

Actually, last time I checked, most GTK+ code (including that produced by
Glade) doesn't even require any changes to compile in cygwin; the Win32 ports
are a little buggy, however.

Plugh!

unread,
Dec 14, 2001, 2:23:56 AM12/14/01
to
Reply all
Reply to author
Forward
0 new messages