Serverless MMOG?
Author
Have anyone thought of designing protocols for a serverless MMOG? I don''t know if it would be possible? There would only be clients and essentially no server. By that I mean, no server that requires short responsetime or great bandwidth.
The advantage would of course be that there''s no risk of a game server becoming a bottleneck. Also, the cost of running an MMOG would be much smaller, since all hardware is provided by the clients and by the internet (routers and such). Theoretically, the minimum responsetimes could be lowered also, in the ideal situation where data is sent from one client directly to affected peers.
In a way I guess this is how the Internet infrastructure works at the basic level. We''re all connected, but still there''s no central "internet server".
quote:Original post by Snakebite
In a way I guess this is how the Internet infrastructure works at the basic level. We''re all connected, but still there''s no central "internet server".
THere is no Central Server, but a Network of Servers. It would be Impossible in my opinion, as for a start how would the clients know how to contact each other? also, It would be much slower than a server based system as each client would have to notify all the other clients in the game-area about it''s status.
You would also have the problem of enemies - how do they know it would be the same on all machines?
If it were done, each client would need the bandwidth and processing power of a server.
Author
quote:Original post by Xgkkp
as for a start how would the clients know how to contact each other? also, It would be much slower than a server based system as each client would have to notify all the other clients in the game-area about it's status.
You would also have the problem of enemies - how do they know it would be the same on all machines?
I'm thinking each client would only need a connection to nearby peers (nearby in the gameworld). This is not a new concept, I've seen it discussed but forgot the term for it. Basically, if I'm out of your sight and you're out of my sight, we really don't need to know what the other is doing. If we move closer to eachother, a connection must be established. Knowing when that occurs is one specific problem. The solution would have to be a distributed one, and one idea how it could work would be this:
A -- B -- C The above represents the logical connections as well as location in the gameworld. If A moves closer to C, A and C should connect. B would have to be involved, since A and C don't know of eachother yet:
B / \ A C If B has the coordinates for it's peers, it will know that A and C are sufficiently close at this point and B can tell them to connect by providing each with the IP address:
B / \ A --- C If they move apart, they'll know when to disconnect. This is to save bandwidth. Of course, they can't disonnect their last few peers or they'll lose contact with the whole game. In a city or other crowded area, the bandwidth problem would grow quickly. A couple of dozen players in one area should not be a big problem. I'm not sure how to counter more extreme cases.
Maintaining the same state on all clients (local to one area) is another problem, sure. I'm still not convinced it's impossible.
[edited by - snakebite on June 10, 2002 11:13:36 AM]
[edited by - snakebite on June 10, 2002 11:14:27 AM]
What you''re thinking of is a loose network of machines in a arrangement that looks like a distributed network. An interesting idea that has some drawbacks though. 
Internet packet routing does not allow broadcast packets to be sent for obvious reasons. You would still need a lightweight server capable of knowing what machines were connected together forming the network. OK a simple web server with some creative perl scripts could handle this. So that removes the problem of connecting to the network.
Aside from the security aspects of running a truly distributed system on your users machines you have the problems with firewalls that are on many machines these days. Common set-up for a firewall is to deny all incoming packets unless a packet has been sent from that port to the destination address. If two machines have this set-up then effectively they can never connect to each other. To over come this you have to get the user to configure the firewall to trust the application or to specifically allow certain ports and/or addresses to pass through. Users may not be happy having to configure open ports on their tightly guarded machines. On a related point, Everquest over comes this by having a central server where the ports are open so the users firewall will allow the outbound packet and reply to be gained. OK so some users don''t have such strict firewall settings and is this case they can act as a message hub for users that have rigid firewall settings. However while this might seem to provide a solution it is usually the users with slower dialup type connections that have more relaxed firewall setting and low bandwidth users wouldn''t make a good message hub. As a general rule the faster the users internet connection the more rigid their firewall settings. I can imagine the customer service nightmare if you had to tell users how to reconfigure their firewalls to allow such network traffic.
There is a good side to such a distributed system though and this would be company networks where you can have several people playing the same online game in the office. A distributed system could take advantage of the fact that in a 16 player death match game you have 7 office friends all in the same death match. In this scenario you have 7 players who can have very good ping times with each other. This is pretty much the system that my network API can provide. ( http://www.replicanet.com ) Basically the network is distributed, with a machine nominated as a master server however when a user connects it first connects to the master server and then the user''s machine tries direct connections to each of the other users. If the direct connection is better (based on ping) then the direct connection is used in preference when communicating to that user.
Anyway those are my thoughts on the matter.
Internet packet routing does not allow broadcast packets to be sent for obvious reasons. You would still need a lightweight server capable of knowing what machines were connected together forming the network. OK a simple web server with some creative perl scripts could handle this. So that removes the problem of connecting to the network.
Aside from the security aspects of running a truly distributed system on your users machines you have the problems with firewalls that are on many machines these days. Common set-up for a firewall is to deny all incoming packets unless a packet has been sent from that port to the destination address. If two machines have this set-up then effectively they can never connect to each other. To over come this you have to get the user to configure the firewall to trust the application or to specifically allow certain ports and/or addresses to pass through. Users may not be happy having to configure open ports on their tightly guarded machines. On a related point, Everquest over comes this by having a central server where the ports are open so the users firewall will allow the outbound packet and reply to be gained. OK so some users don''t have such strict firewall settings and is this case they can act as a message hub for users that have rigid firewall settings. However while this might seem to provide a solution it is usually the users with slower dialup type connections that have more relaxed firewall setting and low bandwidth users wouldn''t make a good message hub. As a general rule the faster the users internet connection the more rigid their firewall settings. I can imagine the customer service nightmare if you had to tell users how to reconfigure their firewalls to allow such network traffic.
There is a good side to such a distributed system though and this would be company networks where you can have several people playing the same online game in the office. A distributed system could take advantage of the fact that in a 16 player death match game you have 7 office friends all in the same death match. In this scenario you have 7 players who can have very good ping times with each other. This is pretty much the system that my network API can provide. ( http://www.replicanet.com ) Basically the network is distributed, with a machine nominated as a master server however when a user connects it first connects to the master server and then the user''s machine tries direct connections to each of the other users. If the direct connection is better (based on ping) then the direct connection is used in preference when communicating to that user.
Anyway those are my thoughts on the matter.
Yep, that''s a very good idea. I''m pretty sure a dozen and more groups are researching about a Peer-to-Peer MMOG.
There is one huge drawback that I would love to see how it would get solved. Hacked Server (since it''s client-side). What''s to prevent a hacked server to send wrongful infos to others and gain advantages ?
There is one huge drawback that I would love to see how it would get solved. Hacked Server (since it''s client-side). What''s to prevent a hacked server to send wrongful infos to others and gain advantages ?
Well, the problem isn''t a "hacked server" as it was called by the previous poster (there is NO server), instead the problem lies in that there is no single authority for correcting out of synch objects. You would continually propogate incorrect information across the network. Since you are running some portion of the simulation on different peer systems, it will inherently get out of synch. When this happens, you have no authority for the clients to reference, and chaos ensues.
Now, add in the general hacker mentality of many online gamers, and you have a recipe for a quickly failed game. Everytime your copy of the simulation receives an update from someone else, you have to accept it as correct, and thereby leave yourself open to false (hacked) information.
What happens in this system when you get 100 players in a small enclosed area? Those peer to peer updates will kill any hopes of having a playable game.
This is an area worth researching as networking technology improves and system hardware gets faster, but it isn''t currently worth considering for a MMOG.
Now, add in the general hacker mentality of many online gamers, and you have a recipe for a quickly failed game. Everytime your copy of the simulation receives an update from someone else, you have to accept it as correct, and thereby leave yourself open to false (hacked) information.
What happens in this system when you get 100 players in a small enclosed area? Those peer to peer updates will kill any hopes of having a playable game.
This is an area worth researching as networking technology improves and system hardware gets faster, but it isn''t currently worth considering for a MMOG.
Has anyone heard of Terrarium? If not, check out www.GotDotNet.com
Basically it is a MMOG for programmers, made by Microsoft to let us have some fun with Dot NET. It is a game where each persons computer acts as a terrarium, where you introduce your own bugs that you have programmed yourself.
As far as how people are linked up, you are only aware of the people very close to you on the chain.
Basically it is a MMOG for programmers, made by Microsoft to let us have some fun with Dot NET. It is a game where each persons computer acts as a terrarium, where you introduce your own bugs that you have programmed yourself.
As far as how people are linked up, you are only aware of the people very close to you on the chain.
I thought that the it had two modes; one mode is a local "test" mode and the other is a out-of-process mode. Basically you submit your assembly to the server and it gets processed there. So your system doesn''t interact with others...
Dire Wolf
www.digitalfiends.com
Dire Wolf
www.digitalfiends.com
Author
quote:Original post by fingh
there is no single authority for correcting out of synch objects. You would continually propogate incorrect information across the network.
Yeah, I guess we need a server afterall. I was hoping by having really hard to break protocols, every client could be trusted and every client would carry whatever information that concerns that particular avatar, his inventory, his vehicle etc. But then I don''t know what to do about information that concerns say a building (what lights are on, what doors are locked, etc).
Perhaps a combination of serverless and today''s star-configuration could be found. A server for critical information but also peer-to-peer to off-load the server and the network.
What I really wish for is a way for us hobby developers to do MMOG. I miss the days of MUDs when almost anyone could run a multiuser game.
But I want it bigger of course and 3D and no $10/month fees. I guess those days are over.quote:Original post by Snakebite
I was hoping by having really hard to break protocols
I don''t think there is such a thing. If you put it on the wire, or on the client, it can and WILL be hacked by some 14-year old kid running SoftIce. The key to keeping hackers from killing your game is to make sure that even if they figure out your network protocol (and they will) that you are not sending information that is of enough use to make it worthwhile for them.
Believe me, the expense of running MMOGs is high enough that if a server-less way to do it existed, the companies paying out the yang to provide these services would have found it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
