We divided up the workload and I’ve been given the back-end server. After discussion a lot on how we want to design the game, we decided that the easiest way would be for the game to be run on each client machine, and the server acts as just a messenger for sending moves from one client to the other to update their state. This simplifies the server by only dealing with encoding/decoding strings, but potentially opens up a lot of problems, such as game state desync, enabling player disconnect/reconnect to the same game, and more. Of course, this makes my job easier, and I can start building the pieces that connect the server to the client connection, and then to the Pygame UI that Tamana is working on. But the more I think about the communication, the more I need to discuss the exact message strings that can convey the various states of the connection and game so that each client can have some knowledge of what is happening with the game. I’m starting to learn why it’s so important to plan beforehand and why positions such as lead and architect are so important. I can’t help but worry that because we don’t have a clear idea on the exact data that will enable each component to integrate, it’s going to cost us a lot of time to go back and homogenize the various inputs/outputs and functino parameters.