Network programming

Network programming

Emblis 11 Jan 2015 22:10

I have been working on a multi-player network game for the past week, mostly for learning. Since I do not have any previous experience with it I figured I would ask if someone else got anything to share.

What is good and bad practice when it comes to network programming?

How do you write robust code considering all the additional problems that network programming introduces? (Latency, packet drops, connection loss, etc)

Do you use any libraries? I am currently only using the Socket and UDPClient class.

Re: Network programming

PiscesMike 12 Jan 2015 18:41

Hey Emblis! Man, I missed you by only a couple minutes the other day in chat… 8-( Ah well.

One word: Serialization. (At least I think that's what RB called it)
Basically, it's condensing everything needed to describe a certain player into a single datagram. In that, you would have things such as Playername (to know what player this data applies to - could also be a GUID or 4 digit code, just something to separate the players from one another), Playerhealth, position, weapon type, ammo amount, etc. The idea is that this one data packet would contain all the information needed to recreate the player on a remote computer. Then all you have to do is transmit the one packet, deserialize it (convert back into program variables), and render the player to the screen where you check for collision. You may have to have several serialized objects. For instance, the player him or herself, and another for bullets as they travel through the playing field. Bullets would probably be a little easier to serialize… maybe just a color that represent the players laser shot, a position, and a velocity. Another example would be text messages. They should be serialized to contain the name of the player sending a message, a text color for the message, and then the text of the message.
Those are some basic examples. As far as networking goes, the only thing I've actually done is a chat program. Pretty simple, but gets complicated when you want to add various text colors, smilies, or the ability to private message.
Another big thing to consider, perhaps more important than the serialization, is your network topology. Will you use client/server, or peer to peer? Each has its own advantages - client/server can be slower, but more reliable, and peer to peer can be faster, but you have to take extra precautions for data loss.

---

"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets

Re: Network programming

rbwhitaker 13 Jan 2015 03:40

It's hard to do justice to the topic of "networking" in a single post. It's a large field, and like you said, there are lots of complexities that come up with it. The devil is in the details.

You might consider using lidgren. It's rather popular. I think it actually ships with MonoGame. To be honest, though, I looked into it when I was doing my networking stuff in my last game in November. It didn't take me too long before I decided I'd have more control over things if I built my own networking library, so that's what I went with. It worked pretty well, doing it myself, but I also didn't address dropped packets or latency. So I kind of cheated by not doing the hard parts.

(My networking library was simply based on the .NET Framework's TcpClient class, and as PiscesMike mentioned, I just serialized everything to a byte array and pumped it into a stream object. I initially used the built-in serialization mechanism, but later wrote my own serializer because I could get it down to about 10% of the size.)

You'll be doing far better than not if you can find a way to simulate lost packets, slow delivery of packets, out of order delivery of packets, and connection losses. You don't want to have to go hunt down a "real" network with those problems to test it out. Simulation is the way to go. So if you build your own, make sure you account for a way to do that. (Lidgren has simulation built in.)

I know that's not much of a full answer, but perhaps it gives you some things to think about.