Re: python socket server allow multiple clients to connect
@25's answer is a good one, but it's worth pointing out that you still have to handle timing, and that the reason this thread isn't just giving out answers is because even a basic "I can walk around" thing is going to probably be around 100 lines.
In particular if you have blocking I/O that won't work because you can only handle one client at a time, if you have threads you need to understand all the concerns threads bring to the table, and if you go select you need to understand what select is. In practice you probably want some sort of abstraction on top of these things, but you can't use any of them without understanding the fundamentals underneath at least a little.
Plus that sort of lock-step model falls down unless it's a game played only between a few people since the speed of the game is limited to the slowest client. SoundRTS does something like it but SoundRTS only has a few people and doesn't need to tick 10-20 times a second.
There is no easy answer to any of this. I get that it feels like there should be, but writing a networked game is at least twice as hard as writing a normal game. It's not just here's 20 lines of code and now you have a server. It literally changes the entire way you write the game in every single way. For example, all of the following can't be done or are terrible ideas:
use of time.sleep. Can't be done because it'll block the network. Better get comfortable with ticking and not using timers at all.
Sending keys back and forth directly. Can be done but prevents the client from hiding network lag.
Sending a request to the server for movement, and waiting on the response to move. Will block the client for a second or more.
Trusting that the client is telling you the truth. You have to check everything in some way or players can cheat.
In Python, using pickle. This is a great way to build a virus because it executes code.
Writing any part of your game in such a fashion that it's going to freeze things even for a little while. For example pathfinding will need to be able to be split across multiple game ticks.
Assuming that network packets will arrive around the same time. For example if you send out a tick packet 10 times a second you can go a whole second without the client getting one, and then it will get 10 all at once. This sounds like a rare circumstance. It's not. All you have to do for it is be on wi-fi and turn on the microwave to reheat lunch, in some cases.
All of the following are inaccurate assumptions: Assuming that the connection is stable. Assuming that the connection is high bandwidth. Assuming that packets don't literally cost someone money because their internet plan is metered. In some cases assuming that the player will keep their same IP for the duration of the game being played (a common concern for mobile).
If someone finds packets that can crash the server they will use them for fun. If someone hates you they will denial of service the server. It is possible to write a basic denial of service attack in 20 minutes with Python and there's another 2 or 3 right behind that that are also easy to write in 20 minutes. You'd better know how to defend against all of these.
You can use podsixnet or pyenet if you want something that looks a little bit like BGT. But the thing is that this thread is hoping to get one of us to take what is literally an entire book of content, and genuinely a topic that is as hard as learning to program in the first place, and turn it into a few paragraphs. It can't be done. There is no short answer. There's no short answer for BGT, or PureBasic, or Python, or any of them. It doesn't matter what you use, the answer won't become any shorter. You need to go find resources on networking fundamentals and read them and understand the parts underneath, then spend some time finding every game networking resource you can get your hands on. That's the genuine answer to this question. I know that multiplayer is the audiogames.net holy grail of game development, but the people who are doing it got there either through massive amounts of persistence or by putting the time in to understand a bunch of complicated concepts, not by starting a thread like this one and continually demanding an example program. Some things are just not going to fit in an audiogames.net forum thread. Sorry.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
