Hi. I''m kinda dreamin'' up a game design and ran into a major obstacle. I''d like to get a massive number of players in one spot with say 20 or so units each - a MMORTS. An example would be 100 players in battle with an average of 15 units each. That would put something like 1500 units into the ''zone''. Gameplay balancing issues aside, I was trying to figure out what kind of server architecture could be used to manage such a huge number of collision detections and rules verifications. Even with the slower than average game speed (I prefer strategy to a clickfest) that I am considering, the server load would probably be too great for one CPU. So, of course there is the multi-CPU and multi-thread option. I know there are 4x CPU servers available and maybe 8X CPU servers but that''s lots of dough ($). Would multiple servers with gigabit ethernet interconnections add an unbearable amount of latency to the interactions between servers managing the same ''zone''? My idea is to have one ore more servers per zone, each responsible for verifying and updating the movement, collision and rules of a subset of entities in the zone. In this scenario, Server 1 would receive the requests from Team A, verify those requests and then broadcast the results to Server 2 and any game clients ''interested''. Likewise, Server 2 would do the same for Team B''s requests. Of course, each server would be holding a duplicate set of statistics for all static entities in the zone (terrain, rocks, trees, buildings etc.) as well as the statistics for the dynamic entities in the zone. This might lead to synchronization issues? I''m pretty sure this idea isn''t new, but I''d like to hear what the holes are. Is this system not used for some really important reason that I am missing? Is it an issue with client/server bandwidth already limitting the numbers anyway? Is it a performance issue among servers or is it a synchronization issue between world servers? Anyone know the specs and server count for current MMO games like EQ, SWG, Shattered Galaxy, Planetside?

quote:

---

Even with the slower than average game speed (I prefer strategy to a clickfest) that I am considering, the server load would probably be too great for one CPU.

---

Don't underestimate the value of good design. First of all, you will likely reach numeric limits on the client before you reach them on the server (unless you have a really bad server programmer or really bad hardware). Keep in mind that you actually have to render each unit in an area(depending on visibility of course).

quote:

---

Anyone know the specs and server count for current MMO games like EQ, SWG, Shattered Galaxy, Planetside?

---

Yes, and your statement

quote:

---

I know there are 4x CPU servers available and maybe 8X CPU servers but that's lots of dough ($)

---

holds true for them as well. You aren't going to see game companies flopping down the cost of 4x and 8x systems for MMORPG any time soon. It's not necessary when there are numerous other ways to partition space so that they can use low end servers(and I think this is really what you should be looking for). No reason to keep the idea of a 'zone' as being a discrete, rigid area (like EQ). If you have 'seamless' zones then you can partition your space on the server everytime you get a high unit count in any particular area (just split the area in two at run time). The client doesn't know the difference (nor does it care...).

quote:

---

Is this system not used for some really important reason that I am missing?

---

If I understand the question, the answer is - because it's not necessary. Otherwise, MMORTS has tons of implementation problems that are not trivial to resolve. The game Sovereign that SOE piled 4 years of development time into was shelved, presumably because they couldn't get an implementation that made sense to MMO and RTS both. I'm working on a MMO strategy game right now as well, and I think we've solved a lot of the actual persistence issues inherent to a multiplayer RTS from a technical and creative/gameplay standpoint. It isn't easy, and the tradeoffs will make or break the game as a result.

Good luck with your game.

[edited by - fingh on August 8, 2003 7:31:54 PM]

"I''m working on a MMO strategy game right now as well, and I think we''ve solved a lot of the actual persistence issues inherent to a multiplayer RTS from a technical and creative/gameplay standpoint."

Oh no! Competition! :o)

"If you have ''seamless'' zones then you can partition your space on the server everytime you get a high unit count in any particular area (just split the area in two at run time). The client doesn''t know the difference (nor does it care...)."

Yeah, I know what you are saying. That''s why I was talking about Team A and Team B without any respect for where the units are actually positioned within the battlefield. It''s that line of thinking that I was following when I begain putting this arrangement together. I just keep getting stuck on the idea of spatial zoning (maybe due to the gameplay issues involved) because of past MMO experience and the functional design I am trying to come up with. The issue would be for a unit on one side of a boundary be unable to shoot a unit on the other side just because they are in different ''zones''. But ignoring spatial location is definitely the solution.

I knew that a continuous world was possible, just maybe a bit challenging. I guess the biggest issue is gameplay, as you pointed out in your comments about Sovereign (that was a game I was rooting for). You are probably familiar with Shattered Galaxy, which is one of the reasons I am dreamin'' up this design right now. It has its own failings. I''ve been trying to think of a good functional design (gameplay/features) that won''t fail the way SG did.

So do you guys have a website for your project? I''d be interested in hearing more about what you are planning. Part of the reason I am dreaming is because I want a better game to play and if you are going to make it then maybe I don''t need to work quite so hard to make it myself. :D

quote:

---

. That's why I was talking about Team A and Team B without any respect for where the units are actually positioned within the battlefield.

---

Actually, I would think you would have to intersperse the units based on locality such that combat between said units can be controlled in an authoritative manner by a single server process (single process controls a discrete area, just a SMALLER discrete area because of the potential run-time partitioning).

quote:

---

So do you guys have a website for your project? I'd be interested in hearing more about what you are planning.

---

No, we aren't ready to publish our ideas to a public site. I put a lot of time and effort into coming up with what our team believes is an innovative aproach to handling persistence in an RTS-type game.

quote:

---

as you pointed out in your comments about Sovereign (that was a game I was rooting for).

---

Heh. I have mixed feelings about Sovereign, SOE cancelled that project just shortly after I quit...

[edited by - fingh on August 8, 2003 11:03:13 PM]

"I would think you would have to intersperse the units based on locality such that combat between said units can be controlled in an authoritative manner by a single server process"

Hmm, well, I don't think that spatial location would affect how authoritative a server process can be about the actions of any units it is managing as long as it knows where the units are and knows all it needs to know about any entities that "its units" could interact with. I think part of the design choice would have to be based on what kind of performance and latency issues you expect to encounter with interprocess communication. There are several logical groupings I think you could use to determine which process manages which units. You could do it based on player ownership, team ownership, unit type and, of course, spatial location. I'm sure it would make sense for the design to filter only the information that a process needs for its work. You could do this at some level defined by continent or island or solar system or whatever method you use to define territorial chunks in your gameworld. I think that, at a micro level, dynamically adjusting spheres of influence or interest for one of these hypothetical server processes might generate quite a bit of unwanted "thrashing" or whatever you want to call it if large numbers of units start moving into and out of the boundary zones of these spheres of interest and processes start trading entity ownership around like baseball cards. At least, I think this would be the case if there are potentially 2000-3000 units engaging in a battle. I'm still just exploring all the ramifications, so maybe this is actually better than my thought of not doing it by spatial location. I suppose that in the interests of choosing the right method, I should consider modeling a couple different methods for dividing up the work and see which one works best.

I am gathering that your project is some sort of space based RTS? You keep mentioning the innovative persistence thing. Is this some way of handling the gameplay balance when players log off? Have you had any luck getting graphics programmers?

Sovereign kinda disappointed me as soon as the design changed from its initial vision as portrayed in an old game mag (was that PC Gamer or Computer Gaming World?). In that issue, Sovereign was described as a worldwide wargame with units based on contemporary hardware. I loved it. Then I saw something later that was all mech-looking and zoomed out Tribes style graphics (colorful, almost cartoon stuff). That kind of turned me off.

[edited by - Igilima on August 9, 2003 1:00:55 AM]

Asheron''s Call uses dynamic load balancing to handle this. If there are 3000 people in one zone and no one in neighboring zones, the servers dedicated for the neighboring zones will help take the weight off the one clogged with 3000 people.

quote:

---

There are several logical groupings I think you could use to determine which process manages which units. You could do it based on player ownership, team ownership, unit type and, of course, spatial location. I'm sure it would make sense for the design to filter only the information that a process needs for its work.

---

Yep. But in my case, since I'll be sending state updates for units based on locality, it makes sense to have only one process sending to the player when possible (although at 'border' areas the player may get updates from multiple servers. I don't see any need for distributing the state of NPCs across numerous backend servers (e.g. player one and player two are controlled by two different servers, but both are in the same location, fighting against some of the same NPC units)

Yes, it's a space-based persistent RTS-like game. Some of the design issues deal with offline players. Yes we have graphics programmers.

quote:

---

Sovereign kinda disappointed me as soon as the design changed from its initial vision

---

Yeah, I think they went through something like 3 complete redesigns before smedley and crew (or more likely, someone Sony Pictures) finally decided to pull the plug. I got to play a short demo in what you call the 'tribes' version. It was neat, although not really massively multiplayer.

quote:

---

Asheron's Call uses dynamic load balancing to handle this.

---

Yeah, there are several ways to do this, and the idea is pretty standard, although every game seems to handle it differently. I believe SWG monitors run-time server loading and migrates load dynamically between servers at both software and (IIRC) hardware level if necessary. Older games like EQ just manage load by throwing more hardware in and adding another complete instance of the game.

[edited by - fingh on August 9, 2003 12:58:16 PM]

The reason you haven''t seen this kind of thing in other commercial games is because it is basically impossible--not because no one has thought of doing it. Get 100 units working, then decide what it would take to manage 1500 at once when they is done. After you do that, see what your FPS is on your client application and see what your lag will be when you draw 1500 instead of 100.

That''s my advice.



Vengeance
Server Team Leader
Planeshift MMORPG
www.planeshift.it

When I was talking about having alot of units in one place, I didnt mean they were all going to be rendered simultaneously by the client with very high detail. My idea is a ground-based RTS. Sure, it could have zoom and pan functions but most of the time the player will be looking nearly straight down at a small portion of the action where his set of units is engaged. If the units were shoulder to shoulder, and the view was zoomed to a point where units were manageably sized, then at most there could be 400-450 onscreen at one time. Additionally, I would use a couple LODs and possibly revert to sprites, if the units are far enough away or the fps drops too far, in order to keep the client in sync with the game. When it comes to distances, I can also use fog of war to obscure all but the necessary units in view.

Using these methods to cull units would be far easier to do in my game concept than in the one fingh is alluding to. In space, you can see quite a ways and to fog it in all the time would kind of ruin the believability of the simulation.

You''re saying these designs that we are discussing are impossible, yet fingh seems to indicate that he has already implemented one form. Are your claims of impossibility authoritative based on experience or just opinion?

quote:

---

Using these methods to cull units would be far easier to do in my game concept than in the one fingh is alluding to. In space, you can see quite a ways and to fog it in all the time would kind of ruin the believability of the simulation.

---

I'm not suggesting 'fog' at all. Even in 3D, you still have a finite visibility based on relative size and distance. We're using LoD for units as well. Our game design dictates that we should never have anywhere close to 1500 units in any single visible area.

quote:

---

The reason you haven't seen this kind of thing in other commercial games is because it is basically impossible

---

I almost agree. If you are trying to port an existing game design like Starcraft or Age of Empires to an MMOG format, yes, I'd say it's impossible. If you are designing a 'new' game then it is very possible with a little creativity. (note - I'm not suggesting 1500 units on screen is reasonable, see next)

quote:

---

see what your FPS is on your client application and see what your lag will be when you draw 1500 instead of 100

---

Certainly. Trying to update 1500 units consistently over the network will kill you, let alone rendering on the client. But then again, if you design the game right from a creative and technical point of view, you shouldn't have to deal with 1500 units at once. That's one of the three real problems with moving a traditional RTS to massively multiplayer:
- persistence
- high entity count
- score/win/loss etc.

To accomplish this, we are going with a not-so-traditional RTS (more of an RTT) model that applies some of the community and 'replayability' ideas (e.g. customization) from other types of MMOGs.

quote:

---

Are your claims of impossibility authoritative based on experience or just opinion?

---

Probably both. If his signature is accurate, then he has some experience with at least one genre on online game. RTS is radically different from an RPG in many respects, but I wouldn't say it invalidates his experience.

[edited by - fingh on August 11, 2003 2:17:12 PM]