Game networking question
I am currently working on a ship simulation in which the player is supposed to be at the bridge of the ship. The view is 180 degree like inside a ship's bridge. So there's 5-6 monitors for each 30 degree of the scene. We decided using 2-3 cpu for this with one cpu handles 2 monitors at most. There can be another instance of player / machine in the simulation so it's basically like a multiplayer fps game++. So this will require some networking, obviously. My questions are:
1. How do most fps handle their network? Do they send some packets with all the data of the game (eg. player 1's transforms, states, physics data; player 2's transforms, states, physics data; ... player x's transforms, states, physics data; game world data; etc) to all the clients from time to time? But won't that make the packet bloated and it'll make the game slower?
2. How do they handle the physics? Do they calculate it on the server or the client?
3. Seeing that one player / machine will consist of multiple cpu's, thus multiple clients, what I'm most afraid of is the state of one client will be different with another even if they're in the same machine. So how do you handle with lost or out of order packets? For example: player 1's main client (the control client) will get a packet to refresh the scene but the same packet is lost for the client for the left side of the same player. Now multiply that with how many players are there in the simulation.
Thanks in advance. This whole thing is still new for me so any advice is very much appreciated.
I dont see this project as needing any networking between the different computers that are drawing each scene. If each screen is controlled by one computer, and the program that is running is identical, all you need to do is make sure each computer have a different camera orientation and coordinate the camera movement.
1) Well, I have no idea what you are trying to create. So, there are many answers to this. If this is a computer game, then all collision checks must be done on the server --Physics as well. The client does the same calculations, but the server is the FINAL authority on everything. NEVER think you are such a great programmer that players will never be able to abuse your system. If you leave an opening, however, small, players will exploit it.
Thanks for the reply. Well, I'm lost. My intention is actually like what you're saying, each screen is controlled by one computer and I intend to use different camera angles to each of them. However I don't understand what you're saying about it doesn't need any networking. How do I control / coordinate the camera movement then? Also this is a multiplayer simulation and each player will have more than 1 screen (and thus more than 1 computer). So there's actually 2 networking problems here. One is for coordinating the scene, camera movement, physics, etc of all the computers of 1 player. And the other is handling the whole multiplayer aspects of each players and the server.
The standard approach, as you suggested in your first post, is for the player to tell the server when it actually does something (move forward, fire a gun...) and for the server to administer regular updates (every 50ms, for example) of the gamestate to all players. In between times, both server and client must continue to interpolate things like movement. Clearly, this means you have to optimise what you are sending, both in terms of the size/compression of the information you send, the frequency with which you send it and how much actual content you send.
The question of content ties in well with your second question. Do you need to keep the physics in sync? Are they integral to the game, or are they incidental? If you're having players throw bricks at each other, you'll need to keep everyone updated on the position of the brick. If it's a matter of a ragdoll without any clipping, it doesn't matter if it's the same on all clients, so you can just update it locally. You'll have to apply the same thought process to everything in the game:
1) Does it need to be synchronised?
2) If so, to what extent?
The trick with lost/out of order packets is simply to number your packets and discard those that come in too late.
More input is needed. Is this going to be controlled by keyboard and mouse? Why do you have to have separate computers controlling each screen? Are you going to use 10 foot sized screens here running at some crazy resolution?
If you have no idea about any of this, then you are in way over your head. Concepts like networking, and especially programming multiple computers to run in sync is going to be FARRRR beyond your ability to learn in anything less than a year or more to learn.
Not to be the devils advocate, but you might want to rethink what you are doing :P
I didn't read everything in this thread as I don't have the time right now, but I'll write some hopefully useful answer anyway. First of all, see this:
Dead reckoning - Wikipedia, the free encyclopedia
About the collision detection and stuff on server side... Doing it server side may be too expensive. A method I've thought of myself (though it probably already exists) is to have it calculated on not just the client but also one or two other clients. This way you distribute the computing power. And for someone to cheat not just they would have to cheat, but also the random clients that are used to compute the same thing.
Should two clients ever produce a different answer then one of them is cheating. Use more clients to find out which is cheating and then ban that client for an hour (the first time) and then longer.
Just an idea though. If you're making a small game this is probably going to be an overkill. But in a big game I'd do it like that.
Well, that's what I'm also thinking. The server must send data regularly at an interval. And also there should be synchronization and such. But I've also got another idea. What if the server only send the physics data like acceleration, velocity and heading of a player to the client once and then only send them again if one or more of the client changes the data? So I don't have to send the data regularly, only when there are a change in, for example, orientation or velocity. Or some game related changes like shooting a cannon or so? So the client itself is the one that will have to calculate from the sent data.
Well, the input would be from a serial device and touchscreens. About the screens that will display the scene, we'll use 5 of them. Although its not 10 foot, we'll use 5 40 inches monitors, probably with the optimum resolution.
My colleagues and I are making a naval simulation so the majority of the scene wold be ocean. We are using the open source Delta3D for this. I don't know whether or not the ' 1 computer 5 display ' way will get an adequate performance. As I said, it is mostly ocean rendering so even if the ocean rendering algorithm is handled by the GPU, can it handle lots of monitor at the same time. The problem we are dealing here is the short timeline for our project. We must get this done by December. So researching for a software side optimization is not an option. Thus we decided to add more hardware to compensate for this. We are working for a government project so money is not as important. Although I hate spending the taxpayer's money more than it was needed, it can't be avoided as of now.
However what I'm saying here is just the worst case scenario. But still it is the most possible road that we will take in the future.
I do know about networking. I've got a Computer degree, although my speciality is more to the Graphics. I do know the concepts behind networking, however doing them first hand is still new to me. The last time I did network programming was like 7 years ago when I have to work on a networking practical project. Developing a multiplayer ASCII Pacman. LOL.
Thanks for the link. I wouldn't worry too much about cheating though. It's a simulation device that won't even have a keyboard so I don't know how someone can cheat on it. :P
The most important thing right now is the simulation's immersiveness and the player's experience when playing the simulation. So both performance and quality of the rendering scene should be good.
The obvious issue I see with this is that, if a client drops an update, it will completely lose any sense of what's going on in the game until something else happens, whereas with regular updates you are out of sync for a maximum of the update interval. Unless, of course, you use TCP, but then you are negating any benefit by adding all that extra transmission overhead.
Originally Posted by g4j31a5
the easy way
Have a single computer control each screen. Have the touchpad send the same signal to each computer. The signal splitter would be like getting a phone jack splitter.
The reason for that is so could try and set up the system so less synchronization is needed between the computers. If each computer has a different camera orientation offset, then you are fine. If you have 5 monitors, each computer will have a 54 degree Field of View, to combine and give you 270. So, if each monitor is offset by 54 degrees, and you have the same starting position, and duplicate movement signals are sent to each computer, then the image displayed will all be coherent.
As far as networking goes, pick one of the 5 computers to be the master. When this master receives data, it sends it to the other 4, and when any data is to be sent, it is sent from this master computer. The other 4 do no sending of data, other than to tell the Master that it has received data successfully. If time is of the essence, TCP connections would be your best bet. if you go with trying to write your own UDP connections, it will take too long.
It doesnt sound like you will have players attempting to cheat in your simulation. So, you can skip the part where you add extra precautions for them. Make all the checks for physics collision and anything else you need on the clients. Then have the clients send any pertinent info to the World Server. The World server would then just duplicate that data to anyone in the area who needs to receive it. This will make your setup time very quick.
Sorry that I'm replying this late.
@AntP: yeah, I know what you mean. I actually also think the same way.
@smasherprog: hmm.. good idea. I don't know how the hardware would be set so the input part is not my concern, at least right now. so you're saying about making a sub net for each player, right? I think that's a good idea. however, isn't TCP slower than UDP? I mean UDP doesn't have to deal with handshaking like TCP, right? It's just sending raw data to the net without any check or double check whether the message is sent or not. so won't that make UDP faster? maybe I can make another layer on top of the UDP so that I can at least have some kind of control. maybe adding a timestamp when sending? and a CRC?
tcp can be bad as the chances of packet loss increase as with any connection. TCP is not that bad, but since you are on a time limit, you can get a tcp code going in a day. If you want to write your own udp code, you are looking at alot longer than a day, possibly a couple of weeks to get code that is runable, then you have alot of testing to make sure it works properly.
I know this because I just did that. Just to give you an idea, World of Warcraft uses tcp and not udp. They should have use udp, but they didn't. So, it is really do-able and will save you alot of time and head-aches.
If you are playing a game like Halo, or Some other first person shooter, defiantly use UDP, but for a simulator, you will have no problem using tcp.
Remember, if you are NOT concerned with cheating, make all the complex calculations on the client. This will make it so you have less to program in the end.
I see. Right, maybe it is better to use TCP instead. After all, the simulation will probably be build upon a private network so TCP would still be as fast. Thanks.