Multiple Servers/Seamless Terrain (Theory Only)
by CdnGater · in Torque Game Engine · 12/17/2004 (8:09 am) · 6 replies
I'm playing with an Idea that is currently totally all theory, and I wanted to get other peoples input.
But first two things, no, this has not been coded, and no, no resource will be created at this time. This is just a discussion.
I know the big push right now is MMO games. (Please, I know what's involved and I have not said I'm doing one, so no comments about it please.)
The hot topic with MMOs is seamless terrain. Now I do not want to discuss seamless terrain or its implementations. What I want to talk about is the back end. The Servers using the current TGE network scheme.
The one assumption I am making is that the client has been changed and now loads its own datablocks, and the server only sends updates, so there is no preload or relighting like what is currently implemented.
Having one server process all the users for seamless terrain is daunting. Not even the current MMOs that use seamless terrain use just one server. So we spread the processing over a number of different servers.
TGE, currently only connects to one server at a time, but if we are on a server boundary how do we show what's near the client from the next server?
One thought I have, and hence this discussion, would be to have the servers log into each other like clients. Setup some sort of markers that would be used as areas of interest for the servers.
Let's say we have two servers. A & B with Marker M in between them with an area of interest using radius 50.
What would happen, is on a regular update, Server A would send to Server B, all its updates for local (non-ghost) objects that is of interest to Marker M.
Server B would do the same thing back to Server A.
Both servers would then have ghosts of from each other around Marker M.
Of course you would setup triggers around Marker M to tell the client to jump from one server to another.
One issue I can think of, and it maybe a minor one, is having the server ghost ghosts to client and what impact that has.
Oh another issue, would be interaction with a ghost from the other server.
Anyway, I would like to discuss this idea, how feasible it would be and any other ideas anyone else has.
But first two things, no, this has not been coded, and no, no resource will be created at this time. This is just a discussion.
I know the big push right now is MMO games. (Please, I know what's involved and I have not said I'm doing one, so no comments about it please.)
The hot topic with MMOs is seamless terrain. Now I do not want to discuss seamless terrain or its implementations. What I want to talk about is the back end. The Servers using the current TGE network scheme.
The one assumption I am making is that the client has been changed and now loads its own datablocks, and the server only sends updates, so there is no preload or relighting like what is currently implemented.
Having one server process all the users for seamless terrain is daunting. Not even the current MMOs that use seamless terrain use just one server. So we spread the processing over a number of different servers.
TGE, currently only connects to one server at a time, but if we are on a server boundary how do we show what's near the client from the next server?
One thought I have, and hence this discussion, would be to have the servers log into each other like clients. Setup some sort of markers that would be used as areas of interest for the servers.
Let's say we have two servers. A & B with Marker M in between them with an area of interest using radius 50.
What would happen, is on a regular update, Server A would send to Server B, all its updates for local (non-ghost) objects that is of interest to Marker M.
Server B would do the same thing back to Server A.
Both servers would then have ghosts of from each other around Marker M.
Of course you would setup triggers around Marker M to tell the client to jump from one server to another.
One issue I can think of, and it maybe a minor one, is having the server ghost ghosts to client and what impact that has.
Oh another issue, would be interaction with a ghost from the other server.
Anyway, I would like to discuss this idea, how feasible it would be and any other ideas anyone else has.
#2
12/17/2004 (9:17 am)
Ben Garney hinted in one of the discussion forums that your idea of ghosting to other servers is a feasible one, and it sounds like you have a pretty good foundation so far!
#3
I had thought of that approach as well, just not too deep. Lets see, basicaly the meta network would echo object moves around the players area of interest. The local server would need to load and unload the objects dynamicaly. Interaction would also be echoed to the meta servers.
A bonus with this would be no server jumping.
I think should look into this approach some more.
Stephen,
It's hard to find things in this forum, would you happen to remember which one your talking about?
12/17/2004 (9:47 am)
OrionI had thought of that approach as well, just not too deep. Lets see, basicaly the meta network would echo object moves around the players area of interest. The local server would need to load and unload the objects dynamicaly. Interaction would also be echoed to the meta servers.
A bonus with this would be no server jumping.
I think should look into this approach some more.
Stephen,
It's hard to find things in this forum, would you happen to remember which one your talking about?
#4
12/17/2004 (10:41 am)
It was just an offhand comment from him in a simiar discussion (that didn't really go too far). Nothing really worth searching for. He just introduced the concept of ghosting objects from one server to another, instead of the more "normal" ghosting from a server to a client.
#5
It might be a larger required pipe to do something like that though. Just a thought.
12/18/2004 (9:07 pm)
Another possible idea is since the client will need to make a connection to another server anyways as it passes that boundy why not when you get somehwat near the boundy have the client send data to BOTH the servers then as they pass over the boundy and get a certain distance away the client will drop one of the connections?It might be a larger required pipe to do something like that though. Just a thought.
#6
Handle that internally, via master servers or something. Bandwidth costs can
be enormous as they are :)
12/19/2004 (7:01 am)
You should never have the clients sending to more than one contact point.Handle that internally, via master servers or something. Bandwidth costs can
be enormous as they are :)
Associate Orion Elenzil
Real Life Plus
has integrated Torque with their game grid back-end
via butterfly.net's product. - butterfly's site is offline at the moment but,
butterfly.net.
Basically what UCSD has going is each 'client' running both torque's server and client, but the server side is in communication with the larger servers.
The idea being massive scalability.
As of a few months ago they were only handling basic player navigation and such, but the framework was shaping up.
I can give you the email of some of the people down there if you're interested.