19 Apr, 2013, Nathan wrote in the 21st comment:
Votes: 0
plamzi said:
Nathan said:
Kline said:
I'm getting close to the point of needing to implement some type of "room" system in my little custom server. I've been thinking about a blend between traditional and wilderness / coordinates. Mostly by keeping a more traditional "fixed container" element of rooms but then maintaining an element of size/distance within the room. So it would be possible to do things like set off an AoE spell in a small group of 3 creatures even if there were 6 total in the room; yet the other 3 were far enough away. Maybe have light radius play into it to effect what/how/when you see exits. Dunno. Still undecided on it all so far.


Hmm…I tried adding some coordinate stuff to mine, but it still feels hacked on. It needs more integration… Hex tiles as a coordinate model might work okay for AoE stuff, I think, since they would more closely approximate a circle. I figure you'd have to implement coordinate/? based movement then to navigate the rooms then, right? That and do you target an area or a creature?


That's a big fundamental decision. It might help to start with sketching out the interface you want to have, whether it is textual, or graphical, or hybrid (or more than one of these at the same time). Having a clear goal in mind usually sets off a domino effect and determines any long series of choices you have to make. It's just that you have to do what few MUD admins do naturally, and that is to realize that the goal should center on the end user experience, client and server and all.

If I were designing a MUD world from the ground up, I would probably retain the room concept and try to present it to the end user as a series of "places" or "scenes". Within each scene, there probably won't be coordinates like Nathan was describing. It does feel hacked, and more importantly, it complicates things pretty drastically by adding the need for collision checks, capacity checks, etc.

For the world as a whole, I would consider having logical placement of "places", unless it improves the user experience to allow "jumps" in certain places.


Not sure exactly what you're getting at with places/scenes. I was referring to the fact that my code makes a room have dimensions (x,y,z) and allows things to have a coordinate point. That is hackish because everything ought to have a valid point/location and ought to occupy space, etc. No object could logically take up zero space and fit on a pinhead… Right now, the code doesn't validate positioning and most things aren't coded to care. Not only that but there's really no way to move through that 'space' at the moment. I have a 'go' command that can try to take you to a point but that's not suitable for actual play.

I was planning on some primitive stuff where exits aren't shown unless you can see them and/or reach them. The problem is that a 3d-esque system introduces the possibility of 3d and a lot of the difficulties that come along with that without the benefit of pretty graphics… That includes how you describe the room, be it terms of square tiles, hex tiles, or raw coordinates.
I was thinking the other day that a hex overlay to something might ease the use of AoE spells (if my magic system was even finished to that level) since hexes are a better representation of a circle and have some implied relations to compass directions.
19 Apr, 2013, plamzi wrote in the 22nd comment:
Votes: 0
Nathan said:
I was thinking the other day that a hex overlay to something might ease the use of AoE spells (if my magic system was even finished to that level) since hexes are a better representation of a circle and have some implied relations to compass directions.


Again, I encourage you to think in terms of the player experience. In order for a player to move from one physical location to another, are they going to have to type a direction? If so, then a hex tile system will either lack east and west, or it will lack north and south, depending on the orientation. That's not going to be an easy sell. If you're thinking of auto-placing people within a room to available locations, what rules would govern that placement and are they going to be allowed to move to another tile? If so, then how will the UI work?

The point I'm trying to convey, one that may be too obvious, is that you're designing a game, not a server.
19 Apr, 2013, Nathan wrote in the 23rd comment:
Votes: 0
plamzi said:
Nathan said:
I was thinking the other day that a hex overlay to something might ease the use of AoE spells (if my magic system was even finished to that level) since hexes are a better representation of a circle and have some implied relations to compass directions.


Again, I encourage you to think in terms of the player experience. In order for a player to move from one physical location to another, are they going to have to type a direction? If so, then a hex tile system will either lack east and west, or it will lack north and south, depending on the orientation. That's not going to be an easy sell. If you're thinking of auto-placing people within a room to available locations, what rules would govern that placement and are they going to be allowed to move to another tile? If so, then how will the UI work?

The point I'm trying to convey, one that may be too obvious, is that you're designing a game, not a server.


Honestly I'm not completely sure about directions, which is, in part, why there's hardly any focus on the coordinates, mostly they just happen to exist in the code somewhere.

If I were to go down that road I might make north and south jump upwards/downwards a tile across the line the separates the tiles for nw,ne/sw,se. As it is you just have named exits that go somewhere. Really I wasn't proposing the hex tiles for navigation just spell effect range checking of some kind. Probably doesn't make any sense anyway. It's awfully hard to think in terms of "player experience" as you put it when there's no play to be had and no players to play. Not exactly sure what it is you're getting at with that last point. The server is what gets coded.
19 Apr, 2013, plamzi wrote in the 24th comment:
Votes: 0
Nathan said:
If I were to go down that road I might make north and south jump upwards/downwards a tile across the line the separates the tiles for nw,ne/sw,se.


My guess is that's going to look strange when visualized, e. g. in a map. There's nothing wrong with the tried and true chessboard approach, with diagonal movement also possible.

When I think of hexagons, I think of early strategy games. Even strategy games today have mostly abandoned them in favor of squares (3D perspective).

Nathan said:
Really I wasn't proposing the hex tiles for navigation just spell effect range checking of some kind.


One thing leads to another. If spells have ranges, players will want to be able to maximize the effectiveness of their spell. That means you'll need to allow movement to a better position. The alternative would be, I guess, to pinion players and move mobs around them randomly, notifying the player when targets are in range. But that makes for pretty strange gameplay.

Nathan said:
It's awfully hard to think in terms of "player experience" as you put it when there's no play to be had and no players to play. Not exactly sure what it is you're getting at with that last point. The server is what gets coded.


"No play to be had and no players to play" is the perfect time to start thinking about the player experience :) If you don't think about how people are going to play your game, then there's a real danger that one may end up with something unplayable.

The server is the part of the game that is in charge of the state. You need a server and a UI acting in concert to actually have a game.

You have to think about the client, even if it's just saying that your target client will be a telnet terminal with no VT100 controls needed. As soon as you say that, you have your set of constraints. For example, you can't expect people to type directions at the rate that a pressed arrow key sends direction data or a mouse sends motion data. So, you'll need to come up with a control system that won't be an obstacle to enjoyment but an enhancement of it. That's hard.

As for what exactly I'm going for with "scenes", I've already gone for it and you can see the result in my mobile app. At some point, I'll get around to implementing extensions to the battle system that will be presented as something like "positions" although really they will just be properties. For instance, I'd like to have positions within the group, where a tank can elect to expose themselves to melee attacks in either the front or the read, while a supporting class would naturally want to stay in the "center" of the group. Likewise, some NPCs can be coded to seek out melee contact and expose themselves to more melee damage, while others, by virtue of their attacks or body size or the fact that they can fly, can be coded to keep their distance, and so would have to be brought down mostly by spells and ranged attacks. All this I think can be pulled off without any coordinates, and should be an organic extension within the amorphous/abstract "room" concept.
19 Apr, 2013, quixadhal wrote in the 25th comment:
Votes: 0
Hex maps work well when it's a graphical game. Civilization V actually moved from a long tradition of square grids to hex grids, and it work ok because you don't move your units by ordering them to walk a step at a time. You select a destination, and they move as far along a route to it as they can, each turn.

If you want to see an example of a hex map in an ASCII game, Conquer v5b28 (beta), had that as an option. It didn't look bad, but there are a couple of things worth noting. First, it's a multiplayer, turn-based, strategy game… NOT a MUD. Second, to draw the hex map, each cell takes up a 4x3 grid on the screen, and that only gives you a couple of characters to use for information, inside the borders.

\__/% \__/* \__/  
/. \__/% \__/^ \__
\__/% \__/% \__/
/. \__/. \__/% \__


Third, as mentioned above, in a MUD, players expect to move a step at a time… In this case, east and west are not directly useable. How do you decide, when the player types 'east', if they take the NE, SE route, or the SE, NE route? What happens if they are attacked, or run out of moves, after the first step?

As you've probably gathered, I have a fundamental belief that text descriptions of your environment are one of the defining characteristics of a MUD. There's nothing wrong with a game that focuses on the map, but IMHO you're not talking about a MUD any more… you're now moving in the the realm of a real-time multi-player roguelike. That's fine, but once you downplay or eliminate descriptions, you might as well go full-on roguelike and have a curses-based display and single character commands… because that works better.

For a single-player example: telnet://nethack.alt.org
19 Apr, 2013, Kline wrote in the 26th comment:
Votes: 0
Nathan said:
Not sure exactly what you're getting at with places/scenes. I was referring to the fact that my code makes a room have dimensions (x,y,z) and allows things to have a coordinate point. That is hackish because everything ought to have a valid point/location and ought to occupy space, etc. No object could logically take up zero space and fit on a pinhead… Right now, the code doesn't validate positioning and most things aren't coded to care. Not only that but there's really no way to move through that 'space' at the moment. I have a 'go' command that can try to take you to a point but that's not suitable for actual play.

I was planning on some primitive stuff where exits aren't shown unless you can see them and/or reach them. The problem is that a 3d-esque system introduces the possibility of 3d and a lot of the difficulties that come along with that without the benefit of pretty graphics… That includes how you describe the room, be it terms of square tiles, hex tiles, or raw coordinates.
I was thinking the other day that a hex overlay to something might ease the use of AoE spells (if my magic system was even finished to that level) since hexes are a better representation of a circle and have some implied relations to compass directions.


Annnnd thank you for swaying me from that idea :). I think I'll stick with a more traditional container style game but go for an implementation closer to LP where exits aren't primarily restricted to compass directions. So, if someone wants to build a zone using "north, south, east, west" – that's cool. However if they want to build it using nouns for "exits" that's also acceptable. Or a mix; whatever. I know Diku-style games do support additional keyword-based exits, but I think I'm going to go with all exits being a noun/keyword, even if they are compass directions.

I'd still like to be able to implement some type of area effect system beyond a single room though, so perhaps I'll allow certain effects to extend through exit locations based on properties: closed, metal, etc. So you can set off a bomb in a room then safely hide behind a solid metal door in an adjacent room while still blowing through the wooden doors in other rooms and doing damage to the occupants.

Talking through this a bit more I'm liking plazmi's idea of "scenes" or "places". Perhaps only focusing on a "room" structure within important areas: cities, a specific dungeon, a guild hall, etc. Then leaving the empty space to connect these places as more of a wilderness/overland interface rather than 20 rooms of "through the woods" as you walk between two towns.
20.0/26