Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualKnolanCross

Posted 14 October 2012 - 09:55 PM

On login information:
If I got it right, the world is randomly generated by the server, the client player will appear at some starting position and you need to send the world information to it?
Is it a 2d game? If it is, I would define a character vision radius and send the information of character vision radius only (probably a little more), then as it moves I would send the information of the region of the direction it is moving.
On update:
In my own hobby project I had a zones approach, the zones were as big as the character vision radius.
In short, I would check the position of the character, then use its vision radius to check what regions it needed information.
At those regions I would check every monster and character in it and see it they were visible and inside the vision radius, then send the information update.
I didn't have any filter on monsters/players that hadn't change, but if I had to implement it, I would use a timestamp (seconds/useconds) of the last change.
My update rate was 20 messages/second, which was pretty smooth for my needs (in my tests, less than 18 started getting bad). But this will depend a lot on how is the player iteraction and how if you use any prediction algorithm in your game.
As of data storing, I used the same objects in the server/client and created/changed then by messages.

#1KnolanCross

Posted 14 October 2012 - 09:53 PM

On login information:
If I got it right, the world is random generated by the server, the client player will appear at some starting position and you need to send information to it?
Is it a 2d game? If it is, I would define a character vision radius and send the information of character vision radius only (probably a little), then as it moves I would send the information of the region of the direction it is moving.

On update:
In my own hobby project I had a zones approach, the zones were as big as the character vision radius.
In short, I would check the position of the character, then use its vision radius to check what regions it needed information.
At those regions I would check every monster and character in it and see it they were visible and inside the vision radius, then send the information update.
I didn't have any filter on monsters/players that hadn't change, but if I had to implement it, I would use a timestamp (seconds/useconds) of the last change.

My update rate was 20 messages/second, which was pretty smooth for my needs (in my tests, less than 18 started getting bad).

As of data storing, I used the same objects in the server/client and created/changed then by messages.

PARTNERS