I'm sketching out some ideas here and I'm interested in what people have to say about it.

Notes on a text game in a '3D' world.

Premise:

• It's not necessarily a good idea to play a mud in 3D.


• You can get a lot of the same stuff done with a traditional room/node layout.


• However a modeled 3D space does afford you some stuff 'for free'.


• I want to strike a balance between simulation and abstraction; the player experience is key.

Building blocks:

- Cells

• x and y are horizontal coordinates, z is vertical.


• A xyz coordinate represents not a specific point in space but a cell.


• A cell is roughly, in feet, 5x5x5, but its size is basically indeterminate and elastic. A humanoid sized player's head won't stick out of the top of a cell for example.


• A cell can be larger in one dimension than another, but 'not by enough to matter'


• The specific size of a cell is not totally important.


• You can think of a cell as a small room in a traditional mud.


• The cell abstraction is an attempt to simplify a coordinate system.

- Layers

• Cells are arranged in a 2D grid on a layer.


• So a z coordinate represents a layer.


• Opaque cells in a layer can block line of sight.

- Building

• Builders create maps in an ascii editor.


• The text representation is procedurally generated.


• Cells can belong to a common space, and that space can have descriptors on it as well.

- Movement

• Players still move with cardinal and ordinal directions, and up/down.


• A cell with a portal/exit property lets a player enter its name to enter its destination. The exit property would have a range in cells that specifies how close a player has to be to enter it, and this could depend on character skill.


• These named exits are not only for special enterable rooms, but to simplify navigation in open spaces, so players don't have to type a direction to move cell-by-cell.


• If a player is next to a climbable cell and the layer above is open, they can climb the cell surface to the next z-layer (depending on character skill of course).


• Movement should keep track of player facing.


• A cell can hold only one actor, but multiple objects, it's not based on real-world physics.

- Distance

• Touching and contact melee (knives) means adjacent cells.


• Short range melee (swords) is one cell away.


• Long-range melee distance (polearms) can be two cells (about 10 feet) away.


• Diagonals for our purposes are not longer than orthogonals.


• Ranged weapons have ranges in multiples of cells


• Distance is represented to the player in multiples of 5 feet, based on cell distances, and adjacency is 'next to you'.

You may wonder why not create a full 3D representation – why the abstraction of cells. The idea is to try not to create a perfect simulation in the first place and then translate that in text so it makes sense, but to simplify and abstract the model in the first place so the translation becomes easier. I'm curious if anyone thinks this will inherently cripple the model and the gameplay.

I don't really understand why you have "cells" as opposed to just points in space, with coordinates being whole numbers only instead of decimals. I guess it doesn't make much of a difference since your cells essentially are just places that people can occupy, considering that they don't really have a size, they're elastic, etc.

The hardest thing in my mind is displaying this information usefully to the player, and letting them manipulate it. If you have detailed positioning like this, then it's very likely that position will matter for things like combat tactics. In that event, people might want to give rather specific instructions regarding placement. The thing is that it could be difficult to see an always-up-to-date map of the surroundings, if you're using a normal text client: you can't exactly constantly spam the map. Commands would have to be extremely intentional in nature: instead of saying "east,east,north" to go behind Bob, you might want commands like "try to get behind Bob". Bob might have to choose to face you, and expose his back to Fred, or continue facing Fred knowing you're circling around. The point being that when you cannot interface very naturally with your positional world, you need to defer control of your avatar to higher-level commands, and let some kind of simple AI figure out how to carry out those commands.

This is what I think is the most complicated problem with detailed positional information, in any case. I'm curious how this is coming along for you.

There are other interesting/fun problems like line of sight determination, but that might be another question for another day.

I'll go a step beyond and suggest that this won't end well without a custom client, or more specifically, by letting players pick any old client. There are a few clients that support custom windows, and you'd probably want to use those in order to separate out information in meaningful ways.

One of the conceptual phases of my project went along these routes, very closely, another question you might ask yourself here is player positioning. If melee combat occurs between cells, does that mean only one player can occupy a cell? If so, how do you plan to handle moving through cells blocked by players. How will you prevent players from blocking an exit for griefing purposes (and they will). If not, you should be prepared to watch players stack up on one or two cells in situations of mass combat.

What is the underlying goal here? What is it that you want to do that makes you reach for 3D space? It might be better to figure that out and then try planning around it. If the goal is to make a graphical game someday, then you should just start that now even if you use stickfigures and MS paint. As an example, the reason we stretched for this was to add more strategy to group PvP as well as allow for vehicles. In the end we ended up with the traditional room model and a general 'region' layer behind\above it. It's still basically co-ordinate based, so the game checks your coords and if there's a room there it gives you the room info. If there isn't a room there it gives you the zone\region description. In general, players can't move outside of the room structure unless they're in a vehicle, and if a vehicle occupies a co-ord with a room in it you can interact with it like an object. A vehicle itself is just another collection of rooms, and because we have a custom client we can provide you a view of the 'outside' (assuming you're in a part of the vehicle from which you can see it) while still letting you see 'inside' the vehicle.

The point is, why do you want this system? And once you have that clear, is this really the best way to make it happen? It sounds like you've been giving it some thought, so keep fleshing it out and see where it takes you.

That's a very good idea, and what I'm aiming for. I have a similar thing going with basic movement, where players can move toward landmarks, or if they choose, control cell movement with east, east, etcetera.

The main reason I'm working with cells is to try to bring the abstraction of the space, which is communicated to the player, closer to the model of the space. The idea being that the model doesn't have to be perfect, so maybe by bringing the model and the abstraction closer conceptually, that'll make things easier to communicate.

For things like line of sight, there are some 3D field of view algorithms I can work with that are well established. That field is pretty new to me though.





While I like and have used clients with multiple windows, and Flash interfaces with different panes and so on, I'm hoping to keep this intelligible in one text window. My main inspiration here is GW2. Of course, adding the z axis may bone the whole deal. ;D

To answer your question about cells, yes only one creature can occupy a cell. My main inspiration here are roguelikes. There is an outstanding problem with that though, with very small creatures (like the size of a bat for example). It may work out that a very small creature and a creature larger than that can share a cell.

Players will indeed be able to block cells, and a very powerful player could easily hold a single-celled exit. However I don't think griefing would be a symptom of cell space necessarily. Other than area design, there are of course other things you can do about griefing to make it less problematic.




I agree this is a very important question, and I have seriously considered doing this with a room/node structure. Other than the obvious hobbyist enjoyment of doing something like this, 3D space works well with the mud idea though. First of all the basic concept is a city of twisting canals, alleys, and rooftop pathways, tall twisted towers and subterranean domains. 3D space adds a lot to making a city like this work well. The main gameplay is with thieves going around stealing the stuff of the wealthy, real estate developers claiming land and putting up buildings, religious leaders creating movements and controlling city neighborhoods, alchemists discovering formula and summoning beings from other planes, and politicians trying to keep everything in order. All the characters can claim resources in different parts of the city. I really want to make the world space an essential part of play and I feel 3D space will add a lot to that.

Random thoughts:

1) If I use a powerful explosive spell to blow a hole in the ground and the crater happens to intersect with a section of underground tunnel which has the same XY coordinates as my current location (but a different Z coordinate) does this create a permanent new "up" exit from the tunnel to ground level, and a permanent "down" exit from the ground into the tunnel system?

2) Is your line-of-sight system detailed enough to detect whether a player inside a house can see a player outside the house through a window, depending on the outside player's exact position? If you're standing in the middle of a plain, does the system detect that you cannot see a player immediately to the north because he's in a valley, but you can see a player further to the north because he's standing on top of a hill, and you can't see a player even further north because he's behind the hill?

3) How do you handle flight and levitation? Or, what happens in the underwater sections of large, flooded caverns? Do you have freedom of movement in 3D space? How do you handle a player riding on the back of a giant dragonfly hovering directly overhead (out of melee range) and dropping rocks on your head?

In theory destructible terrain works fine, but of course for gameplay reasons this has to be handled with care, either by filling in over time destroyed terrain (walls are rebuilt, tunnels collapse and so on), or only allowing it in certain regions (which are still repaired over time). I do like the idea of buildings being laid to waste. :grinning:





Yes, this is one of the things you get 'for free' with a cell system (or I should say, coordinate system). There are always corner cases and the field of view will not be perfect.




You do have full freedom of movement, so it all works as you expect. The flying mount, for example, would simply be out of range, but if in line of sight, accessible to ranged weapons. Creatures can take up more than one cell, though, so a flying creature plus a rider might not fit in certain areas. Swimming wouldn't be much different than DIKU swimming, it's just in 3D.

Area design plays a large role here – the terrain is not necessarily generated, but mapped by a human instead.

An additional way to deal with movement is to allow targeting a location or object, then move towards it or away from it. Combined with line of sight handling this would allow walking towards a distant volcano, or a nearby tree.

Another useful mechanism is the usage of roads and road signs, with commands that allow to automatically follow a road until the next intersection.

Facing with direct cell manipulation would be difficult, I suppose you could "face east" to make your character face east, or shorthand to "fe"… Also, what about ne/nw/se/sw directions?

Actually I want to avoid a 'face x' command if possible. Otherwise you get the lighthouse effect, where players will want to spin around to make sure they're not missing anything, and I don't really see that as compelling gameplay. For that reason field-of-view will not be limited to the 'facing cone', and things like sneaking up on someone's back will work more like a DIKU backstab – so if the character is stealthy enough, they'll simply be absent from the other character's field of view.

Instead facing should be a result of other commands, such as targeting and movement. So, unless you are specifically targeting something and moving in a different direction (strafing for example, or retreating while shooting) you'll always face in the direction of travel.

Slightly orthogonal to your main discussion, but one of my classmates wrote an ASCII-rendered 3D engine for his freshmen project. So there's no reason a MUD can't display very simple ideas of a 3D space to players. ;)

I would be a bit wary of using true 3D though. Even in pen-and-paper games, 3D doesn't work too well. The problem is that we as humans think in terms of 2D far better than we do in 3D for things like maps, directions, tactics, and position. I'm inclined to believe that's more because we've all been using 2D maps and displays our lives rather than 3D holo-displays our whole lives (even in-game maps in 3D games generally get rendered as 2D).

We can _see_ objects in 3D very easily, but we have a hard time conceptualizing objects in 3D space.

That said, you can use a vector-based 2D space pretty much all the same as you're plans for 3D. It's more an issue of how you decide to structure your world than anything wrong with your idea for the code and technology behind it.

I agree. I'm basically putting in the "lighthouse effect" automatically; players will always see all things around them. Stealth will not involve so much being outside the field of vision, but rather hiding behind objects to block the field of view, or using invisibility etc. to make yourself not appear in the first place. It's somewhat comforting that you have thought about this as well and came to a very similar conclusion. :smile:


I wouldn't underestimate the potential for griefing. You can only have so many ways into a building, for instance, so it only takes a very small number of people to block it off. This can be disruptive for experienced players who then have to fight their way in – arguably, this is a feature! – but it can be extremely disruptive for newer players or less experienced characters who don't necessarily know what's going on, or simply can't get around the character.

I'm thinking about having to block cells explicitly. So, your presence in a cell does not prevent passage through the cell, even if only one person can be at the cell at a time. (This can get weird with "crowds" and I haven't figured that out yet.) But, a character can "barricade" the cell, at which point you have to force your way through; I wouldn't necessarily make this combat, but perhaps some kind of agility or strength check, essentially just pushing through or quickly moving around. There could be a third level, where you are not only barricading, but also will actively try to attack any hostile that tries to come through. (This would be indicated to the people trying to pass through, as well.)


I agree completely. There comes a point where there is so much information to be displayed, that it becomes far too difficult to say it in text. We see and parse maps far more quickly than text. Furthermore, you cannot give a real-time updated map if you're spamming the main text window.


Heh. I should probably just bite this bullet some day. So much of what I want to do is just very difficult in text. Graphical games add not only the problem of art (but there are many free tilesets out there for 2d graphics) – the problem of writing an engine is non-trivial as well. It's just that much more stuff to deal with.

While I like the idea of allowing free passage through an occupied cell if the occupier is not actively blocking, I think it has one big problem – the player then would have to specify when they wereblocking, and in a combat situation this could lead to problems. I guess you could say that you always block someone you're fighting, but what if you're fighting a group of enemies – do you need to specify blocking for each enemy you're not actively engaging? If you automatically block in combat, you could allow people in your group to pass – but then what about a friend that arrives who isn't in your group? If blocking exits (whether intentionally or unintentionally) is the main concern there may be other mechanisms to address this issue.




Of course I agree that we parse maps more quickly than text. However I admit that I have always been curious if the conventional wisdom that a text 3D game is untenable holds water. My experience playing GW2 has fed this curiousity, because in that game you do not necessarily refer to an ASCII map every tick during combat, indeed you'd probably get killed if you did. What happens instead for me, and this may very well highly depend on the particular player in a text game, is you create a looserepresentation of where mobs and players are relative to your PC.

A text mud actually has an advantage here. Compared to a graphical game you do not need to be very accurate or precise when targeting something for melee or ranged combat, or for any action really, if the command is abstract enough (and using targeting as was discussed earlier). So while in a graphical game a map is highly important so you can position your character to execute a successful attack, in a text game you do not need that kind of spatial information. My speculation is that as long as the number of things is not too big, you can hold in your head a rough idea of where everything is – "so that enemy is in front of me, that one is above me to the west shooting, and that one is approaching from the south. My ally is to my east."

If you were designing a darkie-vs-whitie style PK game it would be fairly simple, but otherwise you're going to have to make certain assumptions. You could use a recognition-style system to let players label each other as friends or enemies, or you could simply limit it to groups - so that if another friend wishes to pass through your node, s/he first has to join your group. You could argue that the group represents a fighting formation, and that only by fighting as one unit can the players pass through each others space.

You could also reverse the logic, and say that people can normally pass through each others space unless someone is actively blocking. That could also be used for non-combat functionality, such as bouncers or guards blocking doorways, requiring either combat or diplomacy to get past - but because the default behavour would be to let people past, you wouldn't constantly end up with traffic jams in marketplaces or narrow alleyways.

I agree with KaVir about how you could automatically infer "hostiles" vs. "friendlies" vs. "neutrals". I think that most of the time, you're only interested in blocking "everybody but friendlies" or "enemies"; the first can be everybody except for people in your group/clan/nation/etc., and the separate can be everybody in groups fighting you, or known to be enemies of the group/clan/nation/etc. (And yes, this does make some assumptions about how the game world is structured.) In any case, I wasn't thinking that you'd have to block people on a name-by-name basis all the time.

Anyhow, yes, there can be other mechanisms, but I think it's very important to make sure you have it worked out solidly. It would be really too bad if clueless newbies were creating "traffic jams".


In the MMORPGs I've played, you don't need to be precise at all in combat; it basically is point, click, start attacking, and your character takes care of fighting and running after the target if it moves. Ranged combat is similar, although I suppose it can be obstructed by walls.

http://www.circumreality.com/ is of some interest. I tried it out once long ago and it appeared to be a half-and-half sort of thing, but it was becoming more of a graphical game than a MUD.