What is sent in a huge multiplayer game over the net?
Author
I am wanting to make a multiplayer game test. It will have 50 people all playing on one server. My question is, what info do I need to send? How is it sent? (to server then to all clients and then move players?) Or does client move then send to server then to other players? How often is information sent? How do I pack it all so it takes minimal time?
Basically, How do I get exceptable game play with 50 players on one server?
Thanks
Oh, also if there are any dll''s or code or tutorials or docs on this please stear me in the right direction.
Although I am not entirely positive on how an MMORPG works, I do know this: In Ultima Online, data about a player moving is sent from the client to the server and the server will only send it to another client if that other client is within a certain area. When a player enters the area of the client, I believe information about the character is sent, such as name, appearence etc. and is kept until that player leaves the are again.
As for packing it so that it all take a minimal amount of time is complicated. Make sure you choose an appropriate data type for sending positions. If the game is going to be cell-based (i.e. a player can only reside inside one cell) then you will only need to send an integer and so there is little point using a float or double. On the same line of thought, you need to choose how big the integer will need to be. Will your area by more than 65535 cells across or down? In which case you''ll need to use a 32-bit integer rather than a 16-bit. As for information such as name and appearence, it''ll be necessary to send either text, or a value that represents a certain aspect of what is being depicted. For example you could send 1 for brown hair, 2 for ginger hair etc.
As for how often, it is literally only when something changes and when it is necessary for a client to see it.
As for packing it so that it all take a minimal amount of time is complicated. Make sure you choose an appropriate data type for sending positions. If the game is going to be cell-based (i.e. a player can only reside inside one cell) then you will only need to send an integer and so there is little point using a float or double. On the same line of thought, you need to choose how big the integer will need to be. Will your area by more than 65535 cells across or down? In which case you''ll need to use a 32-bit integer rather than a 16-bit. As for information such as name and appearence, it''ll be necessary to send either text, or a value that represents a certain aspect of what is being depicted. For example you could send 1 for brown hair, 2 for ginger hair etc.
As for how often, it is literally only when something changes and when it is necessary for a client to see it.
You might want to just let your client send in keystrokes or relevant data only. But that depends on which networking model your game''s networking architecture is based on. Does your server computes client movement/collision/physics or is it done by the clients in a distributed model? In the former, you send keystrokes, in the latter you send data updates.
Packing or compressing your data packet is seldom warranted unless ur packet is really getting too big. On the other hand, if its too big, that means theres something wrong with your relevant set calculations.
Relevant set calculation is done for every client to find out which are the entities that the client should see. These entities are then sorted in terms of priority. For example, someone standing still infront of you is probably have a lower priority then a rocket heading straight to where you are standing. Depending on the relevant set calculation, the worldstate data packet for that client is then formulate and sent out to the client.
An impt aspect of relevant set calculation is know as Dead Reckoning. DR determines which entities gets catergorized into a particular relevant set. The topic is immersely complicated. I would suggest that you get a good game network programming reference if none of the above makes sense to you.
______________________________________________
(MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting()
http://www.geocities.com/codeman_net/
Packing or compressing your data packet is seldom warranted unless ur packet is really getting too big. On the other hand, if its too big, that means theres something wrong with your relevant set calculations.
Relevant set calculation is done for every client to find out which are the entities that the client should see. These entities are then sorted in terms of priority. For example, someone standing still infront of you is probably have a lower priority then a rocket heading straight to where you are standing. Depending on the relevant set calculation, the worldstate data packet for that client is then formulate and sent out to the client.
An impt aspect of relevant set calculation is know as Dead Reckoning. DR determines which entities gets catergorized into a particular relevant set. The topic is immersely complicated. I would suggest that you get a good game network programming reference if none of the above makes sense to you.
______________________________________________
(MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting()
http://www.geocities.com/codeman_net/
To save on server bandwidth (if its an issue) you can let the server tell the clients which other clients are in their immediate area. Then using Peer to Peer you can fetch information from that client.
This takes out the middle man and decreases the workload of the server.
Though its a tad more work for coding.
I'm currently trying to implement this system but also having the game world on client machines instead of the main server. So when a new client connects, IF the server knows there is a client with the data that the connecting client needs it will forward the client to the alternative source.
DragonWolf
Ammendum:
oh and btw, you should never send code via a network as a rule (i.e. if you send the code associated with an object) and also try and stick to states instead of actural numbers. Since this is how game cheats are done.
i.e. My client says I am at Position X,Y travelling at velocity 1,1 BUT the signal could be changed by a proxy or game crack to say I am at Position X,Y travelling at velocity 1000,1000.
[edited by - DragonWolf on October 2, 2002 10:06:45 AM]
This takes out the middle man and decreases the workload of the server.
Though its a tad more work for coding.
I'm currently trying to implement this system but also having the game world on client machines instead of the main server. So when a new client connects, IF the server knows there is a client with the data that the connecting client needs it will forward the client to the alternative source.
DragonWolf
Ammendum:
oh and btw, you should never send code via a network as a rule (i.e. if you send the code associated with an object) and also try and stick to states instead of actural numbers. Since this is how game cheats are done.
i.e. My client says I am at Position X,Y travelling at velocity 1,1 BUT the signal could be changed by a proxy or game crack to say I am at Position X,Y travelling at velocity 1000,1000.
[edited by - DragonWolf on October 2, 2002 10:06:45 AM]
Author
Well let''s say for a game like asheron''s call or anouther massive online multiplayer game. What would be the best way of working a game like that? Would the server do everything? Or would the client send the updates? Is one faster then the other?
Peer to peer won''t work for an MMP. There are to many issues with firewalls and NAT''s.
Plus, do you really want to give the ip address of all the players in your game to every l33t h4xx0r that walks by? The last thing I need is for some script kiddie to try to DOS my machine because I wouldn''t buff him or so that he can ninja my loot.
Plus, do you really want to give the ip address of all the players in your game to every l33t h4xx0r that walks by? The last thing I need is for some script kiddie to try to DOS my machine because I wouldn''t buff him or so that he can ninja my loot.
Whose network model to use depends on taste.
UnReal uses of a server-centric model whereby only the server holds a true copy of the worldstate. The clients are only "approximating" the server's worldstate with some help from the server of course. Impt decision or calculations needs to be done at the server to maintain the integrity of the one true worldstate.
Quake uses a more client-oriented approach whereby the client does loads of extrapolations and actually computes some of the impt decisions during game play.
Peer to peer updating in my view is poor taste. It gives loads of problems, incoherent visuals, cheating etc etc. The list just goes on.
The method used by epic and id are probably the more applicable i guess, even if its not for a online FPS.
______________________________________________
(MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting()
http://www.geocities.com/codeman_net/
[edited by - flipstar on October 3, 2002 10:39:21 PM]
UnReal uses of a server-centric model whereby only the server holds a true copy of the worldstate. The clients are only "approximating" the server's worldstate with some help from the server of course. Impt decision or calculations needs to be done at the server to maintain the integrity of the one true worldstate.
Quake uses a more client-oriented approach whereby the client does loads of extrapolations and actually computes some of the impt decisions during game play.
Peer to peer updating in my view is poor taste. It gives loads of problems, incoherent visuals, cheating etc etc. The list just goes on.
The method used by epic and id are probably the more applicable i guess, even if its not for a online FPS.
______________________________________________
(MSG_POST_DONE) ? InsertWittySignature() : ContinuePosting()
http://www.geocities.com/codeman_net/
[edited by - flipstar on October 3, 2002 10:39:21 PM]
It all depends on the MMO you are doing, the one I''m currently working on is an RPG, 3rd person based. But uses battle sequences
I don''t like pure peer to peer and I admit there are huge issues to NAT and firewalls. But using a Peer-to-Peer and Client-to-Server allows you to just save a few bytes per second of bandwidth per user (with alot of users thats alot of bandwidth.
Incoherency is still an issue, but is not needed for all games.
DOS attacks are also a problem, but quite a few games have this problem.
Also it can appear to the user that there is less lag due to the server or other clients, since the client relies less on one computer.
As for cheating, most things that require world based logic can be done on the server, else peer-to-peer. (such as did object a inflict damage to object b)
Client-to-Server is alot more secure, but if you are the one paying for the server at the end of the day, decreasing the amount of bandwidth and processor time can save you money.
I don''t like pure peer to peer and I admit there are huge issues to NAT and firewalls. But using a Peer-to-Peer and Client-to-Server allows you to just save a few bytes per second of bandwidth per user (with alot of users thats alot of bandwidth.
Incoherency is still an issue, but is not needed for all games.
DOS attacks are also a problem, but quite a few games have this problem.
Also it can appear to the user that there is less lag due to the server or other clients, since the client relies less on one computer.
As for cheating, most things that require world based logic can be done on the server, else peer-to-peer. (such as did object a inflict damage to object b)
Client-to-Server is alot more secure, but if you are the one paying for the server at the end of the day, decreasing the amount of bandwidth and processor time can save you money.
Unless you don''t care about cheating, you should go with a scenario where each client only communicates with the server and the server verifies everything significant that the client wants to do (like move, shoot, etc).
Basically you want each client to send movement ''requests'' to the server for validation. The server then verifies that the client can do that and then it sends a ''move'' update for the client to any clients in the affected area. That way, no one can cheat by telling the server they have moved somewhere they shouldn''t have been able to get to or at a rate they shouldn''t have been able to achieve.
You can do some predicting if you have communications problems but try not to give would-be cheaters a way to do stuff they shouldn''t be allowed.
I wouldn''t do any peer to peer communications because that may not work well with people''s different network setups and it allows cheating, invasion of privacy and alot of other messy stuff.
Basically you want each client to send movement ''requests'' to the server for validation. The server then verifies that the client can do that and then it sends a ''move'' update for the client to any clients in the affected area. That way, no one can cheat by telling the server they have moved somewhere they shouldn''t have been able to get to or at a rate they shouldn''t have been able to achieve.
You can do some predicting if you have communications problems but try not to give would-be cheaters a way to do stuff they shouldn''t be allowed.
I wouldn''t do any peer to peer communications because that may not work well with people''s different network setups and it allows cheating, invasion of privacy and alot of other messy stuff.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
