I need to do some basic networking for a Pygame project.
Basically, it's a 2D single player or cooperative game. The networking only needs to support two players, with one as a host.
The only information that needs to be sent is the positions of players, creeps and bullets.
I've been reading around and Twisted keeps coming up, but I haven't done networking before, and I'm not sure if that might be an overkill.
So, is it possible for a relative newbie to implement networking in Pygame?
This was asked recently on Reddit, so I'll more or less just copy my answer over from there. I apologize for not being able to provide more links, I have <10 rep so I can only post two at a time.
Twisted might work, but I don't have a whole lot of experience with it. I'd recommend going with sockets, as that's what Twisted uses in the background anyway. Beej's guide (google it) is pretty much the Holy Bible of sockets if you want to learn how they work (in C++, but the concepts extend everywhere). Python does abstract some of the complexity away, but it's still a good idea to know what's going on in the background.
For Python specific sockets, you can go ahead and just use the howto (user745294 posted a link above). Here's a nice article titled "What every programmer needs to know about Game Networking". It goes into the different types of major networking styles (client-server, p2p, udp v. tcp, etc.) and the history behind what some major games used for their networking.
Below is a link to a demo I did on making a networked "game" in Python 2.6/Pygame. It's not actually a game, but each client you create connects to the server and controls a character. You can move your character with the arrow keys and the character will move on all connected clients. I tried commenting the source code with some indication of what I'm sending back and forth, but you may need a little knowledge about sockets to understand it.
The source code is provided in the codepad links in the comment below this post. You will need to provide two images in the same directory as the scripts:
bg.png is the background sprite. It should be an image 400px wide and 300px tall (this can be changed in the GameClient class if needed)
sprite.png is the player character. It should be smaller than the background so that you can see it moving around.
You can use Twisted for networking with Pygame. The "game" project on Launchpad has some examples of how one might integrate the main loops together; basically, use twisted.internet.task.LoopingCall to draw Pygame frames and handle input, while letting the Twisted reactor of your choice run normally.
Since you are already using Pygame, I think this light networking library made for Pygame will do what you need and teach you, but not overwhelm you.
"Mastermind Networking Lib" via pygame.org
There is Pyro (Python remote objects) as another solution for networking in Python.
http://irmen.home.xs4all.nl/pyro/
Using raw sockets is low-level and full of danger. As said before, Twisted is complex and takes to time get up and running. To save yourself some headaches I'd try something like zerorpc.
You need the following solutions:
discovering other player(s) on the (local) network, you don't want player to enter some IP address
handle network errors
serialize messages containing your data (positions, player name, etc.)
handle threading as networking is asynchronous I/O
Above should still be called 'basic', you should really use some fancy networking library with idiomatic API.
Essentially you need to expose the network service (in its own thread) that will push messages to Python's Queue, and then access this same queue from your Pygame code, and if there is a message then you update whatever structures you use to store player's position and draw it on screen.
You shouldn't send stuff like bullet positions over the network as they can be easily (and faster) calculated locally. You just send an event like bullet_shot over the network with a source position and velocity vector.
Related
So I am currently developing a custom dedicated server in UE4 from scratch. I use RakNet as a networking engine and want to achieve the typical dedicated server that can manage adding players to the world, hitboxes, collision and verifying packets in general. What I mean by verifying here is e.g. if the server receives a movement packet it can decide whether the packet's sender can move there or not. I see the biggest trouble in verifying the e.g. movement packets and hitboxes because the server has to have access to the world and collision methods of unreal which I don't know how to do from scratch. Is it possible to get the base server from UE4 and equip it with your own networking engine and packet handling? Or is there a better way to achieve my goal?
AFAIK there is no out of the box solution for that. You need something custom. I can think of 3 solutions:
Just ignore collisions. Replicate what you get from clients, and that's it. Of course this is a cheap, low effort solution prone to hacking, but maybe it's sufficient for your case ?
Write custom collision handling on your server. This is a lot of work. Server would need to know all the colliders positions, dimensions, etc. You could then use a physics library ( i.e. Bullet Physics ) to check collisions or write a custom collision checks.
Compile UE4 as a dedicated server. You can find more info here:
https://wiki.unrealengine.com/Dedicated_Server_Guide_(Windows_%26_Linux)
Just use Raknet instead of a native UE4 networking.
PS. UE4 source code is over 2 milion lines of sophisticated C++ code so telling someone to "just download the source code and change anything you like" is not a viable advice.
PS.PS. I'm not sure if RakNet is a good choice at the present moment, this project was not updated since 5 years.
I need to do some basic networking for a Pygame project.
Basically, it's a 2D single player or cooperative game. The networking only needs to support two players, with one as a host.
The only information that needs to be sent is the positions of players, creeps and bullets.
I've been reading around and Twisted keeps coming up, but I haven't done networking before, and I'm not sure if that might be an overkill.
So, is it possible for a relative newbie to implement networking in Pygame?
This was asked recently on Reddit, so I'll more or less just copy my answer over from there. I apologize for not being able to provide more links, I have <10 rep so I can only post two at a time.
Twisted might work, but I don't have a whole lot of experience with it. I'd recommend going with sockets, as that's what Twisted uses in the background anyway. Beej's guide (google it) is pretty much the Holy Bible of sockets if you want to learn how they work (in C++, but the concepts extend everywhere). Python does abstract some of the complexity away, but it's still a good idea to know what's going on in the background.
For Python specific sockets, you can go ahead and just use the howto (user745294 posted a link above). Here's a nice article titled "What every programmer needs to know about Game Networking". It goes into the different types of major networking styles (client-server, p2p, udp v. tcp, etc.) and the history behind what some major games used for their networking.
Below is a link to a demo I did on making a networked "game" in Python 2.6/Pygame. It's not actually a game, but each client you create connects to the server and controls a character. You can move your character with the arrow keys and the character will move on all connected clients. I tried commenting the source code with some indication of what I'm sending back and forth, but you may need a little knowledge about sockets to understand it.
The source code is provided in the codepad links in the comment below this post. You will need to provide two images in the same directory as the scripts:
bg.png is the background sprite. It should be an image 400px wide and 300px tall (this can be changed in the GameClient class if needed)
sprite.png is the player character. It should be smaller than the background so that you can see it moving around.
You can use Twisted for networking with Pygame. The "game" project on Launchpad has some examples of how one might integrate the main loops together; basically, use twisted.internet.task.LoopingCall to draw Pygame frames and handle input, while letting the Twisted reactor of your choice run normally.
Since you are already using Pygame, I think this light networking library made for Pygame will do what you need and teach you, but not overwhelm you.
"Mastermind Networking Lib" via pygame.org
There is Pyro (Python remote objects) as another solution for networking in Python.
http://irmen.home.xs4all.nl/pyro/
Using raw sockets is low-level and full of danger. As said before, Twisted is complex and takes to time get up and running. To save yourself some headaches I'd try something like zerorpc.
You need the following solutions:
discovering other player(s) on the (local) network, you don't want player to enter some IP address
handle network errors
serialize messages containing your data (positions, player name, etc.)
handle threading as networking is asynchronous I/O
Above should still be called 'basic', you should really use some fancy networking library with idiomatic API.
Essentially you need to expose the network service (in its own thread) that will push messages to Python's Queue, and then access this same queue from your Pygame code, and if there is a message then you update whatever structures you use to store player's position and draw it on screen.
You shouldn't send stuff like bullet positions over the network as they can be easily (and faster) calculated locally. You just send an event like bullet_shot over the network with a source position and velocity vector.
Summary:
My 50% finished 2D sidescroller with Box2D as physics engine should have multiplayer support in the final version. However, the current code is just a singleplayer game.
What should I do now?
And more important, how should I implement multiplayer and combine it with singleplayer?
Is it a bad idea to code the singleplayer mode separated from multiplayer mode (like Notch did it with Minecraft)?
The performance in singleplayer should be as good as possible (Simulating physics with using a loopback server to implement singleplayer mode would be a problem there)
Full background / questions:
I'm working on a relatively large 2D game project in C++, with physics as a core element of it. (I use Box2D for that)
The finished game should have full multiplayer support, however I made the mistake that I didn't plan the networking part properly and basically worked on a singleplayer game until now.
I thought that multiplayer support could be added to the almost finished singleplayer game in a relatively easy and clear way, but apparently, from what I have read this is wrong.
I even read that a multiplayer game should be programmed as one from the beginning, with the singleplayer mode actually just consisting of hosting an invisible local server and connecting to it via loopback. (I found out that most FPS game engines do it that way, an example would be Source)
So here I am, with my half finished 2D sidescroller game, and I don't really know how to go on.
Simply continueing to work on the singleplayer / client seems useless to me now, as I'd have to recode and refactor even more later.
First, a general question to anybody who possibly found himself in a situation like this:
How should I proceed?
Then, the more specific one - I have been trying to find out how I can approach the networking part for my game:
Invisible / loopback server for singleplayer
This would have the advantage that there basically is no difference between singleplayer and multiplayer mode. Not much additional code would be needed.
A big disadvantage: Performance and other limitations in singleplayer. There would be two physics simulations running. One for the client and one for the loopback server.
Even if you work around by providing a direct path for the data from the loopback server, through direct communcation by the threads for example, the singleplayer would be limited.
This is a problem because people should be allowed to play around with masses of objects at once.
Separated singleplayer / Multiplayer mode
There would be no server involved in singleplayer mode.
I'm not really sure how this would work. But at least I think that there would be a lot of additional work, because all of the singleplayer features would have to be re-implemented or glued to multiplayer mode.
Multiplayer mode as a module for singleplayer
This is merely a quick thought I had. Multiplayer could consist of a singleplayer game, with an additional networking module loaded and connected to a server, which sends and receives data and updates the singleplayer world.
In the retrospective, I regret not having planned the multiplayer mode earlier. I'm really stuck at this point and I hope that somebody here is able to help me!
I think Notch is feeling the pain of developing SP and SMP separately. Especially since he told the Bukkit development team that he was planning to transition to the "local server for single player" approach (As you said, like the Source Engine.)
There is no reason you have to have multiple physics simulations running, the latency between the local server and the client would be negligible, the lag compensation could be completely disabled.
There are two basic models you could go off of at this point:
A dedicated server program which does all the brains of your game and lets clients connect.
A listen server where a game can basically act as a server or a client depending on the user setting. There is no separate server program.
The easiest way to make a client would be to add "dummy" flags to your objects so those dummies will be controlled directly by the server. Then, move into the interpolation. (Transmitting object updates at 60 Hz is unrealistic, so smoothing between points makes things still look nice. Source does this by adding a little artificial lag, if you've ever played GTA4 Multiplayer on a sub-par internet connection you can see the effect being overdone on fast cars.)
Also, recommended read:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
You could use the dumb render terminal approach. The advantage is that it's relatively easy to integrate without designing it into your engine from the start. The disadvantage is that latency won't be compensated using prediction techniques, and if there are many visible objects the bandwidth might be high.
One idea is separating the game-state and its evolution from the graphic. So each frame you translate the game-state into a graphic representation (culling offscreen stuff). Then in single-player you render that directly, and in multiplayer you send that graphic representation over the network. And sent the input over the network to the server.
How well that works depends on the number of drawn objects and how complex their graphic description is. But that description is usually rather small for 2D games.
I expect this to work well in a LAN since that has good latency and bandwidth. No idea how well it works over the internet.
Here is a document describing how the unreal network code works. And in the introduction in describes several simpler approaches. You might want to implement one of those.
http://unreal.epicgames.com/Network.htm
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have one computer that is running a c++ program to control a robot and another computer that is running a computer vision system (also written in c++). I would like for these two programs to be able to talk to one another. The communication would not have to be complex, I would just need the robot computer to be able to tell the vision computer when a trial begins and ends (when to start and stop a data collection sequence). Do any of you have advice on how to approach this problem? Rs232 communication between the computers? Some kind of networking solution? smoke signals? Any suggestions would be welcome.
thank you in advance
(edit) In case you think the statement above is vague:
I need to pass a binary (go/don't go) signal from one computer to another. Unfortunately I can't be more specific about what this will look like because (obviously) I don't know what is available. Both computers are on a network, and both computers are running windows. The goal is to syncronize data collected by the computer vision system with actions performed by the robot. The communication does need to be fast enough that it will not slow down either the robot or the computer-vision program. a "good" solution would be 1) easy to implement 2) fast. I do not know much about networking and I am looking for a place to start looking.
thank you again for your assistance
You might use a simple UDP protocol - the advantage being that if you understand the concepts of simple packet protocols on RS232 you'll find it easy to transfer that knowledge to sending the packets via UDP.
If you want a reliable (as in, other parts of the system will worry about errors and retries) stream of bytes between the two PCs, then TCP/IP is not much more complicated to use than UDP.
Both UDP and TCP are accessed through 'sockets'. I'm afraid you'll find that from C++ there is rather a lot of tedious boilerplate to getting that working, but there are lots and lots of examples around.
If they are network-connected you could just use sockets.
The best option will be to use network communication. The easiest way to approach this should be to look at the networking examples in Qt.
You basically will create a client and a server application. You decide what the client does when it sees a certain message from the server. That's all. Qt should take care of the rest of the stuff.
Other answers suggests TCP/IP, UDP, RS232, ... All those things are just options when you use QtNetwork module. I assume that since you ask your question, you don't know about the difference between those. So the safest bet will be to use the highest level (free) library, hence the suggestion to look into Qt.
Another option is to use Boost.Asio. I tend to prefer Qt solution since their API is nicer.
That sounds like a fairly good use for the network socket. If both your machines are on Windows you can even use named pipes.
For Windows, you will need to open the COM n port as a file to communicate over a serial port[1]. I don't have access to my code now, I can look it up when I get home.
RS232 is easy and I like it. However, it it is slow. You need to consider that in your design.
[1] For C++.
Most modern computers have Ethernet capability, so get yourself a cheap hub or switch and look at networking APIs. There's usually some fairly easy socket stuff. One advantage of this is that, if you want to increase communication ability later, such as having your vision software provide instructions and guidance to your robot, you've got the basics set up.
Alternately, set up your vision program so you can start and stop it by hitting random keys. When you're going to use it, put the keyboard in front of the robot computer's CD drive, and eject at the start and end of the robot run.
This may be overkill in your situation, but if I were in your shoes I would probably implement it using the HTTP protocol. The vision computer would run a HTTP server and the robot computer would communicate the state changes using POST requests. The Poco C++ Net library provides you with the facilities required to do this.
I would use a TCP/IP socket for communications. TCP guarantees that the data will make it. So, all you need to do is parse the data.
RS232 is an easy option to program for, however modern PCs don't tend to have RS232 ports. You may need to get USB-RS232 adapters or install a PCI card.
The other problem with RS232 is that you have an additional wire to worry about which can be a nusiance. Also RS232 cables can be limited in length (5-15m) unless you invest in some clunky RS232 repeaters or bluetooth connectors, etc.
On top of all that you're also adding one more item to your project that can go wrong and cost you time in deploying and debugging.
IMO, an elegant engineering solution would be to utilise the hardware that you have and use TCP/IP sockets to communicate.
The web is awash with examples on passing messages between servers and clients:
If you're using Linux:
http://www.linuxhowtos.org/C_C++/socket.htm
Using Windows:
http://www.adp-gmbh.ch/win/misc/sockets.html
I also might look at something like 0MQ to make the connection more robust. It will transmit and reassemble messages regardless of the transport, and handle buffering in the case of temporary loss of connectivity.
But the bottom line is that I would use TCP/IP, but depending on the nature of the robot you may want a slightly more robust connection system than TCP sockets. UDP is nice because it's connectionless-- if the robot temporarily travels out of range/sight/etc you wont have to rebuild the socket and context.
I have been creating a 2D game in Qt and I want to allow others to connect to hosted games to play. Would I just make a "server" in the game and allow others to connect to it?
If this is just a small project and you aren't intended to mass distribute it across the web (it doesn't sound like you are), then you can code up a simple socket server. You will need to modify your existing game code to send the "moves" as a message to the server. It will probably be easiest if you make up a simple network protocol to transmit the move data (if you are ambitious you could try serialization).
A pseudo-code example for a simple Tic-Tac-Toe game:
move1 = "Move X:1:1" //placed an 'X' in square at row 1, column 1
move2 = "Move O:1:2" //placed an 'O' in square at row 1, column 2
reset = "Reset" //clear the board for a new game
...etc...
Your game code will need to generate these messages. Each player will run your game on their machine and this will act as the client.
Meanwhile, back in the server code, you will need to listen for move messages sent by the clients. When you get a move message, you need to broadcast the message to all the other clients so that there boards can be updated. I would recommend moving the server code outside of the game code for now; this will allow you to setup a dedicated server that will handle all the sockets and then everyone who wants to play will simply connect their client up to the server.
The basic idea is that your client needs to broadcast the details about what it's player is doing to the server, as well as listen for data from the server to update the details about the other player(s).
You can find some good discussion of high-level algorithms of a simple Client-Server game in this question as well: Algorithm for Client-Server Games
Hopefully this is enough to get you started! I have used this approach for some simple games (Tetris, Pong, etc) using C++/Qt and they worked out pretty well.
PS. Don't let the idea of writing your own server scare you off. It sounds daunting but it is really not very complicated at all (~100 lines of code or less) and a great learning experience.
Generally, one will need a few things to get something like that going.
Namely, a directory server. Maybe everyone connects to other players who host games to play, but you need to run a directory for games to be listed in order for people to connect.
Either that or you need to run a server and host them there. The choice is yours, the first option is probably easiest on you.
If I were you, I would make a server separated from, but bundled with, the "client". Believe me or not, many games out there take similar approach.