tl;dr
You control how much data you are willing to process each frame. If a packet is too big, break it into smaller cells and process them one at a time (i.e one each frame). If you get a lot of small packets than split the group into chunks and limit the amount of information processing that is done each frame. The client does not need all the information,information; the server does so only send the client information that is crucial to the view. The rest could be handled on the server.
yourThe issue:
___ ___ The client could be a dumb terminal in the extreme case, only accepting and uploading input from the user as in:
player attacks Goblin Lord
and downloading simple view related instructions from the server as in
display kobold thief at (someX, someY) or play attack animation for Goblin[i]
and when you go towards this pattern, the client does not need to receive much data.
and known in advanceLevelLvlObviously using `Enum`**Obviously using** `Enum`s. It is often unwise to attempt to process all the information at once and it results in spikes in performance. Design your code around that. Create an array of tasks and only perform as much as you can lazily evaluating certain things only when you have free resources or they absolutely needed You could buffer things up. If the player line of sight is 9 x 9 squares then have the client aware of a 18 x 18 square and slowly handle entities that are out of site in the buffer zone before it becomes critical (be careful that users could exploit that for an unfair advantage).
ofor is Think what and where the problem occurs and make that far less likely to occur by slightly modifying or tweaking the game mechanics. Remember that gamegames needs to be scalable so you may neeneed to make some compromises or educated decisions about what you place and where.
