Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on a windows game and I am trying to understand the XNA GameComponents and GameServices classes and use. From what I understand about a component is that it has an Update method that gets call in every frame, and a service can be referenced from other components if needed.

So the way I think a network component would work is that in its Update method it would receive and send data. It probably makes sense to receive the network data once per frame, but it doesn't for sending it. Shouldn't the game send its own updates to others the moment it has it to cut down on lag?

share|improve this question

closed as primarily opinion-based by Josh Petrie Dec 15 '14 at 23:56

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

My recommendation is to attempt to write your code using neither of these. IServiceProvider is for something that you don't need. And GameComponent just obfuscates your code flow and makes it harder to craft a nice actor interface (which, in your case will probably need custom Serialize and Deserialize methods for network replication). – Andrew Russell Mar 17 '13 at 15:19
xna can be prone to slowdown due to many factors, and therefore Microsoft introduced GameTime.IsRunningSlowly into the framework, so that this can be checked. If you have the network attempt a tick, or sync, within a standard xna update method, you cannot guarantee that the time interval is constant. You need to implement some sort of callback on the way in which you update the time interval, and handle network messages within that interval. Both are interlinked. My suggestion is to thread the tick or sync message, and let it cycle at 1/60 seconds independently of the main game thread – Jason Coombes Mar 18 '13 at 5:47
"Shouldn't the game send its own updates to others the moment it has it to cut down on lag?" Games often coalesce messages into fewer, larger packets sent less often. This may mean delaying updates by a few milliseconds, or using client side prediction & interpolation to smooth out the gaps, but you save a lot of bandwidth. Data rates may be a platform certification requirement, or just a nice thing to do for your customers who pay through the nose for cellular data. – Chronic Game Programmer Mar 18 '13 at 21:40

I would suggest looking at threading to communicate so you know when you lose connections and when to drop that client from your list. There is a good example of this here A server that uses a COM object will run as a service automatically and may still run even if you close your APP...

I would run the clients and severs as a class and create them on the heap rather than the stack.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.