From senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Thu Mar 21 11:22:24 2002 Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail From: "Brian Payne" Newsgroups: rec.arts.int-fiction Subject: Re: [Inform] Map creation utility Date: Tue, 11 Dec 2001 11:26:17 -0800 Organization: Organization, me? Hah! Lines: 424 Message-ID: <1008098681.606149@sidehack.sat.gweep.net> References: <1007765094.759308@sidehack.sat.gweep.net> <1008033453.693746@sidehack.sat.gweep.net> <98ef019f.0112110502.39683b40@posting.google.com> X-Trace: UmFuZG9tSVa6uOjHNSWpk94Ymzzy2gFm7InMJL6AmHKa84usz0/7ju9Tr8MruQc8 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 11 Dec 2001 19:24:42 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Priority: 3 X-MSMail-Priority: Normal X-Cache-In: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) X-Newsreader: Microsoft Outlook Express 5.00.3018.1300 Cache-Post-Path: sidehack.sat.gweep.net!unknown@206.63.156.65 Xref: senator-bedfellow.mit.edu rec.arts.int-fiction:87869 "Plugh!" wrote in message news:98ef019f.0112110502.39683b40@posting.google.com... > "Brian Payne" wrote in message news:<1008033453.693746@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). > > > > 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. > > > > > > * 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. Brian Payne sofaspud at sofaspud dot org