Network Multiplayer (Multi-human players)
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Network Multiplayer (Multi-human players)
by Max mtg » 31 Mar 2013, 13:08
Do 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?
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Network Multiplayer (Multi-human players)
by Max mtg » 14 Apr 2013, 11:56
Let us discuss the network interaction architecture.
I have commited the initial framework, so you may have a look at the code. Here is what it is supposed to do:
Clients use websockets protocol to connect to the server. A prototype web-based client can be found in src\main\html - is that a correct path for html sources?
The forge application itself cannot connect to another application and I don't plan to develop that kind of interaction in the nearest future. If anyone feels confident about this area, feel free to start working in that field.
Server starts listening on a port 81 now. Port 80 can be used as well, in that case forge might serve the client files via common http protocol and have a dedicated url where the client would connect with a socket).
Client sends to server some strings with commands from a console for now (that is to be replaced by an UI to compose and send that strings under the hood). A common rule is that a command starts with slash (/) - like in some mmo games or IRC, while other strings are treated as chat messages.
Server recieves the string and parses it in forge.net.protocol.incoming.PacketOpcode.decode(String) So that each meaningful message becomes an IPacket implementing class. These packets are processed by ClientState classes that will react to packets valid during the current player state. ClientStates are kept in a stack and process packets in a chain. If the topmost state does not process the packet, the next item in stack tries to do so.
ClientStates may be thought of as analogues of Input classes - both deal with player input and either change game state or just set up parameters for ingame actions.
All messages to be sent in response implement interface IMessage that defines a single serialization method. It's now client's problem to decode them.
Since client has little code and does not have to parse the messages it receives, the serialized messages don't have any defined structure now.
What do you think of all of this?
Please look through classes in forge.net package and leave comments and ask questions.
I have commited the initial framework, so you may have a look at the code. Here is what it is supposed to do:
Clients use websockets protocol to connect to the server. A prototype web-based client can be found in src\main\html - is that a correct path for html sources?
The forge application itself cannot connect to another application and I don't plan to develop that kind of interaction in the nearest future. If anyone feels confident about this area, feel free to start working in that field.
Server starts listening on a port 81 now. Port 80 can be used as well, in that case forge might serve the client files via common http protocol and have a dedicated url where the client would connect with a socket).
Client sends to server some strings with commands from a console for now (that is to be replaced by an UI to compose and send that strings under the hood). A common rule is that a command starts with slash (/) - like in some mmo games or IRC, while other strings are treated as chat messages.
Server recieves the string and parses it in forge.net.protocol.incoming.PacketOpcode.decode(String) So that each meaningful message becomes an IPacket implementing class. These packets are processed by ClientState classes that will react to packets valid during the current player state. ClientStates are kept in a stack and process packets in a chain. If the topmost state does not process the packet, the next item in stack tries to do so.
ClientStates may be thought of as analogues of Input classes - both deal with player input and either change game state or just set up parameters for ingame actions.
All messages to be sent in response implement interface IMessage that defines a single serialization method. It's now client's problem to decode them.
Since client has little code and does not have to parse the messages it receives, the serialized messages don't have any defined structure now.
What do you think of all of this?
Please look through classes in forge.net package and leave comments and ask questions.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Network Multiplayer (Multi-human players)
by friarsol » 14 Apr 2013, 15:23
Will the Client/HTML side of things just open up this websocket and hold it open for the remainder of the time then? I guess it really wouldn't work otherwise, since the Client isn't really doing any work, it would have a list of actions that it's able to take at each state.
I'd imagine running over port 80 may be preferable to evade firewalls that block ports. But I know that is a minor one character change, if it seems important enough to switch to that.
So no major comments from me for now.
I'd imagine running over port 80 may be preferable to evade firewalls that block ports. But I know that is a minor one character change, if it seems important enough to switch to that.
So no major comments from me for now.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Network Multiplayer (Multi-human players)
by Max mtg » 14 Apr 2013, 16:12
yes, there is no processing supposed on client side. Server has all the hidden information and enforces the game rules. Clients' role is: to requests current state of game and transfer players' decisions - clients will also have to draw all that cards, counters, etc.
Server port number has to be moved to preferences sometime.
Server port number has to be moved to preferences sometime.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Network Multiplayer (Multi-human players)
by Diogenes » 14 Apr 2013, 18:04
Hi Max! I actually intended to reply to your previous post much sooner, but real life. Thank you for taking the time to provide a detailed explanation, I understand your concerns and goals better now. I can't really discuss the technical aspects, but I have a few thoughts and questions as a user.
Being able to directly connect to an acquaintance from my local copy of Forge, without relying on a third-party server, is currently what interests me most in network play. While I guess that it will always be possible for an end user to simply set up their own server and join it (one way or another, it's open source after all,) this is not my preferred model. I expected that cheating would be one of your primary concerns for choosing a strict server/client model. I really don't have any concern that my intended play partners might compile hacky versions of Forge with which to cheat. Ideally, I'd like just to type in a friend's IP and play, privately, without depending on a server being live or becoming visible in a public list of lobbies. Would you consider a peer-based connection, in addition to a server-based model?
I'm also curious about what this would mean for a customized portable installation. Would connecting to a server mean automatically updating to the latest version?
We were discussing whether network play would affect the future AI, and this is where we left it:
Anyway, I'm not concerned so much with the technical requirements of this particular method (I can't code it.) To be honest, I'm just worried that the glamour of multiplayer will eclipse single player considerations for a time. I hope that whatever happens doesn't complicate the current solo experience (like in some first person shooters where to play offline you need to create a lobby and manually populate it with bots,) and won't potentially impede the future improvement of the AI.
Anyway, it is *awesome* to see this moving forward. Thanks guys!
Being able to directly connect to an acquaintance from my local copy of Forge, without relying on a third-party server, is currently what interests me most in network play. While I guess that it will always be possible for an end user to simply set up their own server and join it (one way or another, it's open source after all,) this is not my preferred model. I expected that cheating would be one of your primary concerns for choosing a strict server/client model. I really don't have any concern that my intended play partners might compile hacky versions of Forge with which to cheat. Ideally, I'd like just to type in a friend's IP and play, privately, without depending on a server being live or becoming visible in a public list of lobbies. Would you consider a peer-based connection, in addition to a server-based model?
I'm also curious about what this would mean for a customized portable installation. Would connecting to a server mean automatically updating to the latest version?
We were discussing whether network play would affect the future AI, and this is where we left it:
Max mtg wrote:Do 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.
That said, AI has to build possible future game states "on it's own side" without interfering with the actual game state.
A minimax AI creates a tree of all possible actions it can take, and prunes out branches as they under-perform in certain criteria relative to other branches (losing materiel, life, whatever you want to use to evaluate player advantage.) It consequently goes deeper on the lines of play that appear to be the most advantageous, and plays the highest scoring sequence of moves it has found by the end of its analysis. If anything, I think a minimax-style AI would help to divorce card and rules functionality from a presumed AI opponent. As long as it knows all the buttons it can push, can track the relevant info of the game state, and has decent criteria with which to judge what is good for it, it can prune its way to smart plays, no hard-coding required. For increased difficulty, however, it helps if the AI is able to cheat by viewing private information (considering how many more possible branches it would have to generate for every possible hand an opponent could have from the pool of unrevealed cards,) so to be optimally efficient it has to be something more than just another client as far as the game is concerned.Max mtg wrote:I consider it impreferable to modify core components for an AI that cannot act as a separate remote client.
Anyway, I'm not concerned so much with the technical requirements of this particular method (I can't code it.) To be honest, I'm just worried that the glamour of multiplayer will eclipse single player considerations for a time. I hope that whatever happens doesn't complicate the current solo experience (like in some first person shooters where to play offline you need to create a lobby and manually populate it with bots,) and won't potentially impede the future improvement of the AI.
Anyway, it is *awesome* to see this moving forward. Thanks guys!
Re: Network Multiplayer (Multi-human players)
by Max mtg » 14 Apr 2013, 19:53
Diogenes, yes. Peer-to-peer is possible: one person starts forge app, launches a server, tells his IP to friends and they join a private server he has started. And noone else knows that such a server exists. I don't percieve the difference between peer-to-peer and server-based model at this scale.
Ok, looks like minmax ai and multiplayer implementation have nothing in common. In my mind remote player is just another type of player, it can play and win independently from ai.
Speaking of solo play, looks like the team is focused on implementing 100% of the cardpool. We've hit 95% milestone recently and under 640 cards remain to script.
I don't know who and when is going to work on AI improvement.
Ok, looks like minmax ai and multiplayer implementation have nothing in common. In my mind remote player is just another type of player, it can play and win independently from ai.
Speaking of solo play, looks like the team is focused on implementing 100% of the cardpool. We've hit 95% milestone recently and under 640 cards remain to script.
I don't know who and when is going to work on AI improvement.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Network Multiplayer (Multi-human players)
by silly freak » 15 Apr 2013, 15:08
Hi! Your approach looks great, Max; I hope you can bring it through. May I suggest something for network communication?
I have recently found Protobuf, a Google protocol library that takes message definitions and generates (de)serialization code on multiple platforms. There is a third-party plugin for JavaScript, so that might come in handy for your HTML5 client; platform independence would also help for the possible eventual definition of a universal AI that can play multiple games.
Just some thoughts; I though when you're developing a protocol from scratch anyway, this could make your task easier.
I have recently found Protobuf, a Google protocol library that takes message definitions and generates (de)serialization code on multiple platforms. There is a third-party plugin for JavaScript, so that might come in handy for your HTML5 client; platform independence would also help for the possible eventual definition of a universal AI that can play multiple games.
Just some thoughts; I though when you're developing a protocol from scratch anyway, this could make your task easier.
___
where's the "trust me, that will work!" switch for the compiler?
Laterna Magica - blog, forum, project, 2010/09/06 release!
where's the "trust me, that will work!" switch for the compiler?
Laterna Magica - blog, forum, project, 2010/09/06 release!
- silly freak
- DEVELOPER
- Posts: 598
- Joined: 26 Mar 2009, 07:18
- Location: Vienna, Austria
- Has thanked: 93 times
- Been thanked: 25 times
Re: Network Multiplayer (Multi-human players)
by Max mtg » 17 Apr 2013, 13:30
Chat is already working! (not a big achievement but anyway!)
As you start a server, an overlay console shows up, where you can see and type messages for other players.
Remote clients have to authorize on server, that is send '/auth username' command from chat console. Soon a message will appear that a new player has joined the server and he'll be able to read and write messages.
I am also too excited about all of this, so I could take some strange design decisions. If you have noticed something to improve, leave me a note.
@silly freak, I am not sure about Protobuf. Binary serialization is not needed here (I could not make web sockets send binary data from browser side), meanwhile human readability of messages that is currently supported is handy.
As you start a server, an overlay console shows up, where you can see and type messages for other players.
Remote clients have to authorize on server, that is send '/auth username' command from chat console. Soon a message will appear that a new player has joined the server and he'll be able to read and write messages.
I am also too excited about all of this, so I could take some strange design decisions. If you have noticed something to improve, leave me a note.
@silly freak, I am not sure about Protobuf. Binary serialization is not needed here (I could not make web sockets send binary data from browser side), meanwhile human readability of messages that is currently supported is handy.
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Network Multiplayer (Multi-human players)
by Chris H. » 17 Apr 2013, 15:12
Description: I launched Forge on my iMac and then clicked on the Start Server button in the home view as I was curious and I wanted to see some of the new work that Max has accomplished.
- SocketException | Open
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Network Multiplayer (Multi-human players)
by Max mtg » 17 Apr 2013, 15:32
Chris, thank you for lending your time to test this feature!
The results are interesting... May I ask you to perform some tests?
First of all, use build 21055 or newer, because in today's snapshot chat is not working yet.
The internets say that high priveleges are needed to start listening to commonly used ports, like 80, 443 or 3128. So I wonder, will it work if you run Forge as root? Another question I am pondering at - will it work with just a random port, say any number between 2000 and 32000? - Port number is hardcoded in FControl, line 325
The results are interesting... May I ask you to perform some tests?
First of all, use build 21055 or newer, because in today's snapshot chat is not working yet.
The internets say that high priveleges are needed to start listening to commonly used ports, like 80, 443 or 3128. So I wonder, will it work if you run Forge as root? Another question I am pondering at - will it work with just a random port, say any number between 2000 and 32000? - Port number is hardcoded in FControl, line 325
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Network Multiplayer (Multi-human players)
by Chris H. » 17 Apr 2013, 16:24
OK, I did a google search and I discovered that the "The root user in Mac OS X is disabled by default.".
A google search for SocketException Permission Denied In Mac OS X came up with this link
http://augustli.wordpress.com/2010/08/07/socketexception-permission-denied-in-mac-os-x/
Looks like we need to set the port to 1024 or higher. I did this and ran forge and was able to start the server without the crash report.
A google search for SocketException Permission Denied In Mac OS X came up with this link
http://augustli.wordpress.com/2010/08/07/socketexception-permission-denied-in-mac-os-x/
Looks like we need to set the port to 1024 or higher. I did this and ran forge and was able to start the server without the crash report.
-
Chris H. - Forge Moderator
- Posts: 6320
- Joined: 04 Nov 2008, 12:11
- Location: Mac OS X Yosemite
- Has thanked: 644 times
- Been thanked: 643 times
Re: Network Multiplayer (Multi-human players)
by moomarc » 18 Apr 2013, 18:01
Just did a mini test myself and one suggestion is that the console should be draggable. At the moment on narrow screens it can cover the start button. Otherwise it's looking good. 
-Marc
-
moomarc - Pixel Commander
- Posts: 2091
- Joined: 04 Jun 2010, 15:22
- Location: Johannesburg, South Africa
- Has thanked: 371 times
- Been thanked: 372 times
Re: Network Multiplayer (Multi-human players)
by silly freak » 18 Apr 2013, 19:10
Actually, there is an alternative text encoding if that's the only problem you see. I'd think that the JavaScript backend would be able to also use the binary protocol, but that's just a guess. Anyway, I just though that a protocol that handles structured data might be useful sooner or later, but I have no clue in what direction you're headed, so you will be able to make the better decision!Max mtg wrote:@silly freak, I am not sure about Protobuf. Binary serialization is not needed here (I could not make web sockets send binary data from browser side), meanwhile human readability of messages that is currently supported is handy.
___
where's the "trust me, that will work!" switch for the compiler?
Laterna Magica - blog, forum, project, 2010/09/06 release!
where's the "trust me, that will work!" switch for the compiler?
Laterna Magica - blog, forum, project, 2010/09/06 release!
- silly freak
- DEVELOPER
- Posts: 598
- Joined: 26 Mar 2009, 07:18
- Location: Vienna, Austria
- Has thanked: 93 times
- Been thanked: 25 times
Re: Network Multiplayer (Multi-human players)
by Max mtg » 21 Apr 2013, 11:35
What you were definetelly right about is that the serialization I used certainly wouldn't work in any larger scale. Thank you for hints. It takes me a few days sometimes to fullysilly freak wrote:Actually, there is an alternative text encoding if that's the only problem you see. I'd think that the JavaScript backend would be able to also use the binary protocol, but that's just a guess. Anyway, I just though that a protocol that handles structured data might be useful sooner or later, but I have no clue in what direction you're headed, so you will be able to make the better decision!
I've found an alternative way to serialize data, it's named gSon - a json library from Google. A web client should be more that happy with that: it has to cut the header of a packet that reflects message type and feed the rest to javascript eval() method.
Thinkning of other ways to serialize data, I added an oportunity to use different protocols for any other clients that may be developed. Hope the sub system architecture is cleaner now.
It's time to add features like game creation to both server and client, and draft some interface on client side, since typying /auth {name:"Max"} became too complicated to do it manually
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Re: Network Multiplayer (Multi-human players)
by Max mtg » 21 Apr 2013, 22:35
Server port is now configurable via config file (r21115)
The current web client is definitelly just a test unit. I wanted to make a login window in that web page, soon understood that a framework to handle all these windows and panels to be added would be very handy. Started exploring what Sencha Touch has to offer. Set up a webserver on my PC and tried to explore examples from a Nexus 7.
Got disappointed after launching the example broswer in Android Chrome in landscape mode. Browser's header and tabs take about 20% of vertical space, that would be still available to a native app.
The current web client is definitelly just a test unit. I wanted to make a login window in that web page, soon understood that a framework to handle all these windows and panels to be added would be very handy. Started exploring what Sencha Touch has to offer. Set up a webserver on my PC and tried to explore examples from a Nexus 7.
Got disappointed after launching the example broswer in Android Chrome in landscape mode. Browser's header and tabs take about 20% of vertical space, that would be still available to a native app.
- Attachments
-
- nexus 7 screenshot
Single class for single responsibility.
- Max mtg
- Programmer
- Posts: 1997
- Joined: 02 Jul 2011, 14:26
- Has thanked: 173 times
- Been thanked: 334 times
Who is online
Users browsing this forum: No registered users and 38 guests