• Advertisement
Sign in to follow this  

Making a multiplayer FPS, does this make sense?

This topic is 4621 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am making my first multiplayer game (I've done a bit of TCP/IP sockets programming before though). As I said, it's a first person shooter so following the forum FAQ I'm using UDP. I have a few ideas about how I'm going to do this and I just want some of you people with more experience than me to make sure my design makes sense. Each packet will have the first two bytes be the size of the packet, and the third byte will be an ID indicating the purpose of the packet. After that, each packet will be unique depending on what it does. I have a dedicated server exe as well as the client exe, and I think this presents a problem (if you want to host and play at the same time, you'll have two things fighting over the same port). To resolve this, I'm going to have two sockets for each the server and the client - one to send data on, and one to recieve data on. Each player in the game will have their own unique ID (a short), which will be known only to the player and the server. This way the server can tell what player is sending what, and a hacker couldn't simply change the ID to another player's ID to mess with them. Does all of this make sense, or are there better ways to do these things?

Share this post


Link to post
Share on other sites
Advertisement

a few ideas:

http://www.gamers.org/dEngine/quake/QDP/qnp.html

Share this post


Link to post
Share on other sites
Enet looks decent, but it's written in C which makes it ugly at best, and clumsy and hard to use at worst. Is there an OO version out there?

Share this post


Link to post
Share on other sites
Sending and receiving on diffenrent ports will make playing through NAT not work right.

If you have server separate from client, you should have the server always bind to port X (specified by the user, with a default by you), and client bind to port 0, which means "assign any free port". It doesn't matter what port the client runs on, because the server will always call recvfrom() to receive data, and will reply back to the same address using sendto().

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement