As a gaming support platform, MUSCLE is more directly suited to the slower-paced type of game, primary because it does all its network communication over TCP. TCP is based on the concept of "reliable streaming", where if a packet is lost (due to, say, an overloaded router running out of memory), the TCP stack will re-transmit the packet again until it finally gets through. That is just what you want when you are transmitting a file, but often worse than useless if the re-transmitted packet is obsolete by the time it gets to its destination. In these cases, an unreliable datagram protocol like UDP is often a more appropriate method of data trasmission to use.
That said, MUSCLE can be useful even for action/arcade games, because it can be used for everything except the real-time-update packets that can't wait for retransmission. In other words, you could use MUSCLE for peer discovery, chat, data transfer, and other non-real-time updates, and at the same time, use UDP for player and projectile position updates. And of course, if your game is only meant to be played on a LAN, where packet loss is not a major problem, then both UDP and TCP will work fine.
Aside from the compromises inherent in using TCP as a base protocol, MUSCLE has been designed to be as responsive as possible. All client side and server side mechanisms are event-based; there are never any wasteful polling or delay loops at any part of the process. Outgoing TCP buffers are force-flushed whenever the outgoing Message queue runs dry, so that Nagle's algorithm does not reduce responsiveness. The MUSCLE server's node database subscriptions are implemented using per-node callback tables, so that the CPU cost of notifying subscribers about node changes remains constant no matter how many nodes are in the database.
The MUSCLE system was developed as a platform for distributing real-time audio metering data over a LAN for a mixing console application. As such, it has been tuned to deliver forwarded Messages and database updates quickly and efficiently over a reliable LAN (throughput is typically on the order of hundreds of Messages per second). On the open Internet, the packet-loss problems inherent with TCP can cause some delay, but it should still be satisfactory for slower-paced games like FoxRabbitCarrot; and of course, combining MUSCLE with UDP will yield the best of both worlds.
In this article I have tried to give a good idea of what MUSCLE is, and show by example how it can be used as the basis for a multiplayer, multiplatform, networked strategy game. Unfortunately, a multiplayer game is an inherently complex system, and even a lengthy article can do little more than scratch the surface of all the issues and design decisions that creating one involves. Hopefully, however, the combination of this article and the source code archive that is included with it will be helpful to anyone who would like to write a multiplayer Internet game, but didn't know where to begin. If it isn't enough, and you have questions or comments about FoxRabbitCarrot, MUSCLE, C++, or networking in general, feel free to email me; my email address is email@example.com.
Thanks for your time, and if you are reading this, congratulations on getting to the end of the article. ;^)
- "Foxes, Rabbits, and Carrots"
- "The Game and How to Play it"
- "A Brief Review of the MUSCLE Networking Layer"
- "muscled, The basic MUSCLE server"
- "Customizing the MUSCLE server"
- "How to Set up the Custom Server Logic"
- "The FRCPlayerSession Class"
- "The FRCGameStateSession class"
- "Overview of the FRC server"
- "The FoxRabbitCarrot Client Program"
- "How the Client Handles Database Update Messages"
- "MUSCLE gaming Performance Issues"