Text MUD

ID:161132
 
Jun 14 2008, 1:26 am
I was looking to make an old-school text MUD. Is it possible to make one without predefining each and every area? I was thinking, maybe use a map file? Probably a big map with generic tiles, such as "plains," "mountains," etc. and then letting players establish other structures, such as towns and what-not, and then saving them? I'm pretty sure I could handle the saving of newly built structures, but not so sure about the map stuff. All the generic areas would have default descriptions, but if players built there, they could edit the description, block exits, etc.
Jun 14 2008, 4:47 am
Yes, that is entirely possible. Be aware that including a map file will cause DS to default to icon mode instead of text mode and most traditional muds are room based. However, using a map has its advantages.

As to player built structures, just be aware that players tend to name and describe things in ways you may not like, so you may want to adopt a policy and some rules so you don't get "S1R p33n0rz 1337 |-|00D".
Jun 14 2008, 8:13 am
In response to Jmurph
How would I make a map, but then turn it off, so that you don't see it, but can still move around in it?
Jun 14 2008, 8:18 am
In response to Jmurph
Jmurph wrote:
Be aware that including a map file will cause DS to default to icon mode instead of text mode and most traditional muds are room based.

Actually, I believe that it only defaults to icon mode if anything has an icon variable that isn't null. If this is outdated knowledge, someone update me. :P
Jun 14 2008, 8:49 am (Edited on Jun 14 2008, 8:58 am)
In response to Seraphrevan
Just make the game WITH the map, so that you can see what's going on visually, and then when you've got everything setup, make a custom interface without a map. You can also set the world.view = 0 or set client.show_map = 0 if you're worried about people editing their interfaces.

Things will take place on the map exactly as they would if you could see it, so its really not a big deal. Just make sure you limit how fast people can move from room to room in your game otherwise people will be blazing from room to room.

It might also be good to disable arrow key movement, or at least make them non-repeating. But that's just a matter of taste.

But all you really need to do is display the room description to the player whenever they enter a turf.

If you want to go above and beyond that, you can also give each turf directional variables to let you have more control over where going in a certain direction takes people, and if people are allowed to go in that direction at all.

For example, a room.north variable could be one of several values:
  • 0 - means players can't go north from this turf.
  • "north", "east", "south" or "west", meaning going north will take you to the turf in that direction. A nice way to confuse the heck out of your players.
  • tag value - by giving another turf a tag value and setting this turf's north direction as a reference to that value, you can warp players across the map if they go north from this room.
Its also a good idea to have a "no entry" turf type, so you can easily wall off entire sections of the map.
Jun 14 2008, 8:59 am
In response to Foomer
My suggestion would be the base it where each room is a turf, and then include "linker turfs" that only serve to shunt you to the next room in a direction, allowing you to simulate some more esoteric geometry.

So, it might look like this:

turf
  proc
    getDesc()
      return desc
    getName()
      return name
  //non-rooms that only serve to link rooms that aren't adjacent on the map
  shunt
    getDesc()
      var/turf/T = get_step(src, src.dir)
      return T.getDesc()
    getName()
      var/turf/T = get_step(src, src.dir)
      return T.getName()
    
    Enter(atom/movable/A)
      var/turf/T = get_step(src, src.dir)
      return T.Enter(A)
    Entered(atom/movable/A)
      var/turf/T = get_step(src, src.dir)
      A.loc = T
      T.Entered(A)


So, for example, to create some warped geometry:

>>Xv
^Y<<


Where ^ > v < are shunts, if you kept on moving east or west, you'd just end up going through X and Y over and over again.
Jun 14 2008, 9:58 pm
In response to Garthor
You better not mess so much with the movement procs like that, though. While you could improve it to still be quite robust, you're better off just modifying the Move() call itself and simply letting the rest continue naturally, which I'd think is more robust by definition. 
turf/shunt
  var/destination //where this turf will take you. could be any other method as well, such as Garthor's dir method

atom/movable/Move(turf/shunt/newloc,newdir) //called whenever an obj or mob attempts to move anywhere
    if(istype(newloc,/turf/shunt)) //if it's attempting to move into a shunt,
        return ..(shunt.destination,newdir) //make it attempt to move into the shunt's destination instead (automatically following the normal movement behavior for it)
    return ..() //if the code reached here, the above if statement is false, so just carry on as normal without modifying anything.
Jun 15 2008, 8:42 am
In response to Kaioken
That should be .(shunt.destination,newdir) , not ..(shunt.destination,newdir) . Also needs to declare the shunt variable, but whatever.

Also, I realized that the shunts need to be made bi-directional, which is a bit more work and makes them a pain in the ass to put on the map (due to the lack of a NORTHSOUTH direction by default).
Jun 15 2008, 9:13 am
In response to Garthor
Garthor wrote:
That should be .(shunt.destination,newdir) , not ..(shunt.destination,newdir) . Also needs to declare the shunt variable, but whatever.

Oops. shunt should be the same as newloc, I probably ended up renaming one and not the other or something. And correct, you'd need to use .() for it to work with shunts that redirect to another shunt, although those would only make much sense in a dir-based implementation.
Jun 15 2008, 7:11 pm
In response to Volte
Volte wrote:
Actually, I believe that it only defaults to icon mode if anything has an icon variable that isn't null. If this is outdated knowledge, someone update me. :P

Technically, it seems as if setting icon anywhere (compile-time or run-time) directly will force icon mode. You can set icon through the vars list without triggering the map though. =)

vars["icon"]='myicon.dmi'

Jun 17 2008, 7:27 am
In response to YMIHere
That's kind of a troublesome workaround, though. Isn't there just a map control parameter you can use for setting text-mode (setting icon-size to 0 just means 'stretch to fit') or something? Should probably request it if there isn't such a feature.
Jun 17 2008, 7:46 am
In response to Kaioken
Kaioken wrote:
That's kind of a troublesome workaround, though. Isn't there just a map control parameter you can use for setting text-mode (setting icon-size to 0 just means 'stretch to fit') or something? Should probably request it if there isn't such a feature.

I agree. The problem with this work around is that it has to be done at runtime, so you still won't be able to edit the map with the built-in editor nicely. You can, of course, you just won't have any icons.

Now that I think about it though, an extra .dm file containing all of your icon settings that is only included when editing the map is a decent work around for the problem (so long as I'm interpreting it correctly).