   Networking with C#/XNA/Lidgren Newb
  This is my first post here so hi everybody.Anyways: I have began working on a project and am at the point where I would like to add networking capabilities. I have never touched networking so it still seems quite daunting..Ive only written the bare basics of my project and I have made a copy of it so it should still be in an early enough state to use as a "networking sandbox". Ive decided to go with the lidgren library for now as I see no need to reinvent the wheel.I'm sure this is all very basic but as I said I'm new to this so bear with me.This is my understanding/plan which is based on pure intuition (so it may very well be way off) I want to create a "built-in" server/client structure. When a single player clicks to start a new game he is essentially hosting.. If nobody joins then everything is just handled by his machine. His instance of the game is flagged as "Host" and technically all network related code *could* be ignoredNow if somebody joins his instance of the game is flagged as "Client". Right off the bat things get complicated because of my lack of experience. I do not know how reliable(if at all) things can be calculated on the clients machine without things getting out of sync. Should I update all logic on the server machine and send the information to the client (perhaps serialized?). The client would in turn just send commands to the server. This seems like a sound way of doing things but Im wondering if this would overload the network. An example of this system would be to have a "NetworkControlledObj" class from which all up-datable objects are derived. The class contains a bool "IsHost" which is set depending on whether the instance of the game is a host or client.If Host then the object is updated "normally".. the necessary data is sent to an array containing all of the data that must be sent to the clients. This array is serialized at the end of the "heartbeat" and sent to all clients. where it is deserialized...If the object does not have the flag "Host == true" then it obviously just updates according to the data it received from the host that (last?) heartbeat.That is my general inexperienced plan but I'm scared it will result in much lag (if it does, in fact,  work at all ;) ). Maybe it would work fine... I seriously don't know ^^Im posting this so somebody can tell me im right, wrong, semi-right.. whatever. Anything before i start work on implementing this into the games current architectureFor anybody who takes the time to read this thanks whether you can help me or not ^^BTW: I'm aware that the everything depends on a lot of factors like the type of game.. Nr of objects that need updating etc... I'm just asking so generally since I'm new to networking in.. well generalIf it helps: I'm planning an RTS that will play out a bit more like a TBS. (I guess the best comparison would be AI War... although not with that high number of units)Also yes.. I read the FAQ including the first part of it. Didnt help me too much though. Or im blind[Edited by - DakaSha on May 26, 2010 6:46:32 AM]
Quote:Original post by DakaShaI want to create a "built-in" server/client structure. When a single player clicks to start a new game he is essentially hosting.. If nobody joins then everything is just handled by his machine. His instance of the game is flagged as "Host" and technically all network related code *could* be ignoredNow if somebody joins his instance of the game is flagged as "Client". Right off the bat things get complicated because of my lack of experience. I do not know how reliable(if at all) things can be calculated on the clients machine without things getting out of sync. Should I update all logic on the server machine and send the information to the client (perhaps serialized?). The client would in turn just send commands to the server. This seems like a sound way of doing things but Im wondering if this would overload the network. An example of this system would be to have a "NetworkControlledObj" class from which all up-datable objects are derived. The class contains a bool "IsHost" which is set depending on whether the instance of the game is a host or client.If Host then the object is updated "normally".. the necessary data is sent to an array containing all of the data that must be sent to the clients. This array is serialized at the end of the "heartbeat" and sent to all clients. where it is deserialized...If the object does not have the flag "Host == true" then it obviously just updates according to the data it received from the host that (last?) heartbeat.This flagged as a Host/Client is just the perfect situation implementing different classes. I once did that bc i was lazy and thought it would be easier to just implement a flag. at first this seamed perfect but later things became complicated and had to reimplement everything. You know clicking create class in your IDE isn't to hard ;)the other thing is sending data...you should try to pack data as tight as possible and maybe also send the update of all entities in one packed. bc the more packets you send per second the higher is the drop rate and therefor lag.and bc of your client. normaly clients should just send commands and never modify data directly on the server. ya know...never trust anyone ;)   ;Quote:This flagged as a Host/Client is just the perfect situation implementing different classes. I once did that bc i was lazy and thought it would be easier to just implement a flag. at first this seamed perfect but later things became complicated and had to reimplement everything. You know clicking create class in your IDE isn't to hard ;)I really dont know what your getting at ^^ What exactly should I do differently? Quote:the other thing is sending data...you should try to pack data as tight as possible and maybe also send the update of all entities in one packed. bc the more packets you send per second the higher is the drop rate and therefor lag.Isnt that what i suggested? Or am I misunderstanding you? ^^Quote:and bc of your client. normaly clients should just send commands and never modify data directly on the server. ya know...never trust anyone ;)So again your agreeing? Can a typical internet link up handle that much? (I guess it can if that's the standard way of doing things :P );  Hello.I'm currently developing a fast paced networked game with XNA and lidgren too.I'd recommend you read this thread, and the replies below:http://www.gamedev.net/community/forums/topic.asp?topic_id=569670Also, the forum FAQ helped me out quite a bit:http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15You can PM me if you want to share experiences. I'm one month into my project now, so maybe we can help each other out.   ;  heh i doubt id be any help as i seriously dont know anything yet ;)Thanks for your links though. that actually will help alot!. And it seems i was blind while reading the faq ^^Still any suggestions from anybody else is still welcome :)   ;  You will not be able to find the host from the client unless the client already knows the host's IP address or DNS name. (something.com) You can kind of do what you're talking about with a centralized synchronization server, in which case you would make a normal client/server game, except most of the server tasks would actually be done on the clients, and the clients would send each other their IP addresses and open connections to each other via the host. Not sure how to do that with lidgren (never used it), however that should be doable via remoting, although the peer-to-peer part makes it more complex. One option would be allowing anyone to run the server, and having a web site or blog with comments where people could post their current server IP addresses that are running. GoDaddy.com will also run a server for you under their virtual dedicated hosting plans starting at $30 per month, it may be cheaper elsewhere possibly.   ;Quote:Original post by aersixb9You will not be able to find the host from the client unless the client already knows the host's IP address or DNS name. (something.com) You can kind of do what you're talking about with a centralized synchronization server, in which case you would make a normal client/server game, except most of the server tasks would actually be done on the clients, and the clients would send each other their IP addresses and open connections to each other via the host. Not sure how to do that with lidgren (never used it), however that should be doable via remoting, although the peer-to-peer part makes it more complex. One option would be allowing anyone to run the server, and having a web site or blog with comments where people could post their current server IP addresses that are running. GoDaddy.com will also run a server for you under their virtual dedicated hosting plans starting at $30 per month, it may be cheaper elsewhere possibly.I know that you need to know the hosts ip... Im not planning on having a centralized server. I just wanted to know how to integrate networking into the games architecture.thanks anyways!   ;  I would implement it something like this:1) The game always uses a client and a server. Even when playing single player -- client and server run on the same machine (in the same process, even).2) When a player hosts, and a second player connects, then that second player is running only the client part. The server part is then run on your machine.3) Exactly how to distribute state between client and server depends on your specific game design. How you do simulation, prediction and validation varies greatly between, for example, a multiplayer RPG, a FPS, or an RTS game.4) In general, though, you want game objects to have a few different responsibilities:- input: how does the user interact with it? (mouse, key, etc)- action: how does the object affect game state?- presentation: how is the object rendered?- persistence: how is the object saved/restored in savegame files?It's quite possible that you write input and presentation to run on the client side, and action and persistence to run on the server side. You can define some set of properties that the two sides can use to agree on the state of the object -- position, velocity, mesh used to render, whether some explosive has been fused, etc.Now, the job of your client code is to present a UI to the user, based on the state of the game objects, and forward requests from that UI to the action component. The job of the action component is to validate requests, reject bad requests (for example, two users may request to pick up a health pack -- only the first one actually gets it), and update state based on this. State changes get reflected back to clients. Clients render the objects based on the state.This is a pretty classic model that's been used by many games over the years, and it works pretty well.Note that the interaction - action - presentation isn't actually synchronous in a real implementation. Each frame, each object will look for any possible interaction, may receive state updates from the server, and will render itself based on the current state.;Quote:Original post by hplus0603I would implement it something like this:1) The game always uses a client and a server. Even when playing single player -- client and server run on the same machine (in the same process, even).2) When a player hosts, and a second player connects, then that second player is running only the client part. The server part is then run on your machine.3) Exactly how to distribute state between client and server depends on your specific game design. How you do simulation, prediction and validation varies greatly between, for example, a multiplayer RPG, a FPS, or an RTS game.4) In general, though, you want game objects to have a few different responsibilities:- input: how does the user interact with it? (mouse, key, etc)- action: how does the object affect game state?- presentation: how is the object rendered?- persistence: how is the object saved/restored in savegame files?It's quite possible that you write input and presentation to run on the client side, and action and persistence to run on the server side. You can define some set of properties that the two sides can use to agree on the state of the object -- position, velocity, mesh used to render, whether some explosive has been fused, etc.Now, the job of your client code is to present a UI to the user, based on the state of the game objects, and forward requests from that UI to the action component. The job of the action component is to validate requests, reject bad requests (for example, two users may request to pick up a health pack -- only the first one actually gets it), and update state based on this. State changes get reflected back to clients. Clients render the objects based on the state.This is a pretty classic model that's been used by many games over the years, and it works pretty well.Note that the interaction - action - presentation isn't actually synchronous in a real implementation. Each frame, each object will look for any possible interaction, may receive state updates from the server, and will render itself based on the current state.Thanks alot. When i get some time ill try that ;)   