Quote:
Unfortunately very few MUDs expose their unique tags (vnums) to the players, so you have to play all these guessing games with triggers and other heuristics. This is where things get fairly dirty, and where a system for one MUD is not likely to work for another.
Actually, its even worse than that. The only muds that posses such unique internal IDs are so called "modern" muds, for which the ID is an artifact of how the room data is actually stored. Other muds, like LPC use something like an internal queue, IDs that are internal only and generated in the "order" that the rooms get created, which may not be the same every day, etc. They have the advantage that nothing short of a "major" bug requires that you recompile the driver, since everything, including stuff like MXP, is handled in the "library", not the driver. They do, ironically, sometimes use sections that have "virtual rooms", where there is a room type, default exits and an override ability that lets you specify that certain rooms are not part of the automatic generation, and that they should be loaded from a file instead, all of it on a nice, simple, 2D grid. This is however, usually, employed for the overland areas, not the ones with actually puzzles, mobs and other things in them. Modern muds generally have a clear deliniation between "short description", "long description", "mobs", "objects", and "code", with no way to override the first two based on context, limits on what you can do with the third and fourth, and code that, because if this, is hamstrung with respect to what you can actually do with the result, all so you can shove the stuff into a Database, for easy management. Its like coding in Basic, and I mean BasicA, from like DOS 2.0 or something, not even QBasic, which was at least a significant improvement. Imho, there has to be a solution that both a) makes object management easier, but doesn't b) rely so heavilly on the driver to handle every behaviour that you have to practically rewrite the thing to make *either* trivial or "significant" changes to the way the mud works. This imho, makes no bloody sense for a design...
Anyway, you can't rely on there even existing a unique ID for a room, so its pointless to talk about how much easier it would make coding a mapper if muds all provided you with the number. And, as others have pointed out, the lack of a unique way to see which room you are in using a number is only the "start" of the chaos involved with figuring out how to manage it. Though, Onoitsu2's example is "less" of a problem than it might be, as long as the mapper keeps track of "when" and "which way" you moved and you do recieve, at least, exit imformation and, "You can't go that way!", type messages, type messages. The mapper has to be smart enough to know you didn't move, and so "stay" where you last where, until you do successfully move some place. Put simply, "where" you are should only be "verified" with the room descriptions, actual movement should be based on what you as a player try to do, and if it is successful. It might help, to allow the player to tag a room as "unique", so that if the mapper does mis-sync, passing through one of those rooms would reset its location. In the best of worlds, you could make one smart enough to know its been tricked and wait until its sure of where it is again before proceeding to map how it go there, but its more likely that you would end up with one that realized, once it lander in a known "unique" room, that it needs to backtrack its last few locations, until its reasonably sure of where it got confused, just like the player would.
However, making it that smart just adds "more" complexity to the system. |
![[Go to top]](/images/gototop.gif){kind=small}
top