Devlog: TCP Sockets and Events

In my quest to (for some stupid reason) create my own game engine and eventual working game, I have delved into the deep magics. If you have read my past posts, you will know that I am working on a isometric MMO/simulation/RPG thing formerly called GrugNet and now known under the project name ‘Origin’.

Originally, Origin was running on a Flask server using websockets to communicate with the client running in MonoGame, a game framework based off of XNA where you get a basic wrapper for content loading and a abstracted GPU API so you don’t die on the spot, but pretty much everything else is built from scratch. This was working fine until I needed to send data via UDP and not TCP (which is what websockets use), at which point all hell broke loose. I was faced with a decision: Rebuild everything in C#, as MonoGame uses C#, or rebuild my netcode by hacking together Flask and Twisted in some awful way that would probably destroy my very soul. I chose a full rebuild as I was interesting in learning about sockets in .NET as well as the built-in TCPClient and TCPListener.

Now, after many trials and a short walk through the plains of madness, I have arrived at a functional foundation for all of my network communication between my game client and server. This uses the aforementioned TCPClient for the client, TCPListener for the server, and a custom Event Manager for handling bytes sent through the network stream (which is secured via TLS/SSL using a Cloudflare cert I mashed together into a .pfx). While the actual socket stuff is hidden behind these two wrappers, the event manager I am fairly proud of. It allows me to send/receive a JSON serialized bundle of data (represented as either a NetworkEvent or NetworkResponse data transfer object) between the client and server, handle the type of event sent (based on a enum for ease of use), and then respond accordingly or perform business logic depending on the event. It also automatically performs error handling and responds using a custom error event, which is just a NetworkResponse that was fancied up a bit.

Now that this is in place, it is very easy for me to perform whatever I need on the client or server, be that authentication, map generation, rendering, etc, and then communicate all that data to the client/server in a thread-safe and memory-safe way. I can also do DB queries in this way as it is all abstracted/encapsulated.

Next up: Rebuilding procedural tile-map generation and communication of that data in JSON format for rendering on the client end. I already had this working in Python, so it shouldn’t be too bad.


Leave a Reply

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