Name: Anonymous 2015-03-19 20:04
In order to make the server incredibly safe, I would estimate that over half of the code is for error checking. For example, even though all Blakod objects’ references to other objects are always valid, the return value of GetObjectByID is checked against NULL. Instead of using the now-common practice of using assertions to abort a program when unforeseen circumstances arise, the server treats these as possible error conditions and logs the problem, instead of aborting. Since even a single crash could cost hundreds or thousands of dollars of customer service time, this was deemed crucial to the game’s success.
Since there is only a minimal amount of game-specific code in the server, the overall design of the server is quite clean (and fairly obvious). The heart of the server is the Blakod interpreter, which runs the actual game code. Blakod calls are made when messages are received from clients or timers expire. Since the Blakod interpreter is single threaded, only one call into Blakod exists at any time. This puts several demands upon the interpreter. First, it must be rather fast, so that the server does not become backed up by client requests. Second, it must endeavor to prevent infinite loops or infinite recursion in Blakod so that one poorly written Blakod function does not hang the entire system.
To support the Blakod interpreter, the server has modules that handle the storage of Blakod objects, Blakod list nodes, Blakod strings, Blakod resources, Blakod strings, Blakod timers, and callback functions. These callback functions, called C code functions, exist so that Blakod may interact with the server, since Blakod has no inherent input or output.
The server’s primary task outside of Blakod interpreting is keeping track of network connections made by clients. It needs to verify user logins, allow administration of the game, and parse client messages from the network to send the necessary messages to Blakod.
Since there is only a minimal amount of game-specific code in the server, the overall design of the server is quite clean (and fairly obvious). The heart of the server is the Blakod interpreter, which runs the actual game code. Blakod calls are made when messages are received from clients or timers expire. Since the Blakod interpreter is single threaded, only one call into Blakod exists at any time. This puts several demands upon the interpreter. First, it must be rather fast, so that the server does not become backed up by client requests. Second, it must endeavor to prevent infinite loops or infinite recursion in Blakod so that one poorly written Blakod function does not hang the entire system.
To support the Blakod interpreter, the server has modules that handle the storage of Blakod objects, Blakod list nodes, Blakod strings, Blakod resources, Blakod strings, Blakod timers, and callback functions. These callback functions, called C code functions, exist so that Blakod may interact with the server, since Blakod has no inherent input or output.
The server’s primary task outside of Blakod interpreting is keeping track of network connections made by clients. It needs to verify user logins, allow administration of the game, and parse client messages from the network to send the necessary messages to Blakod.