I've developed several games for the android platform and now planning to create my first multiplayer game. What I have in mind is basically just a 2-player game witch you can play with 2 phones over local area connection/WiFi.

Both phones need to be able to pass 3 integer values to the other phone in real time. So far I have considered using Socket's, but before I dig into it too deep I wanted to ask if there might be a better approach?



closed as not constructive by MichaelHouse, bummzack, Sean Middleditch, Trevor Powell, Josh Feb 15 '13 at 16:11

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ A better approach than socket... not sure. However, you don't need to use raw sockets since already existing libraries do it for you. I'm assuming you are developing on android platform with Java (you did not tagged as java) so you can look at Kryonet. \$\endgroup\$ – nathan Dec 6 '12 at 8:35
  • \$\begingroup\$ That's right, I'm developing with java. I'll look into Kryonet. Thanks for the comment. \$\endgroup\$ – Heigo Dec 6 '12 at 8:49
  • \$\begingroup\$ If you're only passing a couple values, you might want to consider Bluetooth. Here are a couple good references: developer.android.com/guide/topics/connectivity/bluetooth.html and stackoverflow.com/questions/5619850/… \$\endgroup\$ – amb Dec 6 '12 at 9:28
  • \$\begingroup\$ I might also consider using bluetooth in the further development, but at the moment, I thing people are more familiar with WiFi. \$\endgroup\$ – Heigo Dec 6 '12 at 9:34
  • 1
    \$\begingroup\$ I'm currently starting to create a multiplayer game also and I'm thinking about having a rest service backend (for player registration, matchmaking etc) and a game server based on tcp sockets. When the match is made and the game actually starts, the rest service will send a socket message to the server and the actual instance of the game will be created (to make things scalable). The clients get the ip for the server and create a connection using a securitytoken provided by the rest service. The game server validates and does the rest. \$\endgroup\$ – Thomas Dec 7 '12 at 14:24

One option you might look at is Socket.IO.

There seems to be a lot of discussion of Socket.IO at Stack Overflow, including:

Alas, I couldn't figure out how to get one Android device to directly communicate to another Android device through Socket.IO, or even one step of indirection with both talking to a single WiFi access point between them. (I still don't know if that was a bug in my code, some sort of firewall in someone else's code, or an inherent limitation of Socket.IO). I did get one little demo working with one Android device sending messages to a web server, which forwarded the message to the other Android device.

  • \$\begingroup\$ As a plugin for a Node.js server Socket.IO might be relevant to a question about real-time multiplayer in a browser game. In the current context of java and android, however, its mention serves only to mislead. \$\endgroup\$ – Eric Feb 12 '13 at 11:20
  • \$\begingroup\$ I have a little demo with one custom Android app using Socket.IO to (indirectly) communicate with another custom app on another Android device, via a Node.js server. It more-or-less "works", but if you know of a better approach, especially one with more direct communication, I (and I'm sure the original poster) would like to know about it -- please tell us. \$\endgroup\$ – David Cary Feb 12 '13 at 21:57

Did you say both devices were in the same room?

Each Android device has a speaker and a microphone. In principle, it's possible for one app to to send a series of tones out the speaker, and then the other app to listen for the tones and decode them back to a message string. You could either (a) use the entire audio spectrum to send data, something like the acoustic couplers of the 60's and 70's, or (b) use a much narrower bandwidth from 15 KHz to the highest your device supports (probably 24 KHz) -- a much slower data pipe, but most people can't hear those frequencies any more -- it's ultrasonic to them.

Ham radio operators have developed many clever techniques for pulling extremely faint signals out of lots of noise.

"Communication over the Audio Jack for Android phones"

Reading sound on Android: a b c

"Narrate's Zoosh software leverages smartphones' speakers and microphones to enable the same data communications between devices that today's NFC provides, but with ultrasonics frequencies that are inaudible to humans." -- Eweek, Slashdot.


Not the answer you're looking for? Browse other questions tagged or ask your own question.