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've been programming a multiplayer game and its coming together very nicely. It uses both TCP and UDP (UDP for movement and TCP for just about everything else). What I was wondering was how I would go about sending multiple moving AI without much lag. At first I used TCP for everything and it was very slow when people moved. I'm currently using a butchered version of this for my movement system and I'm wondering what the best method of sending AI movements is. By movements I mean the AI chooses left/right/up/down and the player can see this happening.


share|improve this question
Could you provide more details on how the movement is done? – jcora Jul 21 '12 at 12:13
Also, it would be great if you actually described how you do it. – jcora Jul 21 '12 at 12:15
up vote 1 down vote accepted

I'm not sure what you mean by "multiple moving AI". Do you have several gameobjects that have AI, and they are moving in the same time?

If so, then here's how I'd do it.

You can have the same AI system on both the server and the client, for example, a state machine. Every gameobject with AI can be described by several states, like "walking_left speed". The AI system would provide various ways of changing these states, but that doesn't matter, because what you're interested in is synchronizing the movement between the server and the client.

What I did when I made my first multiplayer game, was foolishly have the server overwrite the positions of objects. Don't do this, because this results in choppy movement that is dependent on your network latency. Rather, you share those states, and make sure that both the server and the client know that a certain entity is walking at some direction (the direction vector can also specify the speed by its length). If everyone knows at which direction an entity is going, it's a simple matter of designing a movement system that make sure that in same time intervals, entities will be on the same position, and deploying that system on the server and the client side.

Someone at Valve made a post about making multiplayer systems:

Also, I believe that using both UDP and TCP is not exactly a good idea, I forgot why, so you might want to investigate... Another useful link:

share|improve this answer
Thats what I mean. Thanks. I'll give this a go and let you know how it pans out. – Smallbro Jul 21 '12 at 12:44
Great then, if I come up with something else, I'll edit the answer. – jcora Jul 21 '12 at 12:49
Oh! That actually might explain why my TCP version of the movement lagged alot! I was sending the x and y of each player rather than sending booleans for their movement. I need to try this out. :D – Smallbro Jul 21 '12 at 12:55
Yeah, I guess TCP just stacked a tonne of these and then sent them in a single packet... – jcora Jul 21 '12 at 12:59
So this would be sort of like keyframes? Telling where each thing is, and what it should be doing, then both server/client track until next tic? What did @Smallbro mean aby "sending booleans for their movement"? – Paul Aug 20 '12 at 20:08

I don't think that sending information about ai movement every frame is a good idea. What you should send instead is just player actions/commands (not positions). Basically what you need is a simulation (the same) running on every client and just synchronize player actions. If you use random number generators, just initialize them on the clients with the same seed.

This article could be also helpfull to you:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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