Hi I really am sorry if this is a stupid question.

Started by
6 comments, last by superkitty 14 years, 7 months ago
As I said in the introductory thread I'm not always as easily able to understand things so if I miss the point or use any odd turns of phrase I mean no discourtesy. I am relearning c++ to try and program a multiplayer game based in space. I just cannot get my head around this idea though - I get that I can write code so I can use varibles and files take in input and make output and . . . well . . . just about anything you want to put your mind to but how do you manage a situation where different people on different computers give instructions to different objects in the same program? I can't get my head round the concept. If someone can explain just how it works in theory I would be ever so greatful. Matt aka superkitty.
Advertisement
It's called the Server-Client model and it works like so:

Client moves his ship.
Client attempts to tell the server that it moved it's ship.
Server verifies that the client's move is legal (as far as the game rules are concerned).
Server passes the move along to the other clients.
Other clients update their screen with the original client's move.
With you. Is this something I'd code up or have I missed the point ('cause I really know I can be THICK at times and not realise)
Yes. Here's a real quick pseudo-code example that will not compile, but it should give you an idea of how networking works.

class Client{ void sendLocation() {  server.send(location, sizeof(float)); } Vector3f location;};class Server{ void recieveLocation(Client* c) {  while(c->isConnected() && c->isSending())  {   Vector3f clientLocation = recieveBuffer(c);  }  if (clientLocation.x < 0 || clientLocation.x > MAP_SIZE ||      clientLocation.y < 0 || clientLocation.y > MAP_SIZE ||      clientLocation.z < 0 || clientLocation.z > MAP_SIZE)  {   // invalid client coordinates, client is possibly trying to hack.   sendInvalidCoordinateMessage(c); // cancel the move and tell the client he can't move.  }  else  {   for (unsigned int i=0;i<activeClients.size();++i)   {    activeClients.send(clientLocation, c); // inform all other clients about the move   }  } }  std::vector<Client> activeClients;};


Keep in mind this is pseudo code and will not compile, but it should give you an idea of how networking code operates. Look into WinSock to get started. There are plenty of great tutorials.

If I were you and this is your first networked application, I would start with a basic chat window or something. And it's a big help if you have two computers hooked up to the internet at your house. If not, it definitely pays to have some trustworthy friends on AIM or MSN that you can bother endlessly to try your new program :).
Quote:Original post by superkitty
With you. Is this something I'd code up or have I missed the point ('cause I really know I can be THICK at times and not realise)


Yes, you'd have to code the client and the server.

Basically, you'd have to write logic to:
1) Set up communication between the server and client
2) Have the clients tell the server what they want to do
3) Have the server reconcile all those actions
4) Have the server send updates back to the clients
5) Have the clients apply those updates locally

There are libraries to help you out with some of these things (RakNet, OpenTNL, etc), but there's no way for a computer to magically manipulate a program's data on a remote computer.
Fantastic! Got it.

Wait . . . no . . . one thing I'm still a bit lost on.

50 peeps playing a spaceshippy shooty eachothery to deathy thang. So each unit of time client gets responses (1) like move/shoot/check the mirror to see if anyones behind me and my hair looks good/self destruct 'cause I didn't read the manual/whatever.

server then takes those command requests and apply appropriate actions and animations and sounds. server then sends all of aforementioned stuff to each player so show it.

time moves forward to the next unit (2) and the whole thang reoccurs.

so if I press fire at (1) and some else presses fire at (2) I fired first?

and that must mean there's a natural limit to how many peeps can exist in the same place at the same time?

and you gotta code so the client's only waiting for responses from players actually there (i.e. if an area can support up to 50 players but only 3 are there the client cant hang about waiting for 47 peeps commands who aren't there and (since I last programmed using ada back in '99 and was 26% more mentally functional back then) I assume there's gotta be a time delay like you've got 1 second to push a button or your command goes into the next cycle. I'm roughly looking at that right? ANYTHING in my raw thinking that is off the mark even slightly off the mark tell me. please.
Quote:Original post by superkitty
Fantastic! Got it.

Wait . . . no . . . one thing I'm still a bit lost on.

50 peeps playing a spaceshippy shooty eachothery to deathy thang. So each unit of time client gets responses (1) like move/shoot/check the mirror to see if anyones behind me and my hair looks good/self destruct 'cause I didn't read the manual/whatever.

server then takes those command requests and apply appropriate actions and animations and sounds. server then sends all of aforementioned stuff to each player so show it.

time moves forward to the next unit (2) and the whole thang reoccurs.

so if I press fire at (1) and some else presses fire at (2) I fired first?


That's a conditional yes. You have to account for latency when you're doing this sort of thing. Its possible for you to press 1 first, but for your command to arrive at the server after 2. You then have to have the server reconcile this. There are different methods of doing so, and its up to you to implement this.

Quote:and that must mean there's a natural limit to how many peeps can exist in the same place at the same time?


Yes. This is why big games like World of Warcraft tend to slice up their servers (for example, one continent can be hosted on one server, and another content is hosted on another server), and why smaller games have character limits per server instance.

Quote:and you gotta code so the client's only waiting for responses from players actually there (i.e. if an area can support up to 50 players but only 3 are there the client cant hang about waiting for 47 peeps commands who aren't there...


Kind-of. Your client just gets responses from the server and handles those. The server is responsible for telling the client whats there. The server knows how many clients are connected to it. So, your client just gets a message from the server saying "player 2 has moved his character to X,Y."

Lets say there's a Player 3, and you don't get any message saying "Player 3 has moved his character." In that case, your client may choose to just leave the player there. Alternatively, it may decide to predict where to put the player, place the player there, and then move the player to its real location when it gets a message from the server. What the client decides to do is up to the programmer.

Quote:...and (since I last programmed using ada back in '99 and was 26% more mentally functional back then) I assume there's gotta be a time delay like you've got 1 second to push a button or your command goes into the next cycle. I'm roughly looking at that right? ANYTHING in my raw thinking that is off the mark even slightly off the mark tell me. please.


You have the general idea. There is delay. Latency (how long it takes your commands to go to the server, and how long it takes the server to send responses back) definitely plays into it. Most games have code that tries to hide the latency by predicting where things are going, and what will happen, then change things to match reality when the server sends information back to the client.
Cool. Now all I have to do is learn all of the syntax for c++, read the resources on clients and servers and make a working program. only many many hours a day for ? days to make a working game. Easy! Thank you all for your excellent answers however I fear this may only be the first of many questions to come . . .

This topic is closed to new replies.

Advertisement