From senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Thu Mar 21 11:22:24 2002 Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail From: plugh@subdimension.com (Plugh!) Newsgroups: rec.arts.int-fiction Subject: Re: [Inform] Map creation utility Date: 11 Dec 2001 05:02:36 -0800 Organization: http://groups.google.com/ Lines: 251 Message-ID: <98ef019f.0112110502.39683b40@posting.google.com> References: <1007765094.759308@sidehack.sat.gweep.net> <1008033453.693746@sidehack.sat.gweep.net> NNTP-Posting-Host: 192.35.17.15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1008075756 23444 127.0.0.1 (11 Dec 2001 13:02:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 11 Dec 2001 13:02:36 GMT Xref: senator-bedfellow.mit.edu rec.arts.int-fiction:87852 "Brian Payne" wrote in message news:<1008033453.693746@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). 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). > * 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...