Why Not Telnet? 'Cos grid computing.

TriadCity being text-based, it would have been possible to design its server to communicate with clients via the standard telnet protocol. This is the strategy taken by classical MUDs including DikuMUD and CircleMUD, and by many popular proprietary MUDs today. It allows players to use their choice of free telnet clients, including ones optimized for the most common MUD experiences such as command aliasing and so on.

Our choice to write proprietary clients for TriadCity is determined by TC's scale and complexity. Unlike conventional MUDs, TC's server has many hundreds of thousands of AI decisions to compute from moment to moment, determining NPC actions and generating the often complex subjectivities displayed to human players. We use proprietary clients to distribute some of the processing. TriadCity is less like old-school client-server with a smart server and dumb clients, and more like a distributed computational grid capitalizing on the horsepower made available by players. These are some of the tasks performed by clients:

• "Natural language" processing. We use a two-stage parser, where the first and more computationally demanding step lives in the clients. Clients send only perfectly-formed, canonical commands over the wire, performing the heavy lifting so the server doesn't have to. While the processing requirement for a single user command is not burdensome, offloading that requirement allows the server to scale more easily to MMORPG levels.
• Distributed arithmetic. Wherever sustained computation is required — for example, 2D vector arithmetic for chariot races — portions of those computations can be parallelized and distributed. Think SETI@Home. In that regard the TriadCity client/server architecture is something like a single distributed computer.
• Character state management. Housekeeping such as hunger and thirst calculations, attribute computations, and consciousness state can live happily in the clients. Much of the arithmetic driving character subjectivity and situational capability can be offloaded.
• Network encryption. Telnet's not secure. TC's clients encrypt network I/O, so your password is safe at Starbucks.
• Firewall immunity. TC's clients allow connection through company firewalls, so we can happily diminish players' productivity at work. Telnet usually doesn't.
• Bandwidth optimizing. TC's clients transmit only when the communication is guaranteed to be correctly formed. The server doesn't have to invest cycles processing garbage.
• Integrated support for assistive technologies. Our HTML5 client implements WEI-ARIA Live Regions; the Java applet has an integrated screen reader.
• Additional security measures. Because we control the clients, it's easy to know when Bad Guys On The Net are trying to poke the server. Swish-and-flick! — into the blacklist bin with them. Easy-peasy.

Most of this architectural logic is about helping the server scale to MMORPG levels without having to shard the game world or add other complexity. We routinely test with 10k simulated players, and despite its significant AI computational load the server does just fine.

Of course, we don't have 10k simultaneous players in real life. Invite your friends.