Network Multiplayer (Multi-human players)

[drdev]

Looking at your two latest commits makes me wonder if it even compiled on your system after I remerged the branch. It does on mine (I'm still on r27414) and it seems to work fine.

I did a full recompile, and I was able to fix the issues and have them work. Are you sure everything is working on your end?

[KrazyTheFox]

Looking at your two latest commits makes me wonder if it even compiled on your system after I remerged the branch. It does on mine (I'm still on r27414) and it seems to work fine.

I did a full recompile, and I was able to fix the issues and have them work. Are you sure everything is working on your end?

The reason it's not building snapshots:

Looks like some tests no longer work with the GUI update.

[drdev]

I just committed r27419, which refactors the creation of Gui and AI Lobby players into GamePlayerUtils, fixes it so the Gui player name is updated, and fixes it so multiple human players can't both be assigned the same LobbyPlayer, which I'm guessing was causing issues with Human vs. Human play.

Please let me know if there's a reason the guiPlayer instance had to live in GuiDesktop/GuiMobile. I couldn't see one since only one instance of that class will ever live at one time, but maybe I'm misunderstanding your implementation.

EDIT: I just finished fixing the card type issue, which was just a simple typo, as well as fix the Tutor for Card Dev Mode option which was broken due to the new way we are determining what cards can be viewed. I'll continue to do more testing to see if I can find and fix any other issues.

I guess that begs the question, what next? How far off is actual network support now? Is there anything I can do to help?

[elcnesh]

I did a full recompile, and I was able to fix the issues and have them work. Are you sure everything is working on your end?

Yeah. Weird stuff... At least it's working again now.

Looks like some tests no longer work with the GUI update.

Fixed them, and looks like the builds are also working again.

I just committed r27419, which refactors the creation of Gui and AI Lobby players into GamePlayerUtils, fixes it so the Gui player name is updated, and fixes it so multiple human players can't both be assigned the same LobbyPlayer, which I'm guessing was causing issues with Human vs. Human play.

Please let me know if there's a reason the guiPlayer instance had to live in GuiDesktop/GuiMobile. I couldn't see one since only one instance of that class will ever live at one time, but maybe I'm misunderstanding your implementation.

Sounds reasonable. In fact, taking createAiPlayer() et al. out of IGuiBase was on my list as well, since it doesn't quite belong there, so this implementation supports client-server separation very nicely.

EDIT: I just finished fixing the card type issue, which was just a simple typo, as well as fix the Tutor for Card Dev Mode option which was broken due to the new way we are determining what cards can be viewed. I'll continue to do more testing to see if I can find and fix any other issues.

I guess that begs the question, what next? How far off is actual network support now? Is there anything I can do to help?

Great, thanks! All the communication between the game and the players should now take place via two interfaces, IGuiBase (server->client) and IGameView (client->server). By writing network classes in addition to the direct implementations we have already we can send these calls over a network. This means the arguments and return values will need to be serialized. This is basically where my input stops, as I have no experience writing this sort of stuff whatsoever. Is there anyone willing to pick this up and write a first implementation?

[drdev]

Alright, I just fixed a couple more issues that were preventing the command zone from appearing on the mobile game, as well as preventing cards appearing face down if you click on your library tab or your opponent's hand/library tab. Otherwise, everything appears to be working now, though more testing won't hurt.

[Agetian]

Thanks for the prompt fixes! Overall I like the structure of the new code much better, thanks!
Another issue to report: viewtopic.php?f=52&t=6333&p=161338#p161338

- Agetian

[drdev]

elcnesh, can you explain to me why GuiBase.getInterface() is now a field and parameter in a lot of places? Is the plan to eventually have more than one instance of a IGuiBase in a single Forge session? I'm just a bit confused.

[elcnesh]

The main point is that I removed GuiBase from forge-gui, first of all to get rid of all the references to it in the match code. This is necessary to allow forge-gui to possibly call a different Gui (over a network) using the same input code. Then I also refactored it in the quest code etc., and in the end I decided to leave it, to prevent forge-gui from accidentally making a GUI request to the current IGuiBase (the server) rather than that of a certain player (client). But for some parts of the code (quest) it's not really necessary. I think we can now see them as a sort of "member function" of IGuiBase by passing it as the first argument.

[drdev]

I just committed a large refactoring of the new GUI code in the start of an effort to improve Human v. Human support. If all goes well, this should allow Human v. Human to be used to somewhat simulate a network game, which will put us one step closer to network support.

The main change is that we no longer have a single localPlayer or gameView defined for a game, but rather can have more than one defined if multiple human players exist. Each human player gets their own input queue and proxy.

The first thing I'm going to do with these changes is add support for 2 people playing against each other on the same Android device, as opposed to using hot seat mode and passing the device back and forth. Stay tuned for updates on that. It should be really cool once I get it working.

[drdev]

FYI, I just committed another large refactoring to get rid of a lot of code duplication between the desktop and mobile versions in and around match logic. This included getting rid of FControl in the mobile version, slimming it in the desktop version, and moving the duplicate logic within into a new MatchUtil class and IMatchController interface, which is implemented by CMatchUI on the desktop version and a new MatchController class on the mobile app. This also allowed significantly trimming the size of the IGuiBase interface, which was starting to get a bit out of hand.

Please be sure to update immediately if you have any large changes in the works. This change affected around 85 files, so i want to try and avoid merge conflicts. I already had to resolve a few before I could commit.

Please let me know if you see any issues arise as a result of this change. The one I know of right now is that the "Loading game..." overlay no longer appears, and I'm working on that.

[drdev]

So I've got a proof of concept working for 2 people to play against each other on the same device. It allows passing input back and forth between two different prompts on the top and bottom of the screen, with each player's half facing his or her direction. Here's what it looks like right now:

Some things to note that you may not be able to tell from this screenshot:

• When cards are long pressed to zoom, they will face towards the active player
• I'm planning to make it so the active player determines which cards are shown and which are hidden

Some things I'm not sure of at this point are:

• Where to show the stack
• How to let players access the game menu for themselves, view the log or players
• How to let players have different stops (right now both players will stop on the same phases)
• Whether there needs to be a way to prevent the other player from sneaking a peek at your hand

Any thoughts on those are welcome, as is any input on my implementation.

Thanks.
-Dan

[elcnesh]

Wow, this is really awesome... Glad to see the refactoring also brought some good things

About showing cards: maybe tapping them to rotate, so that both players can have a look?
You could display the stack in the middle? Or maybe on both sides (one for each player).
For stops: you could make a menu to have players select their stops, rather than have them clicking the phase display labels. This could be a nice feature anyway (also vs AI) because the labels may be a bit small on phones.
About sneak peeking: placing a screen around your side of the table? I don't know, I think that's pretty much impossible to accomplish when playing a game like this on a single screen. Of course players could just close their hand if they're not doing anything, to at least make it a bit harder for the opponent.

[Agetian]

I think that as far as hiding the hand goes, the ability to temporarily remove the hand from screen (which already exists in Forge and is accomplished simply by tapping the hand icon) should suffice. This doesn't prevent the players from seeing how many cards are in each other's hand, which is good (and is as should be), because there's a number specified right next to the hand icon.

- Agetian

[drdev]

So I've made some tweaks to the layout for the Human v. Human screen so that there's a more reasonable place to display the Stack and individual menus for each player:

As you can see, I've made it so the second player's orientation is right-to-left with the exception of their prompt. Not only does this allow cards and other things to line up again horizontally between players, it also allows putting the stack and player-specific menus on the right. The stack will then come down rotated 90 degrees so each player can read it and so it doesn't block any of the first cards played for each player. The ... menus above and below can be tapped by the player on that side to open up a menu with Game, Players, Log, and Dev (if dev mode on) as options which can be clicked to open the corresponding drop downs to the left and facing the player. I'm also thinking of adding another option to temporarily rotate everything to face that player as was suggested.

How does this seem to everyone? This is proving tricky to implement with all the Graphics rotation involved, so I'd like input before going too much further with this design.

Thanks.
-Dan

[elcnesh]

Looks awesome, and really playable! I think it'd be great if you could finish this. It's also good to get an indication of possible issues that may arise when implementing network play.