Winsocks the Cat Rocks the Hill

After a long time of wanting to tackle some netcode. I finally had the opportunity to do so.

After reading this great article by: @bshokati on the Code Project, I had a good baseline for taking the next step and making some kind of client server program. I decided to keep it simple, I’d make a chat server that spat messages back and forth. Easy enough.


After a little bit of re-reading the code and getting a feel for everything I had a simple chat server. You could connect via IP, set your chat name, and send messages back and forth. Whoo. Such fun. That program was two, separate applications as well, just for the sake of simplicity. One application for the Client and one for the server. I knew in my next step I’d want to alleviate this so I setup a common folder and separated everything into Client/Server/Common code bases and tied them all together with a Main code file.

After I had all the code organized I wanted to step it up and make a simple game, to make a good base for when I add netplay to my 3D School Maze engine. I decided, since I love to abuse the Console window, I’d dust off my old Textmode game skeleton and make a game with smileys running around. I decided to make a textmode smiley deathmatch.

It was simple, the game would be one on one with you shooting the other player with an arrow. Easy. One client, one server, that’s it. Coding the game was easy enough because I already had all the drawing stuff setup, the harder part was figuring out how and when to send the data across the way to keep the games running and the players playing against each other. First I thought, hmm…what if I send the keycodes and have a keyhandler take care of the movement. Then it’ll be like you’re playing someone with a controller right next to you.


This is a good idea in theory, but data packets on the internet sometimes get stuck in traffic and things get out of sync as I quickly learned. Bright eyed and bushey tailed, I fired up my Smiley Deathmatch and started a game 1 on 1 connected via localhost. I moved around and soon I realized, “OMG these are not in sync!” as I looked at the two different windows.

After some thinking, I was on the right track I thought. Sending the keycodes back and forth is a good start, but there needs to be a way to keep things in sync. After some reading, I read about Server Authority, where the Server has final say in everything that happens. So I thought ok, the player can use his keys, and send to the server, and vice versa, but after the server processes the keys of him and the client, he should send a sync packet and sync up all the players.

I then added the states, positions, etc. to the packet, and sent them over. “Viola!” The games were in sync. It does a good job of keeping things in sync, there is no prediciton on the part of the client like “Dead Reckoning” to interpolate where things might be, before the sync packet is sent. This doesn’t seem to be a big deal though as I don’t see things jumping around like crazy. In a 1 on 1 game, with relatively little to keep track of this is fine. Though I imagine that if you scale things up, they may get crazy. It’s a good simple test and I’d like to share with you.

Keep in mind the code is just quick and dirty as it was basically a test so there’s no “professional” coding scheme just basic conventions and trying to get it coded up as quickly as possible so it may be a little hackey, but hey it’s a nice learning example and maybe can help some people out as I did not see very many if any at all examples of simple Winsock games. It’s not meant to do any damage, but I am not liable for any, and use at your own risk.

Enjoy, and make some Cool Stuff!

Download Source and EXE

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>