Coordinates-based Grid
-
I am currently bashing my head through a Python primer with a goal of eventually coding an Evennia game some time in the murky mists of the future and one thing I really, really wanna do is build a roomless, coordinates-based grid similar to KaVir's in God Wars 2. It's such a cool idea and while I'm not surprised it hasn't been used more often for MU*s, I really want to be able to implement it.
Can anyone maybe tell me if it's realistic to code it in Python, or even if anyone has done something similar?
^_______^
(@_____@)
---|---
/\ -
I couldn't tell you who all has done what. I can't tell you how easy/difficult it might be going from hardcode MUD to Python for use in Evennia.
I enjoyed Nightmare LP Mud, one of the last places using a similar skill/class based system is Haven. Its not active but staff still hang out. The main grid is traditional, room/exits all interconnected, but they updated to a virtual ocean and there is a large island out on their massive globe that is coordinate based. It could be something similar, it could be completely different. You're welcome to visit them and chat it up I imagine: http://haven.havenmud.com/.
Coord-based grid isn't new. It was more widely used on space games, mostly Star Wars as far as I know (and I don't know much). The A-Space, C-Space, H-Space and other variations, meant to possibly allow up to infinite space with minimal DB usage. They're still out there as far as I know, most on github. I do believe some were converted from 3D-virtual space to 2D-virtual ocean space. I don't know if any have been converted to land/continent but don't imagine that's much more than a change in the configuration.
Here a quick google search: https://en.wikipedia.org/wiki/Space_system_(gaming) - links to code repository where they are currently stored.
Looks like most include things like range as well. I am not certain, never played it, but The Greatest Generation may have had something similar (help account for bullet travel between 'rooms'). Heck, even FS3 includes some range code that may seem out of place, but joining a combat in progress can be done regardless of rooms so the potential to go coordinate or more open grid was probably thought of in the design as well.
I think its to say, it has been done and can probably be looked at, altered or used to inspire new coordinate-based grids. A main reason I think they're not popular is due to it being linked to vehicles and travel times?
I'm just a surge protector doing my job, sir.
-
-
@lotherio said in Coordinates-based Grid:
I think its to say, it has been done and can probably be looked at, altered or used to inspire new coordinate-based grids. A main reason I think they're not popular is due to it being linked to vehicles and travel times?
The game I have in mind will involve territory and hunting as a giant flying creature, so it just seems like a great fit.
Thanks for the links, HSpace and the rest didn't occur to me as a resource!
^_______^
(@_____@)
---|---
/\ -
@wizz said in Coordinates-based Grid:
build a roomless, coordinates-based grid
I'm not quite sure what you mean. You can't have a literally roomless grid because the entire basis of every MU server revolves around characters being in rooms. HSpace and the like create dynamic rooms. That's eminently do-able in every server, but the code is a pain because you basically have to re-invent the entire MUSH movement system, which is based on static exits linked to static rooms. Most places just don't bother because giant exploration and space games fell out of favor years ago.
-
@wizz said in Coordinates-based Grid:
will involve territory and hunting as a giant flying creature
I'd play it. I enjoyed Battletech to no end. Not the game versions with meta-plot at all, I enjoyed Battletech 3065 Mux, which was just get in a 'pod' load up a 'mech' and play a virtual combat against other's in pods/mechs. Earn credits, by bigger Mechs, rinse and repeat. I had way too many hours of fun doing that, but as @faraday mentioned, people got over it. Old dino's left for other fun, new players didn't have the patience to learn 12 different HUD displays, aliasing in game to get fast readouts when tics mattered, using favorite Mu*client to spawn multiple windows to read it all at once, and just fast keying to move, change speed, conduct jumps, turn torso, keep an eye on relative location of enemies and chat in team chat to keep coordinated (and being yelled at by vets when you messed up).
-
@faraday said in Coordinates-based Grid:
@wizz said in Coordinates-based Grid:
build a roomless, coordinates-based grid
I'm not quite sure what you mean. You can't have a literally roomless grid because the entire basis of every MU server revolves around characters being in rooms. HSpace and the like create dynamic rooms. That's eminently do-able in every server, but the code is a pain because you basically have to re-invent the entire MUSH movement system, which is based on static exits linked to static rooms. Most places just don't bother because giant exploration and space games fell out of favor years ago.
That's KaVir's terminology for it, which I don't believe is literal? If you've never experienced it, GW2 is still up and creating a bit only takes a minute or two, it's basically a MUD. I had never played an HSpace/etc game so it felt very fresh and ridiculously immersive to me, as you can literally wander (or run/crawl/etc, you set a coordinate and a speed and then movement is automatic) across plains, up mountains, through forests, etc. without the artificial feel of typing in "west" or whatever and moving block by block. It's really stuck with me.
And TBH, popularity is not a concern for me. Hell, if I can get something even remotely close to what I'm imagining off the ground, I'd play it completely by my lonesome, it's a dream game of mine.
^_______^
(@_____@)
---|---
/\ -
@wizz said in Coordinates-based Grid:
I had never played an HSpace/etc game so it felt very fresh and ridiculously immersive to me, as you can literally wander (or run/crawl/etc, you set a coordinate and a speed and then movement is automatic) across plains, up mountains, through forests, etc. without the artificial feel of typing in "west" or whatever and moving block by block. It's really stuck with me.
Well you should do whatever makes you happy! I can't help but wonder, though, if it would lose some of that immersive magic once you actually look under the hood and implement it. Because at the end of the day, you're still going west block by block. It's just instead of typing "west" you have a code timer that does "go west" automatically... and instead of having ten thousand rooms @dug in advance, you have a data file with ten thousand entries about what's where so the code knows what type of room to @dig on the fly.
-
@faraday
I actually like the feeling of knowing how something runs under the hood, and given my (super brief so far) experiences coding, I think it may actually make me enjoy it more.
We'll see, I guess, haha. I'll keep you guys updated. -
Double post because I would be remiss if I didn't clarify... there is another way to do dynamic movement that doesn't require rooms on the fly. But there you not only have to implement your own movement/grid system, you also have to re-invent the way that people interact with each other (since typical pose/look/etc. commands are all room-based). At that point I think you're not really utilizing your MU server as a MU server. But again - whatever strikes your fancy!
-
I have been working on an idea for turn-based 2d combat using the web client to draw an overhead view of the tilemap and characters. I was thinking a smaller 16x16 grid within each room, like the original Zelda.
-
@grapenut One of the things I /really/ wanted to do for a D&D 5e game was to make a web based interface that pulled character sheets from the MUX for adventures. It would make tactical combat so much easier but, would need a lot better web coder than me
-
@wizz said in Coordinates-based Grid:
Can anyone maybe tell me if it's realistic to code it in Python
I can answer this with a definitive yes.
-
@wizz said in Coordinates-based Grid:
I am currently bashing my head through a Python primer with a goal of eventually coding an Evennia game some time in the murky mists of the future and one thing I really, really wanna do is build a roomless, coordinates-based grid similar to KaVir's in God Wars 2. It's such a cool idea and while I'm not surprised it hasn't been used more often for MU*s, I really want to be able to implement it.
Can anyone maybe tell me if it's realistic to code it in Python, or even if anyone has done something similar?
It's ridiculously easy. I had done it with TinyMUX softcode around 2003-4. You just take your one room, decide how wide/long/tall you want it, and that's your X,Y,Z extents. 20x50x20 goes from -10 to 10 on the X, -25 to 25 on the Y, -10 to 10 on the Z. You still have to desc all those rooms individually by using some convention such as &desc-X-Y-Z (where the X-Y-Z are actually coordinate values). At that point voice volume vs stats like Acute Hearing can be a real thing - not just a 2D 'shout' heard in all rooms adjacent with exits.
It doesn't get difficult or complicated (even the math is simple 3-value, not even vector, addition/subtraction in 99% of cases) until you decide you want to plot a straight-line trajectory from 0,-4,-6 (4 meters south of room center, 6 meters down) to 4,3,9 (4 east, 3 north, 9 up) and try to determine if there are objects in the path (for example if you want a building/wall to dampen sound).
If you're working with Evennia you have to rewrite say/pose/emit commands to play nice and add a custom object default with a positional coordinates attribute. In TMUX I did it with the fairly new (at that time) @hooks.
-
There are several ways to do this in Evennia. Below are two.
The wilderness contrib
A version of 'room-less' already exists for Evennia. You can look at the
wildernessEvennia contrib here. It works as a mixture of coordinate- and room-based movement.The basic premise is that the world is described by a 2D ascii map representing the coordinates. When a Character enters the wilderness they get their own room with a given coordinate stored on it. All exits of the room loops back to the same room. As they move in a direction through the world, the coordinate changes and a new description and set of exits are loaded but you are not actually moving to a new room. When two Characters share coordinate one simply enters the room of the other and when they separate they each get their own room again. Fixed locations in the wilderness are still "normal" rooms set at at given coordinate, into which you enter when you go there.
This particular contrib is intended to allow large world maps without needing to create thousands of almost-empty rooms to fill the countryside. So you don't get line-of-sight, distance-measures and dynamic objects approaching you etc like you get in GodWars2 - that's something that would need to be added. Especially combat I imagine could be be tricky with that system unless you dictate that combat always happens in the same coordinate (room).
The contrib is also probably not scaleable to cater for the entirety of a game, one would probably want to restructure it more efficienty to make it easier to add content etc. But the concept works well.
Completely Room-less
If you want to completely get rid of Rooms across the world (i.e. really replicate GW2), Evennia can handle this without any changes to the core engine - but you need to add a lot of new code. You can then ignore Rooms completely (unless you want to keep them for indoor locations, say).
You need to redefine the concept of location. For example you could have a new typeclassed entity
Locationthat describes a given coordinate in the world. You can use two EvenniaTagson the Characters and on the 'Locations' to define their x,y coordinate (three if you want 3D).You obviously don't get the help of the default Room-based location/exit mechanics, so you'd need to supply new movement commands to manipulate your coordinate (aka move around).
You next need to figure out how to store the descriptions of each coordinate and how to manipulate it with distance (multiple descriptions for different distance brackets? Some sort of algorithm?).
Finally you need to add an engine that handles relational calculations between objects in the database (see e.g. Nemesis' post above) so you can tell which subset of all "locations" are visible to you from your current spot and should be included in the current description. Things like say/pose etc and how they are affected by distance are additional features to consider on top of that.
It would likely be a really fun project, but you should probably be prepared to spend a lot of time on it.
-
@griatch I assume for completely room-less you'd also need to write custom code for say/pose/emit/etc., since game communication is normally centered around what room you're in. And any object-interaction commands like 'take/give' (if Evennia has those), describe, look, teleport, etc. Sure with enough work it could be done, but the effort involved strikes me as massive.
Not relevant to OP, but FYI for anyone referencing this thread later - Ares doesn't have a wilderness contrib, but if you were going to attempt such a thing I would suggest doing it in exactly the same way that @Griatch described.
-
@faraday said in Coordinates-based Grid:
@griatch I assume for completely room-less you'd also need to write custom code for say/pose/emit/etc., since game communication is normally centered around what room you're in. And any object-interaction commands like 'take/give' (if Evennia has those), describe, look, teleport, etc. Sure with enough work it could be done, but the effort involved strikes me as massive.
You'd actually only need to override the default
search()method on the Character - it is used by (almost) all default commands and is the only component that usually cares about location (by limiting the search to things in the same room). If you change that to be coordinate-aware and return a list of matches 'within reach' (however you define that) most of the default commands should 'just work'. In the same way you could override what is reported as the Character'slocation. No doubt there will be unexpected edge-cases here and there that I could not predict but you might not need to rewrite everything in-depth.Things like line-of-sight, sound travelling and descriptions changing at-a-distance are completely new concepts though that would require rework of the relevant commands. And many build commands would of course also work differently, and require different options (as for any heavily customized game style).
Not relevant to OP, but FYI for anyone referencing this thread later - Ares doesn't have a wilderness contrib, but if you were going to attempt such a thing I would suggest doing it in exactly the same way that @Griatch described.
The eternally-looping wilderness-room is a nifty concept, yes. I don't know how common it is out there but people have also used the idea for things like ship-faring (the water kind) in Evennia.
.
Griatch
. -
@griatch said in Coordinates-based Grid:
Things like line-of-sight, sound travelling and descriptions changing at-a-distance are completely new concepts though that would require rework of the relevant commands. And many build commands would of course also work differently, and require different options (as for any heavily customized game style).
Yeah that's more what I meant -- conceptually it requires a lot of work to figure out how everything would interact. It's nifty that Evennia has a central search() function (Ares has something similar in its VisibleTargetFinder class) but doesn't CmdPose work off of location and not search in Evennia? It looks like at does anyway, and Ares things work off location as well. And even with a central handler - like you said, the "range" for grabbing would probably be different than the "range" for hearing or seeing. And of course walls or obstacles would probably affect all of those things. Whereas most things in MUSH land conceptually use "in the same room" as the default range for almost everything. So I'm sticking with my guesstimate of "massive" as the scope
But it sounds like OP is fine with that and just wants to know if it can be done, which it certainly can. -
Correct, the default Evennia
poseis not using.search()directly. Most likely one would instead tweak the.locationproperty to mean something else should it come to that. But yes, a large amount of code is no doubt going to be needed either way (as I noted in my first post). Regardless of how many of the default commands needs to change, the game style is such that the dev will need to add a lot of custom systems.
.
Griatch -
@griatch said in Coordinates-based Grid:
It would likely be a really fun project, but you should probably be prepared to spend a lot of time on it.
Definitely. Like I said, it's sort of a dream project I've had for a while and may not even be a viable game, but I would love to see it realized. Thank you guys so much for the input, it's a great start!
