Creating an online First Person Shooter

[KornNut]

I am creating an online first person shooter. It is going to be written in C++// Linux // OpenGL API.

Two (or possibly more) users will face each other in a First Person Shooter ON SEPERATE COMPUTERS.

I was wondering how I should do the communication between shooters. For instance, how each shooter knows where the other is.

I was planning on using socket programming:
The server creates a socket.
The sever listens for client(s) to connect to the socket.
The client attempts to connect to the server using the server's IP Address and it's port number.
The server allows connection to the socket.
Once connected, messages are passed from the client to the server through a buffer.

I am positive that the program can be created using this method. However, I am not sure how well it will run. Will the communication of client-to-server-to-client be quick enough for the first person shooter? For instance, will the commincation be quick enough so that the computer can tell if the opponent was hit by a shot at or not at a particular instance of time before the opponent makes his next move.

 

[TheHeadFL]

Depends, really. You're probably going to want to use UDP for most of the stuff, which is a stateless type of 'connection'. Many games also have a TCP connection for control and backup use.

Most of your 'status update' movement/shooting/etc packets would have to be UDP if you want it to ever work over the wide open internet. Packet loss is a reality, and games are latency sensitive. You don't want TCP making the client or server resend critical packets because they were missed. By the time they arrived, they'd be useless.

I think it could be done fairly easily via pure TCP on a LAN though. Theres no reason that your idea wouldn't be fast enough, provided your packets were succinct enough. You're going to have to implement a lot of client-side prediction and calculation, though, to make it fast.

Both client *and* server side should be able to make weapon hit calculations, for instance. All I would choose to transmit back and forth would be, for instance, a point describing the location of the player, a vector describing any shots he may fire, as well as any other pertinent info. Each system should be able to independently detect hits (as much as possible) in order to cut down on the amount of geometry you're cramming across the pipe.

Ideally, you also have some sort of time synchronization system, so that the two systems can arbitrate which event happened first, and so on.

 

[KornNut]

Exactly.

I chose sockets/buffers because they are easiest to implement.

The first item sent in the buffer would be the "type" of instructoin/information (for example, a 1 for a change of opponnent direction and a 2 for a hit/miss of a shot). the rest would be a x, y, z vector coordinates of the shot/movement.

I was just concerned about the speed of this communication.

Both/All PCs will be connected to the same server through a LAN.

 

[KornNut]

Ideally, you also have some sort of time synchronization system, so that the two systems can arbitrate which event happened first, and so on.

Isn't it already synchronized where the first message is read first?

 

[TheHeadFL]

UDP packets are not sequenced and therefore would arrive in any order.

TCP would largely eliminate this problem, however you may run into problems. Client side collision detection would require your machine to evaluate the data based on the time it was received, and any 'fire' or 'kill' (etc etc) messages passed back would have to be timestamped somehow so that the order of events can be determined properly. (Who shot who first, in a close call situation, for instance)

 

[KornNut]

Does any one know of any tutorial web pages or sample code online anywhere for implementing this communication between two computers?

Note: This does not have to be for any two PCs to connect with each other. You can assume that both PCs are on the same high speed LAN. Although I would love for any two PCs to use this program, but for now, I will only be using it with PCs that are on the same high speed LAN.

 

[TheHeadFL]

All you need to do is figure out your own protocol, if you want.

It can even be an ASCII based protocol, not binary, for ease of troubleshooting

Define your 'control' keywords, like position update could be *#*#001*#*# or some other unique type of string. You could have a list of 2 or 3 digit 'control codes' for different messages you would want to send.

Then you just read all the received data into a parser that can key off of the special chars that separate your keywords. Then the text immediately after would be some ASCII representation of your actual data. (X,Y,Z coords, etc)

 

[KornNut]

All you need to do is figure out your own protocol, if you want.

It can even be an ASCII based protocol, not binary, for ease of troubleshooting

Define your 'control' keywords, like position update could be *#*#001*#*# or some other unique type of string. You could have a list of 2 or 3 digit 'control codes' for different messages you would want to send.

Then you just read all the received data into a parser that can key off of the special chars that separate your keywords. Then the text immediately after would be some ASCII representation of your actual data. (X,Y,Z coords, etc)

I understand what you're saying about the protocol. I have followed the same protocol on simple applications like a chat room, instant messaging, and a card game. I was just wondering if the message passing via buffers and sockets was going to be fast enough for a FPS.

 

[KornNut]

Also, there will be no AI in this game. This game is going to be entirely comprised of human players. So, it must be able to hold eight computers on average.