Well suhas,
I believe bluetooth is currently impossible but perhaps cupcake adds
capabilities to be able to talk to a peer?
As for Wifi, you will need to roll your own code. This is because all
games need custom networking code unless they are built from an engine
which has it integrated. A good common strategy is to have one device
act as the host and the other as the client. The host really "runs"
the game and the client just updates its view and tells the host what
it would like to be doing.
If your game is fairly simple, say a player can only move and kick,
then your protocol is very easy on the input side. The client throws
a "move up" or "kick" into the bytestream and when the host sees it,
it updates the position or state of everything and then sends that
back over to the client. Unlike online games, wifi play doesn't have
the bandwidth constraint so you actually can send over almost a full
view of the world every network tic. The client just positions
everything where the host says to and draws.
The loops are like this:
if (isHost) {
processInputFromNetwork(); // other player moving and kicking
processInputFromPlayer(); // this player moving and kicking
updatePhysics(); // where is everything now?
sendWorldToNetwork(); // tell the other player where everything is
now
draw();
}
if (isClient) {
processWorldFromNetwork(); // get the state of the world
processInputFromPlayer(); // this player moving and kicking
updatePhysics(); // combine what the host says the world is with
what we just did
sendInputToNetwork(); // tell the host what we just did
draw(); // draw it all
}
If your code runs really fast then you probably won't need
interpolation but it's generally a good idea just in case the host
gets laggy for some reason or if it is running on a slower phone.
People like using UDP because if there is a network problem, the
packets are just dropped, no biggie. This is fine for the world view
because the client will just show choppiness, or maybe even seamless
updates if you do your interpolation right but if the "player input"
packets are dropped, it's a bad thing. It's like pressing fire and
never having the thing fire.
This approach is good if you have modeled your world. If you haven't,
I recommend taking that route. If you want more than 2 players or
have a world with objects in it, you may want to use ghosting and have
the server manage the object IDs.
As for menus, I like having "Host a Game" and "Join a Game" options.
This makes the netcode simple. When you Host, it just gets the IP
addr of the WiFi device using the Android API, then listens on a port
for clients. Use TCP for that. When you Join a game, it gets the IP
addr of the WiFi device and then attempts to connect to every IP in
the subnet on your Host's port. If it connects and handshakes (think
MYGAME V/(version_number)) then it can get the game state and you can
begin the game or do whatever other steps are necessary there. At
that point the host and client(s) know each other's IPs and can start
up their UDP listeners and throwers.
I recommend running the UDP side on its own thread. That allows for
your game to just empty it's queue of stuff it has received and dump
some new stuff into it that goes to the client or host.
There are other ways to do this but this is how I handle stuff like
this and how Light Racer 3D's multiplayer will work (Coming in May).
On Mar 24, 9:36 am, suhas <suhas.ga...@gmail.com> wrote:
> Hi All,
> I have developed a sports game which is single player.
> Now I want to have one more game mode which is multiplayer.
> My question is how can i do device to device connection in android
> using sets of api which can be :
>
> 1.Bluetooth - whose APIs are not currently available.
> 2.gtalkservice - removed from sdk1.0
> 3.wifi - I dont knw how to connect 2 devices using wifi apis . I have
> asked about wifi because we have developed a game on iphone which used
> wifi connection for multiplayer stuff.
>
> Or is there any other apis which can be used for implementation of
> multiplayer in game ?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
