I'm making a real-time 2D MMORPG in Java. Currently data all surrounding NPCs' and players' data is sent so frequently that the client crashes—it can't handle the data quickly enough. I'm sending data so frequently to make sure the game state stays up to date.
Is there an alternative? Should I make it send information only when needed, like when health is lost or something moves, instead of updating the whole object every time? How do I do this?
NPC on a path only need to be sends periodically.
However instead of only the position you also send the speed and direction the NPC is going. That you only need to send the data a few times a second and the client can extrapolate the current position of the NPC.
Health should only be sent when it updates and once every few seconds as a sanity update.
Crashing? Does not make sense. You can send a lot of data nowadays. There is no reason using a lot of bandwidth would crash a properly implemented client. If it is literally crashing, you may need to debug some more.
You don't need to send everything.
Remember the client program is only used (normally):
You only need to send information about what is visible to the player. Creatures that are out of sight, don't need to be updated at all until the server decides there is a good chance they are visible again to the player (always err on the side of sending a little too much).
Stats that haven't recently changed, don't need to be sent at all. You normally only need to send the "diff" between the previous state and the current state. For that purpose you need to keep track of the last known update that was sent to the players. Movement doesn't need to be updated each frame. You could instead compute a spline that describes the npc movement to save space. If the npc is alerted and changes its behavior because of player characters then update about that.
Game states can be synchronised by sending "deltas"—messages that describe how to get from one game state to the next, rather than sending the whole state. You seem to have figured out that this is possible.
To get you started on the right path of thinking, here's a more concrete (but naïve) way that could be implemented:
In server code, store a boolean "change flag" for each property that you might want to send to a client. Whenever the property is changed, set the corresponding flag. On update, only send properties which flag is set, then unset all flags again. When the client receives any message, it overwrites the given properties on its own copies of the game objects, but doesn't change any of the properties that weren't mentioned.
This works well if your game world is small and all clients need to get all changes.
It might also be worth looking into event architectures, as they're a very effective and commonly used abstraction for synchronising just this kind of thing.
If your world is large, you might want to look into partitioning it into regions. Clients could then request a full state update when entering a region, but receive deltas about objects in the nearby region only while they remain there.
you should try to minimize the amount of data you're sending - only send what is needed. Like ratchet freak said, for movement you could only send the direction if it updates. health also only on update.
could you post a "log" of all things you're sending each time? We could then better help you to reduce it size.
