Served: The Server Server Part III
In the previous parts, we talked about the beginning and end of Served, a bit of an over the top project to create a reusable server framework for game development.
To summarize (in case you forgot), the basic idea was to write a Node.js server, build it as an executable, then launch that executable standalone or from the game client as a separate process. From there, the server could be used for a single player game or allow connections from other players. There's more than a few issues with this idea, but we've covered a fair number of them already. And, besides, at the time I had an absolute blast working on it. Unfortunately, my enjoyment dwindled as time went on and all those issues started catching up with me.
Ultimately, however, the project was a nonstarter not because of the flaws in the design, but because I didn't pay my dues in learning the technology I was working with. In my haste to build this thing, I only researched as far as the matter at hand required. And I ended up digging myself into a hole. I didn't know a damn thing about NAT's, public and private IP's, or even how a server truly works. I didn't know any other way a game could run a server. Hell, I didn't even consider why the back and front end of most games share a codebase. I was hotheaded and naive. But I learned.
Around February 2017, several months after I had abandoned Served, I was working pretty extensively with Haxe. It got me wondering if Haxe had any networking capabilities. The answer was a resounding yes. The only hurdle was, short of a few chat samples, there wasn't much in the way of tutorials. All I had was hit or miss documentation and an assortment of existing libraries, such as haxe-ws and mphx.
That's how Served got its second wind. From the start, Served was always a research project, I just did a poor job with the research part. This time, I was set on doing it right. It took a while and there were struggles, but I got there. I learned about all the facets of networking that I had neglected the first time around. I learned that TCP isn't so bad. I learned a bit about NAT traversal, and made peace with the fact I may need a public rendezvous server to handle connecting clients. I even learned that my arch-nemesis from the days of Minecraft server hosting, port forwarding, serves an actual purpose. Who knew?
With sufficient knowledge, I got started on Served 2.0, my own Haxe networking library 'hxsvr.' With a basic understanding of networking fundamentals, and the source code of a few existing libraries to look at, development went much more smoothly. I even lifted some techniques into my implementation. After all, I wasn't out to reinvent the wheel here, but I wanted to customize the rims.
If you'd like, you can check out the source code of hxsvr over here. Fair warning: At the moment, it's pretty barebones. Currently, I only handle sending strings and parsing as JSON. Definitely not idiot proof and probably not secure. But I'm still learning. So far I can create a server on desktop and connect through desktop and Flash (don't ask) clients. I've successfully connected to servers on my local network and externally via port forwarding. As a bonus, the codebase also is already set up so I will be able to handle single player and multiplayer connections to a local or external server. Certainly better results than the original Served.
There we have it. All caught up on the history of Served and its new form. There's still a lot of work to do on hxsvr, like single player support, a better packet handling system, and maybe toy around with connecting clients via a rendezvous server. I also have a small game project I'd like to build to put the system to work. We'll talk about it some more once I've made some headway there.
To summarize (in case you forgot), the basic idea was to write a Node.js server, build it as an executable, then launch that executable standalone or from the game client as a separate process. From there, the server could be used for a single player game or allow connections from other players. There's more than a few issues with this idea, but we've covered a fair number of them already. And, besides, at the time I had an absolute blast working on it. Unfortunately, my enjoyment dwindled as time went on and all those issues started catching up with me.
Ultimately, however, the project was a nonstarter not because of the flaws in the design, but because I didn't pay my dues in learning the technology I was working with. In my haste to build this thing, I only researched as far as the matter at hand required. And I ended up digging myself into a hole. I didn't know a damn thing about NAT's, public and private IP's, or even how a server truly works. I didn't know any other way a game could run a server. Hell, I didn't even consider why the back and front end of most games share a codebase. I was hotheaded and naive. But I learned.
Around February 2017, several months after I had abandoned Served, I was working pretty extensively with Haxe. It got me wondering if Haxe had any networking capabilities. The answer was a resounding yes. The only hurdle was, short of a few chat samples, there wasn't much in the way of tutorials. All I had was hit or miss documentation and an assortment of existing libraries, such as haxe-ws and mphx.
That's how Served got its second wind. From the start, Served was always a research project, I just did a poor job with the research part. This time, I was set on doing it right. It took a while and there were struggles, but I got there. I learned about all the facets of networking that I had neglected the first time around. I learned that TCP isn't so bad. I learned a bit about NAT traversal, and made peace with the fact I may need a public rendezvous server to handle connecting clients. I even learned that my arch-nemesis from the days of Minecraft server hosting, port forwarding, serves an actual purpose. Who knew?
With sufficient knowledge, I got started on Served 2.0, my own Haxe networking library 'hxsvr.' With a basic understanding of networking fundamentals, and the source code of a few existing libraries to look at, development went much more smoothly. I even lifted some techniques into my implementation. After all, I wasn't out to reinvent the wheel here, but I wanted to customize the rims.
If you'd like, you can check out the source code of hxsvr over here. Fair warning: At the moment, it's pretty barebones. Currently, I only handle sending strings and parsing as JSON. Definitely not idiot proof and probably not secure. But I'm still learning. So far I can create a server on desktop and connect through desktop and Flash (don't ask) clients. I've successfully connected to servers on my local network and externally via port forwarding. As a bonus, the codebase also is already set up so I will be able to handle single player and multiplayer connections to a local or external server. Certainly better results than the original Served.
There we have it. All caught up on the history of Served and its new form. There's still a lot of work to do on hxsvr, like single player support, a better packet handling system, and maybe toy around with connecting clients via a rendezvous server. I also have a small game project I'd like to build to put the system to work. We'll talk about it some more once I've made some headway there.