A note on "reverse engineering": Companies that do this either determine the *behavior* of a product, then recreate the behavior, code unseen, or *if* they do use code, they usually have a team, who will have no direct access to, or contact with, the people that produce the final product, dissect the code/product, then write a detailed specification. Someone else, who have had no contact with the first group, share no members, etc., then takes that specification and builds a product from it.
This depends a lot on if the intent is to produce "compatibility" or "replication". For compatibility purposes, which would mean something like having Mushclient generate "data" that Zugg's mapper would act on as though it came from the original zMud mapper, anyone can rip apart the program to see how it works. We however are discussion "duplication", the making of a competing product, which replicates the entire behavior, and doesn't need to be compatible at all. That sort of thing requires greater separation, if for no other reason than to protect against *claims* of code theft, and not just design theft.
Its not too hard to guess how the predictive system he uses likely works. Even similar rooms will "usually" contain a mob, object, etc. that can make it unique, not to mention exit names, so figuring out which room you are dealing with is *usually* going to be a matter of assuming that its on a set grid, then "predicting" that two seemingly identical rooms *can't* be the same if they "appear" to be 500 rooms away from each other when you come across the second instance. The only question, and this could be tested, is if zMud's mapper can handle situations where 2-3 ways exist to get into a room, some from 20+ links away, but it can't tell if its the same room until you then start moving through additional repeats outside of it. Either a) it can decide that it made an error and try to correct it, or b) it can't, since making such a predictions isn't all that easy to start with. The more complex issue is handling muds where the "logical" location of rooms might place them in the same locations as other existing rooms. That is why I don't think showing the "closest" by stored coordinate is a good idea, but rather that any "map" display needs to be generated by looking N rooms from the "current" room. The odds of two rooms, a mere 3-4 rooms apart, overlapping each other visually isn't too high, and if they did, a good mapper could still "adjust" the view, if in an isometric design, to appear someplace other than the same physical location as the other room it overlaps. The only real question is how much the offset should be, if its only a "this isn't the same room" display, not an actual change of altitude (going up/down).
I would suspect that zMuds' mapper has a more primitive method of handling up/down too, but can't say without checking, in that it probably "hides" all rooms not on the same apparent "level". I.e., if you go up, then everything below/above you is then hidden, and only the rooms on "that" level are shown. This is probably the only practical solution for a 2D flat display, which is why I think some sort of isometric system would be nicer. |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2
3
4
5
6
7 8
9
10
11
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top