25 Dec, 2010, DemiGod wrote in the 1st comment:
Votes: 0
I was hoping someone that has coded both a normal room system and a coordinate system could tell me what they preferred using in a MUD and whether or not a coordinate system is much more of a hassle to implement.

To define a coordinate system, take the example of a building courtyard, just outside. In the courtyard, you can climb a tree, take cover behind a car or move 10 rooms through the building to look down from a window again on to the courtyard.

Each of these rooms [i.e. in the tree, window and behind the car] are all actually part of the same larger room. I was told that a coordinate system would allow for this.

What are people's experience with this kind of system? Is this the best route to take or are there other ideas you can lay on me?
25 Dec, 2010, Cratylus wrote in the 2nd comment:
Votes: 0
DemiGod said:
What are people's experience with this kind of system?


Trigonometry, mostly. And surprises. Trigonometry and surprises.
25 Dec, 2010, DemiGod wrote in the 3rd comment:
Votes: 0
While I understand what both trigonometry and surprises both are individually, I have no clue what you're talking about.
25 Dec, 2010, Cratylus wrote in the 4th comment:
Votes: 0
DemiGod said:
While I understand what both trigonometry and surprises both are individually, I have no clue what you're talking about.


Why would you be hiding behind a car? Because you want to avoid someone's line-of-sight.

How does the mud figure out whether the car is between you and your seeker?

It has the coordinates of three objects. You, your seeker, the car.

Surprise! Trigonometry!

-Crat
http://lpmuds.net
25 Dec, 2010, KaVir wrote in the 5th comment:
Votes: 0
DemiGod said:
I was hoping someone that has coded both a normal room system and a coordinate system could tell me what they preferred using in a MUD and whether or not a coordinate system is much more of a hassle to implement.

I've coded both, as well as a couple of hybrid systems, but I prefer full coordinate-based systems. The basics are pretty easy to implement, but it can require a lot of work to flesh it out and polish it, and it'll have an impact on many other parts of the mud design. It's not something I would ever recommend changing in an established codebase.

However the real challenge isn't one of implementation, but of familiarity and acceptance; movement is an integral part of the mudding experience, and many players can't accept sweeping changes to the way it works. Personally that's a price I'm willing to pay, because it's an essential part of my mud concept, but I wouldn't recommend thinking of it as a selling point.
26 Dec, 2010, Idealiad wrote in the 6th comment:
Votes: 0
@KaVir, Speaking of acceptance, has anyone added key commands like WASD or the arrow pad to mushclient for movement?
26 Dec, 2010, Ludwig wrote in the 7th comment:
Votes: 0
I played a Resident Evil mud where each "room" had X,Y coordinates (invisible to the player) and the view was top-down, the way roguelike game look. Guns would only fire in the 8 compass direction, so you had to line up with your target to hit it. Shotguns on the other hand would fire in a crude cone in one of the 8 compass directions. It had line of sight, so tall objects and walls would have blackness behind them (from your point of view). Items were visible on the ground, but you couldn't interact with them unless you were adjecent to or on top of them. Every time you took a step the screen would redraw the room and update the objects, the characters, your new field of vision, etc. I personally liked it a lot. I didn't have trouble adjusting to the coordinate system because the movement system and map were so intuitive and fast-responsive.

Sorry that I can't offer any coding perspective. I only played it.
26 Dec, 2010, David Haley wrote in the 8th comment:
Votes: 0
Idealiad said:
has anyone added key commands like WASD or the arrow pad to mushclient for movement?

This is tricky, because MUSHclient does not support character mode (sending characters one at a time as opposed to sending when return is pressed). So you need to use macros (which you can for the arrow keys) to send a command instead. But you can't use macros for the WASD keys.
26 Dec, 2010, DemiGod wrote in the 9th comment:
Votes: 0
Ludwig, that actually does sound very intriguing. I believe that is more complex than I would prefer to implement in this MUD but it definitely gave me some things to think about.

Thanks to all for the input.
26 Dec, 2010, quixadhal wrote in the 10th comment:
Votes: 0
The other major difference between a FPS-style MMO, and a text MUD, is that commands are always discrete (so far!) in text games. In most MMO's, you push down 'W' (or up-arrow) to begin moving forwards and let go of the key to stop moving. Even character-mode won't give you access to the keyup/keydown events you'd need to properly implement that style of gameplay.

For that, I believe you'd need to go down to the termio layer, and that puts you into a world where you have to care more about exactly what system you're running on.
26 Dec, 2010, Cratylus wrote in the 11th comment:
Votes: 0
DemiGod said:
Ludwig, that actually does sound very intriguing. I believe that is more complex than I would prefer to implement in this MUD but it definitely gave me some things to think about.

Thanks to all for the input.


Interestingly what he described are largely compromises in a hybrid coord/room system which actually
point to a system *simpler* than the one you talk about in your OP.

I think you should probably have a firm idea of *exactly* how your mud should work, and then ask questions.
I get the strong feeling you have less of a grasp on your intended gameplay than you know.

-Crat
http://lpmuds.net
26 Dec, 2010, KaVir wrote in the 12th comment:
Votes: 0
quixadhal said:
The other major difference between a FPS-style MMO, and a text MUD, is that commands are always discrete (so far!) in text games. In most MMO's, you push down 'W' (or up-arrow) to begin moving forwards and let go of the key to stop moving. Even character-mode won't give you access to the keyup/keydown events you'd need to properly implement that style of gameplay.

That's a client limitation rather than a server one. You could (for example) do it with the mouse buttons using certain mud clients, and personally I'd prefer overhead or isometric (which are often controlled by mouse) rather than first-person anyway.
26 Dec, 2010, quixadhal wrote in the 13th comment:
Votes: 0
KaVir said:
quixadhal said:
The other major difference between a FPS-style MMO, and a text MUD, is that commands are always discrete (so far!) in text games. In most MMO's, you push down 'W' (or up-arrow) to begin moving forwards and let go of the key to stop moving. Even character-mode won't give you access to the keyup/keydown events you'd need to properly implement that style of gameplay.

That's a client limitation rather than a server one. You could (for example) do it with the mouse buttons using certain mud clients, and personally I'd prefer overhead or isometric (which are often controlled by mouse) rather than first-person anyway.


It's a client limitation, but it's one that can't easily be worked around unless you require a custom client. It's easy to catch keydown/keyup events (or mouse, if you prefer) for a particular platform, and send commands like "beginmove north", "endmove" for the server to handle. However, this puts anyone using a plain telnet client at a distinct disadvantage, since they now have to type commands to start and stop movement. How much of a disadvantage depends on how quickly movement happens, and how much it affects gameplay. Non-combat movement is probably not a big deal, but positioning in combat would be a terrible handicap.
26 Dec, 2010, KaVir wrote in the 14th comment:
Votes: 0
Well you could always grab the source code for MUSHclient or Mudlet or whatever and modify it. When you're talking about creating a FPS-style interface, I think it pretty much goes without saying that you're going to need some sort of customised client, and you're likely to deal with much more difficult things than catching keypress events.

But you don't need any of that for a coordinate-based system.
27 Dec, 2010, Scandum wrote in the 15th comment:
Votes: 0
Not overly difficult to add continual asdf movement with TinTin++, though it would require a little bit of scripting knowhow to do it elegantly. The actual maps would be pretty poor, but even with the best efforts 2d maps will look 1994 at best. In other words, it'd be a pathetic imitation of a 3d MMO.

I think dynamically described line of sight descriptions would be a more immersive solution, but as far as I know it's incredibly difficult to create a good generic dynamic description engine as you'd need a decent physics engine as well in order to describe the surroundings properly. Modern MMOs are still in the builder generated content era (almost no dynamic content), so this is one of a few areas where MUDs can be truly competitive.

I'm not aware of any bare bone bases that provide physics with dynamic descriptions.

If you go for a coordinate system I'd suggest using a tile based approach - keeping in mind that a 15x15 tile can be easily displayed as 5x5 or 3x3 while a 13x13 tile (being a prime) scales poorly. Not sure if even (20x20) would be easier than uneven. I'd also go for dynamic tiles with a shared pointer grid, as static tiles (as used in most wilderness implementations) will be severely limiting.
27 Dec, 2010, DemiGod wrote in the 16th comment:
Votes: 0
My ignorance in the complexity of coding these systems, I will admit, is great. What I am hoping to accomplish, however, is quite clear.

I would like to make connection between the two and I don't plan to incorporate anything like this ResEvil system. I was actually planning to keep it somewhat simpler [in theory], reiterating that code-wise, I don't know what it will take to implement just yet. This is why I enjoy hearing all of your stories to both give me ideas as well as solidify my own.

Maybe you can tell me if my logic in this system makes sense from a programmers standpoint. Keep in mind that these numbers are theoretical and can be changed, they are not chosen for exact measurement just yet. I'd like to first design the concept:

I would prefer to keep most rooms as single rooms. Certain rooms, however, will incorporate the idea of having a window in a building able to look down, snipers on mountain sides, etc. Distant players or mobiles, essentially. In the main room, and in other "standard" rooms, objects would be placed that have coded properties that allow you to take cover. Let's use a car, for example.

A player would take cover behind the car. The car's properties would add defensive bonus to the player as well as make him hypothetically "invisible" to other mobiles [let's not consider other players just yet]. The mobile will scan the room for adjustments in player behavior every 5 seconds or so, or if the mobile suddenly has no one to attack. Now that the player has hidden behind the car, the mobile senses it has no opponent, so it scans its surroundings. The player it not actually invisible, it has just changes status in the room. The mobile now sees this new status and as it attacks the player, the defensive properties of the object is now aiding the player. The mobile can change tactics due to this as well, possibly by throwing a grenade. How the grenade would find the player behind that car instead of the one by the tree 20 meters away, I don't know yet. I don't visualize just yet without having a coordinate-type system.

The same properties can be applied to mobiles or other players. Hence, the cover system is created by objects, rather than "sub-rooms" if you will. What are your thoughts on this from a programming standpoint? Is it more complex or less? Am I missing something in the logic that would be important when coding this type of system?
27 Dec, 2010, Runter wrote in the 17th comment:
Votes: 0
I'm using SDL for the client I'm working on. That's how I catch the wasd key events.
27 Dec, 2010, Cratylus wrote in the 18th comment:
Votes: 0
DemiGod said:
Maybe you can tell me if my logic in this system makes sense from a programmers standpoint.



DemiGod said:
A player would take cover behind the car. The car's properties would add defensive bonus to the player as well as make him hypothetically "invisible" to other mobiles [let's not consider other players just yet]. The mobile will scan the room for adjustments in player behavior every 5 seconds or so, or if the mobile suddenly has no one to attack. Now that the player has hidden behind the car, the mobile senses it has no opponent, so it scans its surroundings. The player it not actually invisible, it has just changes status in the room. The mobile now sees this new status and as it attacks the player, the defensive properties of the object is now aiding the player. The mobile can change tactics due to this as well, possibly by throwing a grenade. How the grenade would find the player behind that car instead of the one by the tree 20 meters away, I don't know yet.



Does it make sense? Sure, of course it does.

It sounds like what you're really asking is "is this hard?"

Based on your posts thus far, and the fact you have to ask, yes, it will be hard for you.

It should also, however, be rewarding and fulfilling, if you actually do it.

My original response might have seemed pointless and dismissive to you. "Surprises and trigonometry".

It was meant to be intriguing and thought-provoking. When I embarked on my hybrid coord project
I had little idea what I was in store for. It made me think about my codebase in new ways, and
forced me to come up with answers to problems with tools I had intentionally avoided earlier in
life due to their apparent uselessness. It made me realize that high school math actually did
have something worthwhile to it. It made me look at my favorite codebase in ways very different
than its original authors had intended.

At the risk of once again seeming dismissive, I think that the only useful answer to your questions
involve you sitting down and starting to write code that does what you want. Very quickly your ideas
of what your gameplay should be will be distilled to their most salient essentials, and the questions
you then have will be very clear and subject to straightforward answers by people who have been there.

Until then, it's hard to answer a question very much like "what is it like on other planets and how
would I get there?"

Depends on where you're going and what you're prepared to do to get there.

-Crat
http://lpmuds.net
27 Dec, 2010, DemiGod wrote in the 19th comment:
Votes: 0
I have others who are coding the hardcore aspects of this MUD. I'm actually just looking for outside input whether or not there are parts of this logic that can be refined.
27 Dec, 2010, Scandum wrote in the 20th comment:
Votes: 0
You'd probably want to go for room templates still. Make each room 15x15x15 or something and allow placing furniture in it. Next add a variable that determines where the player is, and what direction he is facing.

If you do this correctly you can let characters climb onto cars, climb through windows, climb down a ladder to the room below, or with the right skills, up through cracks in the wall. Line of sight would be next, which can start of really simple by not seeing someone that walks into the room from behind you. If you let players take up space you can add commands to climb on players, and allow this as an aid to get over fences and other obstacles, while primarily allowing someone to get passed an idling player in a narrow alley, though all out pk is a solution to this problem as well.
0.0/51