I've already spent three weeks on the protocol, and though the blueprint has (hopefully) been drawn, I've barely broken ground on building the house. Yes, this does seem at odds with my commitment to using existing libraries wherever possible. So before I bore you with the technical details, I want to explain two things: why I didn't just use a common protocol for which clients are readily available, like telnet or HTTP, and why I chose to write a custom protocol from scratch rather than use something like object serialization to XML.
As I mentioned before, Trade Wars 2002 has retained a small but faithful following. I believe the one characteristic that unites these players is that they're tinkerers. Many of them are programmers. And from Telix to SWATH, these dedicated players have always loved their scripts. (I was one of them; some of my scripts from ten years ago are still available from the SWATH script library.)
Scripting in Trade Wars was once a subject of controversy. For those who weren't drawn to it, it seemed to spoil the competition. Some even called it cheating. But there was never any way to prevent it, so it was tolerated, then accepted, and finally became the norm — but only in Trade Wars. Most modern games use closed-source clients, and place severe restrictions on enhancing or scripting them, if they allow it at all.
From the outset, I've designed my game with scripting in mind. I want to keep the game enjoyable to casual players by incorporating features like global cooldown timers to give human reflexes a chance against scripts. But rather than merely acknowledge the inevitability of scripting, I'm officially encouraging it and making it easy. I want to entice the authors of Trade Wars helpers and scripts to play my version. I want scripting my game, or even developing an entire custom client for it, to be an opportunity for inexperienced programmers to write something exciting. Above all, I want every player to enjoy the fruits of a competition for the best ways to collect, analyze, and present the game data.
I came up with several criteria for the format of the protocol's messages. First, I wanted them to be human-readable, for easy understanding, logging, and debugging. This ruled out binary. Second, I wanted to maximize content and minimize bandwith. Bandwidth shouldn't be an issue in this century, but I envision my game being played on smartphones, and the telcos are still outrageously stingy with their data plans. So this ruled out XML. Third, I wanted the messages to be extremely simple to generate and parse in any programming language.
I eventually settled on a properties list crammed into a string of comma-separated values. Every message is terminated by a newline. A message might look like this:
ts=1307312894,type=SERVER_HANDSHAKE,name=Official Test Server,version=1.0,protocol=1.0
I've been working on an XML document describing the various message types. It follows an XML schema, which I suppose makes the schema meta-meta-data. From this master XML document, I'll generate the Java library for reading and writing messages. Details next week!