views:

260

answers:

7

How can I build a simple 2-player game, that communicates over the internet?

I need to solve the problems of:

  • lookup or rendezvous - two players want to find each other.

  • ongoing communications. Either player can initiate an action that requires delivering information to the other side, in a reasonbly quick timeframe (IM-type latency, not email-type latency).

In this regard, I suppose it is equivalent to a 2-way chat, where people want to be able to find each other, and then also, once paired up, intercommunicate.

Further requirements:

  1. for now, assume the endpoints are Windows OS, relatively recent.

  2. assume neither endpoint machine is directly accessible from the internet. Assume they are client machines, hidden behind firewalls that block incoming requests. The machines can make outbound requests. (say, over HTTP, but TCP is also fine)

  3. communication should be private. For simplicity, let's say there's a shared secret already in place, and the endpoints are able to do AES. I guess what I mean by this is, any intermediary should not need to decrypt the message packets. The decryption will happen only at the endpoints.

  4. all custom code should run only on the client PCs.

  5. Assume there is no server in the internet that is under my control.

  6. I'm happy to use third-party servers to facilitate intercommunication, like an IM server or something, as long as it's free, and I am not required to install custom code on it.


What APIs are available to facilitate this design?

Can I do this with IM APIs? WCF? Are there WCF Channels for Windows Messenger?

What protocols? HTTP? I have this tagged as "peer-to-peer" but I mean that virtually; there's no hard requirement for a formal p2p protocol.

What message formats would you use?


EDIT

To clarify the requirements around servers, what I want is NO SERVER UNDER MY CONTROL. And NONE OF MY CUSTOM CODE ON ANY SERVER. That is not the same as "No server".

Think of it this way: I can send an email over SMTP, using custom code that I write on the sending and receiving side. My custom code can connect via a free SMTP server intermediary. This would require no installation of code on the SMTP server. This is something like what I want, but SMTP is not acceptable, because of the latency.

EDIT2
I also found this: library for Instant Messaging, like libpurple, but written in C#


ANSWER

I can do what I want, using libraries for IM frameworks. One simple way to do it using Windows Live Messenger is to use the Messenger Activity SDK. This proves the concept, but is not really a general solution. But, similar things can be accomplished with the IM libraries for various messenger systems, like libpurple, or using libs for IRC channels. In all these cases, the IM servers act as the firewall-penetrating communications infrastructure.

+1  A: 

libpurple along with otr can give you the privacy-over-IM such an application would need.

Ignacio Vazquez-Abrams
looks interesting. Don't really wanna write for GTK+, though.
Cheeso
Neither libpurple not libotr require GTK+.
Ignacio Vazquez-Abrams
ok, I misunerstood that "what is libpurple?" page. now I am interested. need to read more.
Cheeso
I'm looking for an sample "Hello, World" for libpurple, cannot find.
Cheeso
+3  A: 

Every 2 player game must have some type of server environment by the basic need of having to communicate between two clients/players at the very least. Keep in mind, each of the clients/players can also act as its own server to communicate with other linked clients. But the need to keep tabs on all clients/players at any given time and the need to facilitate searching of other clients/players inherantly requires some type of server environment to begin with.

drlouie - louierd
I didn't mean to say "No server". What I want is "no server under my control" and "none of my custom code installed on the server". In other words, I don't want to write server-based code to facilitate communication.
Cheeso
A: 

you have a lot of conflicting requirements. both clients behind a firewall blocking incoming requests pretty much means they can't do peer-2-peer since neither machine can act as the server, and you will need to have a transport server in the middle somewhere routing messages to each client. right now what you are asking is pretty much not possible given the no server requirement.

fuzzy lollipop
Not **no server**. The reqmt is **no server under my control**, and **no server running my custom code**.
Cheeso
you don't understand, one of the clients (or some other machine) HAS to act as a server in any case, that is just how these things work. And if both clients are blocked for incoming requests, then there HAS to be a third server to bridge the two clients together.
fuzzy lollipop
Fuzzy, that's wrong. One of the clients does not need to act as a server. If that is what you think, you don't understand the problem space.
Cheeso
something has to act as the server for your "game" logic, and if isn't a third server then it has to be one of the clients very simple distributed programming 101
fuzzy lollipop
A: 

You could setup a message board on one of the free message board servers so that players can find each other. You'll probably want to encourage them to use private messages to exchange IP addresses. Then, use a protocol that connects using IP addresses. Good luck with that. Firewalls make it a pain.

Then, of course, one machine of the pair would need to act as server, the other as client. Your software must contain both sets of code. I've written such a game and can tell you that the communication code gets a little confusing.

I can tell you right now that you'd be much happier in life if you wrote a web service to facilitate communication. But, then, you'd need a server for that.

Good luck. You're going to need it.

OR, you could just write a game for an IM client, like Microsoft Messenger. I've seen games for that one, so I know it can be done.

BoltBait
Piggybacking on the existing IM servers seems like the right thing. How?
Cheeso
A: 

As somebody has said, it may not yet possible to do so if you don't have any mediated server between 2 players. As you're happy to use third party server, I suggest that you build your system using Google App Engine + XMPP over HTTP. It works nicely over internet and behind firewall. And yet it's free (as long as your system doesn't grow out of GAE quota).

instcode
The requirement is NO SERVER UNDER MY CONTROL. And NONE OF MY CUSTOM CODE ON ANY SERVER. That is not the same as "No server".
Cheeso
Well, in that case, you can just use any XMPP-compatible IM server (google talk, jabber.org...) and find an XMPP library which supports your PL binding (C#?). Check out this url: http://xmpp.org/software/libraries.shtml. You should use XMPP because it dominates over other IM protocols and a lot of XMPP servers are available out there.
instcode
something has to act as a server, one of the clients or a third machine as long as the clients can't accept incoming connections then you need a third machine as a server to coordinate the 2 blocked clients. no matter how many times you say the same thing in ALL CAPS doesn't change the fact that you can't do what you want because of the CONFLICTING restrictions that you are placing on the implementation
fuzzy lollipop
Fuzzy, you are explaining to me that I need a server, and I'm very clear on that. Repeating it doesn't make me agree even more. I understand a server is necessary. I wrote in all caps because I don't know how else to get people to understand the plain English that I am writing. Maybe you could read the part in all caps again?
Cheeso
A: 

Peer to peer is out due to your firewall constraint. This doesn't really work easily for directory services anyway.

The next easiest method I would use is to toss up a very simple CGI server script on one of the numerous super cheap web hosting sites. It seems that you don't want to go this route. Is there some particular reason? 100 lines of code and a super cheap server should give you everything you're asking for and more.

I suppose you could hook into some sort of third party chat library thing. I don't know about the current IM protocols, but good old IRC and a separate channel for your game would work. You even could cobble something together using FTP. BLOG comments on a free blog site would work too. The question is why?

These are all kludges. They get the job done in obtuse, inelegant, and poorly scaling ways.

I urge you to reconsider the web server solution.

CoryZ
as for plugging into chat protocols, libpurple and msnpsharp look good so far. Not a kludge at all. This is how IM clients work.
Cheeso
You are relying on 3rd party infrastructure that you do not control and is not designed for this application. This also adds additional code complexity. For all I know it also may violate the TOS of the IM server. This is a kludge.With that said, if the libraries work for you, go right ahead and use them. Understand that you are adding additional work for yourself and giving up control of a critical part of your app.
CoryZ
+2  A: 

IM is the wrong tool. Instead, use an IRC chat room.

With an IRC chat room, your clients "log in" to the chat room, and that is used for your "presence". Anyone in the chat room is "available" to play the game.

Once that is done, the game instance communicate with each other through the chat room. They can use the global channel, or simply private IRC channels for game traffic.

The issues to solve:

  • First, all game state is shared on the clients. Many games have done this (RTS's like Age of Empires, RPGs like Diablo). But client states are susceptible to hacking and cheating. That's just a plain truth. If the game is popular, it WILL be hacked.

  • Ping traffic. Basically the flow is you log in to the room, your client is in "available to play" mode. Then it pings EVERYONE ELSE to see if THEY are available to play. This will happen with every client "sign in" to the chat room. You can then use the public room for broadcast events "Frank is ready for a new game", "Frank started a game with Joe", etc. That can help keeps games in sync and not chatty, but when a client connects to the chat room, it's going to go "Hi All, it's Bob, what are you all doing". So you need to manage that.

  • Traffic volume. IRC rooms can handle a lot of traffic, but not a LOT of traffic. Most are designed to prevent "spamming", "flooding", etc. So you may well be rate limited on you game play. Not a problem for "Checkers", more so for "World of Warcraft" during a 40 man Raid. That's a game design issue.

  • Terms of service. The IRC provider may well say "Uh no, you can't do that with our service". I haven't looked in to it, so I don't know, but could be an issue.

Other than that, IRC is a pretty good fit. Lots of IRC bot code floating around on the net, I've never used any of it.

Will Hartung