@jonjava
Well, using Kryonet you don’t have to worry too much about having an efficient protocol. If an int is not needing all of the 4 bytes, it’ll just scale it down.
Kryonet is really a nice way to go around all that silly technical networking. Not that you shouldn’t know - it’s just not necessary for development, which saves you tons of time!
On the server, what I usually do is this: Have your listener report back with what packets where received, and from whom. You can insert this data in a queue.
Your game-loop (logic, that is on a different thread than the listener), will then at the start of each cycle go through and process each packet. Since you know who it’s from, it’s easy to find the client to apply the changes to. If any of the packets needs a response, make it and queue it (like the receiving queue).
Afterwards, you do a “process” of your game world where you update everything that runs without player interaction. These would be behavior for NPC’s, or changing up how your fountain sprays water.
In the end of the game-loop, you send a same packet to each client with the most general information. For me, this has usually been movement of all players and/or appearence-flags. Like animations. You can assemble these individually for each specific client, but so far I’ve just sent the same packet to everyone. Then the client can figure out who’s who.
Lastly, you can send the response packets to each client. The reason I wanted to wanted to queue this, was so that I’d send out packets roughly at the same time. This probably doesn’t make any sence for most games, but I always wanted to keep my ticks intact, and not make some packets come way before others.
That’s just how I’d do it, though. I don’t think you even need a “tick”. You can just respond right away, every time the listener receives something. Just remember not to block the listener, because it’s kind of important.
Good luck!