The program will instead allow you to play a game of Connect Four via a network, by connecting to a server that I've provided. Your program always acts as a client.
When this program starts, the user will need to specify the host (either an IP address, such as 192.168.1.101, or a hostname) where a Connect Four server is running, along with the port on which that server is listening.
Additionally, the user should be asked to specify a username. The username can be anything the user would like, except it cannot contain whitespace characters (e.g., spaces or tabs). So, for example, boo or HappyTonight are legitimate usernames, but Hello There is not.
Once the user has specified where to connect, the program should attempt to connect to the server. If the connection is unsuccessful, print an error message specifying why and end the program. If, on the other hand, the connection is successful, the game should proceed, with the client acting as the red player (and moving first) and the server — which acts as an artificial intelligence — acting as the yellow player. For red player moves, the user should specify the move at the console, as in your first program; for yellow player moves, the program should instead wait for input via the socket. The game proceeds, one move at a time, until the game ends, at which point the program ends. I32CFSP conversations are relatively simple: they are predominantly centered around sending moves back and forth, with the assumption being that both conversants will be able to determine the game's state simply by applying these moves locally; for this reason, the game's state is not transmitted between conversants.
I32CFSP conversations are between two participants, which we'll call the server and the client. The server is the participant that listens for and accepts the conversation; the client is the participant that initiates it. (You'll be implementing the client in this project; I've already implemented the server.) The client is always the red player and the server is always the yellow player; this means that the client always moves first.
Because one of the goals of this project is to explore writing programs consisting of multiple Python modules, you will be required to separate this program into at least the following five modules:
The provided connectfour.py module is one of the four; it implements the underlying game logic, but performs no interaction with a user and does nothing with sockets or network communication. You should be able to use this as-is, with no modifications to what's been provided.
One module that implements the I32CFSP and all socket handling. If you're going to connect, read, write, etc., via a socket, you would do that in functions written in this module.
One module that implements the console-only user interface and one of the two programs' entry points (i.e., it's got an if __name__ == '__main__': block at the bottom, and is the one you would execute in order to run the console-only version of the game.
One module that implements the user interface for the networked version of the game that plays against an artificial intelligence. It, too, will need an if __name__ == '__main__': block at the bottom, and would be the one you would execute in order to run the networked version of the game.
One module that consists of the functions that are the same in both user interfaces. Examples would include a function that prints the current game board to the console and a function that asks the user what move he or she would like to make next.