From senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed1.cidera.com!Cidera!portc03.blue.aol.com!audrey04.news.aol.com!not-for-mail Thu Mar 21 11:22:24 2002 Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed1.cidera.com!Cidera!portc03.blue.aol.com!audrey04.news.aol.com!not-for-mail Lines: 141 X-Admin: news@aol.com From: robotboy8@aol.com (Robotboy8) Newsgroups: rec.arts.int-fiction Date: 12 Dec 2001 03:03:27 GMT References: <1008033453.693746@sidehack.sat.gweep.net> Organization: AOL http://www.aol.com Subject: Re: [Inform] Map creation utility Message-ID: <20011211220327.15018.00001713@mb-fg.aol.com> Xref: senator-bedfellow.mit.edu rec.arts.int-fiction:87889 >(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? -- Sanity is a sure sign of a lazy mind.