RTS Game in XNA (C#)
Author
Hey, I'm a part of a team that is developing an RTS game. I'm covering the networking side only.
Because I have only worked with a 2D top down shooter game and a multiplayer harvest moon clone (2d also) I am struggling to create a good plan for this RTS game.
First of all I have an old library of network functions (socket based) that was created in Visual Basic that I'm using, but I think it may be better to use Lidgren or something similar. The old library was created with 2D games in mind and only supports TCP.
Now seeing as an RTS will have many more objects to cater for then my previous games (and also more human players) I do not know how to combat lag. First of all let me say that I'm using a single host layout and I don't know what the maximum amount of objects that need to communicate data will be.
I was thinking that I could have each player state what their viewport is too the server, then have the server request all object data from them regions, but I don't know if this would actually be anymore effecient, because of say every player is viewing a different region.
Anyway please help, I'd also like your opinions on networking libraries too use, I have never dealt with UDP before and I don't exactly like the idea of worrying about packet loss/order and lidgren is the only 1 that I know of for C#.
Please please please help. I'd love to hear your ideas, thanks!!
[Edited by - Kurt69 on July 21, 2007 9:44:24 PM]
Most RTS use a totally different networking method than e.g. 3D shooters.
They are not sending any infos about the units to the client. Only commands from the players are exchanged and every client runs its own simulation. The critical thing is that all clients must be in sync, but that way the network traffic is not dependend on the number of units at all.
Both TCP and Lidgren should be ok for that, but i would prefer Lidgren because of additional features for compression and server discovery.
Edit: Does anybody know if theres a simple opensource-rts that uses a synced networking model? I would really like to know how that works exactly!
They are not sending any infos about the units to the client. Only commands from the players are exchanged and every client runs its own simulation. The critical thing is that all clients must be in sync, but that way the network traffic is not dependend on the number of units at all.
Both TCP and Lidgren should be ok for that, but i would prefer Lidgren because of additional features for compression and server discovery.
Edit: Does anybody know if theres a simple opensource-rts that uses a synced networking model? I would really like to know how that works exactly!
Author
I just read the Age of Empires article on gamasutra, and wow this looks like its going to be an extremely hard task for one person. First of all thanks to both of you this has helped alot, I've decided to go with Lidgren.
But yeah, reading that Age of Empires article, it says things like path-computation went wrong and lead to desync, how exactly would I get around those type of desyncs?
Thanks.
But yeah, reading that Age of Empires article, it says things like path-computation went wrong and lead to desync, how exactly would I get around those type of desyncs?
Thanks.
Doing the network part actually turns out to be really easy. It's the gameplay that's hard :-)
First, you should make sure that all gameplay is calculated using integers only. It's fine to use floats for rendering, but the gameplay positions should really be fixed-point quantities (say, 16.16 format) and use fixed-point math. Else you'll have all kinds of floating-point "fun" trying to get consistent results between all clients.
Second, you should make sure that all random numbers are derived from a random number generator that is seeded by the tick number, each tick -- and that it's called in the same order on all clients.
Third, make sure that the order you step individual entities is consistent. For example, using a hash table off entity ID could lead to different ordering depending on what order the entities are created in. Instead, use a dictionary on the ID. Don't use the object reference itself as a key, because it's not ordered between machines.
Really, your job as a network programmer will be:
1) Explain the model the game HAS to follow to your fellow programmers.
2) Write the lobby/join/host code.
3) Write the code that accepts user input, forwards to server, bounces to other clients, using time stamps.
4) Write the code that delivers user input at the right timestamp on all machines, and/or pauses the game if some client is late in delivering.
All of that is pretty simple. Then comes the problem:
5) Read through all gameplay check-ins, screening them for potential de-sync bugs. Flog responsible parties until they repent their ways.
You might also want to have an automated test set-up, using at least two machines (one Intel and one AMD, one ATI graphics and one NVIDIA) to run through pre-defined scenarios, and making sure you don't de-sync.
For testing purposes, it's useful if you can send the game state, or at least a hash of the game state, from each client each step. If the server ever notices someone is out of sync, it will immediately report the error and tell all the clients to breakpoint. If you store the user input in a replay log fashion (simple with this model), then you can get back to that point on the faulting machine and debug why it went wrong.
First, you should make sure that all gameplay is calculated using integers only. It's fine to use floats for rendering, but the gameplay positions should really be fixed-point quantities (say, 16.16 format) and use fixed-point math. Else you'll have all kinds of floating-point "fun" trying to get consistent results between all clients.
Second, you should make sure that all random numbers are derived from a random number generator that is seeded by the tick number, each tick -- and that it's called in the same order on all clients.
Third, make sure that the order you step individual entities is consistent. For example, using a hash table off entity ID could lead to different ordering depending on what order the entities are created in. Instead, use a dictionary on the ID. Don't use the object reference itself as a key, because it's not ordered between machines.
Really, your job as a network programmer will be:
1) Explain the model the game HAS to follow to your fellow programmers.
2) Write the lobby/join/host code.
3) Write the code that accepts user input, forwards to server, bounces to other clients, using time stamps.
4) Write the code that delivers user input at the right timestamp on all machines, and/or pauses the game if some client is late in delivering.
All of that is pretty simple. Then comes the problem:
5) Read through all gameplay check-ins, screening them for potential de-sync bugs. Flog responsible parties until they repent their ways.
You might also want to have an automated test set-up, using at least two machines (one Intel and one AMD, one ATI graphics and one NVIDIA) to run through pre-defined scenarios, and making sure you don't de-sync.
For testing purposes, it's useful if you can send the game state, or at least a hash of the game state, from each client each step. If the server ever notices someone is out of sync, it will immediately report the error and tell all the clients to breakpoint. If you store the user input in a replay log fashion (simple with this model), then you can get back to that point on the faulting machine and debug why it went wrong.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
