Using a UDP socket i send the serialize version of each of them, the client receives them and create a view for each one.Everything is running very good until now.

The problem arises when I want to make things a little better.Due that my current map is small, I have a few NPC's, Players and spells. However when want to start adding more I cant keep sending all map info.This brings the fact that I only will need to send the data NEARBY the player's position.

It only occurs to me this solution:In each individual server thread, check the players position, and iterate over the list grabbing only nearby objects.However this method will consume a lot and will be very slow.

Amusing as it is to see my real name (Chuck) used like this, I think the word you're looking for is "chunk". Tho if I don't lay off the beer and curries, I'll certainly be deserving of the latter name too

The answer is, when a player enters a chunk, you load enough surrounding chunks to cover the entire view distance plus one extra chunk (so the horizon doesn't appear in choppy fashion). In fact, you'll probably want even more chunks in memory than what's visible so you can still run the simulation in them, though you can fudge things a bit if you can prove no one can see what's happening.

As for keeping the current chunk updated for each player, since you always have to know exactly where in the world every player is, knowing what chunk they're in should be a trivial matter of dividing their coordinates by the size of the chunk.

Once you've generated a chunk, don't think of it as "loading" or "saving" it -- they all exist, just that some might have to be moved from disk to memory or back. Thinking of it that way, it's just more of an optimization problem than a show-stopping design problem. Don't be afraid to just throw every chunk in RAM to start out while you're developing -- as long as you keep some notion of discrete chunks, it'll be simple to offload them to disk or stream them over the network later.

Oh, and don't use UDP unless you're fine with dropping packets. If you find yourself retransmitting them, you're already well on your way to poorly reinventing TCP.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org