Network Multiplayer (Multi-human players)

[xbon]

If network multiplayer is introduced, wouldn't the same problem that happened to cockatrice happen, with the wizards of the coast lawsuit and what not?

[Xitax]

I think that if there's no central server, then no. If it only supports local hosting, that is.

[Max mtg]

It's somеwhat early to count chickens that have not hatched yet.

We've heard of what they made to cockatrice. On the other side, another game with its multiplayer is still well and alive.

[drdev]

Is anybody working on this anymore? If not, any objections to me taking a crack at adding network support? I have some ideas.

[troyready]

FWIW, last thing I saw was max stating that he wasn't interested in it anymore so I think things are wide open for you.

(saying this just as a random user that would looove to see it added)

[elcnesh]

I've tried some things a while ago, but failed miserably to get anything working at all. It'd be great to get it working! If I can be of any help, let me know, as I'd love to contribute to that part of the code. (Although FYI, I'm on vacation till mid-august )

[rikimbo]

I actually started looking into this part of the code a few days ago. I managed to get chat working between two instances of Forge (and tested it remotely as well), and that's as far as I've gotten so far.

I also have some ideas about how to tackle the bigger challenges, so we could bounce ideas.

EDIT: I'd like to help if I can, but I also recognize that this might get done better and faster if you just Grab the Reins on this. So just let me know what your plan is.

[drdev]

So my plan is pretty simple overall. I feel like Forge is ultimately a casual game, so I see no reason that we need to go to great lengths to prevent cheating. With that in mind, we can continue to allow all game logic to run on the client, and only use the server to send an updated game state to the other player. We wouldn't need to do any validation on the server, and we would simply disable Developer mode for network games to prevent being able to cheat without hacking the client-server messages, which hopefully nobody playing Forge will be malicious enough to do.

Since Forge's game logic isn't currently built in such a way that individual actions could be serialized and sent, I'm thinking instead that every time a player passes priority, we'd simply serialize the entire game state and send it to the server. The other player's machine would then just ping the server on an interval, and if it detects that an updated game state is available, it would retrieve that state, deserialize it, then call the necessary client logic to apply it on the UI side, just as as we already do after the AI takes actions.

With such a strategy, the only tricky part is creating an optimal serialization method for the game state. The good news is, if we can do this, it would also allow us to add support for saving and loading games, which would be a nice enhancement.

Obviously this isn't the most secure or optimized strategy for implementing network support, but I feel it's by far the most doable given the current state of Forge. We can always make it faster or more secure later, but meanwhile I'd rather just have something working without first having to do a major refactoring of Forge's codebase.

How does this plan sound to everyone?

[elcnesh]

Sounds good I was thinking the same thing about security/cheating; we're not trying to recreate MTGO by supporting tournaments etc. (in fact that'd probably be the fastest way to get Wizards to kill this game).

Serializing the game would consist of serializing the Game object, which contains the players, which in turn contain the cards, right? That doesn't sound like it should give too much trouble.

Meanwhile I've started fixing some multiplayer-related bugs, which will probably become quite relevant once players start playing multiplayer online.

[drdev]

I guess the next question is where should the server be? Can we create some kind of central server that can also host a game lobby to help people connect and play? That would be nice if it's not too difficult (or too risky in terms of Wizards).

[elcnesh]

Hmm, good question... It might be risky, but having a central server would be really cool. What I'm afraid of though, is people who start cheating on the central server – If you play only with friends, you can just contact them when you notice cheating, but on the internet, that's a lot harder.

Although this would probably also limit Wizards' interest in us, making it safer. I'd say, for now let's use decentralized servers. The code is the same, so we can always decide to set up a central server later on.

[KrazyTheFox]

Yeah, I think we're going to need to be very careful about not stepping on MTGO's toes here. Decentralized servers is probably the way to go and we could always create a new subforum/topic to find people to play (or maybe a friends list type of deal—also decentralized?).

[rikimbo]

I agree with elcnesh and KrazyTheFox about the decentralized servers. I think we could start by having one player host the game, and another player joining directly.

In terms of the mechanics, the way I had thought of doing it was to set up another PlayerController for a remote player. When a 2-player game is created over network (say between Clyde and Biff), on Clyde's instance, Clyde has the human player controller, and Biff is a remote player controller. On Biff's instance, it's the opposite (Biff is assigned a human player controller, Clye is assigned a remote player controller). Then, as you said, all of the game logic would all be locally figured out on each player's machine. Synchronization would be handled by the remote PlayerController to obtain player actions and decision results. The way I ideally picture it is that to the core game code, the remote player controller acts exactly as an AI player controller does. The remote PlayerController will, instead of automatically generating decisions and game actions (as the AI controller does), obtain them by querying the server.

Currently the game is not set up to be able to easily serialize game actions, as you said. That is the challenge of doing the approach above... It would probably involve creating some serializable objects that the remote player controller could use to communicate with the server, and then it would build the proper objects out of the info retrieved in order to communicate with the rest of the core game code.

[eljinete7]

Wow! Network multiplayer in Forge would be so nice. I can only say please please drdev try to implement it and many thanks in advance.

I think the two main things that would make Forge almost perfect are online playing support and a better AI (and perhaps that Gauntlet modes at last work ).

My best wishes to you drdev and to all you guys and I hope that so cool new feature could be finally done to improve Forge.

[Xitax]

So my plan is pretty simple overall. I feel like Forge is ultimately a casual game, so I see no reason that we need to go to great lengths to prevent cheating. With that in mind, we can continue to allow all game logic to run on the client, and only use the server to send an updated game state to the other player. We wouldn't need to do any validation on the server, and we would simply disable Developer mode for network games to prevent being able to cheat without hacking the client-server messages, which hopefully nobody playing Forge will be malicious enough to do.

I agree with this sentiment, but a relatively simple way of preventing cheating (and may be necessary anyway to make sure information isn't dropped or something skipped) is to check for out of sync gamestates.

About servers: strongly feel we need a decentralized system. A meetup board might be a good idea. But the game itself should always be P2P. Maybe keep a list of friends addresses or enable a chat lobby via direct IP? Maybe hook into an IRC lobby for open chat?