Network Multiplayer (Multi-human players)

[uhlersoth]

Yes, I agree a thousand times over with what sidereal said. Piecemeal migration is the way to go.

But, apparently my statement of piecemeal intent was interpreted as, "uhlersoth wants to add multiplayer functional next week!"

[friarsol]

But, apparently my statement of piecemeal intent was interpreted as, "uhlersoth wants to add multiplayer functional next week!"

I was mostly confused because it seems like you want to take our open source project, program for it, but not actually contribute code to the project.

[Max mtg]

But, apparently my statement of piecemeal intent was interpreted as, "uhlersoth wants to add multiplayer functional next week!"

Lookes exactly like that. "I already have the server, just want you to make some modifications to FControl"

[uhlersoth]

To do this, my idea is to begin by swapping out the standard home screen with a simple lobby (online players in a JTree, with the option to invite them to games, etc) that you would expect to see in any server program. All the multiplayer work would need to be maintained separately, yes, but I'm not asking y'all to take on that job. If my efforts pan out I would send the code your way and you could do with it whatever you want - throw it away, integrate it, whatever.

But this feature request of mine follows this model. It opens a hookpoint for creating the lobby. I'll then be able to create a lobby in my own local code without impacting the existing dev stream.

What I've created so far is a server. You login with a Java client (using sockets) and can see a list of anyone else logged in. After selecting a user, you can send them a game invitation, and... that's as far as I've gotten.

Like I said, not sure how you interpreted these comments as either:

I was mostly confused because it seems like you want to take our open source project, program for it, but not actually contribute code to the project.

or as:

uhlersoth wants to add multiplayer functional next week!

Lookes exactly like that.

Anyway, I'm not interested in bickering or red tape. I'm in 100% agreement with the analysis sidereal presented as to what needs to happen, which means I can exit stage left knowing that he'll be pursuing what needs to be done.

[friarsol]

Like I said, not sure how you interpreted these comments as either:

I was mostly confused because it seems like you want to take our open source project, program for it, but not actually contribute code to the project.

I'm not trying to lure you into an argument here, but "I'll then be able to create a lobby in my own local code without impacting the existing dev stream." is exactly why it sounds to me what I said above. Why couldn't this be potentially apart of Forge, or at least in its own branch while you worked on it?

[uhlersoth]

So here's what I don't get. When I propose a nonfunctional hookpoint to allow for the possibility of a different home screen, for the purpose of allowing for a multiplayer homescreen, the answer is:

Frankly, though, I think this is too large for a first-time contribution. You will be touching nearly all subsystems in this, and each have their own little quirks and histories. It might be wise to make some smaller contributions first, just to get some familiarity with the codebase. It will also give the devs a chance to become familiar with you and get a feel for how likely you are to destabilize currently working code

But when I say that I'm not interested in an all-in-one-go approach:

I agree completely regarding your "integrate in one go" comment - not gonna happen. But that's actually why I'm hoping to use this dev model - determine some hookpoint that leverages multiplayer, which can be opened up without any impact on the existing dev stream. The last thing I would want to do is have any of your current resources redirected toward a side project like this. Given a choice, I would much rather see Forge stay up to date with all the latest rules changes than to see multiplayer added.

The answer you're giving me is:

Why couldn't this be potentially apart of Forge, or at least in its own branch while you worked on it?

Y'all need to make up your minds. I don't consider myself a Forge developer. I've never made a contribution to the code, and I don't presume to have the authority or experience to do so. I've made that abundantly clear. But which is it -- do you want me making contributions to the code, or not?

If so, then the nonfunctional abstraction change I proposed at the start of this is the first thing that should be done. If not, then why are you telling me to put my code into a branch?

[Max mtg]

I think you can make the contributions by developing features and commiting them in a personal branch in code repository - they will be visible to everyone there. You will have absolute freedom to implement and test any features you like.
Later on these features (if they are compatible with the principle trunk follows) may be merged into main codebase and become part of that "official" distribution - that betas Chris publishes twice a month.

So start developing with implementation of that nonfunctional change.

[myk]

Y'all need to make up your minds. I don't consider myself a Forge developer. I've never made a contribution to the code, and I don't presume to have the authority or experience to do so. I've made that abundantly clear. But which is it -- do you want me making contributions to the code, or not?

If so, then the nonfunctional abstraction change I proposed at the start of this is the first thing that should be done. If not, then why are you telling me to put my code into a branch?

I agree with what Max just said. We absolutely want you making contributions to the code (and, thus, becoming a Forge developer). We were just concerned that this is an unusually lofty first goal, even if it is broken up into parts. We are not opposed to it, we just wanted to communicate that you might be taking on more than you realize. However, it is a feature that I think we are all enthusiastic about and we want to help you as much as we can. Working in a branch will keep all Forge-related code in one place, facilitate merging, and allow us to see what you are doing so we can collaborate with each other.

[friarsol]

Yep, exactly what Max and Myk were saying is what I was trying to get across.

1) Everyone seems to be in agreement that any progress in this area is not going to happen overnight.

2) All of the Forge devs understand that it's a major task, especially considering the historical track-record of other first time developers.

3) We can really use extra hands developing, so we want to make sure if you are interested in developing it stays somewhere close at hand, so we can provide tips, concerns, and feedback.

uhlersoth, hopefully you'll forgive the awkwardness it took to get to this resolution.

[Chris H.]

It think that we are in agreement here. Several of us have the ability to give you commit privs to our SVN if you would like that ability. Working in a branch initially may prove to be beneficial to all of us.

It generally proves to be far easier for the person who would like to see a code change to ask for commit privs and to then make the changes himself. In the past a few of us have tried to add in other people's work to the SVN and this tends to be time consuming and can be difficult to accomplish.

At first this idea of a lobby can be simple, and at some point later on we would probably like to see this use the same interface elements that are used elsewhere in the project.

And I too hope that you do not take our efforts to communicate as personal assault on you and your efforts. None was intended.

[Max mtg]

Apparently, uhlersoth's enthisuam has gone somewhere... as well as he has.

I'd like to see multiplayer implemented anyway, so shall we discuss the roadmap to it?
I see the steps like this:

0. Lobby - other players may connect to Forge application acting as server to chat, select deck and confirm they are ready for the match.
1. Match (1) - connected players have to be able to spectate the match, that is read the log and recieve active phase and turn info, battlefield state updates, changes of player lives and counters.
2. Match (2) - connected player should appear as a player in a match, it will be enough if he is able to confirm play/draw question, mulligan and at point at cards he wants to play.
3. Match (3) - player is able to chose targets and pay all kinds of costs.
4+ Playes has to be able to repsond to various requests for extra data made by ability effect executors.

What do you think?

[friarsol]

Looks about right to me.

Have players in a game have been isolated enough where hot seat is basically doable? I would think that might be a prerequisite (ignoring the fact that you'd be able to see your Opponents hand etc)

[Diogenes]

Hey guys, I know I've made some loopy posts the last week (which has been particularly sleep-free for various reasons) and I'm not a programmer, but I just have a couple quick questions about multiplayer:

If there is still the intention to implement game states, wouldn't it be better to focus on that first? On the one hand it seems like it would make multiplayer more robust, and on the other I'd imagine you'd have to redo a lot of the multiplayer implementation anyway to accomodate for game states if they're added at a later time. In the meanwhile, game states are a major target for improving the single player.

Second, as a user I can wait for multiplayer for a long time. Seeing as another fan game has had troubles recently over this issue (for other reasons than just existing, granted,) might it be better to wait until all that blows over?

[Max mtg]

@Sol, I cannot evaluate codebase's hotseat readiness. Yet, I don't consider it a prerequisite for multiplayer. Remote player is going to be third type of player with its own ways to pay costs and select abilities to play.

Look, multiplayer is about adding a player of third type with its new method of interaction with game over network. Meanwhile hotseat is about Forge being able to select which player is controlled now by input received from swing.
These look like different kinds of tasks to me. To make it clear, I won't pursue aims on hotseat development, and don't plan to use forge app in remote client mode. The first client is going to be an HTML5-powered web application... a plain console for the first few weeks - at that time the protocol to be set up and tested is the main purpose. And then we'll see which kind of client is worth developing and re-evaluate further plans.

@Diogenes, I am sorry, but looks like I've missed that posts about states and counldn't find them now via forum search. What is the idea here?
Anyway, full game state MUST NOT be serialized and transferred to clients.

[Diogenes]

@Diogenes, I am sorry, but looks like I've missed that posts about states and counldn't find them now via forum search. What is the idea here?

Hey Max. Sorry for the confusion, I may have made several assumptions that weren't correct or even obvious in my previous post. I'll try to explain what I was trying to say.

It's my understanding that currently Forge doesn't keep any kind of history of game states during the course of play, nor can it easily save and load them, and that this is the primary reason why a minimax style AI opponent can't be implemented (along with any kind of undo functionality beyond mana cost payments.) I was assuming (perhaps incorrectly) that if this type of feature were present in Forge, multiplayer would be designed around the players' clients passing around game states (at least occasionally) rather than sending raw player input from client to client (which wouldn't have a way necessarily to check if the players somehow desynchronized, presumably from bugs in code,) or running off a server (which requires one client to act as a server, not always preferable in a multiple-opponent game, or that all players connect to a dedicated server, something I dislike in general.)

Again, I'm making assumptions, but intuitively it seems easier to me for the application to handle all payments, targeting, and interactions (etc.) locally, then send out a log of the local player's actions culminating in the game state when they pass priority to all opponents (obviously passing priority without doing anything wouldn't require a snapshot.) Each client would simply replay other players' actions rather than execute them, so spectating would be relatively foolproof (one could even start mid-match.) I might be incorrect that this method is preferable, and I see that it might be grossly inefficient (although compared to streaming video or the amount of data transferred for an fps, it might still be a negligible bump.)

If the above is accurate, my thinking was that implementing game states first would simultaneously enable work on some kind of pruning AI (improving single player) and prevent extra work later in upgrading the multiplayer code after game state support is added. Plus it might push multiplayer back a bit, which I don't feel is a bad thing at the moment.

Edit:

Anyway, full game state MUST NOT be serialized and transferred to clients.

Did you just add this line? I totally missed it when I was typing the above. Since I have no idea why this is the case, I realize that I'm way out of my depth here. Out of curiosity, why not?