[Silver1992]

So, after reading a lot of the why and why not's in my previous topic I decided to go with C++ for the time being. I'm speeding through books at the moment but on the bus today I started thinking about how to make lets say a simple game with multiplayer - But not sure if my logic is right. (I'm also making a few assumptions)

Here is the list of assumptions I'm having.

• That sending "Data" across the interwebs is not that hard. In my dream world right now its a matter of telling the client which port and IP it should poke with a stick and telling the server which port it should be guarding for pokes on.
  
• That I need to follow a pattern on the server side. (This will be pointed out further later on)
  
• That the majority of the data packages I send will actually turn up. (So not taking into account data loss)

Now onto my logic! So for this made up game the game itself is going to be simple. You have a 10 x 10 tiles map in all green, each tile is 64x64 pixels. On this map of grassyness there will be one stick man. all we can see of this man is is the round black head which fits inside one single tile. All you can do in this game is press W,A,S,D to move one tile in whatever direction those represent. So basically position is moved by 64 pixels in somewhat direction.

Now this is going to be the normal type of game (Please note I've only made games in C# before so this might be colored by that) So we'll have an Update part in our loop and a Draw part. Update happens before the Draw.

So, we'll have 3 variables that we actually care about. That's the PositionX, PositionY and PlayerID Out of all these 3 only the PlayerID is something we initiate on the client side. It's going to be the integer value 1.

So, (This is going to partly be experience from PHP + mySQL) I'm assuming that I'm making a variable at the start with something like Ipadr and Port which are a double and integer variables storing the information on where to connect.

So during game loading the client does something like this

• Lets say we have a function in whichever network library that are available that is something like "netDatasend(data1, data2, data3, data4)" where you can send data.
  
• We're going to send something like netDatasend(PlayerID)
  
• So what I'm thinking is that even though you can send whatever you want to the server it has to know what the fudge to do with what it gets. So we have some kind of constructor or the C++ equivalent of that. So somehow on the server side we've made it so that if it only gets a single integer value sent to it that its a PlayerID (At this point i'm not really sure how it would be in C++ but the server should check if there is any object of the "Players" class. If it doesn't find any Object with that name then it creates a new one. With the PlayerID which would be 1. So now on the server there is an Object or whatever its called in C++ by the name of 1 which holds two Variables PositionX and PositionY who hold a default position that would be something like upper left corner or whatever.
  
• The client would now in the update part of the game ask the server for those position variables - After which the player would be drawn on the map.
  
• At some point the player decides to press a button for the stick man to move to the right. Now at the update logic the game still asks the server for the position of the player, then he subtracts or adds the 64 needed to move one to the right (And all the other stuff like changing the sprite of the player to make it look like its moving happens here as well)
  
• At the end of the update the client sends another netDatasend(PlayerID, PositionX, PositionY) which the server is instructed that when it gets an integer value followed by two double it should use the first integer to find the object in this case PlayerID == 1 and use the following two numbers to set the PositionX and PositionY of the object.
  
• And so it goes.

This is a rough sketch, I can imagine there is tons of things I haven't considered which is why I'm posting this here.
Still there are a few things I want to mention

• Yes, I realise that it would be smart to make some kind of system that checks the PositionX and PositionY against the PositionX and PositionY of the prev update to check if there has been any movement, and only incase of movement would you actually bother requesting or sending the positions to the server.
  
• Might also be some advantage to calculate the position's server side. So what you send is instead what key has been pressed and then the server does the calculation.
  
• Now to make this a multiplayer game you could add it so that at the end of update the client sends a request that makes the server respond with the Positions of all active players and draw them in the Draw. Then add some kind of collision detection on the server and you have some crappy game.

Any and all input would be love! I will also answer any question you might have.

[BBeck]

I don't know how much I can say if you use a network library. Seems to me that would be 100% dependent on how they built the library and you would have to talk to someone who's familiar with the library unless it was just a thin wrapper. Which in my mind, would kind of defeat the purpose of having a networking library because it seems to me that you would want to obfuscate all of the low level details.

Anyway, if you were building it from scratch in C++ for Windows (which is what I would do if I were working in C++), I would tell you read this book "Windows Sockets Network Programming" by Bob Quinn and Dave Shute. I believe that's the book that I learned Sockets programming from and it was really good. It's a really old book and there "might" be a better book out there, but I know for certain that that's a good one (for Windows programmers anyway).

Sockets programming isn't all that difficult once you get past the steep learning curve of figuring out what's going on.

First of all (whether you use WinSock or a library), you need to decide whether this is going to be peer-to-peer or client/server. It sounds like you're leaning towards client/server and I probably would too.

Then you have to decide whether you're using UDP/IP or TCP/IP. UDP is more like sending letters in the mail and TCP is more like picking up a phone and calling someone.

So, if you have a TCP server and game clients it would work something like this:

The server opens up a socket in "listening" mode. The server "probably" only has one IP address and it opens up a TCP port in "listening" mode. (If the server has multiple network cards, each card will have it's own IP Address and set of TCP and UDP ports.)

A client opens up a TCP socket to call to the server's listening port.

The server answers. As it does this, it spins up another TCP port and then tells the caller "Call me back on this port(the new one it just spun up)" and then hangs up. This allows the listening port to go back listening for the next caller.

The client then calls back on the new port number and communication is established. The server's listening port is still listening and the client has an open communication channel established with the server.

Once you get that TCP connection open it's basically just a "byte stream". So, anything you send in the stream is guaranteed to be received on the other end unless the connection is broken. So, you can send anything in that stream. The hardest decision you make is what to send and receive. You can send and receive simple text messages like "Hey, how's it going? What are you up to?". Seriously, you can send that and you'll receive it just like that on the other end. But it may make more sense to send numeric codes back and forth as long as both sides know what the codes mean.

You have a send and receive buffer. Anything you put in the send buffer will show up on the other computer's receive buffer. If you have Windows Asyncronis communications setup you'll have Windows events that are raised when anything new shows up on the receive buffer. And you just write a Window's event handler to pull the new data off the receive buffer and process it however you want to process it.

See, that's too terribly complicated. You just have to get someone to explain to you how that works, and there was no one to explain it to me, so I had to figure it out all by myself. But reading that book was where I made the break through and finally understood.

As far as client server architecture, I would probably have the whole game happening on the server and the clients doing nothing but drawing the results and sending requests to the server to make things happen. It certainly reduces the chances of someone hacking the client and cheating.

This post has been edited by BBeck: 15 August 2012 - 11:10 AM

[Silver1992]

I actually understood 95% of everything you wrote. Part of it. Like UDP (Unreliable Data Protocol) as my teacher called it and TCP (Three way handshake (I always imagine some Mexican dudes doing a stand-off for some reason)) are stuff I've got a somewhat understanding off.

However the byte stream and buffer mechanics was new to me Thanks for that piece of info, trying to gather as much info I can before deciding if this would be to hard for one person or not.

Going to take a look at the book (Or if anyone has a better one I'll consider that) But yeah. Leaning towards TCP and Server/Client. And for now I just want something simple, you know learning on the way.

[BBeck]

Silver1992, on 15 August 2012 - 12:46 PM, said:

I actually understood 95% of everything you wrote. Part of it. Like UDP (Unreliable Data Protocol) as my teacher called it and TCP (Three way handshake (I always imagine some Mexican dudes doing a stand-off for some reason)) are stuff I've got a somewhat understanding off.

However the byte stream and buffer mechanics was new to me Thanks for that piece of info, trying to gather as much info I can before deciding if this would be to hard for one person or not.

Going to take a look at the book (Or if anyone has a better one I'll consider that) But yeah. Leaning towards TCP and Server/Client. And for now I just want something simple, you know learning on the way.

Glad it helped! :-)

Networking with Windows Sockets is very "do-able" for one person, especially once you get fairly good at it and can crank out the code quickly.

Writing some simple programs may prove useful. You could write an FTP program. If you can get ahold of an FTP server (hopefully free ware or shareware or Linux or something), you could write an FTP client that can Get or Put a file. You can learn all about the FTP protocol through information you get on Google and FTP is a pretty simple protocol. It kind of gives you some idea of how "commercial" software has used TCP-IP communication to get the job done. You can use a Telnet client (built into Windows) to contact the FTP server and type in what your program will send to the FTP server. Your program is going to be more of an "automated" version of the Telnet client. The Telnet client just helps you learn what to say to the FTP server to get it to do it's thing, before you build your own client program that does the same thing. It's a pretty good learning project.

But I think a lot of the communication going back and forth in your game is probably something that you'll have to work out on your own to suit the game you're building. Using byte data rather than plain-text in the stream will generally be more efficient. But otherwise, it's largely up to you what goes across.

Khan Academy has a good set of lessons on encryption, if you decide you want to learn to encrypt the channel just as a learning exercise.

[stayscrisp]

If you have gone down the SDL and C++ route then you can use SDL_net it's a helpful library that wraps up the more system specific stuff. I have used it before and it was pretty nice.

[LaughingBelly]

Also, if you are making anything more complex than a stick man walking in a treeless landscape, you will not be able to provide a good experience if the entire computation is on server side. You will get a very stop and go movement for both the player and the friends he is seeing in his game client.

In a lot of commercial games, the clients do predictive calculations by using current velocity and acceleration and only take corrective action if the server reported values start to differ by too much. Remember that as soon as your network latency crosses about 35ms, the user will notice the delay if the computation is server side. The client has to compensate this by keeping the other players moving based on a predictive algorithm to keep the illusion that a particular player is still moving smoothly across the map.

The how of transferring data from client to server and back is mostly simple compared to the work of figuring out the other parts (what data to send, how much, how often and what to do when the data gets delayed.)

[Silver1992]

Thanks for all replies. Any good books or articles I should read on the subject?

Also my game wiki is here

[LaughingBelly]

I gathered most of what I know from various websites.

Here is one that explains it reasonably well: FlipCode Article