One of the network architectures I've looked at basically divides messages into important and unimportant. Important will use TCP, unimportant, UDP.

Assuming a client/server model, the server is responsible for maintaining the 'true' game world, clients will push their movements/updates to the server, the server will push its true 'vision' back to the client.

The clients will be rendering their 'picture' of the true game world to the user, but due to lag will usually involve some prediction (you can get away without, but you will notice lag quicker), the periodic server messages will correct the client if the prediction gets too far away from the 'true world'.

Now the server->client messages are important, and should be TCP, client->server messages can be a mix, things the server _must_ know should be sent on reliable TCP channels.

To distribute data and bandwidth there is also the potential of using client<->client messages as well (usually positional updates), these would usually be UDP as they are 'unimportant' optional update information, which could improve the clients prediction without requiring server bandwidth, but its no great loss if they get dropped as they might be wrong (compared to the server updates).

Don't know about the boost library, but Beej's guide is good for network socket knowledge, might be worth a skim at least. I also remember some good articles about the HalfLife 2 network system, but that might just scare you even more ;)

Best of luck,

Alex

It's not that complex, if you have a message system and something that manages connections and network traffic for you, you're half-way there.

If you use a third-party library, such as Raknet or Enet, you can have a mix and match of reliable and unreliable deliveries.

For example, creating a player could be a one-off reliable message sent to all the clients.

Then further updates would be unreliable serialisations of the player state, stuff in the player that changed (like position, orientation, animation state, health points...).

Enet and Raknet have an internal reliable delivery system on top of UDP, in fact, the UDP / TCP network transport is abstract and not really important as far as the user is concerned.

All the user needs to do is handle messages and network events (new connection established, connection closed, new message received, send message to a node, broadcast message to all nodes, ...).

So in fact, the interface to the network layer can be made simple.

Transmitting object states, object creation, object destruction requires serialisation, all you need really is serialise() / deserialise() methods for the objects you want to network, as well as some form of unique ID and type ID to uniquely address your objects (player #1, player #8, car #654, badger #92, ...).

Managing bandwidth is another problem, for example, if your player stops moving, or a pile of box is static, sending position updates would be redundant. There are methods, such as delta compression, but that can be quite tricky to manage.

Then you can worry about client side prediction and interpolation later.

If you are not interested in the network guts but more about making a game, a third party library will help you and save you tremendous time. But I am no expert on boost::asio (I kinda write my own).

Here is a series of articles regarding the design of a networked multiplayer game. It's not complete, but when it will be, it will be pretty much all the steps you need to take to design a multiplayer game.

Quote:asio is network API wrapper, nothing more.

Pedantically: ASIO is a general aynchronous worker library; it supports asynchronization of various blocking operations, including networking and other I/O.

I highly suggest RakNet. It abstracts away all of the details so that you can focus on actually sending messages back and forth, rather than *how* to send messages back and forth. It also has an extremely effective BitStream utility which is very useful when serializing networked objects to and from packets.