As far as the networking code itself goes, I'd say it's pretty well optimized for being a generic system (where most of the processing needs to be client-side). The server will only send data that has been changed, and compression is done as-needed.

Since neither your bandwidth nor cpu are being maxed out, I have to believe you are getting lag spikes (where your cpu is instantaneously maxed) rather than a continuous lag. This may occur when some world event forces updates on all users simultaneously or something to that effect. Does this seem likely, given what you've seen of the game, or are things basically sluggish all the time?

To properly diagnose this, I think we'll have to host a busy server from a debug version so we can see where the bottlenecks are. But any further specifics you can provide would help. Like I said, we can run some simple tests to see how we do (vs, say, FTP) in mostly idle-states and work from there.

Falacy wrote:

The games have occasional lag spikes, but I don't worry much about them. Every online game I've ever played has its lag spikes every now any again, I don't consider it out of the ordinary. I'm more worried about the continual lag buildup as player count increases. 30 70 and 90 seem to be main lag increase points. Before 30 players the game will play as lag free as it will get when connected to a BYOND server. At 70 the lag will start to get noticeable. At 90+ players in HU I'd say the game is nearly half as responsive as it should be.

What I'm wondering is if the game is continuously laggy or just having more frequent lag spikes as the player count increases. I don't know if this is something you can easily determine from the cpu monitor. It seems odd that you'd have lag if cpu and bandwidth are continuously available. My best theory is that frequent world events (such as the sending of the map or possibly an internal event to your code) are, at some number of players, taking more than a tick to complete, and this is resulting in lag. But then I'd think that'd show up on the monitor.

Have you tried increasing your tick lag to see if that has any effect at all? Even if it's not a direct improvement, if the behavior is different it might give us some insight into the problem. For instance, it might worsen the behavior for less players but improve it for more.

I run my games in debug mode if that's what you're referring to, any steps I should take to get you additional information?

I mean we'd have to run the server in our debugger, so we could properly profile it. This would require running your .dmb and having a large number of players connect, or finding a comparable test case. But we can try this (with your approval obviously) as a last resort if we can't figure it out with smaller test cases.

Tom wrote:

From the developer's perspective, the best thing to do to accomodate large volumes of players is, as others have mentioned, using link() and multiple servers. In recent updates we should have removed any of the old prompts that bugged players when they were moving between servers, so the experience is seamless. Correct me if I'm wrong about that and we will fix it.

This works fairly well, FYI. The delay between being linked seems to be approximately 3-5 seconds, which isn't bad.

One thing that could improve is the fact that the interface reverts to default state when you switch to a new world. It also moves the physical position of the window to some static location, every time you link(). The map also goes black. Also, you get two connection messages in the default output window which are impossible to suppress and quite annoying. Ideally, the games windows and their contents stay exactly the same while being linked. The map should basically be a snapshot of how it looked when you got link()ed. At least in the case of being link()'ed to the same DMB. At the moment, I do a few things to try and make this as seamless as possible:

All interface elements that require modification at runtime to look how they shouild before being shown, are never visible by default - Otherwise they'd show in their default state when being linked.

The map is not visible by default. At the same position and size as the map is a label with the text 'Loading', which is visible by default. This has the effect of basically showing 'Loading' there in place of the map.

The default input is resized to 1x1 pixel and hidden in a corner - This window will 'absorb' the default messages that aren't nice.

Of the above, I can see some of the issues here might not be possible to solve (Or be difficult). But things are not quite seamless yet, even though what I have now looks pretty close - The resizing/repositioning is very bad; and if your game operates with multiple windows, some of which are not always open, that will look really bad as well as they will poof. I suppose in that case you'd do what I did with the map for those windows, using a 'Loading' label as visible across the entire window.

On networking: I'd like to see isolated testcases, as opposed to referring to GOA and the like - As Stephen said, and I don't mean this as criticism either, but optimizing games for many players is a pretty difficult thing that not many people in BYOND grasp.

Tom wrote:

http://www.softpedia.com/get/Windows-Widgets/ System-Utilities/Multiple-Processor-Monitor.shtml

What am I supposed to be doing with that thing? It seems to just do exactly what the task manager does...
http://www.angelfire.com/hero/straygames/ByondBugs/ YoureAWidget.png

EDIT: That's with 5 servers of HU and a server of PC being hosted from DDs.
Also, I don't have a multi-processor system, I have a single-processor multi-core.