Closed GoogleCodeExporter closed 9 years ago
Issue 328 has been merged into this issue.
Original comment by August.D...@gmail.com
on 5 Apr 2012 at 1:16
Adding the terms "Local", "Multiplayer", "Another Person", "Offline",
"Hotseat", "Hot Seat", and "Human" to make this issue more likely to show up in
a search.
Original comment by August.D...@gmail.com
on 5 Apr 2012 at 1:18
Issue 336 has been merged into this issue.
Original comment by August.D...@gmail.com
on 13 Apr 2012 at 5:38
Original comment by eiko.wag...@gmail.com
on 1 Sep 2012 at 10:17
Question from having looked at the source code - is this already set up to
allow separate-device multiplayer if an activity to connect to an actually
remote server (rather than the "virtual remote server" that's running in the
background when a game is started) is exposed within the app, or is that mostly
leftover code from older versions which no longer works?
Additionally, if it's the former, would it be possible to manually run the
server-side only on a private webserver, to allow multiple android clients to
all connect to a static IP, rather than needing to discover the IP and any port
forwarding on a mobile device?
(Sorry if my questions don't make much sense - I've looked at the code online
and checked out a copy of it from SVN, but I'm still having difficulties
compiling the source to do something even as simple as rebuilding/compiling the
APK, so I've not been able to play around with it yet.)
Original comment by Nicholas...@gmail.com
on 18 Oct 2012 at 7:40
Would very much love multiplayer as well. Pass & play would be a start, online
multiplayer would be awesome! Perhaps I could assist in the latter, I'm a
system engineer, so I could contribute designing / running / hosting the server
side. I might be able to get some guys to help out with the code as well, let
me know if this is needed.
Original comment by IntensM...@gmail.com
on 7 Dec 2012 at 3:08
Milo: Take a look at com.mehtank.androminion.server.DominionServer in
svn/trunk/androminion/src - it *looks* as if the online multiplayer is already
somewhat implemented, the app just locally runs the server on your device and
then connects to it over localhost. It seems as though you should be able to
just run that as a regular Java application on a regular server and then enable
the mobile UI to connect to the remote server with minimal changes.
Original comment by Nicholas...@gmail.com
on 7 Dec 2012 at 3:36
Is anyone actively working on this? I am planning on trying to get this
working, at least crudely. I've got the source building, and I've found a few
starting places for trying to get this to work. I can see, though, that
there's a lot already in the code to handle multiple human players, so it seems
likely someone else is actively working on it (or has in the past). If that's
the case, it'd be good to talk to whoever that is, so that I don't duplicate
any work.
Original comment by drai...@gmail.com
on 23 Dec 2012 at 2:37
Ok, so I've figured out mostly how the code works, and it looks to me like the
main problem is in initPlayers in com.vdom.core.Game. Because the game server
initializes all of the players with players[i].newGame(context), including the
RemotePlayer, there's no way for the RemotePlayer to reside on another device.
Adding a player to the game needs to be handled as an event, so that another
device can send a message telling the server that it's one of the players.
The road map for implementing this feature would look something like this:
1. Change the initPlayer code to a client-server architecture, using events
instead of sequential calls, as is currently done. Get the app running as it
currently is with this new initialization code (i.e., still single player, just
a more multiplayer-friendly initialization). The StartGameActivity would
create a RemotePlayer and register itself through an event with the server.
2a. Add a "Join game" button in addition to the "Start Game" button, letting
the user specify a host and port where the game server is running (it'd be nice
if it would work over bluetooth, also, though I don't know much about how that
works).
2b. Allow the user to specify hotseat game play instead of waiting for another
device to connect to the server when more than one human player is specified,
and figure out how the UI works for that. This is kind of orthogonal to 2a and
can be done at the same time, hence why it's 2b and not 3.
The hardest part is step 1, but it shouldn't be that bad. Once the
initialization code is fixed, it looks to me like the rest of the app is
already built to handle multiplayer, so it should be straightforward to do
steps 2a and 2b.
I can start working on this, though it would be nice if someone who is more
familiar with the code could confirm that this does seem like the right way to
implement this feature. If anyone has any suggestions or complaints about
this, that would be good to know, too (like, if there's a particular event
style I should follow, or something).
Original comment by drai...@gmail.com
on 24 Dec 2012 at 9:16
Noting that my comment #9 on this thread reflects a poor understanding of the
code. See issue #582, which I am merging this into, for a better idea of how
to implement multiplayer.
Original comment by drai...@gmail.com
on 27 Aug 2013 at 6:43
Original issue reported on code.google.com by
jboom...@gmail.com
on 22 Mar 2012 at 4:47