"The Snowball of Nerf-Hate Effect"

[SirBruce]

[/boggle. We regularly have 100 on 100 open field fights with our npc troops, with ai controlled attacking, including basic particle effects with 60+ fps on a good gaming machine. That is with average 800 poly models, NO Level of Detail versions of the models, basic network optimization (this is over the internet against a decently powered desktop acting as a dedicated server, T-1 line only access), plus full terrain rendering. Oh, and that's all without shaders, so no offload of work to the GPU.

I really don't have a position in this thread, but I feel compelled to point out that the above is almost meaningless.  It doesn't matter what it's like with 100 vs. 100 npc troops; it matters what it's like when you're updating 100 vs. 100 pc characters, each connected to the server via the Internet.  And you're not simulating that.  Actually drawing the graphics isn't the big issue; it's processing the latency-ridden client-server and server-client updates.

Bruce

[Evangolis]

/boggle. We regularly have 100 on 100 open field fights with our npc troops, with ai controlled attacking, including basic particle effects with 60+ fps on a good gaming machine. That is with average 800 poly models, NO Level of Detail versions of the models, basic network optimization (this is over the internet against a decently powered desktop acting as a dedicated server, T-1 line only access), plus full terrain rendering. Oh, and that's all without shaders, so no offload of work to the GPU.

At full zoom out of our current camera position, yes, you can overload the client's machine by having 500+ units on screen at once, but again, we have no level of detail models currently, so you are rendering in excess of 400,000 polys all in motion. With the avatar 1st/3rd person camera, the field of view is drastically reduced (down at the fight instead of god view), and with proper distance culling and level of detail assignment, it's not a serious performance issue on computers that can be purchased today.

The latest performance/rendering tests were performed prior to the collision work (that's our current milestone actually), so of course there will be some additional performance loss due to that, but we're not talking masterful collision here either, just simple bounding boxes.

I don't think the problem is entirely graphical.  I think much of the issue is the communications between multiple clients with each other and the server.  While I lack the computer acumen to diagnose the problem, I do know that I have seen the same problem in every MMOG I've played.  That isn't to say that you are not the exception or the breakthrough, but I heard the guy who designed the hardware and networking for SB explain why he did it the way he did, and that sounded like it should have worked too... but it didn't.

Ack, SirBruce beat me to the point.  That is why I hate these long replies.  And he was more concise, which is why I hate being a pendant.

I didn't say use of ninja sieges was a design flaw, I said the effectiveness of ninja sieges was a design flaw. The fact that 10 players can attack a city in the middle of the night with literally 5 minutes prep time, and maybe 15 minutes to run there (and that's only if they don't have a summoner spy in the target guild, or nearby), and then proceed to completely destroy the entire set of city walls in under a few hours is ludicrous.

Actually, the real effectiveness of ninja sieges wasn't in the physical damage done, it was in the morale damage.  Attack groups raiding your tree and killing everyone in town leads directly to people not logging on, followed by cancelled subscriptions.  If I can kill one AFK player at 3am, I will be effective, given that I do it often enough.  And if I can't kill one AFK player at 3am, what is the point?

In pre-release shadowbane, (I didn't participate, so this is from what I've been told) siege weapons were individually controlled, one per player. To move any attacking force, you needed dozens of players, if not more, all actively controlling them constantly. What I said is that if you design the need for mobilization properly, a couple of players tops could manage the mobilization over a long period of time, including swapping off the "babysitting" as appropriate. Instead of setting a bane and then having 2 days+ to wait for anything to happen, you instead begin mobilization of attack forces at that point, converging on the attack site after the mobilization period. All this time, the npc forces are in game and therefore can be attacked prior to centralization, as well as defended. All without the need for 5 groups of players to manually move the attack force for any lengthy period of time.

There were a number of siege scenarios in SB beta.  'Rolling Trebs' (siege weapons then were very slow pets, and in fact they still are pets, AFAIK) was the mechanic up through Beta 3.0.  The problem with the mechanic (aside from the bugs and crashes) was that you basically had to completely overwhelm the defenders, and then stand around for hours while you damaged the buildings.  Whether you won or lost, the battle was a very short term thing, while the players had to invest vast quantities of time building the cities, moving the siege weapons, and then using them, all for a relatively brief battle.

The mechanic in Beta 4 and live is to render the weapons immobile, and build them on the spot.  Unfortunately, the problem is only lessened.  Cities are still slow to build, slow to damage, and sieges are still relatively short battles, although the current implementation no longer requires hours of pre-battle preparation.

Now the mechanic you seem to be proposing for the game you are working on is a movement of NPC surrogates over time.  The question I have is how this process extends the player's action/entertainment time, since clicking menus and giving commands to NPCs isn't likely to be the sort of thing most players enjoy.

Also, Zepp's game has negative ping code.  So there.   

Ack!Mud 4.3 is Copyright (C)1998 by Stephen Zepp

Well, his game has code, anyway, which is more than I can say.  How about you?

[Calantus]

Ninja tactics will never have a good non-instanced/forced scheduling solution IMO. If you make sieges last for hours and hours you reward those guilds that have catass player who can put in that kind of time. Otherwise there will be a time when your siege numbers dwindle, if the defenders can mobilise at that time, you essentially get a ninja siege defence. If you make it so a siege cannot be taken down easily then the siege would last so long that the guild with the ability to get more people to stay longer will win. It doesn't matter how good your members are if the majority can only put in 5 hours that day and the siege is going to last 24 hours.

And catasses always find a way. Before he left college and got a job my friend played Utopia and his kingdom would organize fights at any time of the day/night depending on when their opponents would be offline. If they were attacked they would call eachother on cellphones. This is where it's good to mention that my friend lives in Australia... and they'd call him from Sweeden to get him online. And they'd stay on for hours in a war to make sure they crippled their enemy early on. Unless you find a way to make sure the fight only goes on in reasonable blocks of time, then the guild with more people willing to sacrifice their lives for the game is going to win. Always.



I'd also like to point out to people that large-scale engagements are never going to be right in a game that lets your customize your face to the extent of SWG and with all the gear customization that has been available since UO. That's just way way way too much info you have to send to every PC in the vicinity.

[Stephen Zepp]

[/boggle. We regularly have 100 on 100 open field fights with our npc troops, with ai controlled attacking, including basic particle effects with 60+ fps on a good gaming machine. That is with average 800 poly models, NO Level of Detail versions of the models, basic network optimization (this is over the internet against a decently powered desktop acting as a dedicated server, T-1 line only access), plus full terrain rendering. Oh, and that's all without shaders, so no offload of work to the GPU.

I really don't have a position in this thread, but I feel compelled to point out that the above is almost meaningless.  It doesn't matter what it's like with 100 vs. 100 npc troops; it matters what it's like when you're updating 100 vs. 100 pc characters, each connected to the server via the Internet.  And you're not simulating that.  Actually drawing the graphics isn't the big issue; it's processing the latency-ridden client-server and server-client updates.

Bruce

He mentioned specifically rendering issues with 200 game entities. As I've mentioned elsewhere in the thread, if your game design allows for 200 directly client controlled and fully update needed player objects in a close-in situation, then it's the game design that should be adjusted. While it is possible for 200 player avatars to be in the same geographical space as 200 npc troops, it's not a necessary part of game play, and good design makes it an extremely rare occurence. Of course, players could do it intentionally, but they can do a hell of a lot of other things to bring a server to it's knees as well. You plan for them, plan to make them not a necessary game mechanic (stacking for instance), and cover your bases the best you can.

[Stephen Zepp]

I don't think the problem is entirely graphical.  I think much of the issue is the communications between multiple clients with each other and the server.  While I lack the computer acumen to diagnose the problem, I do know that I have seen the same problem in every MMOG I've played.  That isn't to say that you are not the exception or the breakthrough, but I heard the guy who designed the hardware and networking for SB explain why he did it the way he did, and that sounded like it should have worked too... but it didn't.

Ack, SirBruce beat me to the point.  That is why I hate these long replies.  And he was more concise, which is why I hate being a pendant.

You are absolutely right, but my response (and numbers) was based on Haemish's comment about the inability for clients to render that many objects at once. The network aspect is a maze as well, but even then better design (back to collision, spacing sieges out instead of providing a single point of siege activity, or at most 2, like the bane circle/ToL problem) helps to handle it--just not with the same systems/mechanisms.

I didn't say use of ninja sieges was a design flaw, I said the effectiveness of ninja sieges was a design flaw. The fact that 10 players can attack a city in the middle of the night with literally 5 minutes prep time, and maybe 15 minutes to run there (and that's only if they don't have a summoner spy in the target guild, or nearby), and then proceed to completely destroy the entire set of city walls in under a few hours is ludicrous.

Actually, the real effectiveness of ninja sieges wasn't in the physical damage done, it was in the morale damage.  Attack groups raiding your tree and killing everyone in town leads directly to people not logging on, followed by cancelled subscriptions.  If I can kill one AFK player at 3am, I will be effective, given that I do it often enough.  And if I can't kill one AFK player at 3am, what is the point?

Valid point..and a good one.

There were a number of siege scenarios in SB beta.  'Rolling Trebs' (siege weapons then were very slow pets, and in fact they still are pets, AFAIK) was the mechanic up through Beta 3.0.  The problem with the mechanic (aside from the bugs and crashes) was that you basically had to completely overwhelm the defenders, and then stand around for hours while you damaged the buildings.  Whether you won or lost, the battle was a very short term thing, while the players had to invest vast quantities of time building the cities, moving the siege weapons, and then using them, all for a relatively brief battle.

The mechanic in Beta 4 and live is to render the weapons immobile, and build them on the spot.  Unfortunately, the problem is only lessened.  Cities are still slow to build, slow to damage, and sieges are still relatively short battles, although the current implementation no longer requires hours of pre-battle preparation.

Now the mechanic you seem to be proposing for the game you are working on is a movement of NPC surrogates over time.  The question I have is how this process extends the player's action/entertainment time, since clicking menus and giving commands to NPCs isn't likely to be the sort of thing most players enjoy.

The concept of mobilization of forces doesn't extend player's entertainment time--that's not the purpose. the purpose is to allow for (in fact, require) an in-game observable, and interruptable, process for building up to large sieges, with the minimal amount of forced mass-player interaction. Say you have a guild of 40 people, with a "staff" of 5. That staff is what takes care of the mobility and logisitcs as one of their management tasks, mobilizing very large numbers of npc's at the strategic level (hell, all you are doing is telling them to foot-march from one place to another) with a couple of minutes of strategic/mobility map interface work. When the other guild members are needed, they can be called in (and have quick mobility, it's just the npc's that do not) to lead these troops in tactical situations. For the majority of the guild players, they simply show up at the combat times (either the siege itself, or as a quick response in case the rally point was attacked, or possibly route march areas attacked, etc.) and lead their troops, or fight as avatars, as appropriate for their playstyle.

Also, Zepp's game has negative ping code.  So there.   

Ack!Mud 4.3 is Copyright (C)1998 by Stephen Zepp

Well, his game has code, anyway, which is more than I can say.  How about you?

/blush...while I take the fact that you looked as a compliment, please understand that our current project has absolutely no relation to that old mud code!

[SirBruce]

He mentioned specifically rendering issues with 200 game entities. As I've mentioned elsewhere in the thread, if your game design allows for 200 directly client controlled and fully update needed player objects in a close-in situation, then it's the game design that should be adjusted. While it is possible for 200 player avatars to be in the same geographical space as 200 npc troops, it's not a necessary part of game play, and good design makes it an extremely rare occurence. Of course, players could do it intentionally, but they can do a hell of a lot of other things to bring a server to it's knees as well. You plan for them, plan to make them not a necessary game mechanic (stacking for instance), and cover your bases the best you can.

Ahh, I see now, and you were specifically saying that before his response and he still didn't get it.  I should have known better than to take something Haemish wrote for granted.  :)

I will say that a lot of people use the term "rendering" rather loosely, and it is true that if you had 200 player characters on screen, your actual "drawing" of those objects is going to suffer because it's going to be tied to some degree to your network update loop.  But that's really not what he was saying.  You said lots of players is a problem, so you can use NPCs, and he said no way, all the games with that many players were terribly laggy because of all the updates, and you again rightly pointed out that's why you're talking about NPC entities and not all those players.

Bruce

[Typhon]

Defender AI
In DAOC Ninja seige's were possible because pvp-npc's used the same AI as PvE mobs.  you could 'pull' them... which made the gate and walls pretty much useless.  you could spell-shoot the npcs on the ramparts with no increases penalty to spell resistance.  essentially the AI  removed the effectiveness of the defense of the keep.

This could have been improved by coding PvP npcs differently.  Have them check the gate status to determine whether to rush or not (gate is up, don't rush).  Have them check the gate status to determine the radius of their call for help (if the gate is still up, have the call for help radius be HUGE.  If the gate is down, have the radius be smaller, to simulate npcs fighting other invaders of the keep, or keeping to their posts).

Instance and World
That said, I actually like instances.  I think there should be many more, and win/loss of instances fights sould effect overall game progression.

I think there should be instances that cap out with only a group or two and there should be instances that cap out with a full raid group (talking WoW here).  Would be very cool if the win/loss rate of instance battles had effect on towns/villages in the area in which they occured. 

Additionally, I think that instances should be able to be run at any time (not scheduled), with npcs making up the defenders, but the 'award' for winning should be strongly effected by the number/balance of pc's in the battle (make players want a balanced fight).  Some mechanic should be in place for the initiating force to attract enemy players to a particular battle (give the initiators the ability to 'blow a horn' and give defenders a couple minutes to muster - ideally 'blowing the horn' would make that particular battle worth more to players in the instance, and to the win/loss metrics)

[Evangolis]

He mentioned specifically rendering issues with 200 game entities. As I've mentioned elsewhere in the thread, if your game design allows for 200 directly client controlled and fully update needed player objects in a close-in situation, then it's the game design that should be adjusted. While it is possible for 200 player avatars to be in the same geographical space as 200 npc troops, it's not a necessary part of game play, and good design makes it an extremely rare occurence. Of course, players could do it intentionally, but they can do a hell of a lot of other things to bring a server to it's knees as well. You plan for them, plan to make them not a necessary game mechanic (stacking for instance), and cover your bases the best you can.

Hmmm, I can't comment on your game specifically, and I'm not quite sure of the actual size of the geographical space of 200 NPCs, I do have doubts about what you are saying.  I suppose you could put very large collision boxes around PCs (though aren't solutions like that Virtual Instancing?), but short of that, I don't know how you are going to avoid crowds in an MMO.  Every MMO I have played has crowd issues, and while the specific causes vary, the general cause is the same.

Specific causes may be a commercial area (intentional -  EQ Bazaar, Player created - EQ Commonlands), a special NPC (FCs in SB, GMs in EQ), a battle of significance (relic raids - DAOC, City Sieges - SB), a high traffic area (Starting cities on Launch day) or a zone of interest (new spawn areas in most games, phat lewts).  The common factor is that they are all points of special reward.  How you are going to avoid such special rewards is not clear to me, particularly since players may well define special rewards without your advice or consent.

Short form.  If players can create a crowd, they will probably find a reason to do so, and your game will need to deal with it.

[Stephen Zepp]

You are thinking about purely "one player is one and only one avatar". While we are not going to retard the relative power of an avatar so much that they can't accomplish much, think along the lines of Warcraft: A "player" was made up of squads of troops, plus their heros. In our design, a player consists of roughly the same--a ratio of "avatar" powered characters that players advance as if it was an RPG, and npc troops that are more RTS oriented, that the player controls if that is their playstyle.

Yes, there will be areas of conjestion, and areas that require pretty high powered platform (server) resources to manage, but strong scoping rules give fine level control over which updates are sent and at what rates to each of the clients based on their "proximity" to the object being updated, and therefore their requirement for how much, and how often, they need those updates.

Take EQ's old bazaar as you mentioned. EQ's model was pretty much to send every update to every client in a zone every time anything changed at all--they pretty much completely duplicated the game state of the zone on each client at a fixed, unchanging rate. If, however, you scope net events to the clients based on their observation probabilities over small time slices, there are a lot of net updates that simply don't need to be sent to a lot of the clients.

From the rendering perspective, the only things that need to be rendered are the things in view. Using dynamic level of detail (rendering less polys and less detail based on the screen size of the viewed object for example), you can manage the total rendering needs of a particular frame of a particular scene based on camera position, field of view, and several other characteristics for optimizing rendering.

Take it to the extreme for a minute for explanation purposes: AFAIK, Shadowbane did not use dynamic lod for their player objects (this could be wrong, my understanding is simply from observation over more than a year of constant play), so if you had 50+ player objects in your far field of view, you still rendered all of the polys for each of those player objects. Now, take for a moment games like Total War, where you can have hundreds/thousands of units on screen at once. This is accomplished with a ton of different techniques in general, but some of those techniques can be used dynamically in a scenario like this--if the objects are in your far, or middle field of view (and therefore very small, or small on your screen), you don't need to render all of the polys--the player is simply not going to be focusing on each and every unit, and doesn't need a full visual representation of the object in the same way they would if they were staring it in the face. For the far field of view, you can even replace the 3-D model completely with a detail billboard mapped to a simple 2-poly model, making it almost a non-factor from the rendering perspective.

[HaemishM]

[/boggle. We regularly have 100 on 100 open field fights with our npc troops, with ai controlled attacking, including basic particle effects with 60+ fps on a good gaming machine. That is with average 800 poly models, NO Level of Detail versions of the models, basic network optimization (this is over the internet against a decently powered desktop acting as a dedicated server, T-1 line only access), plus full terrain rendering. Oh, and that's all without shaders, so no offload of work to the GPU.

I really don't have a position in this thread, but I feel compelled to point out that the above is almost meaningless.  It doesn't matter what it's like with 100 vs. 100 npc troops; it matters what it's like when you're updating 100 vs. 100 pc characters, each connected to the server via the Internet.  And you're not simulating that.  Actually drawing the graphics isn't the big issue; it's processing the latency-ridden client-server and server-client updates.

Bruce

To agree with Bruce here, internal testing means shit. Shadowbane's original siege engine tested great... internally. When it hit the beta test server, it wasn't even a good slideshow.  I don't care what anyone will tell you, if you and a majority of your testers are not at a remote location, you have NO FUCKING IDEA what kind of latency issues will crop up.

Also, the optimism of some in this thread is cute. I eat it with a side of Chianti. The MMOG industry lives off of your optimism.

[SirBruce]

Actually, we're not in agreement.  If you read the rest of the posts, you'll see the situation you were talking about and I tried to back up was actually totally not the situation Zepp was talking about, and he even said so, twice.

Bruce

[HaemishM]

I read later that you took a snipe at me. Thanks. Pigfucker.

The problem with his scenario, as I apparently failed to get across, was not only client-side rendering, but also the amount of server to client interactions that have to take place. Both create the huge bottlenecks seen in sieges to this day.

Shadowbane DID use quite extensively level-of-detail scenarios for rendering. Whether or not theirs sucked rocks or not doesn't change the fact that they did use these rendering techniques. The theory is sound, as with everything, it's the implentation of said LOD effects that determine lag or smooth frame rate.

Now, you are saying that you are running 200 NPC battles, with exactly how many PC's involved? Yes, you may get smooth frame rate on that, as well as no latency issues. But if every player in the battle has NPC's, and you get 100 players on each side, you are still going to have rendering issues. Total War is a good start, but God Forbid TW ever had to render all those troops PLUS a playable character for each unit's commander on the field. Or are you saying that the only people who control NPC's retinues are the RTS style players? So let's say there are only 200 NPC's, and then another 100 PC's without retinues who are fighting on each side. You still have 200 PC's, all needing server to client updates on the other characters in their view, PLUS server to client updates on the position of NPC's, the state of the city's defenses, any deformable terrain effects, any ranged weapon effects, and the server has to process all that and send it out, on top of NPC AI, pathfinding and collision detection for all NPC units and PC's.

Oh yes, and you still need that server (or cluster) to send out information to the players on the other side of the world who may or may not have anything to do with the whole dealie.

Yeah, I'm thinking you will need some negative ping code. Because that's the kind of thing I'm talking about. If (big if) you get the player's client to not shit itself with that much stuff on the screen, your netcode will have to be better than anything and everything currently on the market.

Good luck with that. Frankly, it sounds like a good idea that isn't possible with current tech. And if it is possible, I don't see it coming in at under $30 million, no matter how much of this you reuse.

[Stephen Zepp]

[/boggle. We regularly have 100 on 100 open field fights with our npc troops, with ai controlled attacking, including basic particle effects with 60+ fps on a good gaming machine. That is with average 800 poly models, NO Level of Detail versions of the models, basic network optimization (this is over the internet against a decently powered desktop acting as a dedicated server, T-1 line only access), plus full terrain rendering. Oh, and that's all without shaders, so no offload of work to the GPU.

I really don't have a position in this thread, but I feel compelled to point out that the above is almost meaningless.  It doesn't matter what it's like with 100 vs. 100 npc troops; it matters what it's like when you're updating 100 vs. 100 pc characters, each connected to the server via the Internet.  And you're not simulating that.  Actually drawing the graphics isn't the big issue; it's processing the latency-ridden client-server and server-client updates.

Bruce

To agree with Bruce here, internal testing means shit. Shadowbane's original siege engine tested great... internally. When it hit the beta test server, it wasn't even a good slideshow.  I don't care what anyone will tell you, if you and a majority of your testers are not at a remote location, you have NO FUCKING IDEA what kind of latency issues will crop up.

Also, the optimism of some in this thread is cute. I eat it with a side of Chianti. The MMOG industry lives off of your optimism.

All of our testing is fully remote. In fact, only 2 of our team members even live in the same state!

[Shockeye]

All of our testing is fully remote. In fact, only 2 of our team members even live in the same state!

For anyone who cares, his virtual team information can be found here.

[Evangolis]

My concern is slightly different from Haemish's, and mostly the same.  I'm willing to believe that you can code a better client update system than we've seen so far.  While I haven't seen the code, I've seen the results, and there has to be a better way.  But I still don't trust your confidence in large event scenarios this side of some actual beta.  To steal somebody's rephrasing of a classic quote, "no game design survives contact with the players".  I think this has been a hidden truth of gaming that MMOs have uncerimoniously dragged into the light of day.

On the other hand, I was equally confident about WoW have massive security problems, and so far that hasn't happened, Thottbot aside.

[Stephen Zepp]

The problem with his scenario, as I apparently failed to get across, was not only client-side rendering, but also the amount of server to client interactions that have to take place. Both create the huge bottlenecks seen in sieges to this day.

Shadowbane DID use quite extensively level-of-detail scenarios for rendering. Whether or not theirs sucked rocks or not doesn't change the fact that they did use these rendering techniques. The theory is sound, as with everything, it's the implentation of said LOD effects that determine lag or smooth frame rate.

Fair enough...and now that you mention it, the perfmon stuff did use heavy LOD reduction-the implementation broke things even worse for me personally, so I never used it beyond the first day.

Now, you are saying that you are running 200 NPC battles, with exactly how many PC's involved? Yes, you may get smooth frame rate on that, as well as no latency issues. But if every player in the battle has NPC's, and you get 100 players on each side, you are still going to have rendering issues. Total War is a good start, but God Forbid TW ever had to render all those troops PLUS a playable character for each unit's commander on the field. Or are you saying that the only people who control NPC's retinues are the RTS style players? So let's say there are only 200 NPC's, and then another 100 PC's without retinues who are fighting on each side. You still have 200 PC's, all needing server to client updates on the other characters in their view, PLUS server to client updates on the position of NPC's, the state of the city's defenses, any deformable terrain effects, any ranged weapon effects, and the server has to process all that and send it out, on top of NPC AI, pathfinding and collision detection for all NPC units and PC's.

I've said this several times, but here's the last one: Any design that puts ALL of the units, plus ALL of the players in a single action locii is doomed to exactly the situation you describe. Therefore, don't create a design that commonly puts all of the units plus all of the players in the same action locii, either from a rendering or network updating perspective. Finally, you do not need to send individual update packets for each and every NPC--that's what flocking is all about. You send squad based updates and flocking parameters, and the clients replicate.

You don't send the entire terrain deformation information, you send parameters for the deformation and the client replicates.

You don't send ranged weapon effects, you send Attack Events, and the clients display. Attack Events are extremely optimized for network bandwidth.

NPC AI during large scale combats is extremely basic--you aren't doing huge amounts of goal checking, your not focused on exact positioning, insane manuevering, etc. Additionally, your run an AI check for the squad leader, and once again propagate the required actions for the rest of the squad via flocking concepts (different obviously than positional flocking, but the theory is very similar).

You aren't performing pathfinding for each and every unit--you are performing fat path pathfinding for the squad leader of a unit (and only if necessary).

You are performing collision checks for each unit, but we're talking extremely basic (and very fast) container based bounding box checking.

It is interesting by the way how this ties in to the Designing Security thread, because absolutely there are areas of vulnerability in this design. A critical factor for success is solid analysis of those vulnerabilities, and how they can be abused to affect gameplay.

Oh yes, and you still need that server (or cluster) to send out information to the players on the other side of the world who may or may not have anything to do with the whole dealie.

No, you do not. At most, you need to send out of band global chat channels. If you seriously think you need to send an update to every player in the game world from every player in the game world every tick, well that right there points out the reason for our complete disagreement about the issue.

Yeah, I'm thinking you will need some negative ping code. Because that's the kind of thing I'm talking about. If (big if) you get the player's client to not shit itself with that much stuff on the screen, your netcode will have to be better than anything and everything currently on the market.

This may sound as if I'm trying to weasel out of something--but this is a design discussion, not an implentation discussion. There are huge issues at pretty much every step in the design regarding implementation specifics--I am not at all trying to claim otherwise.

Good luck with that. Frankly, it sounds like a good idea that isn't possible with current tech. And if it is possible, I don't see it coming in at under $30 million, no matter how much of this you reuse.

Good google skills ;). As an aside to your above comment about netcode having to be better than anything and everything currently on the market, TGE's netcode actually is award winning, and considered one of the top notch netcode implementations in the industry.

EDIT: Just to be out in the open, the purpose of these discussions is not to try to vaporware market our project, but to stir up pros/cons discussions about designs. Our project isn't even CLOSE to anywhere near a playable game, and isn't going to be for years. It's not the intent for me at least here to talk about our project as a playable game, but to talk about MMOG design concepts. If anyone at all has gotten the impression that I even come close to thinking all of these ideas (or even hell, most of them) are going to survive through to final implementation, let me get rid of that right now--it's not the case. For example, while I am pointedly disagreeing with just about everything Haemish is saying, his comments and positions are absolutely being refactored into designs.

Personally, I'd be much more comfortable if the focus of this topic, and any others got away from the concept of game implementation and "current state", but I know that won't be perfect--I take the blame for that when I brought up a direct reference to one of our performance tests--completely my fault.

[Stephen Zepp]

My concern is slightly different from Haemish's, and mostly the same.  I'm willing to believe that you can code a better client update system than we've seen so far.  While I haven't seen the code, I've seen the results, and there has to be a better way.  But I still don't trust your confidence in large event scenarios this side of some actual beta.  To steal somebody's rephrasing of a classic quote, "no game design survives contact with the players".  I think this has been a hidden truth of gaming that MMOs have uncerimoniously dragged into the light of day.

On the other hand, I was equally confident about WoW have massive security problems, and so far that hasn't happened, Thottbot aside.

Absolutely true observation--and as I said in the above post, I'm debating from a design point of view, not an "implementation issues" point of view. They are a completely different ball of wax!

Edit: Yes, I'm confident, but I'm also not idiotically ignoring all of the entirely valid points brought up either! It's a long, long road from design to beta...

[HaemishM]

If your design is not going to factor in the fact that there WILL BE an assload more units than you want into it, you have failed at the design stage. I'm not talking about every player on the server being there. But unless you put an artificial limit on the size of a guild or alliance, you better be able to count on there being a lot more players at the action focii than you it sounds like you are counting on. Again, if it goes to 11, MMOG players will not be satisified with 10.

How exactly does your design intend to keep every single member of a guild out of a siege? It sounds to me like you are trying to make Total War, except that 5 or 6 players can all play unit commanders. What happens when a 200-player guild wants to siege. Sure, it may only take 5 guys online at any time to move the NPC's into the fight, but when the fight happens, you can count on at least half of any half-assed organized guild to be at the siege. What exactly at the design stage are you going to do to cut out that eventuallity?

Strangely enough, that's one of the reasons instancing has become so popular, because you can't design expecting that players will do what you want them to do. If there's a bigass fight going on, people who may not even be remotely involved will want to be there. And again, numbers matter. The first rule of military strategy is get there the firstest with the mostest. It doesn't matter if you only need 5 guys, if an organization can move 500 with efficiency, they will whether your design encourages that or not.

Also, the updates you would have to send to the rest of the players on the server cluster have nothing to do with the siege updates, I'm talking about just the regular updates EVERY client has to get from the server in order to function. Those transactions pile up, putting strain on the server cluster. Combine those with the ultra-intense transactions in a large siege, and you have server lag.

[Stephen Zepp]

If your design is not going to factor in the fact that there WILL BE an assload more units than you want into it, you have failed at the design stage. I'm not talking about every player on the server being there. But unless you put an artificial limit on the size of a guild or alliance, you better be able to count on there being a lot more players at the action focii than you it sounds like you are counting on. Again, if it goes to 11, MMOG players will not be satisified with 10.

The design intent here is to handle that by managing it via geographical size vs unit size (back to the assumption that collision is critical here to avoid stacking), combined with dynamic load balancing. If/when a particular action locii becomes "overpopulated", break it up into two (or more) more evenly balanced action locii, and/or distribute server requirements across higher powered assets.
If 50 total players plus all their units are at a siege of one medium sized village, assign them a "level 2" resource set. If another 50 players show up, either assign a higher powered resource set, or break it into 2 locii. That's the concept (again, I know there are huge implementation issues there).

If you have a siege pitting the two largest guilds in a world, allocate your most powerful server resource sets to them.

How exactly does your design intend to keep every single member of a guild out of a siege? It sounds to me like you are trying to make Total War, except that 5 or 6 players can all play unit commanders. What happens when a 200-player guild wants to siege. Sure, it may only take 5 guys online at any time to move the NPC's into the fight, but when the fight happens, you can count on at least half of any half-assed organized guild to be at the siege. What exactly at the design stage are you going to do to cut out that eventuallity?

It doesn't intend to keep people out of sieges, but it does intend to distribute them across separate action locii...and this is the simularity between action locii and instances that we do mostly agree on...for the purposes of performance (rendering, network, server load), we agree on the concept: break the points of conjestion into separate "instances". The only things that I disagree with regarding the concept of instancing is "multiple instances of the same content", and "no persistence of actions outside of the instance".

Strangely enough, that's one of the reasons instancing has become so popular, because you can't design expecting that players will do what you want them to do. If there's a bigass fight going on, people who may not even be remotely involved will want to be there. And again, numbers matter. The first rule of military strategy is get there the firstest with the mostest. It doesn't matter if you only need 5 guys, if an organization can move 500 with efficiency, they will whether your design encourages that or not.

The SB model, and even many RTS games (warcraft 3) really pressed the point of "fasted with the mosted" (or mass/concentration of force), but that was because in both of these games, there was basically a binary event that determined win or lose. Take a look at military history from the perspective of "ok, what really won these battles?". Much of the time, while tactical effectiveness and sheer force were very important for a specific engagement, the strategic objectives, handled properly, were really what wins wars. Our current games simply don't allow for concepts like logistic line interdiction, territorial supremacy, and any of the concepts of strategic/tactical mobility. Our games today are pretty much just "get everyone in the same spot and slug it out until only one is left standing"...and that is the fundamental design change we're trying to work on when it comes right down to it.

EDIT: Point that demonstrates is the "Scout Battle" stuff that was mentioned either in this thread, or elsewhere. That's a recon screen battle, and is one of the largest contributing factors to successfully prosecuted engagements. You got just a taste of that with SB, and I've seen some players use recon amazingly well in winning warcraft 3 games, but for the most part the game design simply doesn't even take it into account. I think it should take it into account, and a lot more of the contributing factors in war.

Also, the updates you would have to send to the rest of the players on the server cluster have nothing to do with the siege updates, I'm talking about just the regular updates EVERY client has to get from the server in order to function. Those transactions pile up, putting strain on the server cluster. Combine those with the ultra-intense transactions in a large siege, and you have server lag.

If the primary siege event(s) and the "rest of the world" all share the same server resource set, absolutely. That's the purpose of the dynamic load balancing. For example, in SB, what happened on the War server didn't have any (well, much anyway) "lag effect" for the players on Corruption (except for the common tie points we can assume: databases and total network hardware). In EQ, it was very rare for 3 huge raids in ToV to affect players fighting gnolls in other zones.

It will never be perfect, I'm not trying to say that at all. But the principles already exist to distribute load at a higher level, and if implemented well, they can be extended down to lower levels--again, either AC or AC2 did this exact thing. It just didn't get copied by other developers much because of other, completely unrelated reasons.

[HaemishM]

Wait, how exactly is what you just now described NOT instancing? Because it pretty much sounded like the exact same technical implementation I was on about, only you give one set of people one set of content, and another set of people different content.

How is that not instancing?

[Stephen Zepp]

Wait, how exactly is what you just now described NOT instancing? Because it pretty much sounded like the exact same technical implementation I was on about, only you give one set of people one set of content, and another set of people different content.

How is that not instancing?

I commented on this in another thread (I think), but the problem with the term "instancing" is that it is collecting a LOT of meaning. You use it in two ways that I can tell--one to discuss load balancing in and of itself (which is a fine definition, but load balancing works as well), but you also have attached the concepts of "forced balance" and "limited access" (which implies controlling access to content that wouldn't be limited for any other reason than load balancing).

However, when used in relation to other games, it picks up some really wild additional meanings:

--exact duplicate geographies/content that can be accessed simultaneously but not while interacting with each other by multiple players. (Player A is standing at 11.4, 23.1, 5.6 in ZoneA::Instance1, while Player B is standing at 11.4, 23.1, 5.6 in ZoneA:Instance2, yet they don't see each other).

--raid/pvp style where entry into a particular instance is allowed/disallowed based on the current participants in that particular instance.

I completely agree with the needs of the first description (load balancing), but when you start adding in things like the second two, that's where you and I differ strongly.

As an example, if you have SuperStrongGuildA with 100 members, and they all want to attack BrandNewGuildB with 10 members, I agree that you need to give the fight itself a separate resource set from the rest of the game world, but I do NOT believe that you should also limit the number of members of GuildA that can participate in that siege simply because GuildB is weaker.  Balance is critically important, and you don't want the rich getting richer, but I do not agree that forced balancing in fights via controlled access to instances is the way to do that.

I also do not believe that RandomPlayerX should be able to visit where the siege is happening, and NOT participate in the siege itself.

[HaemishM]

Good luck getting that load balancing thing working. You are aware that the exact same mechanic you describe is currently in ever MMOG in one form or another?

[Hoax]

I'm going to add some non techno babble in here...     :-D

I think you can force players to spread their forces out during siege combat.  You make it a bad tactical choice, sure people will bring the max amount of forces you let them bring.  But if you put enough things into a game that do heavy AoE damage, or spells jump from target to target, or plagues that spread from npc to all nearby npc's ect ect ect, siege weapons with heavy blast damage, cannonballs that will hit one person and roll into others, archers who are inaccurate but who have a chance of missing into nearby targets ect ect ect.

Make it tactically completely fucking unsound to not maintain a good spread between forces.

Make a siege practically require you to surround the fortress/town/village/castle via some kind of mechanic, and make them take up allot of geographical space, thereby spreading out forces to several battle points.

Make flanking, and attacking from the rear effective against npc troops to encourage/force players to have skirmishers/vangaurds to protect against such attacks.  Further spreading forces out on the battlefield.

I believe one can through gameplay prevent just sticking as much firepower in one place the most effective tactic.  We've all agreed (its seems) that you wont prevent having more forces from being more effective so it seems logical the solution is to make spreading those forces out by far and away more effective then getting them all packed in one point, or you just arbitrarily tell people they can't participate ala Haem's instancing...

[Stephen Zepp]

I'm going to add some non techno babble in here...

I think you can force players to not gather too much in one spot.  You make it a bad tactical choice, sure people will bring the max amount of forces you let them bring.  But if you put enough things into a game that do heavy AoE damage, or jump from target to target, or plagues that spread from npc to all nearby npc's ect ect ect.

Make it tactically completely fucking unsound to not maintain a good spread between forces.

Make a siege practically require you to surround the fortress/town/village/castle, and make them take up allot of geographical space, thereby spreading out forces to several battle points.

Make flanking, and attacking from the rear effective against npc troops to encourage/force players to have skirmishers/vangaurds to protect against such attacks.  Further spreading forces out on the battlefield.

I believe one can through gameplay prevent just sticking as much firepower in one place the most effective tactic.  We've all agreed (its seems) that you wont prevent having more forces from being more effective so it seems logical the solution is to make spreading those forces out by far and away more effective then getting them all packed in one point.

Nail on head man, that is exactly what I mean!

[Stephen Zepp]

Good luck getting that load balancing thing working. You are aware that the exact same mechanic you describe is currently in ever MMOG in one form or another?

You could also say that every Windows game ever made has persistent storage--because Windows pages out memory to disk as required. Doesn't mean this "persistent store" actually accomplishes what it should.

In other words, there is a big difference between static load balancing (everyone in one zone that doesn't change dimensions is on one resource set), server load balancing (everyone on one game world uses a separate resource set), and dynamic load balancing.

Is it going to be difficult to implement? Hell yes--it's one of the hardest things around. Can it be implemented well? Absolutely--AC did it already. Can we do it? Guess we'll see!

[Hoax]

Let me add what I consider a complicated to balance and implement but eligant in effect method to accomplish what I was saying in my last post.   (perhaps I'm on a roll?)

Reduce the effectiveness of npc troops the more any one player tries to control.

i.e.  If playerA is controlling 15 scouts they respond instantly to his orders and move quickly and effectively like rts units.

PlayerB on the other hand has 100 units, it takes a variable amount of time perhaps up to 1 minute for them to fully respond to his orders, they move slower to a point, and take awhile to switch targets or break off attacks.

Not only does this encourage people to use only the forces they need, and punish zergs but its realistic as giving orders to a handfull of men is easier then commanding an army I'd wager.

[Evangolis]

If the primary siege event(s) and the "rest of the world" all share the same server resource set, absolutely. That's the purpose of the dynamic load balancing. For example, in SB, what happened on the War server didn't have any (well, much anyway) "lag effect" for the players on Corruption (except for the common tie points we can assume: databases and total network hardware). In EQ, it was very rare for 3 huge raids in ToV to affect players fighting gnolls in other zones.

To quote a favorite phrase from Larry Niven, "That turns out not to be the case."  At the end of beta Shadowbane brought multiple servers on line for the first time, and hideous lag and server crashes followed, owing to something in the way networking had to be done.  I heard several sides of it, and couldn't claim to have understood it all then, although everybody sounded very knowledgable about it.  The problems persisted into launch, and I think still do, and as I understand it, this was a primary cause of the guy responsible for the hardware choices leaving the company a few months later.

It is going to be very hard to test this stuff short of full beta, and even then, things always seem to be more complicated in Live.  I would suggest that there might be a possible mockup test you could do with a mockup set of servers and something like the SETI-at-home screen saver, using unused bandwidth to run a mock client.  I also saw a Realm Wars game on the Garage Games site, and that might be an even better test of the networking code.  You'd know better than I.  In any event, nothing ever seems to fully replicate what happens in Live.

I like what you are trying to do with your project, by the way.  I don't think it will work, not even one in a million, but it's your time, and who knows?  I'll try to remember to check your next couple .plans, as I'm curious what you've experienced.

I have to bow out of this discussion now, as I have to run toi the Hinterlands for a couple of days.  Talk among yourselves.  :-D

[Stephen Zepp]

Interesting to hear, because from a black box perspective, SB was one of the ones that (appeared, obviously) to not use load balancing within a server...the fact that you could lag standing completely alone in a city while a very large siege was happening on the other side of the world. Guess they tried it, but had network backbone issues--only thing I can think of to cause the cross-over lag if they were on different resource sets.

[Alkiera]

Interesting to hear, because from a black box perspective, SB was one of the ones that (appeared, obviously) to not use load balancing within a server...the fact that you could lag standing completely alone in a city while a very large siege was happening on the other side of the world. Guess they tried it, but had network backbone issues--only thing I can think of to cause the cross-over lag if they were on different resource sets.

As far as I know, SB servers were NOT run on multiple machines like every other MMO, but were on single monolithic machines.  Several references to 'big iron', etc.  IMO, this would be the cause of most of the server-side lag in that game.  They didn't seem to have any load balancing at all, tho I recall them claiming they would.  I don't think it ever happened.

As far as EQ, they did have static load balancing, as each game server was multiple machines, each machine ran a handfull of zones.  Occasionally you could feel it when your current zone was on the same box as ToV during raid time, or other major zones.  But only occasionally...  You also tended to feel it when they managed to crash that zone, as it frequently took down the whole machine, or forced them to reboot it, or some such... which would affect a couple other zones as well as the problem zone.  Early on, this kinda stuff was noticable with zones sharing boxes with East Commonlands or Greater Faydark, both being heavy player-congregation zones pre-Luclin.

I think dynamic load balancing is almost a 'holy grail' of MMO Gaming.  Having a setup that allowed a machine to scale the amount of territory that it had to manage by the number of players within that territory, so that as more people arrived, the machine had less space to manage, is ideal.  Getting it to work well...  is apparently not easy.

Alkiera

[Stephen Zepp]

Interesting to hear, because from a black box perspective, SB was one of the ones that (appeared, obviously) to not use load balancing within a server...the fact that you could lag standing completely alone in a city while a very large siege was happening on the other side of the world. Guess they tried it, but had network backbone issues--only thing I can think of to cause the cross-over lag if they were on different resource sets.

As far as I know, SB servers were NOT run on multiple machines like every other MMO, but were on single monolithic machines.  Several references to 'big iron', etc.  IMO, this would be the cause of most of the server-side lag in that game.  They didn't seem to have any load balancing at all, tho I recall them claiming they would.  I don't think it ever happened.

As far as EQ, they did have static load balancing, as each game server was multiple machines, each machine ran a handfull of zones.  Occasionally you could feel it when your current zone was on the same box as ToV during raid time, or other major zones.  But only occasionally...  You also tended to feel it when they managed to crash that zone, as it frequently took down the whole machine, or forced them to reboot it, or some such... which would affect a couple other zones as well as the problem zone.  Early on, this kinda stuff was noticable with zones sharing boxes with East Commonlands or Greater Faydark, both being heavy player-congregation zones pre-Luclin.

I think dynamic load balancing is almost a 'holy grail' of MMO Gaming.  Having a setup that allowed a machine to scale the amount of territory that it had to manage by the number of players within that territory, so that as more people arrived, the machine had less space to manage, is ideal.  Getting it to work well...  is apparently not easy.

Alkiera

The biggest stumbling block I'm having in designing a strong dynamic load balancing scheme is the action locii merges/splits. They require transferring all of your client connections to the new resource set, and this simply takes time to negotate all the connection remaps and ensuring the data is loaded well--time which is going to be noticed by the players. Boundary handling is a big issue as well, although not quite as difficult as the first.

[HaemishM]

So you plan to literally almost physically transfer all the characters, terrain information, NPC's, etc. to an entirely other piece of macchinery when there get to be too many people there, and you plan on doing this without them noticing, as the entire server architecture starts tossing around hundreds of concurrent connections and do it all seamlessly, transparently to the user?

Yeah, good luck with that negative ping code too.

I do not see why you are bothering trying to do something like that. With that kind of idea, you are going 3/4 of the way to instancing the siege anyway. If it works, you could potentially sell that tech to anyone for asstons of dollars. But if it doesn't, and I'm inclined to believe that without MAJOR financial backing and more patience than any VC/Publisher has shown in MMOG history ever, you're going to have a long cluster fuck of a beta ending up like Wish in a cancelled game.

Instancing is a better technical solution because it takes into account the limitations of today's hardware and Internet infastructure. Add in the fact that with instancing, you can more easily adjust things like balance, numbers, terrain placement, and additional siege-specific scripting features to make the experience much more dynamic than anything that's been seen on the PVP front. And you're only real argument against instancing is it "removes the virtual worldness." Which it doesn't, because you still have a world, that can be changed, and there are still thousands of others in the world, they just aren't all banging up against the siege's front door.

[sinij]

So you plan to literally almost physically transfer all the characters, terrain information, NPC's, etc. to an entirely other piece of macchinery when there get to be too many people there, and you plan on doing this without them noticing, as the entire server architecture starts tossing around hundreds of concurrent connections and do it all seamlessly, transparently to the user?

This does sound too ambitious to me, but without ambition there would be no innovation. What I keep wondering is why not use distributed processing with dynamical recourse allocation instead of copying process information around? You can much easier transfer calculation_a to another machine/processor than a process requiring calculation_a performed.

[Stephen Zepp]

So you plan to literally almost physically transfer all the characters, terrain information, NPC's, etc. to an entirely other piece of macchinery when there get to be too many people there, and you plan on doing this without them noticing, as the entire server architecture starts tossing around hundreds of concurrent connections and do it all seamlessly, transparently to the user?

Yeah, good luck with that negative ping code too.

I do not see why you are bothering trying to do something like that. With that kind of idea, you are going 3/4 of the way to instancing the siege anyway. If it works, you could potentially sell that tech to anyone for asstons of dollars. But if it doesn't, and I'm inclined to believe that without MAJOR financial backing and more patience than any VC/Publisher has shown in MMOG history ever, you're going to have a long cluster fuck of a beta ending up like Wish in a cancelled game.

Instancing is a better technical solution because it takes into account the limitations of today's hardware and Internet infastructure. Add in the fact that with instancing, you can more easily adjust things like balance, numbers, terrain placement, and additional siege-specific scripting features to make the experience much more dynamic than anything that's been seen on the PVP front. And you're only real argument against instancing is it "removes the virtual worldness." Which it doesn't, because you still have a world, that can be changed, and there are still thousands of others in the world, they just aren't all banging up against the siege's front door.

Once again, AC/AC2 already does this. They have a main action locii of the entire game world, and then break off additional locii as needed, and re-merge them as required.

How do you think "instancing" works? Exactly what I said. It creates a new "instance" of your content, duplicating everything (in the case of EQ's "many copies of same content") and then ports over the characters as required. Drive mirroring handles the raw "transfer" of data automatically, as would shared memory if it's actually on the same physical server (bad assumption, not scalable). The only difference between dynamic and static load balancing in this particular case is that there is no merge/split functionality to handle shifting performance hits.

Dynamic load balancing is in no way "new/unproven" technology. Kernel schedulers for multi-cpu systems already do it. Hell, single cpu kernel schedulers do it--check out the "nice" command in any *nix flavor. High volume traffic web servers do it. Shit, even elevators do it (of course, it's much easier since there is a lot less data :P).

If a siege is occuring, and player Z cannot login, walk for 2 minutes and be at the siege, that's immersion breaking, at least for our project. I would argue that the same is the case for many persistent world games.

[Stephen Zepp]

So you plan to literally almost physically transfer all the characters, terrain information, NPC's, etc. to an entirely other piece of macchinery when there get to be too many people there, and you plan on doing this without them noticing, as the entire server architecture starts tossing around hundreds of concurrent connections and do it all seamlessly, transparently to the user?

This does sound too ambitious to me, but without ambition there would be no innovation. What I keep wondering is why not use distributed processing with dynamical recourse allocation instead of copying process information around? You can much easier transfer calculation_a to another machine/processor than a process requiring calculation_a performed.

Haemish was using an implementation mechanism (and not a particularly good one, you wouldn't "move" everything all at once, nor would you initialize a new resource set only as it becomes needed, that is way too much delay) to invalidate a design. Two completely different things. Your implementation suggestion is a much better one, although it would actually involve a lot more when you have to factor in cross-boundary functionality.

For example, say Player Z is in the action locus "Main". A siege is going on at City ABC, and has it's own action locii defined, call it "Siege10". As the player approaches the boundary, a reference object representing Player Z has to be entered into "Siege10", so anyone near his boundary crossing point would be able to observe him. As he crosses the boundary (using a hysteresis(sp?) algorithm to avoid thrashing across the boundary) the reference in object in Siege10 becomes the primary control object, and the "old" control object in "Main" becomes a reference object (reference object meaning that everything that happens to the control object is mirrored in the reference object). Once he moves away from the boundary (out of the max observable range of anyone back in action locii "Main"), the reference object in "Main" is removed.

Again, the critical performance issues are not with the concept of the action locii themselves, nor is it in the boundary crossing (although there is a tiny bit of increase here as the reference objects must be maintained)--the primary issues are in the management of the action locii themselves, specifically any merge/splits as the allocation metrics demand new action locii to be formed to handle high demand (large sieges). Predictive scheduling (lots of units are convering on a particular locale, so predict that a high level resource set is needed, and kick it off, including the reference object management ahead of time) will probably be the primary solution, but it needs more research.

EDIT: I hesitate to mention this due to this community's general perception of the game, but either Darkfall Online, or Dark and Light (can't remember which, and don't have the research links on this computer) are using this design concept as well. I have no reports whatsoever on how their implementation worked, but the public mention of the implementation (by the dev's) is positive.

[MaceVanHoffen]

If your design is not going to factor in the fact that there WILL BE an assload more units than you want into it, you have failed at the design stage. ...

Again, if it goes to 11, MMOG players will not be satisified with 10. ...

How exactly does your design intend to keep every single member of a guild out of a siege?  ...

As I've mentioned elsewhere in the thread, if your game design allows for 200 directly client controlled and fully update needed player objects in a close-in situation, then it's the game design that should be adjusted.

While it is possible for 200 player avatars to be in the same geographical space as 200 npc ... and good design makes it an extremely rare occurence. Of course, players could do it intentionally ...

This is a fundamentally unsolvable problem because of the emphasis on combat.  Emphasis, or perhaps even total focus to the exclusion of anything else.  Combat by its very nature tends to make players want to cluster together, especially in an RTS-like game.  I think you have to try something else.

The only reliable way I see to encourage players along different lines is to give them non-combat ways to interact with the world that are every bit as compelling as combat.  As long as the only or most compelling option players have is combat, then that's all they'll do, increasing the risk of breaking the overly-elaborate system described above.  Give players crafting systems that aren't file download bars with a sound at the end.  Give players rewards for exploring.  Give players intricate missions that are more than just kill-this-foozle-and-bring-back-an-item.  Give players things that make them want to spread out over the game world because it has direct benefit to do so.    Do those things, and a smaller percentage of your concurrent players will be involved in combat at any given time.  This reduces the risk of player clustering and, in turn, the need for so much developer time spent on solving what amount to glorified network problems instead of putting in compelling game content.