How do you keep track of the positions of the players in a MMORPG? I read that you can use either a database or you can store the coordinates in files. I tried using a database but it was slow. How can files be used to keep track of players positions?
\$\begingroup\$
\$\endgroup\$
Add a comment
|
4 Answers
\$\begingroup\$
\$\endgroup\$
4
How can files be used to keep track of players positions?
You write the player position to the file. For example, if you identify every player with a unique number (or a GUID), you could use that as the file name. In the file, simply write the position data out in a format you can parse later. For example, 467239.txt might contain 20, 3, 19 if player #467239 is at that (x, y, z) location.
This is not that different from what you would do with a database, however -- a database should not be "slow" at this operation, it should be very fast (probably faster than files, because you have more disk IO overhead or IO locking contention -- if you stored multiple positions per file -- in a filesystem-based approach).
Perhaps you were trying to use the DB or filesystem to store the player position at runtime? You should not do this at all.
At runtime, in your server, player positions should be kept in-memory and updated there, as you would do with any other kind of game. Periodically they can be saved to disk or other persistent storage -- for example, when the player rests, saves, or logs out.
But writing every players position to storage every update is unnecessary and extremely inefficient; it will never be fast enough to handle anything resembling "massive" player scales.
-
1\$\begingroup\$ Yes, actually, i was saving player position to a postgreSQL at runtime. But, if i keep it in the server memory how can i update the position in the clients ? \$\endgroup\$ Commented Oct 3, 2011 at 16:34
-
12\$\begingroup\$ The method by which the client is updated is the same in all cases: the server tells the client what his or her position is via a network message (or more realistically, the client, which is doing local prediction, also has a local position that the server validates and confirms for the client). You should not have your client accessing the database that the server is accessing. \$\endgroup\$– user1430Commented Oct 3, 2011 at 16:44
-
1\$\begingroup\$ I miss the point about saying "do it with a file", only to explain it is actually worse than using the db and then explaining which is the real problem. Why do you need that useless file explanation in the first place? It only confuses the casual reader, wich no benefit for anyone. \$\endgroup\$– o0'.Commented Oct 4, 2011 at 7:17
-
6\$\begingroup\$ It's been my experienced in the past that ignoring direct questions and simply proceeding to lecture about what I think "the right way" should be tends to be more confrontational and makes the OP less receptive to being guided away from the weaker foundation their original question is coming from, that's all. \$\endgroup\$– user1430Commented Oct 4, 2011 at 14:54
\$\begingroup\$
\$\endgroup\$
1
The Position must be in RAM while in use. (ex: player's character is in the world) You cannot use the DB as operating memory. Well you can, but this will be terrible.
You should save the positions regularly, but not every time they change.
I would also avoid saving all positions at the same time. If you want to maintain persistence in case of a server crash you should save the position as often as possible but on the game's spare time. Simply do this by batches.
Save 30 positions while spare time is available.
As for the clients. They should receive (relevant) game state updates through a connection to your server software. Not from the DB... That would be impractical, slow, bad, evil and the force would be disturbed.
-
2\$\begingroup\$ And yes use a separate thread to avoid situations where the database might block the rest of your game loop. \$\endgroup\$– CoyoteCommented Oct 3, 2011 at 19:36
\$\begingroup\$
\$\endgroup\$
What I do in my server, is to store the players direction (vector) and last position, if the player has a speed, I do calculate the players new position every 2 seconds.
The client has its own position position of course and sends it new direction (vector) to the server.
The server is authoritative about the position and sends a position packet if the client moved a certain distance since last check (this may lead to rubber band effect is client is out of sync).
All this happens in memory of course.
\$\begingroup\$
\$\endgroup\$
I have a separate thread I queue to to save to files every 500 or so game ticks. Otherwise, you should store everything in RAM.
