0
\$\begingroup\$

I am trying to make a turn based game, so first should I use UDP or TCP for the client server set up and why?

Second how do I implement it? I have seen a lot of code that just sends byte strings to each other but that is not sufficient enough to make a game... I have heard of Remote Method Invocation, and I haven't found a good explanation of it or a good implementation of it, so if you could show some of that as well.

Lastly, on MSDN there was the WCF (the tutorial on MSDN does not work on my computer at least) so it does not help me understand what it does

So how should I try and set up my server? and how to I call methods from the Client, and from the server? and how to I make the client or server respond to each other?

Thanks for any response that may help!

\$\endgroup\$

1 Answer 1

4
\$\begingroup\$

A turn-based game should use TCP.

TCP guarantees that you receive all packets in the order they were sent. You can basically treat it like a file stream.

UDP gives no such guarantees - you could receive a packet out-of-order, duplicated, or not at all. A UDP connection will give you lower latency (it doesn't have to wait for late packets or re-sends), but you don't need that in a turn-based game, and the logic to handle those scenarios is non-trivial (not worth the effort).


Personally I would probably implement this using TcpListener and TcpClient. I'd use BinaryReader and BinaryWriter to send and receive data on the resulting NetworkStream.

I'd implement "Remote Procedure Call" (or RPC, a more general term for "Remote Method Invocation") with something extremely simple, like this:

if(reader.ReadInt32() == NetworkMessage.PlayEffect)
{
    PlayEffect(reader.ReadString(), reader.ReadInt32(), reader.ReadInt32());
}

Using WCF is an option. But before you do, consider if you actually need any of the features it provides. It is basically a framework for writing "services" that produce and consume messages, usually over a network.

One of the key features of WCF is that it allows for very loose coupling between client and server - allowing many different clients and servers to interoperate. You generally don't need this for a game, which generally just has one client application and one server.

When in doubt, do the simplest thing that could possibly work - you can always switch to something else later - and that is made much easier if you haven't attached yourself to a bulky framework.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .