KryoNet sending at an interval

Hello,
I’m trying to send packets after a cycle that runs @ 20hz
But I’m having trouble with it, currently I’m just using the KryoNet server.start() method.
As soon as I receive a packet I sent a response. What I want is having that response being sent after one game loop cycle has been handled. So the server would broadcast every 20hz instead responding immediately.

I’m not sure if I should do it every 20hz or respond immediately. Any suggestions?

Do you want the server to broadcast (something) every 20 Hz regardless if it got a response or do you want the server to send a maximum of 20 packets in a second if it gets a response?

Your question is quite vague right now; some detail will help! :point:

Respond to things like login immediately, and send general updates at 20hz.

As chrislo27 said, make some more decisions (or share the results if you already have). From the questions you have posted, I would suggest you step back and maybe tackle networking in phases. However, if you insist then just simply look up more information about the type of game you want to make and how other games handle that kind of traffic.

I believe this is your question, I personally would make a timer.

In the server’s update method, add something like this-


int counter = 0;

public void update() {
         if (counter < 20) {
                counter++;
         } else {
                counter = 0;
         }

         if (counter % 20 == 0) sendPacket();
}

This way packets will only be sent once a cycle.

I’m making a real time 2d top down shooter. At the moment I’m responding to packets immediately. and updating logic @ 20hz
I’m thinking of making a Queue of packets and poll them in the server’s logic thread

Respond to important packets immediately (like the others have said) such as login and whatnot, and logic-related packets such as movement of entities can be sent every game tick (however fast your game tick speed is).

Sending movement packets for still entities isn’t preferred. To counteract this, you can store a last game tick position in the entity but NEVER send that position to the client (since the client doesn’t need it). If the last tick’s position is the same as the current one, the entity hasn’t moved and you don’t have to send a movement packet for it. This is a bit unrelated to your question but it will help in the future.

Well I was thinking of doing it that way, but I’m not sure which method is most efficient.

When a player moves I only update the position for all clients in that room. So not everyone gets the packets. However I imagine this being send often which isnt really efficient. basicly unnecessairy packets vs more packets; due to client responding immediately instead @ 20hz

If you have a lot of packets, it’s advised to combine them into one (for example, movement updates for entities can be bundled into one single packet). It’s more efficient to send a big packet than a bunch of tiny ones.

Updating the position for clients only in a room is great. It culls the unnecessary packets being sent (which I should do myself, doh! ::)).

Minecraft updates its positions 20 times a second (when there’s a change in movement). Since the game runs at variable frame rates (the most common being 60), it interpolates the positions of entities over some number of frames. Instead of moving the entity directly to its new position, it’ll quickly move it closer and closer in a very short period of time. This makes it appear smooth. If you do play Minecraft, it’s also why you sometimes see an enderman teleport and watch it go through a bunch of blocks to its destination.

Alright, I will send packets @20hz for only those who need it.
And I’ll have to learn how to interpolate

Just as info: This method is known as “dead reckoning”. And it “extrapolates” the current position by a known movement vector. It is also using “extrapolation” instead of “interpolation” because we extend the range of known values (i.e. the position), whereas with “interpolation” we would calculate values in-between those we already know.

The method I stated is interpolation because you’re smoothing out position packets. I didn’t get into extrapolation.

There is an awesome site to teach you interpolation and extrapolation (along with other little multiplayer things like anti-cheat). It also has a live demo you can try yourself.
http://www.gabrielgambetta.com/fpm2.html