I apologise if something like this has been answered before, I just can't figure out a good way to word my question well enough to include all details about my problem.
I'd like users to be able to host servers for my indie game in a way virtually identical to, for example, Minecraft. I don't want any official servers, the game is mostly intended to be played with friends and not random strangers.
I've thought of many ways to accomplish this but I could never solve one important detail - I want the server to be able to remember users and put them where they left off when they reconnect (give them their character, the character's inventory, etc).
But any solution I could find or think of either made it potentially very easy to steal someone's character and connect to the server pretending to be them, or required me to make players have a way to register with accounts, something I can't afford to host myself.
I guess what I need is a way for the server to send a token to a new connecting player, and then have a way to see if the player sending that token back is the same person, and not an attempt to replicate the token. That to me sounds like public key cryptography, but the game engine I'm using doesn't seem to have any libraries for that (unsurprisingly), and I certainly am not qualified to make a library like that myself. But maybe there's an easier solution I'm somehow missing.
This might be a stupid question, but I hope it's worth a try asking. Thank you in advance for any help. Sorry I was so wordy by the way.
TLDR: I want users to host game servers that can remember reconnecting players without risk of players' progress being stolen.
If you have not already, look into sessions. Session cookies. But also setting up a basic log in system with php or whatever server code your server uses is not hard, and most basic hosting provide the mysql and php needed to do a basic log in page, you just have to code it yourself.
I'd like to implement a simple video chat system for students to tutor each other. I'm a one man show, and would like a system I can run in a cost effective way starting with 10 users, and hopefully scale up as needed.
WebRTC seems like a great, low latency, and cheap option to build this feature. However, if clients are communicating, then they must know each other's public IP. Is this a significant privacy or security issue?
What is the worst case scenario of somebody getting my IP address? Wouldn't any malicious actor have to get through my ISP to get my specific location?
Thanks!
If you host it yourself, WebRTC can be extremely cost-effective. I've been running the SFU at galene.org (disclaimer: I'm the main developer), which is used for multiple lectures with up to a hundred students. Even though this is a full-fledged SFU (and not a mere TURN server), hosting amounts to just over €6/month.
If your tutoring sessions involve just two or three people, then peer-to-peer WebRTC might be enough, but even then a TURN server will be required, especially if some of your users are on university networks. For larger groups, you will need to push your traffic through an SFU.
If you do peer-to-peer WebRTC, then any user can learn the IP of any user they are communicating with; this is most probably not an issue, since the IP addresses are most probably already being disclosed (e.g. in mail headers). If you go though an SFU, then the IP addresses are not deliberately disclosed, but they might still leak; for example, the SFU implementation mentioned above (Galene) discloses IP addresses when a user initiates a file transfer since file transfers happen directly between clients, in a peer-to-peer fashion. (It may be possible to avoid this disclosure by setting the iceTransportPolicy field to relay in the PeerConnection constructor, but I haven't tested how effective it is.)
WebRTC doesn't have to be P2P. You could run a SFU. Each user will upload their video to your server, and the server will distribute via WebRTC. Then the users will never know each others IPs.
I don't have any exact numbers, but it isn't expensive either. Your biggest expense will probably be bandwidth. Lots of Open Source SFUs exist, this is a good list to get started.
If I were to create a mobile game, such as Go Fish, where a number of users could play, I need an easy way for all the apps to communicate. I don't want a user to need a google or other account to register.
I thought that IRC could be used. I realize I'd have to have a way of getting the clients to know about each other for a particular game, but would IRC be ok? Is that against the TOS? Is it an appropriate use of the service?
I want an easy, always-free way for apps to communicate with each other. Low volume messages, fairly quick response time. Completely anonymous.
IRC is just a simple protocol and games have been using it for chat for decades.
Its probably not ideal for a modern game though, particularly because it poorly handles users losing connection.
You also have to host the server as its not peer-to-peer or anything so it requires maintenance and isn't entirely free. You'd probably also need to customize the server for your needs anyway so requires further work.
That all said I'm not super familiar with alternatives in the space.
I am trying to make a turn-based board game that will be run on multiple computers. I am writing the game logic and design in VB. I searched for a little and could not find the information I was looking for. One question I have is, will I need a server if there will only be 2 players. Also, what language should I use to write the server side code. I have never done network programming before so I am not sure even where to start. Any information will be helpful.
you don't need a "server" so to speak. You do need someone to host the game, which would act as your server. Basically, you want one person to host the game, and you want the other players (the clients) to connect to that host. Say for example, you're on a LAN and you want to host a game. Your IP is 192.168.1.101 for example. As the host, the clients will search for your game on the network, grab your IP and open up a connection. In addition, you'll grab their IP as well.
There are a few things you also need to consider, such as host migration if the host quits.
If you're coding the game in VB, then there's no reason your networking code can't be in VB either. The .NET Framework has some pretty solid networking methods. The NetworkStream is something you'll want to look into.
http://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx
You can use this to send/receive data between the server and clients.
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:
for now, assume the endpoints are Windows OS, relatively recent.
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)
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.
all custom code should run only on the client PCs.
Assume there is no server in the internet that is under my control.
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.
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.
Every two-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 inherently requires some type of server environment to begin with.
libpurple along with otr can give you the privacy-over-IM such an application would need.
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.
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).
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.
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.