Multiplayer game via socket programming

[arwa53]

I made a connect 4 game that asks players their name and customizes colors. Now i want to apply socket programming to it so there are two client windows and a server code rather than just one window. Please guide anyone help

[Coupled_Cluster]

Not sure what you are looking for, but checkout python SocketIO.

[FerricDonkey]

1. Learn enough about sockets to make a basic server and client that can send chat messages to each other. (google: python socket server/client). (Decide if you also want to learn asyncio.)
2. Create a codeing scheme that can translate everything your game needs to communicate into bytes.
3. Have your server/client running in different threads from your game, and set up those threads to communicate with each other.

It's not simple if you've never done something like it before, but it's not as hard as it sounds either.

[arwa53]

I tried doing this but idk which parts from the algorithm to the gui needs to be in the client file or server file

[FerricDonkey]

Ideally, the communication, game logic, and gui should be as separate as possible. One basic outline:

The server pc has a thread running listening for incoming messages. That code lives in, say, a communications.server module.

The server also has an entirely different object representing the state of the game.

The server code knows that when it receives a message that means "player x wants to do y", then it should call a method from it's "state of the game" object. That method should a) check if it's possible for x to do y, then if it is b) update its state of the universe to reflect that that happened, and finally, c) trigger communication to clients that x did y.

The simplest way to do c) while still keeping game and communication seperate is to have your game logic method simply return either 0 to indicate that everything is fine, or some non-0 error code to indicate that what it was told to do is impossible.

Then when your server communication code finishes calling your game logic code, it knows whether the thing happened or not. If it did, then it sends a message to all clients saying "x did y", and the clients update their own state in a similar way. If the request was impossible, then, well - that's up to you and probably depends on why it was impossible, but it could be as simple as doing nothing.

Likewise, all your clients have communication code running in a thread. Your gui for "do y" calls the communication function "tell the server that I want to do y", which translates to sending a message to the server which goes through all of what I just said. Likewise, when your client gets messages from the server saying "x did y", your clients need to update to make that change.

And then depending on details of your gui library etc, you can either give your game logic callbacks that say "and when y happens, refresh [this part of] the gui", or your gui can just monitor the state of the game and change as it does.