MMO servers typically have many GB of RAM available and sometimes even use a good chunk of it for caching and precomputation purposes. RAM is cheap and computers are fast. If you don't have profiling data to prove your performance assumptions, then those assumptions are worthless, period. It doesn't matter if you're new to game programming or have been doing it since the punch card era; I don't care what your intuition says, unless you've benchmarked the exact use case in question, you're probably wrong. There's a good chance you're dramatically wrong.

To add to this, MMO servers are also typically highly partitioned. Even for huge AAA projects, they don't have the world on one box (well, they probably do, but it's on-disk), but a small piece of it. Working at a MMO developer, RAM has never been our bottleneck. Typically it's either the database or some abstraction on top of the database.

But that's all a moot point when talking about a MUD, which is orders of magnitude different.

I would, however, enjoy seeing how navimeshes and the like are stored in a database for MMORPG's, as that would probably mirror my setup the closest.

No serious (read: shipped) MMO would store navmesh data in a relational database format. What you will typically find is some kind of custom binary format that describes a compact data structure. Most of the time that data is just read directly into RAM, potentially with some fixups for pointer addresses, and used from there.MMO servers typically have many GB of RAM available and sometimes even use a good chunk of it for caching and precomputation purposes. RAM is cheap and computers are fast. If you don't have profiling data to prove your performance assumptions, then those assumptions are worthless, period. It doesn't matter if you're new to game programming or have been doing it since the punch card era; I don't care what your intuition says, unless you've benchmarked the exact use case in question, you're probably wrong. There's a good chance you're dramatically wrong.As has also been touched on, some data is not relational by nature and storing it in a relational DB is just unwise at best. It isn't really a performance or efficiency concern in my mind, though. It's an appropriateness of abstraction concern. The more you cram into your DB without reason, the more awkward things are going to get.Trust your gut. Your gut says it would suck to store your navigation data in your database. So listen.

EDIT - Reread after I've had some sleep, and now I feel silly. Leaving the below as a reminder to myself to stop and think. Thanks to everyone.

Alright, the tone of this response irked me, so I apologize in advance if I come across harsh.

I'm not discussing ram. I understand that part. The vast majority of my game runs in ram. The database is only used for persistence. What I'm asking about is persisting navigational data. I can only work with what I know, and what I know is databases. I literally can not speak to any other method of storage when it comes to this because I'm not fully aware how it would work. If you have another suggestion, great. I would love to hear about it and learn. That's why I'm here.

Not to mention the fact that I've already admitted to not really knowing the performance outcome, and believing im being overly conservative. I feel like, had you read my posts, you would have seen that.

I apologize if I'm reading too much into this, but I read it six times and am having a hard time seeing this any other way.

If the room is 3x3 and has 16 edges then just move toward the goal in a straight line. There's no need for any complication. Pathfinding is only necessary when there are obstructions.

Incidentally, four more edges would complete that graph quite nicely.

There will be the possibility for obstructions, so I will need to account for that. I am curious though, where are the other four edges coming from? I only count 16.


All this being said, I think I'm going to build a static navigraph class with nodes and edges preloaded, as all the rooms are generically shaped. This will allow me to plan a route with very little extra data needed to be stored. I will use my entities to shape the room how I see fit, like placing a 'hole' entity in a square and making it take up the whole square, so that the square appears blocked when i try to path. Thank you everyone for your time. You've helped more than you know!

I am curious though, where are the other four edges coming from? I only count 16.

I am curious though, where are the other four edges coming from? I only count 16.

Entries and exits of the room.

Ah. I figured that may be what you meant. However, in my game, I would potentially need nine more edges on enclosed rooms, and.... A whole lot more on open terrain. I did that so you could have multiple doors on one wall, allowing players to enter and exit a room from multiple spots.

Mad props on that graphic though.

EDIT - Holy crap! I just found the other four edges INSIDE the room. Blind as a bat...Thanks!

No, no. It's not problem. I was a bit tired last night when I wrote that. Woke up this morning and reread what I and you wrote and was sort of like....eh? Didn't want to just delete it as I wasn't sure if it had been read.

As for the above, that makes sense. Didn't realize I wasn't clear about loading my database into memory for calculation purposes. Sorry about that.

I think I've probably got this figured out now. Again, thank you for your time. Apologies again for MY tone. Back to the grind!