Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm looking into designing and implementing an online RPG (or more accurately, redesigning an existing piece of server software).

One of the problems is that of managing visibility. Update data for other players should only be sent to a game client if their player is near the other players (i.e. you shouldn't get health updates for people you can't see on the other side of the map). The main problem is that if you had to compare all the players every time an update is sent, it would just take way too long as the number of players scales (think up to a few thousand players per map and each of them updating up to 3-5 times a second).

If the players are in a 2D space (it's 3D but the z difference shouldn't affect visibility) what is the best way to manage the visibility of other players?

My idea is to have a separate thread that compares the space difference of all the players every few seconds or so and stores references to all nearby players in the player's object for easy access when an update needs to be broadcasted.

The existing system uses grids to organize players, and only uses only players in the current and neighbouring grids to do updates. There are some problems with the system though, as it isn't that efficient (besides knowing which grid they are in, no other caching) and sometimes visibility limits should extend beyond 2 grids of distance.

Is there a better or easier way? If it can be multithreaded that would obviously be better, and the less main-thread calculation the better.

(For anyone wondering, the project is in C++).

share|improve this question

migrated from programmers.stackexchange.com Dec 4 '11 at 0:38

This question came from our site for professional programmers interested in conceptual questions about software development.

    
Divide and conquer. Spatial partitioning. Grids are great if you have a known map size. Why do you think that your current grid system isn't efficient? A separate thread would work fine, minus having to manage locks, but has nothing to do with your real question. –  Patrick Hughes Dec 3 '11 at 23:01
    
Ignore the previous comment, sorry. I may investigate ways to make the current system better. If you were to design a grid system from scratch, what would the best design be? Should distances be cached for faster access? –  Pat S Dec 3 '11 at 23:30
2  
Your problem is also known as "interest management" if you're looking for search terms. Photon describes its basic concepts here: doc.exitgames.com/v3/mmo/concept There's also a doc (pdf) that describes different types of interest area spacing here: gram.cs.mcgill.ca/papers/boulanger-06-comparing.pdf –  Tetrad Dec 4 '11 at 1:28
    
@Tetrad: Interesting article. I didn't think about actual visibility checking. –  Jimmy Dec 4 '11 at 1:40

1 Answer 1

Your current grid system sounds like the spatial hashing system described here.

In theory, the performance should be fine unless too many entities exist in the same grid block.

However, the grid-based hashing isn't as commonly used as a Quadtree. The Quadtree is a bit more involved to implement, but it has a few nice features.

  • it costs O(log N) to find something. This is pretty graceful in terms of scaling up to thousands or millions of objects.

  • It isn't fixed at a particular scale. This means that it works just as well when you have 1000 really close to each other or 1000 objects really far apart. Obviously both these cases are not handled gracefully by the grid.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.