Re: Network Multiplayer (Multi-human players)
Posted: 31 Mar 2013, 13:08Do you mean to say that minimax AI has to simulate and evaluate the next possible states of game? I don't know how this AI is supposed to work, but I am pretty sure that even the current AI has already been tied too closely with game code. So that now we have to put considerable efforts to separate them.Diogenes wrote: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.)
That said, AI has to build possible future game states "on it's own side" without interfering with the actual game state.
No client can be trusted, that is why it shall be allowed to pass only commands directly to server that is going to check every action for legality. Client is considered to be in enemy's hands, so it must not learn any hidden data or be able to perform illegal game state changes. That is why I object against game state being sent there and back again.
On the other side, each remote player should be able to obtain current game state to show it to whoever controls the client (it could be an AI as well) That is why clients are going to recieve the game state, that includes only information they are allowed to posess. Players will know their hands, cards they exiled face-down and all the public data which is avaliable to spectators - battlefield, counters, lives, number of cards in all zones.
For the nearest future Forge app is expected to act as a server with an always-connected local GUI player. As soon as we learn how to to start a match without a local human player, there will be dedicated servers.
That approach will have all clients run the same code as server does. That would mean no mobile or web clients.Diogenes wrote: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.)
I consider it impreferable to modify core components for an AI that cannot act as a separate remote client.Diogenes wrote: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.
Yes, trying to imagine what you meant by game states.Diogenes wrote: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?
