I want to make a multiplayer game. In my testing, I have realized that my server/host side of the code requires an infinite loop to run. In this infinite loop, the host code waits for a connection on the TCP WiFi socket, then processes the connection. once the connection closes, it returns to the waiting portion. I want the code to start the app, then start the hosting process. The hosting process would then call events in the game. I have successfully tested the hosting code as part of a Python webserver, but I need help tying it into Panda.
Perhaps taskMgr will run it in the background?
Idea. I am posting here both to remind myself for tomorrow and for any critique from the community.
Launch and bind the socket when the player starts the game. Call conn.recv(1024) every frame, so that anything which has been sent by the user who joined will be updated into the main game. Possible faults: may hang up waiting for connection input. Possible pros: may force all players on a server to the same frame rate, ensuring good synchronization.
You have several options:
- Instead of a while loop, put the contents of the while loop in a task. Panda will then run it every frame.
- Put your while loop in a coroutine. You then have to use an API for receiving data from the socket that works in an asynchronous manner, using
await. Then, Panda will run other tasks while it is waiting for data.
- Put your while loop in a thread. This requires you to implement inter-thread synchronization/communication, which is not trivial.
The first option, refactoring your code to use a task instead, will likely be the easiest to implement.
Thank you rdb. I may have a way to implement your first suggestion. I will at least try, anyway. By using conn.settimeout(float), I can ensure that the host side never hangs up for more than a certain amount of time. I will try to keep that at 1/30th of a second or lower. If the host side somehow hangs up and the guest gets a few frames ahead (it will also be using the same timeout) and sends multiple packets, then when the host side uses conn.recv(1024), it will read multiple packets in the same bytestring. Therefore my packets must be timestamped so that the host/guests can keep up with each other. The worst that should happen is that the other players will ‘jump ahead’ a few meters every now and then.