08 Dec, 2009, Tonitrus wrote in the 1st comment:
Votes: 0
I've been thinking about movement in muds for awhile. I really don't like how movement tends to work in muds.

The normal mud movement leaves only two possibilities that I can see.

Laggy movement

Movement is laggy and annoying, since it takes too long to move around. Spamming a bunch of directions in (so you can go 50w for example), leaves you lagged while you walk. While moving, you can't look around, so if you want to look around, you have to type w, look, w, look, w, look. Or even less interesting: w, scan w, w, scan w, w, scan w.

This is insufferable.

Non-laggy movement

Movement is much faster, so you don't have to wait so damn long for your commands to go through. You still can't look while moving without interlacing movement commands with other commands, and entering in a bunch of directions at once can still lead to weird situations if you get attacked along the way. Also, now you can miraculously move across the entire game world in a matter of minutes.

Meh.

Also, with both setups a room is unreachable from any other room, and if a person decides to leave the room they're in, there's no way to stop them. So if you are thinking of attacking someone, for example, you can't afford to put in another command before you attack them. You can't afford to look at them, or to talk to them, they might leave the room, and as long as they're moving, they're untouchable.

Ugh.

I've been toying with the idea of having a coordinate-based system and maybe some sort of nethack-like display, since even being blind on nethack is only barely a nuisance as far as navigation goes. I was thinking then of maybe having movement be more of a statement of intent, and have movement be something that happens automatically every round or whatever. So if you wanted to go 50 west, you could just type west and wait until you arrived, or possibly even limit the number of movements to exactly fifty, but the actual process of movement would be an update issue and not a laggy command issue.

That way, you can look around while movement occurs, people can run from you while you attack them, you can chase people based on your character's speed and not based on twitch mechanics, and so on. You can also study spellbooks while you walk, sort your inventory on the way, that sort of thing. Or, gasp, even talk to the people walking with you.

On the other hand, if I assume I'll have 1 second rounds and try to play nethack moving one space a second, I get pretty impatient pretty quickly. I haven't played any muds that have actual coordinate movement, so I don't know how people do the movement on such things, but I get the impression that movement as I have specified might be slow and a bit on the boring side. If it's sped up too much, you end up with players being able to walk across the whole world in a manner of minutes, and if there's a 2d display, it draws attention too how limited they are as far as displaying range goes. I don't consider this particularly desirable either.

I am hoping that people who've had more experience with this sort of thing can point out other issues and (hopefully) solutions. I probably won't really be able to decide how things should be until I've got a codebase where I can test these ideas, and my codebase is progressing rather slowly (I'm just happy it takes connections)

I also recognize that, even if I were to set up a movement system like I've specified, that sometimes people really only want to move one "room" per movement command, and I'd have a mode for that as well.
08 Dec, 2009, Idealiad wrote in the 2nd comment:
Votes: 0
Quote
I haven't played any muds that have actual coordinate movement, so I don't know how people do the movement on such things, but I get the impression that movement as I have specified might be slow and a bit on the boring side.


….God Wars 2. Not boring.

That said, there's no reason you couldn't have automatic movement in a room based mud that fits your criteria, especially if you have laggy movement (that would probably help you to read any conversation you're having without it getting spammed off the screen). For example Maiden Desmodus has automatic pathfinding (I'm sure many other muds have this), and you could theoretically have conversation during this, though in MD's specific implementation I think that disrupts the pathfinding.
08 Dec, 2009, Greyankh wrote in the 3rd comment:
Votes: 0
I played on a mud, once called Faerun, now called Rauvyon that has a neat mud movement system. On the base part, you move like a normal mud., but when fighting, you enter a tactical mud. It gives an ascii display if you ask for it.

*****
* @ *
* *
*r *
*****
This room would be a 30 x 30 room, which the builders actually have to input. Also, the longer the room, the more normal movement it takes. Now, when there is an aggro mob, if you are not within the adjoining ten feet, you will see the mob travel toward you until it gets close. It is a really involved system. There are quite a few other unique things about that mud as well. The coder is quite good. He implemented a seasonal growing system, a tracking system, and mud footprints and snow foot prints. Mud and snow take more movement to wade through and he implemented a hunting algorithm that certain mobiles hunt players while the player is in the zone or area.

Grey
08 Dec, 2009, Orrin wrote in the 4th comment:
Votes: 0
Idealiad said:
For example Maiden Desmodus has automatic pathfinding (I'm sure many other muds have this), and you could theoretically have conversation during this, though in MD's specific implementation I think that disrupts the pathfinding.

Most actions should be fine without interrupting the pathfinding, certainly speech, emotes, looking around, checking inventory etc.

To the OP, there are several ways to solve the problems you mention. If you're concerned about people moving out of combat range then you could add more ways for people to prevent movement so it becomes easier to trap an opponent in one place. You could also put in a mechanic where you engage an opponent and then they are unable to disengage from combat with you. This would probably combine well with a short range tactical positioning system like Greyankh mentions.

Our standard movement is lagged and you can only enter one direction at a time, though most PCs will train their survival skill so they can run (which moves you with no delay). There's no need to type look as you do a look on entering each room anyway. Our pathfinding system allows you to autowalk to a bunch of different places, though it lags even while running. It's mostly aimed at helping new players find their way around.

Preventing people from traversing the entire MUD in seconds is difficult using a room based system. Capping the frequency of movement commands is a popular solution, but a better way would be to design your game world such that each zone is a discrete geographical area and then link them using a non-room based travel system. For example, if I want to travel on the road between Gnome Village and Orc Village instead of having 5/10/50 almost identical road type rooms linking them I'd simply leave one village and after a short delay, possibly with some themed text scrolling by for me to read, I'd be at the next village. Players may well find the delay annoying after the 100th time of travelling between the villages, but it will certainly stop them from speedwalking all over the game world. You could expand this idea with little instanced zones randomly generated between areas as a kind of MUD equivalent of the classic RPG world map random encounter.
08 Dec, 2009, KaVir wrote in the 5th comment:
Votes: 0
Tonitrus said:
While moving, you can't look around, so if you want to look around, you have to type w, look, w, look, w, look.

In most muds I've seen, you automatically "look" when you enter a room.

There's also another variation of laggy movement that I've seen (on an RPI I believe) - instead of a WAIT_STATE that lags all your input, there's simply a movement delay, so you can still type other commands while you're walking. This also indicates to other players when you're starting to leave a room, giving them the chance to react.

Tonitrus said:
Non-laggy movement … now you can miraculously move across the entire game world in a matter of minutes.

At least you could, if it weren't for one of my least-favourite game mechanics…movement points. I once recall playing a mud where I could move perhaps 3-4 rooms before needing to stop and sleep for a couple of minutes. That's really not my idea of fun.

Idealiad said:
….God Wars 2. Not boring.

But the movement system is definitely one of the biggest stumbling blocks for newbies. Well not complete newbies, they seem to pick it up really fast, but pseudo-newbies (new to GW2 but with experience playing other muds) seem to struggle quite a lot. In fact I actually ended up trying to make movement "feel" more room-based, at least within the starting village.
08 Dec, 2009, Mudder wrote in the 6th comment:
Votes: 0
I know I struggled with it a lot when I was checking it out. Though admittedly I didn't read any help files or do proper newbie stuff. I assumed I could just figure it out as I went along. I didn't. :redface:
08 Dec, 2009, KaVir wrote in the 7th comment:
Votes: 0
Mudder said:
I know I struggled with it a lot when I was checking it out. Though admittedly I didn't read any help files or do proper newbie stuff. I assumed I could just figure it out as I went along. I didn't.

Yup, that seems to be a common problem. There are plenty of detailed help files, but the veterans ignore them. There are also context-sensitive hints that guide you through the first stages of the game, but the first thing many experienced mudders do is switch them off. Then they quit because they've no idea what to do or how to play.

I don't think there's really much I can do about it though - it's not as if I can force people to read the documentation.
08 Dec, 2009, quixadhal wrote in the 8th comment:
Votes: 0
Movement points (or endurance) was one of the ways many Dikurivatives tried to counter being able to move instantly from room to room. You could burst a fair distance, but travel still required time or resources to restore your move points. In my own game, it was pretty typical for people making the trip from the newbie village to the first big city to have a mage cast 'fly' on them. Even then, if you took more than a few wrong turns on the road through the mountains, you'd need to rest in the giant-infested hills before you got there.

Given the choice to do it differently, I think I'd opt for movement to have its own "heartbeat" timer. So, you can queue as many moves as you like, you can specify a distance to move, or even a target, and the movement heartbeat will push you one step along that path every few seconds, unless you enter combat or otherwise stop.

Added bonus, you could have a landmark system (even room based) where once you visit somewhere, you can now have a tag to return to. So, in my earlier example, starting in Shlyar you'd have to find the way to Highstaff, but then you could "goto Shylar" to return. Obviously, you might want the pathfinding algorithm to optimize for movement cost or safety rather than raw speed/distance.
08 Dec, 2009, Xivek wrote in the 9th comment:
Votes: 0
Kavir said:
But the movement system is definitely one of the biggest stumbling blocks for newbies. Well not complete newbies, they seem to pick it up really fast, but pseudo-newbies (new to GW2 but with experience playing other muds) seem to struggle quite a lot. In fact I actually ended up trying to make movement "feel" more room-based, at least within the starting village.


Yeah, everyone I have introduced GW2 to gives up (particularly in the first dungeon) because the movement feels awkward for newbies.

The most success I've ever had with getting the typical mud vet to try out a coordinate-based system is Trenton's DBZ mud. It had a map (no room descriptions) and employed WAIT_STATE, but you could fly x spaces across the map based on your speed stat.

E.g., with 5 speed you could "fly 5 e" and instantly teleport to that location on the map, leaving a aura trail in the rooms you moved across.
08 Dec, 2009, KaVir wrote in the 10th comment:
Votes: 0
quixadhal said:
Given the choice to do it differently, I think I'd opt for movement to have its own "heartbeat" timer. So, you can queue as many moves as you like, you can specify a distance to move, or even a target, and the movement heartbeat will push you one step along that path every few seconds, unless you enter combat or otherwise stop.

That's roughly how my movement system works, except the moves aren't "queued", but instead each move automatically adjusts your target destination. So typing "north 1 mile" sets your target to 1 mile north, and typing "north 1 mile" again moves your target an additional mile north. If your feet are in a movement position (walking, jogging, etc) you'll automatically move a number of feet per second based on your movement rate until you reach your destination.

During combat your target will be your opponent, and you will therefore move relative to them (charging towards them, retreating away from them, circling around them, etc). The one exception is mounted combat, as your mount has its own separate target and will handle the movement - thus it's possible to have your horse galloping towards a forest while you fire arrows into the player who's chasing after you.

quixadhal said:
Added bonus, you could have a landmark system (even room based) where once you visit somewhere, you can now have a tag to return to. So, in my earlier example, starting in Shlyar you'd have to find the way to Highstaff, but then you could "goto Shylar" to return.

I support that as well, although it always takes the shortest route (a straight line), and doesn't work so well with certain terrain such as winding rivers. I should probably put a bit more work into it.
08 Dec, 2009, Kline wrote in the 11th comment:
Votes: 0
I still use a very standard movement system with the only notable changes being most movement has a very slight delay, but you can gain spells or other bonuses to make it faster (certainly a combat advantage when fleeing/chasing a person). Also after 5 or 6 sequential movement commands (admin settable, user toggleable) you switch into "speedwalk" mode and are only displayed the room name and visible exits until you perform a non-movement command.
08 Dec, 2009, Skol wrote in the 12th comment:
Votes: 0
I've used the standard Diku room/movement system and actually am looking at a number of changes. One thing I did was to institute room sizes (x/y only currently, assumed 'cube'). I'm looking at a MV_WAIT_STATE rather than simply WAIT_STATE for lag for the reasons above, I had the same conclusion.

I used to have a modern spy mud that was a blast, but I approached movement differently there. Rather than increase a players move points as they level or anything like that… I did 30/60 (walk/run), different wait state lags, and movement refreshing every tick update. It's interesting for sure, and I'm sure somewhere in between is the solution I want.

I'm thinking of a few 'lags', movement, combat (kick/bite/bash etc), casting. I already have delayed actions where a player is 'doing' something and can use informational commands while in progress, only stopping if he chooses to do a different action. But I haven't decided if I want something like that for movement, as it's generally pretty fast. Speeds though I think I'll end up with: godspeed (no lag), hasted/running, walking, sailing (sailing WILL most likely be a delayed action so you can 'sail north' and be doing things on the ship).

Anyway, great discussion. I've gone over movement tons of times in my head, paper/blah code, even experimented on my bases.
08 Dec, 2009, David Haley wrote in the 13th comment:
Votes: 0
I'll fess up straight away: I only skimmed the posts thus far.

That said, it seems that your problem has nothing to do with movement, really, and everything to do with lame command queuing systems. There's basically no reason that you shouldn't be able to simply cancel all pending actions. Of course, since the MUD implements "queuing" by forcing delays in between commands, this is impossible, but if you reworked the MUD to create "lag" by processing all input and sticking things into a timed queue, you could allow commands like "clear queue" to be processed immediately and do the obvious thing.

I think that this problem is wholly orthogonal to issues of coordinates, running, etc.
08 Dec, 2009, Runter wrote in the 14th comment:
Votes: 0
In the past I ran a MUD that used both diku style room/movement system and an overmap/wilderness/worldmap system for travelling over large distances.

Inside of the typical diku style room system on this MUD I disabled the movement point system completely and made it free. However, I still used a movement value for the wilderness system that could require a camp to be setup along the way. (Giving away your position from miles away with a smoke ploom.)
08 Dec, 2009, Mudder wrote in the 15th comment:
Votes: 0
Personally I like the idea of movement points. It adds a sense of realism and a limiting factor for PK.

Many might argue that realism can go too far, and it can, but I don't think movement points does. I would compare it to mana points.
09 Dec, 2009, Tonitrus wrote in the 16th comment:
Votes: 0
KaVir said:
Tonitrus said:
Non-laggy movement … now you can miraculously move across the entire game world in a matter of minutes.

At least you could, if it weren't for one of my least-favourite game mechanics…movement points. I once recall playing a mud where I could move perhaps 3-4 rooms before needing to stop and sleep for a couple of minutes. That's really not my idea of fun.

Movement points are pretty terrible. I did find a way to make them vaguely less obnoxious though, when I was thinking of running a Smaug PK mud. I moved the movement update to every round so that being out of movement only slowed you down a lot instead of making you stand hopelessly still. This was assuming a system where everyone isn't flying all the damn time, of course. Still not fond of it, though.

KaVir said:
There's also another variation of laggy movement that I've seen (on an RPI I believe) - instead of a WAIT_STATE that lags all your input, there's simply a movement delay, so you can still type other commands while you're walking. This also indicates to other players when you're starting to leave a room, giving them the chance to react.


KaVir said:
quixadhal said:
Given the choice to do it differently, I think I'd opt for movement to have its own "heartbeat" timer. So, you can queue as many moves as you like, you can specify a distance to move, or even a target, and the movement heartbeat will push you one step along that path every few seconds, unless you enter combat or otherwise stop.

That's roughly how my movement system works, except the moves aren't "queued", but instead each move automatically adjusts your target destination. So typing "north 1 mile" sets your target to 1 mile north, and typing "north 1 mile" again moves your target an additional mile north. If your feet are in a movement position (walking, jogging, etc) you'll automatically move a number of feet per second based on your movement rate until you reach your destination.

During combat your target will be your opponent, and you will therefore move relative to them (charging towards them, retreating away from them, circling around them, etc). The one exception is mounted combat, as your mount has its own separate target and will handle the movement - thus it's possible to have your horse galloping towards a forest while you fire arrows into the player who's chasing after you.

I was thinking of a system a lot like what quixadhal was suggesting.

If I'm reading this correctly though, the RPI version would be something like this:

> west
> west
> north

And while I wait, it goes through the commands, in order, "west, west, north".

If it were Godwars2, how would it be handled? You said movement alters the destination, so would it be "west, northwest"?

If I'm understanding the GW2 system correctly, it seems like it would be very confusing.

I was thinking of having movement commands a little more odd. Instead of specifying a specific path, you specify a … direction. The movement command "nw", for example, would just move n,w,n,w forever, until you chose to stop. Or if you wanted to move in a more interesting route, you could use numbers. 5en would run e,e,e,e,e,n over and over again. I was thinking that for specifying a number and stopping, you could do something like 5#n or something. I'm still not sure how great an idea this is.

I did think of queuing moves, but not having movement commands shift a destination, exactly (except that I'd thought of having certain movement commands for moving toward a moving target or object (advance, retreat, flee, circle, that sort of thing)).

Reading through these posts also made me rethink something else I'd considered having. Instead of one command queue, I could have a few. "free actions", "normal actions", and … maybe "partial" actions, or something. That way when using laggy commands, you could still speak or move, unless the particular type of lag you were experiencing prevented such things. I'm not sure if that wouldn't be a better movement system than my "directions" idea, but I'm still not fond of the staccato motion of mud movement. I guess it could also lead to weirdness where the different types of actions might get synced up in unpredictable ways.

I anticipated that veteran mudders would be very fussy about any change to the movement system, so I figured I'd have a "step" mode, where each movement command only moves the person one room in the specified direction. That's probably the best mud movement idea I've had.

I like the idea of coordinate-based movement a lot because you could track velocity and use it for hilarious things like casting spells to create ice sheets and watching people fall and slide the direction they were already running, which you have conveniently lined up with a cliff.
09 Dec, 2009, David Haley wrote in the 17th comment:
Votes: 0
Tonitrus said:
I was thinking of having movement commands a little more odd. Instead of specifying a specific path, you specify a … direction. The movement command "nw", for example, would just move n,w,n,w forever, until you chose to stop. Or if you wanted to move in a more interesting route, you could use numbers. 5en would run e,e,e,e,e,n over and over again. I was thinking that for specifying a number and stopping, you could do something like 5#n or something. I'm still not sure how great an idea this is.

Honestly, I think that this sounds kind of disastrous unless you have a full coordinate-based MUD that makes assumptions about most movement taking place on open spaces.

Tonitrus said:
but I'm still not fond of the staccato motion of mud movement.

Your movement will be as gross as your spatial granularity; if all you have is rooms then your movement will stutter from room to room. If you want it to be smoother, you must introduce more granularity in your spatial system, which opens up all kinds of unpleasant worms, because spatial information affects far more than just movement.
09 Dec, 2009, Tonitrus wrote in the 18th comment:
Votes: 0
David Haley said:
Tonitrus said:
I was thinking of having movement commands a little more odd. Instead of specifying a specific path, you specify a … direction. The movement command "nw", for example, would just move n,w,n,w forever, until you chose to stop. Or if you wanted to move in a more interesting route, you could use numbers. 5en would run e,e,e,e,e,n over and over again. I was thinking that for specifying a number and stopping, you could do something like 5#n or something. I'm still not sure how great an idea this is.

Honestly, I think that this sounds kind of disastrous unless you have a full coordinate-based MUD that makes assumptions about most movement taking place on open spaces.


I'm assuming that by disastrous you mean "prone to causing disaster" and not "that's a terrible gameplay feature". The idea when I was toying with it is that you could basically just type out a general course and then make "corrections" to it. I'd also probably auto-stop people in dangerous terrain. For example, I don't think a person should be able to easily walk into a deathtrap that isn't somehow concealed unless they are blind or 'assisted' in that direction. Whether or not it'd be a terrible gameplay feature, I couldn't say.

Thinking about it now, I'd be inclined to have 3 travel modes. A "step" mode for people who really want to move that way, my crazy direction idea mode (assuming I don't scrap it), and a mode with something akin to queued movement. Presumably then everyone could find a mode of moving that they don't hate.

David Haley said:
Tonitrus said:
but I'm still not fond of the staccato motion of mud movement.

Your movement will be as gross as your spatial granularity; if all you have is rooms then your movement will stutter from room to room. If you want it to be smoother, you must introduce more granularity in your spatial system, which opens up all kinds of unpleasant worms, because spatial information affects far more than just movement.


I'm not sure what you're referring to. I know there are many side-effects of having a co-ordinate system, and most of the ones I've thought of are desirable. I don't necessarily need a lot of granularity, though, what I meant by "staccato" is that a guy who has just typed in west 50 times as fast as he can spam them can stop on a dime by simply not typing anything else, or worse, make a 360 degree turn and head east instantly. Even with some sort of queued movement + "heartbeat" system, the moves are going to be burst-prone in that movement will only occur on the "heartbeat". This is accepted as a constraint of the genre, and, honestly, a great deal of granularity in a text game (in either text-display or on an ASCII map) would be more irritating than useful.
09 Dec, 2009, KaVir wrote in the 19th comment:
Votes: 0
Tonitrus said:
If I'm reading this correctly though, the RPI version would be something like this:

> west
> west
> north

And while I wait, it goes through the commands, in order, "west, west, north".

I don't remember trying it, but I have a feeling it doesn't allow you to queue directions. Of course there's no reason why you couldn't queue directions if you implemented something similar.

Tonitrus said:
If it were Godwars2, how would it be handled? You said movement alters the destination, so would it be "west, northwest"?

The first command would set your destination 1 plot west from your current position, the next would change that to 2 plots west and the third would change it to 2 plots west and 1 plot north. You'd end up moving to a position 2 west and 1 north exactly as you would by queuing movement commands in a room-based mud, but the difference is that you'd walk there in a straight line instead of zigzagging.

Tonitrus said:
I was thinking of having movement commands a little more odd. Instead of specifying a specific path, you specify a … direction.

Well you could effectively do that in GW2 by typing something like "north 500 miles".
09 Dec, 2009, Scandum wrote in the 20th comment:
Votes: 0
KaVir said:
quixadhal said:
Added bonus, you could have a landmark system (even room based) where once you visit somewhere, you can now have a tag to return to. So, in my earlier example, starting in Shlyar you'd have to find the way to Highstaff, but then you could "goto Shylar" to return.

I support that as well, although it always takes the shortest route (a straight line), and doesn't work so well with certain terrain such as winding rivers. I should probably put a bit more work into it.

What more or less worked for me was adding roads, road signs, and allow players to travel along roads until the next intersection, which is fairly easy to add as you only need to remember the direction the player came from to find the next direction to take.
0.0/110