I hope this comes across clearly...it''s not so easy to type this in a quick post! I''ve got a MMORPG in my head that I''m trying to translate to a very detailed design document. I''m not interested in trying to program the thing by myself, but I would like to design as much as possible without touching code first. I''m a bit weak when it comes to the networking aspects of a large online game, and I have a "is this possible" type question that I would like to have answered first before I go down a design path that I can''t come back from. I get the impression that typical online games like EQ have a single monster server in the background (one for each "shard"?). I would think this immediately imposes a maximum to the number of users that can connect to a single server. I would like to avoid this bottleneck from the start, and design an architecture that is based off of many small server PCs. Ideally, I would like to have task-specific PCs that I can pass the client connect to. For example, I plan on separating battles so that they do not take place in the same area that random players may be running past. In this way, a battle could be run from a separate PC that does not require constant updates from the main game world. Can I have a client connect to a game server, then when they enter a battle have the game server pass the connection off to a battle PC, then when the battle is done pass the connection back to the game server? This is a simple example, but in the final design this will be happening among a huge number of devoted PCs. Can anyone think of any negative impacts this would cause (performance-wise, scalability-wise, complexity-wise)? Hope that question made sense!

Its perfectly possible as far as i can see, in fact ive been pondering that myself, my game being more action oriented, i was thinking of having certain people choose to be "squad leaders" and their "squad" would connect to them, and then would be routed, through that computer, to the main server, decreaseing the load on the server, the only problem that this creates, is lag, adding another relay point adds lag, i plan to implement this plan and see how bad it really is, if i see it as acceptable, i will use it, another thing you might want to look into is multicasting, though my understandind is that its not availiable everywhere... which may be/is a problem.
hope that helped
-Dan

Ademan, aren''t you relying too much on the client then in terms of security?
I see a weakness in people starting a backend client to create a load of "squadmembers" helping them out. You can''t controll that.
Or people trying to retrieve sensitive data of their squadmembers. You have to be very carefull with things like these. Every bit of data that is evaluated by a client before arriving at the server is potentially at risk.
Same with the server relying on clients sending absolute positions instead of keypresses. This sort of data can be manipulated.

True, but two things, first i dont plan on giving my build out to anything but my close friends (none of which i would expect to be able to do taht) and second, this is my first run at networking within a game, while id like to simpulate keypresses, that seems like there would be too many packets (one per keypress) OR too big (accounting for every keypress, additionally, i only plan to send the velocity of the user to the server, it will calculate all physics, and then send the absolute positions back, this MAY create a latency issue, but i dont know that yet, and untill i try it out for myself im going to assume it wont
-Dan

Ofcourse, you have to start somewhere.
Also remember that security through obscurity does not work well. People will be able to reverse engineer your application.

But if you aren''t worried about cheaters, then your concept could work.

Anyway, the keypresses thingy could be very light on networking resources... Assume your player can press 20 keys (forward, backward, left, right, fire, switch weapon, etc etc), you could suffice with a 20 bits packet, effectively 3 bytes of data. With an OR and AND operation you can extract whether a bit is set or not.
Then you have an "internal framerate" or for example 20 frames per second. each "internal frame" the client sends this key status to the server. 3 bytes... 20 times a second... 60 bytes/sec... sounds reasonable... 30 clients... 1800 bytes, just under 2kb. Ofcourse, not taking into account other overhead as client id''s or special events or whatever a client needs to send to the server.
The server also has to update its clients with position information. This is a lot more data to worry about. Depending on precision you can''t suffice with one or two bytes for position and orientation.
Client ID, one byte
X Position, two bytes
Y position, two bytes
Z-Rotation, one byte

Add game events, a third dimension and multiply all this with 30 clients and 20 "frames" and a bunch of network overhead and you are looking at a load of data a standard cable connection is not capable of dealing with (we got crappy cable here...).

I''ll stop now... I''m typing more than I should again and I''m derailing the thread.
But I''m convinced the key-press thingy is the way to go in terms of security and network load.




Still, to come back on the original post, technically it is possible.
CL - Client
SRV - Server

CL -
SRV -
CL - yO, Log in
SRV - Aight
~~~~~~
SRV -
SRV - CL: connect to SRV2 with IP xx.xx.xx.xx at port y for battle z
CL - OK
CL -
CL -
SRV2 -
CL - Yo, I''m here for battle z, I''m client CL
SRV2 - Ah, yah, I got you in my list
~~~~~
SRV2 - Yo, CL... the battle is over (or, you are leaving the battle), connect to main server xx.xx.xx.xx at port y for normal operation
CL - OKi Dokie
CL -
CL -
SRV -
CL - yO, Log in , I''m back from battle z
SRV - Aight
~~~~~~
etc etc

Something along the lines of that.
It''s definately not a technological bottleneck, but you really have to work this out very good and detailed.