Max mtg wrote:@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:
Max mtg wrote: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?