From senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hub1.nntpserver.com!newsfeed.direct.ca!look.ca!nnxp1.twtelecom.net!news-east.rr.com!news-west.rr.com!newsfeeder.randori.com!news.randori.com!da56b563!not-for-mail Thu Mar 21 11:22:24 2002 Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hub1.nntpserver.com!newsfeed.direct.ca!look.ca!nnxp1.twtelecom.net!news-east.rr.com!news-west.rr.com!newsfeeder.randori.com!news.randori.com!da56b563!not-for-mail From: Arcum Dagsson Newsgroups: rec.arts.int-fiction Subject: Re: [Inform] Map creation utility References: <1007765094.759308@sidehack.sat.gweep.net> <1008033453.693746@sidehack.sat.gweep.net> User-Agent: MT-NewsWatcher/3.1 (PPC) X-Answer: 42 X-tra-quote: "My God, you killed Gleep! You b*st*rd!" X-YZZY: "A hollow voice says 'Fool'." X-FNORD: fnord.fnord.fnord. X-Kie-Line: Optional Kieran John subject line :) X-clusive-Kie-Line: Involuntary Kieran John subject line X-wank: misc wank X-do-not-alter-my-posts-when-archiving: Including adding links, b****** it! X-no-productlinks: yes Message-ID: Lines: 192 X-Complaints-To: abuse@randori.com Organization: Randori News - http://www.randori.com Date: Mon, 10 Dec 2001 23:01:03 -0800 Xref: senator-bedfellow.mit.edu rec.arts.int-fiction:87849 In article <1008033453.693746@sidehack.sat.gweep.net>, "Brian Payne" 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..."