0
\$\begingroup\$

I'm currently designing a simple game in C# and want to implement online multiplayer support. Before venturing onto doing something like this, I just had a few questions about clients and servers.

  • Is a server responsible for sending and receiving data to and from clients?
  • If a client wants to send data to another client, should it send the data to the server, and let the server send that data to the specified client?
  • When it comes to handling data, should the server have access the same classes the client does? This way the server can convert the bytes sent in, to a specific class? Or should the server just handle all the data in bytes, and send it back out if necessary?

Sorry if there are to many questions, any help would be appreciated!

\$\endgroup\$
  • \$\begingroup\$ I have quite a bit of experience in this, but its kinda hard to answer this without knowing what type of game your trying to make multiplayer. a RPG? a RTS? or a FPS? etc. some types of games require whats called an authoritative server where some don't so kinda need a type at least :) \$\endgroup\$ – Jacqueline Loriault Jul 24 '17 at 14:40
0
\$\begingroup\$

If you're thinking something that will have one global league, like pokemon go, league of legends - things where scores area compared - then you need the communications to go client-server only.

There are a bunch of ways this will make it easier, but among them are that your clients can know the address of the server, and with peer to peer it would be virtually impossible to prevent cheating.

If you're thinking of a LAN game sort of thing where a bunch of people set up a game together, play for a bit and close it down, then you could do peer to peer. This introduces a few problems, the body being network related: discovering the other clients and routing. Often discovery is done using UDP and this doesn't cross network boundaries well.

I'd use the minecraft model myself. (Pretty sure the original Doom did similar back in the day). Basically one machine gets dubbed the server and coordinates objects - location, velocity, creation destruction motivation inventory.

When a client joins they need the address of the server. Minecraft makes it easy for the user to set up a LAN game by telling the person on the server the address to use.

In terms of responsibility, I'd say it goes both ways, but you don't have to agree. Depending on your protocol, some things will be easier to implement.

If you can have open sockets/long connections then both ways will be really efficient. Client tells server when an event happens - a purchase, a death, initiating a ballistic path. Server then tells all of the clients who then update their local data.

You'd probably want to chase this option if you're doing real time action.

It might be simpler though to have your clients polling the server for state change. Your comms code might be simpler but you'd have to think real hard about minimizing the amount of data you transmit.

For same / different classes - it depends. I'd start with the same. At some stage you'll find data that is only needed by the server or the client and you'll have to decide whether to have it on both anyway (which would make switching a local game to multiplayer and back easier ) or separate them (which gives you more code to manage but may improve security). I'd leave that decision as late as possible.

\$\endgroup\$
1
\$\begingroup\$

The answer to all of these questions is "It depends".

1.) and 2.): There are two types of networking, one is a traditional one, it only has 1 server and every client is connected to this. The data always goes through the server. This is generally considered as the safer method.

The other method is called peer-to-peer (or P2P) networking. It doesn't have a main server, every client (peer) sends data to the other clients directly. This can be much faster than the first method if the peers live close to each other. It's less safe than the normal method, because the users can modify the data they send. You'd usually implement this with UDP, because with TCP you'd need a separate server and client socket for each peer and you need to store the IPs.

3.) Sometimes the client and server even share most data classes, but you generally want to avoid sending anything other than the input from the client to the server to avoid cheating.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy