From senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hub1.nntpserver.com!headwall.stanford.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!hub1.nntpserver.com!headwall.stanford.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:36:16 -0800 Organization: http://groups.google.com/ Lines: 91 Message-ID: <98ef019f.0112110536.448a316e@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 1008077777 24226 127.0.0.1 (11 Dec 2001 13:36:17 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 11 Dec 2001 13:36:17 GMT Xref: senator-bedfellow.mit.edu rec.arts.int-fiction:87853 > > 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... We'll see, ther are some rather snarky folks around here. Still, if we keep it to one thread, we should be ok. > > I've got a few suggestions, mainly on things to implement to make things more > customizable, and things to wait on... > I'd wait till you've got the base of the editor working before adding this. It'd > be nifty afterwards, though. > 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. > 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) As I said to Brian, it is important that he knows up front what all desired features are. It is much simpler this way, than to try to add tehm later. He shoudl collect a big feature list & prioritize it. So, please post all of your suggestions now, rather than holding back. > 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. That wasn't forseen. Are you sugegesting that he generate code? If so, the user shouldn't be constrained to providing only plain text, but should also be able to provide code - e.g some rooms have a different descriprion the first time that you wvisit them than from subsequent times. > 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. He, he, told you so, Brian. Muh ha ha ha!!! (please visit http://plugh.cjb.net and give me some advice/feedback too. Maybe I can do the TADS version & Brian the Inform version). > 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. "You know. I think we should put some mountains here. Otherwise, what are all the characters going to fall off of? And what about stairs? Yodellayheehoo." [snip] > 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). Nice idea. I wonder how practical it is though? I always put ideas to the Colossal Cave test. Someone will always make a map whose geometry doesn't quite fit. > Mind, I would wait till version two, and have some of the other things I > mentioned waiting on be version three or four... So long as they're planned & Considered from the start ;-) > 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... Sounds like an idea. Do you have any "teach yourself XML in 24 hours" URLs? (must look on code monkey) [snip] > 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. Some good sound comments there. I hope you'll give me some too ;-)