Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

CoolnessItself

multiplayer - general idea of how its done

This topic is 5211 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How does the normal multiplayer fps, for example, manage multiplayer? Does the client send the server packets containing keypresses? movements? hows it all work? [edited by - CoolnessItself on May 10, 2004 5:30:30 PM] [edited by - CoolnessItself on May 12, 2004 9:05:11 AM]

Share this post


Link to post
Share on other sites
Advertisement
It really depends on who is writing the multiplayer layer All the keypresses and state changes are usually done locally for speed, while the server acts more as a validater and distributer of data. For example, the game client sends the server its current state and the server determines if this state is valid. Since the client follows the same game rules as the server when processing user input and other game logic, the data is valid 99% of the time. Of course there are exceptions, like if someone is cheating or there is packet loss. Then your state is sent to all ther other clients, who update their local states to reflect what the server sends them. Then there are things such as clientside prediction which try to predict future states to maintain smoothless in the game when you don''t have the best connection with the server. All this happens for all the clients, with the server maintaining the "master" game state.

So to answer your question, not every little event is sent to the server, usually it''s just things like the client''s current state, as well as any other small bits of information that might not be stored in this state.

Share this post


Link to post
Share on other sites
Thanks for the informative post

What do you mean by current state? It seems like it would be incredibly inefficient to send the entire world''s data to the server - so do they just send the characters'' locations or something?

Share this post


Link to post
Share on other sites
If you send incremental state changes (how RTS tend to work) then you /must/ deliver every single packet to every single client every time. One lost packet puts you out-of-sync. RTSs work that way because there are too many avatars to send absolute updates.

For FPSs and MMOGs you send absolute positions unreliably and status changes reliably. EQ did an excellent job with their netcode, you could have up to 33% packet loss and the game still played extremely well.

Share this post


Link to post
Share on other sites
In general the game has 3 parts, client, server and game.

Client draws the scene and menu''s to the screen, plays sounds and music and reads the input devices (keyboard, mouse).

Whenever the player starts a game it creates the server object and starts it.

It communicates with the server with function calls/methods.

The server communicates with the game, it can start/stop it.

The game manages the scene and does all the logic, update positions of players and objects, handle shooting etc.

These components are eg. classes, they are part of the same program. They can be split off into DLL''s instead of being in the same exe to allow updates.

The trick is that you can have 2 kinds of server objects. Either local, where it just talks to client and game using functions/methods, or it can be a proxy server (dummy server). In the last mode it connects to a port using TCP/IP or UDP/IP, all functions/methods get translated to messages and sent. It can also receive messages, and it then calls the function/method that corresponds with it. In this case the player runs only client and proxy server, and the (dedicated) gameserver runs the real server and game logic.

Local mode:
client - server - game

Network mode:
client - proxy server <---> server - game

Share this post


Link to post
Share on other sites
How would the server wait for connections? A while(1) loop would tie down cpu. (or do you just have a 50ms delay in between loops or soemthing, risking packet loss?)

Share this post


Link to post
Share on other sites
There are two ways to do this. You could either a) use the asynchronous form of your network functions, and thus specify a callback function to be called whenever a connection is accepted, or b) create a separate thread dedicated to handling the networking.

Share this post


Link to post
Share on other sites
Well... that''s when you start getting into language-specific details, but a suppose the psuedocode for the asynchronous method would look something like this:

Socket socket = new Socket(AddressFamily, SocketType, ProtocolType);

socket.Listen(32); // Backlog up to 32 connections

socket.BeginAccept(ConnectionCallback, stateInfo);
.
.
.

// The callback

public static void ConnectionCallback(StateResult ar)
{
Socket newSocket = ((Socket)ar).EndAccept(ar);
// Add your socket to an array of client socket

clientSockets.Add(newSocket);
// Keep listening...

((Socket)ar).BeginAccept(ConnectionCallback, ar);
}

I''ll concede that was more C# than it was psuedocode, but you get the idea. We being an asynchronous request for accepting connections. Everything a client tries to connect, the callback is called, we accept them, and begin another asynchronous request. The thing to remember is that simply because it''s asynchronous doesn''t mean it will handle all the connections. It simply means that your code will keep executing without blocking (ie. stopping and waiting).

Meanwhile, somewhere in a main function:

foreach(Socket socket in clientSockets)
{
// Do stuff with this client

}

Of course, it''s best not to store just the raw socket, maybe something more like a custom ClientConnectionState class, etc.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!