Well, After spending well over 500 hours on my MMO. I stopped months ago. I figure, if I am going to use it to get a job, I should finish it. -Client is fully working. Not an issue. I am working on the core now. Here is what I have been testing. I want to have a formula to support 4,000 people in an area. My test client that loads everything works wonders. I have gotten to about 1,000 online in one area running back and forth. Though, my Quad core is about 80%. Here is what is happening..... I follow the theory of surrounding areas. |A|B|C| |D|E|F| |G|H|I| So, if you are in E region, you know about ABCDFGHI. Now. If you have 800 people in the region and your doing an update, you update each person in the area. So, you will have for 1 person, 800 updates. 2nd person has to do each for each. So, Here are my options that I came up with in my head. -Dynamic zone lines. (OMG PLEASE DONT SAY THIS IS IT!) Could be very hard. -Limit the updates. (best solution). When there are this many people around you, one target loading slow, is not very a big issue. Plus if anyone attacks anyone, they are instantly given the packet upon the 1st attack. So not really the issue. How can I go about Limit the packets? The people that know about each other are in ThreadedDictionaries. (C# Language). While, I see very little performance downgrade to these locks, I think its merlely not updating 800 people each loop, which is every 2.25 seconds. (We could increase that timer too). We could also try to set a XYZ point upon the update. When you get too far from that point, we can update. But then you run into the part if someone else ran from you, you will still get their update. (This could be best for people sitting in town). Though, when you forget about someone else, they forget about you. This was a topic I made similar about 8 months ago, hopefully some new faces, plus some of my new ideas. Thanks! Ken

Also, mind you, as stated they are lists. So, if anyone else has a way to limit around the lists that would be great. What if I limit to 200 then alternate set 1, 2, 3, 4 each time so im only spending time updating 200 max each loop.

Mind you, these conditions are very very rare. I highly doubt there will ever be this many online at all, but I like to know im coding right.

Is the game 3D or 2D? What's the sight range for each client? What spatial partitioning are you using? A grid with a 2D rectangle for the camera and cull outside the client's view?

Everything past this sentence you already know, but I just want to make sure. If your map is say 100000x100000 units and you use a grid of 500x500 cells and 4K players are evenly distributed throughout the map that's 0.1 players per cell. Basically you'll define a viewing rectangle or circle and grab all of the entities in the cells that overlap the rectangle/circle. Since you inserted all the entities into their corresponding cells that means you'll be able to get a list of adjacent entities very quickly. (All of this can be implement with O(1) algorithms if you're clever with a linked list + observer pattern). Also look into hashed grids.

I also use full state updates and delta state updates. Store the known entities and objects for a client. Obviously if you go to insert something into that known entity list and it's not in there the player doesn't know about it and a full state update is required. If the client gets really out of sync? Remove all of the entities in the container and it does a full state update to them. These algorithms can also be implemented extremely cheaply. You can even run the checks for updating this list every 100 ticks or something if you want to and cut the cost down so low that it becomes almost free. >_>

Is that basically what you have?

About the problem at hand limiting the packets updates is a good idea. You can even drop the field of view if that's possible especially for populated areas. 800 players in an area is going to be insane. I'd be more worried trying to stop such traffic in one area. I mean it's not like players can do anything meaningful in such a dense region.

Some of what you mention have to do with the client.

This is just server side. Simple.

Its the MMO server. Players just need to know about other players near it.

Some what you have mentioned I will look into, I have heard Trees is where I need to be, just never really worked with them.

Ken

Quote:These algorithms can also be implemented extremely cheaply. You can even run the checks for updating this list every 100 ticks or something if you want to and cut the cost down so low that it becomes almost free. >_>

This is probably what I am looking for. How can I run checks quickly? From my knowledge, I would have the cycle the entire List<> and check if a player has run to far from another player.

Another problem could come into play is .Broadcasting() packets. For each person that knows of this person, broadcast. If the list is 400, that could be a large broadcast.

Ken

Dont worry!
I got time vehicle, and i already know, your mmo will be release in future!
and will be better than WoW, and everything else, you will be pionier of MMO's. :)

then dont forget about me. I know your in future earns alot of money from mmo, then you should give me some. :D

(You can edit a post by the way. No need to double post).

When you register a player to a cell in the grid you register the cell with the player. Removing the player from the cell is then instant since you have the cells the entity is in and can just call entity.RemoveFromSpatialPartitioning() or something. So you have a region around the player where you check for adjacent cells. Something like:


So you have the known entities and a fullStateEntities hashset. You don't have to run the above code every frame. You just need to run it enough so that the known entity list is reasonably up to date. You mentioned how do you know if an entity is moving far away? There's a trick. When building delta packets for the known entities for any entity that is X distance away remove them from the hashset and skip them. If they come back within range they will automatically be picked up for a full state update by the above code. :)

Sir,

Sorry I didn't mention before, it is a 3D game. Basically, those grids I have are not just 1 set away. Since its a 3D game, I think your formula wouldn't work. The grids I stated could be as big as town. (I wouldn't say that big but they are not blocks). Its not like chess.

So, when people get into the game, they go into a cell. That cell then is used when the update process goes through. When people move, if they are within range, they are added into the KnownList of the entity.

Ken

Use smaller cell sizes then? Is there a reason you made them so large? This method applies to both 2D and 3D games though. You could be use a 3D grid if needed, but then the hash grid idea becomes much more important due to the memory needed.

The lines are followed by the client. And I dont have the source to that anymore.

As you speak of HashTables, I currently have all known entities in a List<> The problem is cycling through that list. I need to find the quickest way to either A) Go through the entire list, B) If the list is large, only do X amount. Problem with this is I have to ensure that the next time around, we do the rest. Personally, I think A is the way. But in what order is best.