From senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!nntp.abs.net!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!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!nntp.abs.net!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail From: plugh@subdimension.com (Plugh!) Newsgroups: rec.arts.int-fiction Subject: Re: [Inform] Map creation utility Date: 12 Dec 2001 02:14:45 -0800 Organization: http://groups.google.com/ Lines: 366 Message-ID: <98ef019f.0112120214.bee6f72@posting.google.com> References: <1007765094.759308@sidehack.sat.gweep.net> <1008033453.693746@sidehack.sat.gweep.net> <98ef019f.0112110502.39683b40@posting.google.com> <1008098681.606149@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 1008152086 21019 127.0.0.1 (12 Dec 2001 10:14:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 12 Dec 2001 10:14:46 GMT Xref: senator-bedfellow.mit.edu rec.arts.int-fiction:87894 > > > 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(); 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 ;-)