Which network engine/library/system to use in a .NET turn-based game? [closed]

Question

I'm developing an abstract strategy turn-based game in C#.

Being so, high network load is not expected. The players don't even have to be connected all the time. The host could wait for the current player to connect and make his move. I know I could make a web site to run that, but I want anyone to be able to host their own games.

I need something reliable and that enables me to have good productivity.

I'm already underway with WCF. Was that a good choice? Which other network framework should I consider?

Answer 1

I've been using WCF for my own turn-based strategy game, and it's worked out very well. The durable sessions area great, and duplex channels with client callbacks are ideal for pushing messages to the client at will from the server. WCF also supports multiple endpoint bindings, so you can have the local player connect through a named pipe binding while remote players connect through TCP bindings.

I recommend TCP bindings with binary formatting if you're sending lots of data on each turn.

Answer 2

If you feel comfortable and productive in WCF there may not be a strong reason to use anything else. I certainly think that WCF is a good place to start because if you follow its contract pattern it is an easy pattern to convert to work with other systems, should that need arise.

For one of my own projects, I started with a WCF prototype. When I started into "the last mile" I found that more often than not I was fighting WCF to get things done. I was particularly having issues with game matchmaking in WCF's peer-to-peer stack, which didn't quite give me the tools that I needed. In that project I ended up switching to XNA's network library, which gave me the Xbox-like matchmaking (and GamerTags and whatnot) that I was looking for and (badly) attempting to emulate in WCF. (Of course, XNA's networking library assumes you are working in an XNA game, and unfortunately still doesn't support publishing the game on Windows without a GfW Live contract.)

I didn't touch that much of my networking code in the switch from WCF to XNA Net, because the contracts themselves (the interface classes) didn't change all that much (other than dropping the WCF attributes). Writing Reader/Writer classes that implemented or consumed my contracts was fairly straightforward. I probably could have kept support for both with a little bit of #if WINDOWS mangling, but I had decided to just drop WCF support at that time, because it simplified things on that project. Perhaps interesting, in starting other projects directly with XNA Networking, I've still been using something of WCF's interface/proxy-driven "contract" pattern. I've been meaning to write a blog post on that subject, actually, because I think it is a good pattern to follow.

Answer 3

If you are simply passing "turn" changes back and forth then you are on the best path. WCF will allow you the greatest flexibility without adding very much to your development efforts, especially if you already know .NET.

Since it seems that latency is not an issue in your game, WCF is a great choice, because it will abstract away all of the message encoding from you, and since you don't need to eek out every last bit of performance, this abstraction should be more benificial to you than harmful.

Answer 4

Consider Neutron: http://www.exitgames.com/Neutron

It natively supports turn-based games, as well as account management and all the other things:

However, it costs at least $100 per month.