Newbie Help
Author
After reading the DirectPlay documentation, it sounds like peer-to-peer games simply need to send changes in the game world back and forth to each player''s computer, correct?
What''s to stop you from simply running the entire game on every computer, and only sending the users'' input to each other? Is it because of the lag time, where a slight delay could possibly make differences in the game world? Are there ways to get around that? And what about just the individual player characters themselves? What if only the player''s single character info is sent?
When you send data, do you let a certain amount of info build up before you send it off, or do you send data every frame to the other computers? Or every certain amount of time? The game I''m developing is an action game. Does that make a difference as well?
I''m very new to this, any help will be appreciated.
I hope i can give you some useful answers here...
"it sounds like peer-to-peer games simply need to send changes in the game world back and forth to each player''s computer"
Thats one way to do it!
"What''s to stop you from simply running the entire game on every computer, and only sending the users'' input to each other? "
This is another way to do it!
This is actually what quite a few RTS games do, they send each players input to all the other computers, and then each computer performs all the AI routines, and hopefully each computer has a very close approximation of the same game-state. One of the obstacles to this is...
"Is it because of the lag time, where a slight delay could possibly make differences in the game world? "
... Synchronization. This can be reasonably simple, or more complex. The simpler way to do it is to synch all the players when they connect by using the latency (ping times) between computers to come up with a "time" value that all the computer agree to. This means you can timestamp your messages, so that you can perform speed things up if they happened in the past etc. This can cause sudden "leaps" from units in the game as they catch up. This is most useful when all units are controlled by AI (even though you tell a unit to move somewhere, it''s actual movement is still controlled by pathfinding AI). When the units are actually totally controlled by players...
"And what about just the individual player characters themselves? What if only the player''s single character info is sent?"
Some of the things you might/would send are...current movement vector, what weapon you''re holding (when you change weapons), firing info. A game like this can use prediction to predict where the other players are moving to based on the most recent movement vectors to get an approximate position for the players. You can then "sycnh" every second or so where the actual absolute position of a player is sent out.
"When you send data, do you let a certain amount of info build up before you send it off, or do you send data every frame to the other computers? "
This depends on a few factors. First, you should know that every time you send a packet, it has an attached network header of around 100 bytes (give or take), so you shouldn''t be sending off packets all over the place, however, in an action game, you want to send your data off as quickly as possible to reduce perceived latency, so you need to compromise. You can use the players network connection as a guide to how often to send, and how much data to send. ie. you can afford to waste your bandwidth on network headers if you are running over a fast cable connection, but you will need to build up your packets to reduce over head on a modem connection. You won''t send data every frame, theres no need, if a game is running at 30fps, often very little changes between frame 23 and 24! I hear about 10 times/second is a good update rate for movement updates.
"The game I''m developing is an action game. Does that make a difference as well?"
It can indeed. An rts requires far fewer updates, as the majority of the game is controlled by AI, whereas an action game (usually) involves total player control. This means you actually have to send updates about the players movement, rather than just what key they pressed and when. Action games are much more time sensitive, they can''t really do things in the past and then catch up like tha AI in an rts could. If you''re laggy, thats your problem not the games!
I''d also suggest you look into client-server architecture, rather than peer-peer, as it has many many advantages over peer-peer, and very few disadvantages.
Hope that helps!
"it sounds like peer-to-peer games simply need to send changes in the game world back and forth to each player''s computer"
Thats one way to do it!
"What''s to stop you from simply running the entire game on every computer, and only sending the users'' input to each other? "
This is another way to do it!
This is actually what quite a few RTS games do, they send each players input to all the other computers, and then each computer performs all the AI routines, and hopefully each computer has a very close approximation of the same game-state. One of the obstacles to this is...
"Is it because of the lag time, where a slight delay could possibly make differences in the game world? "
... Synchronization. This can be reasonably simple, or more complex. The simpler way to do it is to synch all the players when they connect by using the latency (ping times) between computers to come up with a "time" value that all the computer agree to. This means you can timestamp your messages, so that you can perform speed things up if they happened in the past etc. This can cause sudden "leaps" from units in the game as they catch up. This is most useful when all units are controlled by AI (even though you tell a unit to move somewhere, it''s actual movement is still controlled by pathfinding AI). When the units are actually totally controlled by players...
"And what about just the individual player characters themselves? What if only the player''s single character info is sent?"
Some of the things you might/would send are...current movement vector, what weapon you''re holding (when you change weapons), firing info. A game like this can use prediction to predict where the other players are moving to based on the most recent movement vectors to get an approximate position for the players. You can then "sycnh" every second or so where the actual absolute position of a player is sent out.
"When you send data, do you let a certain amount of info build up before you send it off, or do you send data every frame to the other computers? "
This depends on a few factors. First, you should know that every time you send a packet, it has an attached network header of around 100 bytes (give or take), so you shouldn''t be sending off packets all over the place, however, in an action game, you want to send your data off as quickly as possible to reduce perceived latency, so you need to compromise. You can use the players network connection as a guide to how often to send, and how much data to send. ie. you can afford to waste your bandwidth on network headers if you are running over a fast cable connection, but you will need to build up your packets to reduce over head on a modem connection. You won''t send data every frame, theres no need, if a game is running at 30fps, often very little changes between frame 23 and 24! I hear about 10 times/second is a good update rate for movement updates.
"The game I''m developing is an action game. Does that make a difference as well?"
It can indeed. An rts requires far fewer updates, as the majority of the game is controlled by AI, whereas an action game (usually) involves total player control. This means you actually have to send updates about the players movement, rather than just what key they pressed and when. Action games are much more time sensitive, they can''t really do things in the past and then catch up like tha AI in an rts could. If you''re laggy, thats your problem not the games!
I''d also suggest you look into client-server architecture, rather than peer-peer, as it has many many advantages over peer-peer, and very few disadvantages.
Hope that helps!
100 bytes is a bit of a steep approxamation.
from what ive seen its around 20-40bytes depending on what protocol and api you use.
from what ive seen its around 20-40bytes depending on what protocol and api you use.
Sorry, you''re correct, i kinda pulled the 100 bytes from my *** cos i couldn''t be bothered looking it up.
Author
Thank you, that is an extremely helpful reply.
And you even sparked some ideas for me. How about creating a simple linked list of player input changes? The movement in my game is actually based off of time. It wouldn''t be very difficult to "back it up" if necessary. What if I were to insert a list node for every frame that the players input device changes, and stamp it with the current time. Then when the data is sent every 100 ms, the other computers would perform the input as if it happened when it actually did? Of course some things would be difficult. Like trying to attack another character.. how would I know where that character was when the time was farther back.. I guess I would have to keep important records like this in the list as well.
But I''m talking about a crazy-paced side scrolling medieval fighting game, so collision and movement are really all that is important. I''m not worried about "jumps" when the connection is slow, but if a hit misses on one computer and hits on another, that would be complete failure.
If a game is not built from the ground up with multiplayer features in mind, does evolving it dramatically change the engine?
And finally, doesn''t client-server mode require a dedicated server? Which requires money? And are peer-to-peer games possible over the internet?
Sorry for so many questions, and thanks again for the very helpful info.
-Jiia
And you even sparked some ideas for me. How about creating a simple linked list of player input changes? The movement in my game is actually based off of time. It wouldn''t be very difficult to "back it up" if necessary. What if I were to insert a list node for every frame that the players input device changes, and stamp it with the current time. Then when the data is sent every 100 ms, the other computers would perform the input as if it happened when it actually did? Of course some things would be difficult. Like trying to attack another character.. how would I know where that character was when the time was farther back.. I guess I would have to keep important records like this in the list as well.
But I''m talking about a crazy-paced side scrolling medieval fighting game, so collision and movement are really all that is important. I''m not worried about "jumps" when the connection is slow, but if a hit misses on one computer and hits on another, that would be complete failure.
If a game is not built from the ground up with multiplayer features in mind, does evolving it dramatically change the engine?
And finally, doesn''t client-server mode require a dedicated server? Which requires money? And are peer-to-peer games possible over the internet?
Sorry for so many questions, and thanks again for the very helpful info.
-Jiia
The problem you may find with "backing up" the changes to be sent, is havign to play catch-up when the data arrives. This is why most action games tend to just accept that lag exists, try to minimise it, but not actually try and go into the past and change it. I believe some games have tried to use the backing up/time stamping technique, and it basically made people with high pings invincible because they were never where they appeared on screen! They were there half a second ago, or whatever. This was actually so drastic, that cheats were created to artificially give players high pings! 
If a game is built without any multiplayer features in mind, it may require some hefty overhaul, depending on how it''s been built. If it has multiplayer features, just not network features, it''s not too hard to add in network features...
Client-server games require a server...if the server is dedicated, it is better, because it will be able to run faster etc., but it doesn''t HAVE to be dedicated. At a basic level, without any really fancy code on what data to send where, computers in a peer-peer network are all doing the same load as a server would! So, changing over to a client-server system takes that load off EVERY computer, and puts it on only ONE computer. It also takes the load of bandwidth off every computer. In a peer-peer system, every computer has to send data to every other computer, so you end up sending and receiving a lot of data, client-server, the clients only send and receive data from the server, and the server is also more capable of making decisions about what data clients actually need, than peers are in a peer-peer. I really suggest you read a couple articles on client-server.
Peer-peer games do work over the internet...it''s just a bunch of connections after all
, but, people behind NAT firewalls may have difficulty with peer-peer games, as you need to forward ports for all peers to listen on, in a client-server system, only the server needs to have ports forwarded.
If a game is built without any multiplayer features in mind, it may require some hefty overhaul, depending on how it''s been built. If it has multiplayer features, just not network features, it''s not too hard to add in network features...
Client-server games require a server...if the server is dedicated, it is better, because it will be able to run faster etc., but it doesn''t HAVE to be dedicated. At a basic level, without any really fancy code on what data to send where, computers in a peer-peer network are all doing the same load as a server would! So, changing over to a client-server system takes that load off EVERY computer, and puts it on only ONE computer. It also takes the load of bandwidth off every computer. In a peer-peer system, every computer has to send data to every other computer, so you end up sending and receiving a lot of data, client-server, the clients only send and receive data from the server, and the server is also more capable of making decisions about what data clients actually need, than peers are in a peer-peer. I really suggest you read a couple articles on client-server.
Peer-peer games do work over the internet...it''s just a bunch of connections after all
, but, people behind NAT firewalls may have difficulty with peer-peer games, as you need to forward ports for all peers to listen on, in a client-server system, only the server needs to have ports forwarded.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement