It all started around 2002 when a bored grad student started to code a client-server online game in "C++". Though the code could hardly be called object-oriented at the time, since it was not more than a hideous mess. As most hobbist game programmers that attempt to tackle on networked games, he started with UDP sockets and rolled his own ordering and reliability mechanism over UDP. Luckily, two very skilled programmers (Nix and Huntta) took charge of the game project and the code evolved from a crappy mess to a respectable píece of C++ code that didn't crash every other minute.
Meanwhile, the bored grad student decided to use his newfound knowledge to write a client-server game engine. It was intended to be a full-fledged networking solution for small-scale, client-server Internet games (game objects, scripting, ...) but this was abandoned in favor of a more specialized engine. Anyway, the ZIG Game Networking Engine was born. ZIG integrates packet compression, data buffers, C++ object serialization helpers, address helpers, timer helpers, statistics, a simple client-server API and other goodies. At its bottom, ZIG contains the same "roll-your-own" transport protocol which is layered over UDP.
ZIG evolved for many years (about 6 years). It changed from a multi-threaded engine to a "selectable API" engine (single-threaded or multi-threaded with various threading strategies available) and finally to a strictly mono-threaded, non-blocking API. The conclusion we finally reached was that multithreading is too nasty to debug and that the bottleneck is the network anyway, not the CPU. Though polling is inefficient, we found that the added latency and CPU overhead was never a serious problem, at least for our game projects. The peace of mind of debugging a mono-threaded application was well worth it. And, if it worked for Quake, why wouldn't it work for us? ZIG was applied successfully in two games that we know of: Milan Mimica's Sparklet and Singular Studio's Hoverkill (unreleased commercial game). Both Milan and Singular Studios contributed heavily to the ZIG engine.
In mid-2008, the bored grad student was already working with another grad student that actually knew how to use C++ properly, and that already contributed hugely to the ZIG codebase (for instance, he added the streams feature, which made the ZIG library much more useful). The bored grad student finally noticed that people might want to use ZIG's underlying transport protocol, instead of using the higher-level, client-server game API provided by the ZIG library. This would also be an opportunity to redesign and properly document our streams-based protocol. By the way, we noticed around 2006 (2007?) that a thing called SCTP existed. Who knew? Games programmers were known for a long time now for reinventing TCP over and over. But we actually reinvented SCTP. That was surely a good sign, and a welcome improvement on the wheel-reinvention community!
And so the "ZSTP protocol" was extracted from the bowels of the ZIG Game Networking Engine. Not only extracted, but practically reborn as decent C++ code, thanks mainly to the new grad student. The bored grad student currently hopes to remain relevant due to his self-proclaimed ability to apply his laziness to API and library design -- the library must be easy to understand and use by lazy people like him! The API perks such as packet compression, and data packing and unpacking for dummies are a must. Download the library and start using immediately! Maybe we should change the name to Prêt-à-Porter Stream-Sockets Library? We don't know.
Maybe someone will find our work useful, maybe not. We keep hacking on it because it allows us to learn, and it allows us to have complete control over our code. Not only control in the GPL sense (source code for SCTP is widely available, after all), but control in the sense of having a stronger mental model on how this whole stack of networkey things works. Game programmers write game engines to learn about games. Network game programmers write game "netcode" to learn about networking for games. Something like that.
| Back to the main page |