I'm working on a small networked game (LAN only) with one computer acting as a server and all others (including the actual game running on the same computer) acting as clients. Essentially, the server is transparent to users, but exists to simplify state management for me. The basic concept I have now is that each player's computer will say, "Hey, I'd like to play" via broadcasting and will keep a list of the other players on the network. After each player running the game indicates that they are ready, one computer is chosen as the server and the rest default to clients.
When choosing which computer on the LAN to use as a server, is there really any established way to choose one and inform the others?
I've been tinkering with the basic idea of simply having all players' computers pick a random number and have the one with the lowest (or highest, doesn't matter) be the server (regenerating random numbers for computers which roll the same one). Each computer would receive the "rolled" number of the others and could determine which would be the server, after which it could connect to it. It seems crude, but I'm not sure if it matters since all the computers would physically be on the same network within a few feet of each other. Would this do the job adequately or is there a significantly better way?
To be honest with you, I would make the decision a little more complicated than that. I would be inclined to do some basic information gathering to determine which computer has the most power and elect that one to be the sever (power is intentionally a vague term because the most powerful computer will depend on the requirements of the sever and the game). Give that the server will need to run an additional piece of software (the server in addition to the game) it stands to reason that unless all of the computers have equal specifications, there would be one better suited to the task than the others. As long as all of the nodes are running the same evaluation on the data, they should all reach a consensus as to who should lead or you could have the first node that created the game be responsible for determining which node should be the server.
It may also be worth having the server set up to periodically reassess it's qualifications to be the sever. For instance, background processes could start that would hinder it's ability to perform adequately, or a more powerful node could join the game. Obviously shifting the sever hosting the game would be nontrivial, but it's something to think about. (keep in mind, this happens in online gaming i.e. Halo. When the all client connectivity to the sever drops below a certain threshold, the game is paused and reestablished on a different server that can provide better performance).
Related
I am currently working on the design of a measurement system. It has a three instruments mounted on a pan/tilt head, but only one serial line from the instruments to the Beaglebone Black (BBB) that controls everything. Instrument A and B are similar (use the same commands and module). I'm using Python to control everything. During testing, I had additional cables so that I could wire each instrument to a separate port on the BBB, but that is not possible in the final setup.
Since I needed some processing capabilities on top of the pan/tilt head anyway, I'm using a PIC24 device to connect all instrument serial connections to.
My idea is to multiplex the 3 serial connections, for instance by adding a prefix A_/B_/C_ to the commands/replies.
This I can do.
Communications and processing for instrument A and B is done by the same Python module, which has a function measure() that takes the serial port (ie. /dev/ttyO4) as one of the parameters. I'll obviously need to adapt this.
I need to find a way to allow different modules to access three "virtual" ports, with the choice of either stream A/B/C.
So in short: I (think I) need some kind of class/... that opens the serial port and multiplexes/demultiplexes three streams. Instrument A and B are not to be used simultaneously, but A/C and B/C can be used at the same time. Timing is not critical, a couple of hundreds of milliseconds delay is not an issue.
One option would be to use a second PIC to do the reverse of the microcontroller near the instruments, but I suppose this should be possible in Python as well...
I think the elegant solution is to add some code for your PIC to work as a Modbus slave.
There seem to be good efforts already done, so maybe you can use something like this as a starting point.
You can have the three UARTs connected to the sensors continuously writing to several Modbus registers and query those from your BBB with something like pymodbus or pylibmodbus.
It will also be possible to use other buses/protocols like CAN, but if you run Modbus directly on the TTL UART (instead of over RS485, which you won't need unless you have long distance or a noisy environment) you don't need any additional hardware. You will have to modify the firmware on your PIC and write some more lines of Python on your BBB.
But if you want to learn something new (assuming you don't know already), Modbus is quite an easy and useful protocol to add to your toolbox. It's still very popular and open (the spec is publicly available and you have tons of info and code).
EDIT: I'm keeping my first answer as a reference for others, but the question did not refer to sharing the same physical cable for multiple ports so what I wrote here is not really useful somebody misunderstands it the same way I did.
This question has come up a number of times, see for instance Receiving data from multiple devices using parallel wired RS232
Serial lines are not intended to be multiplexed, if you decide to follow this route I think you'll get many headaches.
Is there a reason not to use a multipoint protocol like RS485, SPI...? I'm sure you'll be able to find one that works for your needs. For RS485, for instance, the
investment in new hardware would be minimal and the software side would be a piece of cake.
I am posting here concerning the emulation of computers on the local network, without destroying the local network.
When a computer connects to wifi on your local network, the computer can be seen in the "Network" section of Explorer(on Windows) and can be addressed via internet protocol.
My Goal: I would like to create a program such that I could receive streams of data from a remote computer via radio waves. The communication would be full duplex, there would be a transmitter and a receiver on both ends.
My Idea: I would like to utilize Qt to create an application which would receive and demodulate the radio waves like sound (through OpenAL buffers) which would act similarly to a driver program for the emulated computer connection, without destroying my connection to the local network. In this way, I believe that some truly novel things could be done, as I could for instance, use PuTTY one the emulated connected computer remotely while browsing my local network and the internet from my "base" computer.
Extended explanation: I want to perform a weather balloon project, sending a small computer (likely Raspberry Pi3) via a weather balloon to the far reaches of our atmosphere. One of my worries is being able to communicate with the device, such as receiving locational (telemetry) data in real time and being able to (potentially) retrieve arbitrary data in real time.
I understand that I may very well be approaching this question in the wrong way. There are probably existing systems out there that grant telemetry data and some arbitrary means to transfer file data, of which I am unaware. But from what I have seen, I also cannot find a device that utilizes this approach (packet radio emulation of a computer on the network). I have a personal curiosity towards this approach, and thusly will accept the answer which follows most in line with this approach.
P.S: Video which inspired this idea:
https://www.youtube.com/watch?v=Ueb5JG0dCL8
What you're trying to do is called software-defined radio, and is rather popular. Modern computers, even little ones, are more than powerful enough to do the modulation/demodulation entirely in software.
There's very little left for you to do other than designing the RF channel, purchasing often open-source hardware, and using existing open-source SDR implementations out there. The input/output to your Qt program would be either a QIODevice-like data stream that you'd couple to the SDR library's data scrambler/descrambler, or a packetized data stream that you could run some higher-level protocol on.
Do note that unless you limit yourself to an industrial license-free band, you are likely to need an FCC license to operate the transmitter, and an FAA license to launch the balloon.
Your question is essentially off-topic here. It probably belongs on amateur radio stack exchange under the [sdr] tag.
If you're thinking of implementing a complete WiFi stack using SDR, I'd like to discourage you: it's patent-encumbered up the wazoo, so no open-source implementations exist, and the sheer amount of standardese you'd have to wade through to do a compliant implementation is staggering. We're talking on the order of 5,000 pages of standardese, where almost every other sentence is important so if you ignore it, you're not compliant.
I'm trying to use Psychopy to trigger a second machine's data collection. I could use an I/O card, but I wondered how difficult it would be to use the NICs in Ad-Hoc mode?
Thank you
We are currently communicating with an eye link 2 running our experiment on one machine and the eye link software on another. In some tests of the mirametrix eye tracker we also used some variations of virtual and real machines talking to one another (as an aside, we never quite got the performance from the mirametrix that we needed).
We mention some of the tools we used here: https://brittlab.uwaterloo.ca/research-tips/
If you have a network card in each machine you could just connect them with an ethernet cable and set up tcp/ip to let the programs on the two machines talk to each other. If one machine needs to also talk to the outside world you could add a second network card (or if a laptop just buy a cheap usb wireless).
With more specifics about what you are trying to achieve others may be able to give you more specific feedback.
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
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.