Network game, sending player positions.

[maitrelame2]

Hi everyone,

I am trying to make an mmorpg (yes i know i am crazy), we can chat and all but i am having issues with player positions. I really don't know how to send player positions from server to client.
My idea was to make a singleton that contains a vector of every player id and a map with the players positions.
I just take every id from the vector and plug it in the map.
It works just fine but I have a refresh rate of 5-6 fps per second (my client is running network on an other thread). I have to lock the singleton everytime I want to send the positions which means every loop.
May the mutex be the problem ?

BTW : How do you treat data server side ?
Do you :
Recv Data -> treat -> Recv -> treat -> Recv (end of transmission) ->
treat (data to send) - > send -> treat....
Or is it better to have one thread to send, one to recv and send event to main thread which will treat and send back to the threads ?

If you have suggestions or a link I would really appreciate it.

Thanks.

[rogerborg]

I don't follow your description of your current solution; it's not clear what data you're actually sending to the client. It almost seems like you're sending state information on every player as frequently as possible, but that would be 100% certified batshit insane, so I'm probably misinterpreting.

So rather than discussing the solution, how about we back up to your requirements? We'll need to know at a bare minimum the following:

* How your world is spatially partitioned.
* How frequently you expect the state of mobiles (players and NPCs) to change.
* Whether your control model is the typical ORP "click to win", or whether there's any skill based element regarding exact positioning of mobiles.
* Your tolerance for having mobiles appear to overlap each other on the client.
* The relative importance that you attach to bandwidth versus lag.
* How important you consider dealing with hacking / out of sync errors (the two are closely related).

If you want to skip to the end, we discussed this briefly over here.


The threading question is interesting, but again, why are you going with a multithreaded solution in the first place? What problem is it solving, or what requirement or assumption led you to believe that it would be to your advantage to do so?

[Catprog]

(I have no idea about MMO design but here at some points)

First off don't send all your data to the clients for security reasons but only send the potions the player can actual see .

Also is there a reason your using such a high refresh rate?


Here is an idea.

2 small maps of player potions per area.

One takes updates. When the time comes to send a update the other map takes over the updating. You then send the data and clear the 1st map. This flip flopping continues while your games runs.

This way you only have a small amount of data to send each update.

This is in addition to a master list of the positions so you can check where a player is.

[maitrelame2]

Thanks for your answers.

How your world is spatially partitioned.

I don't really get what you mean. If you mean area and zones I use a virtual grid (see the snipets Terrain Engine for more info).

* How frequently you expect the state of mobiles (players and NPCs) to change.

I am trying to make a next-gen mmo (the physics, the render and all work correctly I am just a weaker on network). So I suppose I have to update everytime something changes ?

* Whether your control model is the typical ORP "click to win", or whether there's any skill based element regarding exact positioning of mobiles.

As said above I am trying to make a next-gen mmo, I am developping a MMORPG based on the manga naruto and had in mind to type specific letters in order to make spells, this includes the faster you type the letters the faster you do your spells. There is also a high level of physics for exemple if a player does a spells that's suppose to modify the terrain, the terrain will be destroyed. I am using PhysX by aegia on both server and client.

* Your tolerance for having mobiles appear to overlap each other on the client.

What do you mean exactly by overlap ?

* The relative importance that you attach to bandwidth versus lag.

I don't care how much bandwidth I have to use, the most important part is the lag. (I have a 2x1Gb/s server unlimited transfer).

* How important you consider dealing with hacking / out of sync errors (the two are closely related).

I made some protections like crypting my packet, but dealing with hacking is I think really important, but for now I don't know how to protect from hacking or sync problems.

I don't follow your description of your current solution; it's not clear what data you're actually sending to the client. It almost seems like you're sending state information on every player as frequently as possible, but that would be 100% certified batshit insane, so I'm probably misinterpreting.

No you are right I am trying to update as frequently as possible but that was just a test. Later on I will add a system to send the player visible by the client.

Hope you have the answers you needed to help me.
Thanks again for your help

[rogerborg]

Bear in mind that I'm taking you at your word that you are designing a "Massive" game. If that's bullshit^W marketing, and you're aiming at <1000 players, then you don't have to worry about some of this.

How your world is spatially partitioned.

I don't really get what you mean. If you mean area and zones I use a virtual grid (see the snipets Terrain Engine for more info).

OK, that's good. You'll want either:

*Discrete zones with 'gated' access so that objects in a particular zone won't be able to interact with (i.e. see or know about) objects in other zones at all.
* A contiguous world, with a cheap way to identify nearby objects, since you'll be doing it a lot. Objects should only distribute information about themselves to players who are close enough to need that information.

* How frequently you expect the state of mobiles (players and NPCs) to change.

I am trying to make a next-gen mmo (the physics, the render and all work correctly I am just a weaker on network). So I suppose I have to update everytime something changes ?

And how frequently do you expect that to be? It sounds like you're planning a relatively dynamic world.

* Whether your control model is the typical ORP "click to win", or whether there's any skill based element regarding exact positioning of mobiles.

As said above I am trying to make a next-gen mmo, I am developping a MMORPG based on the manga naruto and had in mind to type specific letters in order to make spells, this includes the faster you type the letters the faster you do your spells. There is also a high level of physics for exemple if a player does a spells that's suppose to modify the terrain, the terrain will be destroyed. I am using PhysX by aegia on both server and client.

I'll pencil in "Don't know" at this point.

* Your tolerance for having mobiles appear to overlap each other on the client.

What do you mean exactly by overlap ?

Intersect, appear to occupy the same area of space.

* The relative importance that you attach to bandwidth versus lag.

I don't care how much bandwidth I have to use, the most important part is the lag. (I have a 2x1Gb/s server unlimited transfer).

Great, it's good that you know how much bandwidth you have available. That means that you can calculate how many update packets you can send and receive per second i.e. half your available bandwidth to account for packet headers and resends, and divide by your typical update packet payload.

Have you done that calculation?

* How important you consider dealing with hacking / out of sync errors (the two are closely related).

I made some protections like crypting my packet, but dealing with hacking is I think really important, but for now I don't know how to protect from hacking or sync problems.

The server will have to validate all information from the clients. Obviously you put as little trust in the client as possible, but movement is generally handled on the client so that each player has a good interactive experience.

However, the server should hold each players definitive position, and when the client sends movement information to the server, the server should validate that such a movement (based on its definitive position) is theoretically possible. If the client is moving too fast, then the server should correct the position to a possible one, and send it to all nearby players. This isn't just a defence against speedhacks: the player may have received a speed crippling effect that their client doesn't know about yet.

I don't follow your description of your current solution; it's not clear what data you're actually sending to the client. It almost seems like you're sending state information on every player as frequently as possible, but that would be 100% certified batshit insane, so I'm probably misinterpreting.

No you are right I am trying to update as frequently as possible but that was just a test. Later on I will add a system to send the player visible by the client.

Fair enough, although I would urge you to spend some time on a robust design rather than tinkering until things appear to work, as network problems are a beeyatch to debug if you don't have well defined behaviour to compare them to.

Generally, you only need to send information on an object's state to a given player when:

1) The state changes, and that player is close enough to it.
2) When the player first moves close enough to the object that they need to know about it.

You'll notice that these are very different conditions.

The first happens based on the object's state changing, and relies on it knowing about nearby players.

The second happens when the player moves. If you have discrete zoning, then it's fairly easy, since you can likely get away with sending the state of every object in a zone when the player moves in to it.

If your zoning is more fuzzy, then you'll likely have to implement a system where each time the player moves a significant distance, you find all the objects that are visible from the player's new position, then for each one, check if it was visible from the old position. If not, then send its state.

Whichever way you go, then instead of sending a mucking great chunk of state data for all object to all players, you'll need a method to selective send state information about object A (only) to player B (only).

[maitrelame2]

Thanks for your answer !
I got all the information I need to keep going.

But I have another question :
Is it better to have 3 threads per client (server side) or only 1 thread.
For the 3 thread design (my new one) I have :
-1 thread send
-1 thread recv
-1 thread treat
The 3 threads are members of the same object.
I have a queue for the message to send, and a buffer for the recv function.
Every packet has a header with the size of the packet followed by the opcode and the data. That's why I add every data received to the same buffer.
Is this better than a thread that sends data, recv data and send data at the same time ?

[dlangdev]

what network lib are you using? just wondering because you mentioned you're using a custom made frame/protocol.

thx.

[maitrelame2]

I am using the system's API (posix and winsock)

[dlangdev]

nice to know you're working at that level.

also, is it possible to view some of your work, maybe we can collaborate in the future if there's a need for it. i can share my vps server for testing the handshake, though.

let me know, send me a pm if there is any interest on your part.

[rogerborg]

If you're using BSD sockets, then I'd recommend using a single thread and non-blocking sockets, since it saves you doing any synchronisation and it shouldn't introduce any significant latency.

The only thing that I'd consider using threading for is file/database I/O, and even then only after I'd identified a problem with using synchronous access.

That said, while it's useful to be able to use BSD sockets, RakNet provides so much more useful functionality that I'd highly recommend using that instead.