RTS Multiplayer

50 ms is nearly imperceptible. You're doing something wrong. I recommend calculating the latency and displaying it. That is start a timer (ms resolution) and send a packet of input from the client then have it get processed and when the server sends out an update packet append a ping message to it so that when the client gets it then it can stop the timer and record the time. The idea being is that you want to record the latency from the time of input until the player can see the effect of that input.

(Also TCP is fine for an RTS in case you has doubts).

Also it's been said many times, but RTS games provide audio queues or animations to lower the perceived latency.

Quote:

Original post by CzarKirk there aren't many tutorials (at least not that I can find) on this particular topic.

One of the reasons is because, in my experience (and learned the hard way), RTS are not exactly the easiest kind of games to start with. The only harder game genre to develop I can think of are MMOs.

This is because it involves lot of AI (Pathfinding, low level AI for units, high level AI for enemy players) managing lots of units, collision detection, managing a 3D window with the mouse, making advanced yet intuitive GUIs, etc.

Other games (i.e. FPS) just require basic collision detection, basic AI (i.e. just aim and shoot), the player is the one who is managing the unit with the keyboard, simple GUIs.
Then you can improve on further elements individually one at a time (i.e. improve AI by making enemies that hide and seek, add inaccuracies to the enemies so that they don't look like perfect shooters; or used more advanced physics so that the player can interact with the scene and add puzzles to solve).
But the basics you need to get a simple working FPS can't be compared to what you need to get even a simple RTS.

Quote:

Original post by CzarKirk First of all, I could swear Age of Empires used TCP and not UDP.

Well, TCP is a good (and easy) choice for RTS.
They've chosen UDP because of the reduced lag; and implemented themselves a system that would guarantee packet order and 0% packet loss.
That's not easy but can be done. Their system works faster than a TCP because TCP is a general-purpose protocol with such guarantees, while their system using UDP has been designed only for their specific scenario.

Quote:

Original post by CzarKirk Secondly, how do you "process all messages" for 50 ms without the game lagging horribly? I added a 50ms delay into my loop as a test and it's horrible.

You will need to define lag. Everyone says "lag" for a different thing.
A game running at 50ms per frame means 20FPS which is a bit slow, and will feel "frame-skipped". However running at 50ms per frame and processing input at 50ms intervals is an entire different thing.
Let's take this even further: Running at 50ms per frame, rendering at 50ms, and processing input at 50ms intervals is an entire different thing.

Processing input at 50ms is almost unnoticeable. Sure it's not desirable in a fast action game, but will still work reasonable well.
Running at 50ms feels a bit unresponsive.
Rendering at 50ms feels frame skipped.
Running and rendering the game at 50ms feels slow as hell.

RTS games unfortunately will have processing input and running the game tied toghether, stuck at 50ms; because you need to tell the computers the frame has finished so they all move together (what is called "lock-step").
However, you can render at any framerate, interpolating between logic frames, thus making it feel smooth. In other words "what you see is not exactly what it is"
For more information on this, read Fix your timestep

Hope this helps
Cheers
Dark Sylinc

TCP is a totally fine protocol for an RTS, or any input-synchronous simulation. The semantics match perfectly: you need earlier events before processing later events.

You can easily have 20 simulation steps a second by de-coupling rendering frame rate from simulation frame rate. Specifically, you'll have rendering-only things going on (animation, movement towards a goal point at a fixed speed, particle system evolution, etc), and then you'll have actual game-state things (shooting, taking damage, choosing a new goal point, etc). The game-state things should be done synchronously at a fixed rate; the rendering-only things can be done as often as you want (typically at Vsync rate).

http://www.mindcontrol.org/~hplus/graphics/game_loop.html

Hi thanks for your feedback and suggestions. I have tried to decouple rendering from simulation but no matter what I try it freezes each communication state update. I think this is because when one client reaches the end of its communication turn, it then waits for other clients to signal they are ready and send their communication. If the latency is 200ms then this means there is a 200ms pause each turn. I have tried allowing clients to process a few turns ahead (eg up to 3) but then it will just start freezing again when one client is too far ahead. I guess what I need is for clients to dynamically change their actual game speed so neither reaches the ahead limit? This is hurting my head.

As for Age of Empires, I have it installed on my computer and it lists TCP/IP as the protocol used so I don't understand why the tutorial says UDP.

It sounds as if you're not pipelining.
If you're rendering the output of command frame 10, you need to be sending commands for, say, frame 15, and be waiting for commands for frame 11. This allows there to be 200 milliseconds of latency (lag, delay) without there being a stop.

This is why, in any RTS, when you give a command, there will first be a "yes, sir!" animation, and THEN the unit will start moving. The acknowledge animation masks the delay for the queued command.

This has been incredibly helpful to me so far too, as I have the exact same problem. But I post here because I can't find that "Archers Tutorial" the OP mentioned. Could someone please provide a link?

Thanks in advance.

Forum FAQ