Thread: Game networking question

Hi,

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.

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.

@AntP
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.

@smasherprog
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.

@EVOEx
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.

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.