Mudlet Mapper

hempa
Posts: 48
Joined: Sat Jan 02, 2010 1:07 pm

Re: Mudlet Mapper

Post by hempa »

Don't use exit length to decide which would be the fastest past, but instead allow the mappers to set weight for exits, or even rooms to avoid for speedwalking (perhaps you became enemied to a town or a city and can't run through it).

Weight would be used to calculate how 'fast' the exit is. For instance, for swimming movement or the like, or for special commands required.

When speaking about this, swimming is quite important in movement on many MUDs, and I'd expect a mapper to have a feature to add special commands or prefixes to movement. It would also be quite important to handle delayed movement such as the IRE tumble skills or swimming.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet Mapper

Post by Vadi »

What we're talking about is conditional weighting. Someone with and without gallop will travel the same distance in different times!

But yes, that concept definitely will be present.

roysjosh
Posts: 1
Joined: Tue Jan 05, 2010 3:43 pm

Re: Mudlet Mapper

Post by roysjosh »

I would recommend a database backend like sqlite or db4. Then you just define a schema that contains all the info you want:

Code: Select all

CREATE TABLE Mud (
  mudId INTEGER PRIMARY KEY,
  mudName TEXT,
  mudHost TEXT,
  mudPort INTEGER
);

-- each entry in this table is a "standard" exit for a certain MUD
-- i.e., suppose a MUD has only 6 standard directions: n,e,s,w,u,d
--   there would be 6 entries with dirName="longname" ("West")
--     and commandToSendToMud="shortname" ("n" etc)
CREATE TABLE ExitNames (
  exitNameId INTEGER PRIMARY KEY,
  mudId INTEGER REFERENCES Mud(mudId),
  dirName TEXT,
  commandToSendToMud TEXT
);

CREATE TABLE Room (
  roomId INTEGER PRIMARY KEY,
  mudId INTEGER REFERENCES Mud(mudId),
  name TEXT,
  desc TEXT,
  ...
);

CREATE TABLE Exits (
  exitId INTEGER PRIMARY KEY,
  fromRoomId INTEGER REFERENCES Room(roomId),
  toRoomId INTEGER REFERENCES Room(roomId),
  command TEXT, -- if this is NULL, we go with the default from ExitNames.  otherwise this is sent instead
  ...
);
etc, etc. I like the MVC idea, with the configurable View. As for path-finding algorithms, look up graph theory and the shortest path problem. I would also recommend starting development with a simple View, work out the bugs in the Model and Controller, and then make fancier Views.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet Mapper

Post by Vadi »

Well, while sql might be a good storage format, it's not something that's feasible to be used internally :|

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet Mapper

Post by Heiko »

roysjosh wrote:I would recommend a database backend like sqlite or db4. Then you just define a schema that contains all the info you want:

Code: Select all

CREATE TABLE Mud (
  mudId INTEGER PRIMARY KEY,
  mudName TEXT,
  mudHost TEXT,
  mudPort INTEGER
);

-- each entry in this table is a "standard" exit for a certain MUD
-- i.e., suppose a MUD has only 6 standard directions: n,e,s,w,u,d
--   there would be 6 entries with dirName="longname" ("West")
--     and commandToSendToMud="shortname" ("n" etc)
CREATE TABLE ExitNames (
  exitNameId INTEGER PRIMARY KEY,
  mudId INTEGER REFERENCES Mud(mudId),
  dirName TEXT,
  commandToSendToMud TEXT
);

CREATE TABLE Room (
  roomId INTEGER PRIMARY KEY,
  mudId INTEGER REFERENCES Mud(mudId),
  name TEXT,
  desc TEXT,
  ...
);

CREATE TABLE Exits (
  exitId INTEGER PRIMARY KEY,
  fromRoomId INTEGER REFERENCES Room(roomId),
  toRoomId INTEGER REFERENCES Room(roomId),
  command TEXT, -- if this is NULL, we go with the default from ExitNames.  otherwise this is sent instead
  ...
);
etc, etc. I like the MVC idea, with the configurable View. As for path-finding algorithms, look up graph theory and the shortest path problem. I would also recommend starting development with a simple View, work out the bugs in the Model and Controller, and then make fancier Views.
This is pretty much exactly what I've been planning to do.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet Mapper

Post by Heiko »

Jeremy wrote:One thing I would like to be able to offer users, as a developer, is the ability to be able to download a map db from our servers with the click of a button.
This is pretty much the best solution for both MUD & player and I'm definitely going to support this. Users get high quality graphical maps and the network and server loads get reduced. We'd need to agree on some kind of db layout and user localization means though. What about x,y,z room coordinates via ATCP/MXP? You can email me a map db + test account to speed up development and testing.

ixokai
Posts: 63
Joined: Fri Dec 25, 2009 7:43 am

Re: Mudlet Mapper

Post by ixokai »

I think the specifics of the storage "format" is a premature question here; in a new system, allowing the model to drive the controller is something of a mistake. When working on an existing system, we have to deal with the legacy data and wrap it in a model and we're just stuck with it, but in a new system we can figure out what we really need to do first and how it performs and operates, and often at the end of knowing this-- the storage decision will be obvious.

What we shouldn't worry about is -how- to store data, but -what- should be stored. What specific data points are necessary to perform whatever we want to perform. The obvious ones are room name, some unique identifier, and a list of links to other unique id's with. But at that point we should see if that's really all that's needed.

For example, Lusternia's "fly" gives me significant pause. You go around and go 'up' and 'down', and this changes your level on the built in maps, but in a way 'up' and 'down' are really just simple directions. But you can sometimes fly and move around. Now, I'm told that fly isn't a direction but a position within a room so we don't need to know that: BUT -- is that always the case? I only play on one mud right now (well, 1.1, MKO's rabbits obliterated me to despair, but I still have an account :)) so I don't really have a solid basis of understanding.

Are there some muds where 'fly' enters not a 'position in a room' but a really different logical room with its own logical orientation to other rooms-- and in particular, is it possible to 'fly' places that you can't walk? The question of "levels" is something we may have to address in storage (and in later algorithmic development).

But right now, what we need to know is *what* to store. We should have that in idea, and store it in some dummy format for right now and work on the controller-- the algorithms-- the meat of the program, and once we have that done -- adjusting the dummy data as we do for efficiency and as new needs become apparent -- the best storage method will probably be obvious.

I'm doing some experimentation on pathfinding algorithms shortly, starting with the Dijkstra's which is the obvious/basic compsci-y one and moving on to some more specialized ones. Vadi's got me a partial Achaea IMap that I'm going to parse(its got about 22k rooms), but if a more complete dataset is available, that'd make the algorithmic testing more useful. I dont' really care about the format as long as its textual and clear. (Meaning, I don't want to deal with a binary file, but anything text/XML/whatever that's bigger and more complete is cool)

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet Mapper

Post by Vadi »

Here's another map from some random MUD: http://dl.dropbox.com/u/84880/mume.xml

I'll go about checking out the most popular mud engines and how they handle the geography.

Jeremy
Posts: 12
Joined: Wed Dec 30, 2009 7:09 pm
Location: Bellingham, WA, USA
Contact:

Re: Mudlet Mapper

Post by Jeremy »

Heiko wrote:
Jeremy wrote:One thing I would like to be able to offer users, as a developer, is the ability to be able to download a map db from our servers with the click of a button.
This is pretty much the best solution for both MUD & player and I'm definitely going to support this. Users get high quality graphical maps and the network and server loads get reduced. We'd need to agree on some kind of db layout and user localization means though. What about x,y,z room coordinates via ATCP/MXP? You can email me a map db + test account to speed up development and testing.
Here you go: http://www.imperian.com/map.xml

That is every room in Imperian. If you need some changes on that, let me know, I am not a code ninja by any stretch of the imagination.

IRE games have to have several 'maps' that are separated by areas because all the rooms are not logically laid out and there would be too many rooms overlapping if we just made one giant map. I am sure we are not the only game like that.

You can see some examples of what I mean here: http://www.imperian.com/maps.php

I will set up atcp tomorrow to send out room numbers.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet Mapper

Post by Vadi »

Some additional info in regarding to algorithms - here is IMappers explained:

The algo kinda works like A*. Start with a room, mark it with number 0. Put all its neighbours in a list, let's call it ListA. Visit every room in ListA, mark them with number 1, and put their neighbours in ListB. Once done with ListA, rename ListB to ListA, and make ListB be a new, empty list. Then repeat until every room in the world is visited (or until you hit the destination, but it is so fast that it does not matter where you stop). That is A*. My algorithm is similar, except it uses more than one list. If the maximum "cost" of travelling through an exit is MaxCost, then I have MaxCost+1 lists... I mark the list I am currently scanning (like ListA above) with its number, say CurrentList. If one of the rooms in CurrentList has a neighbour with a cost of 4, then I add it to the list with index (CurrentList+4) modulo (MaxCost+1).

Post Reply