Using a quad-tree or an array would both solve your problem. The quad tree would probably increase your performance should you require searching or fast indexing. I'd use the quad-tree to outline the area covered by the AreaComponents. Each AreaComponent would have a quad-tree where the adjacent AreaComponent's area overlaps. Really, quad-tree versus two-dimensional array is simply an implementation issue.

The key to the whole concept is the idea of the overlapping areas covered by the area component. Here's a little image I made to help describe it.



We refer to the center AreaComponent in the above image as "this" AreaComponent for the remainder of this discussion. The red lines divide the theoretical area owned by each AreaComponent. The green lines show the actual area covered by the AreaComponent because of the overlap.



The blue squares are the parts of the area that are covered exclusively by the AreaComponents. There is no overlap in these areas.



The red squares represent the theoretical area owned by each AreaComponent. These squares are overlapped by other AreaComponents.



The green squares "in this case" represent the area that "this" AreaComponent overlaps its neighbors.

Each AreaComponent contains a list of its 8 adjacent AreaComponents. These are the other red outlined 4 x 4 boxes in the image above. When the player's character is in the blue boxes only the current AreaComponent can/will manage his position. This AreaComponent does NOT update his neighbors about the players position or any information about the player.

When the player enters the red boxes from the blue he is still only being managed by the current AreaComponent but now the player's position information and properties are being broadcast to the neighbor AreaComponents that overlap the player's current position.

When the player moves from the red to the green boxes the AreaComponent notifies its neighbor that there is an inbound player and it manages the player's position until the neighbor takes over control. Once control is taken over from this AreaComponent we will still recieve player position information until the player leaves this AreaComponent's overlap area.

Now in reverse; a player leaves a neighboring blue square and enters it's red square that borders our AreaComponent above. This red square is now in our overlap area so the other AreaComponent starts to broadcast the player's position information and properties to us. When the player's position transitions from our overlap area to our red squares the other component tells requests that we take over processing. Once we take over processing we update the other component about player position UNTIL the player enters the blue squares.

The windowing idea allows seemless area transition by allowing the server ample time to process the transition between servers for each player. It also solves the problem of having two players in adjacent areas not being able to see each other until either crosses into the other area.

Hope this makes it even clearer.

The benefit of using a quad-tree versus a 2D array is search time. Tree based searching is usually always faster than 2D array traversal.

RandomTask



[edited by - RandomTask on January 15, 2003 4:25:35 PM]