That wasn't an assumption, on the contrary, it was the benefit of the doubt.
So then you admit to assuming the game will have similar logic, which is a far
more flagrant assumption. Even the number of ways to communicate over a network
(with standardized network protocols) is limited compared to the number of
ways to configure software logic and game mechanics.
Because both systems use databases or (might) require some level of persistence
does not automatically establish the overall solutions with be even vaguely
similar.
Your examples are insubstantial.
I enjoyed the article.
I think, Mr. Koster is speaking in a very abstract sense. In practice however,
how a protocol is implemented can affect both client and server operation
significantly. I think there are enough examples to safely conclude, this is a
fact. [Hint: take a peek at a few RFCs]
An example (inspired by one of Mr. Koster's comments) might be the difference
between, whether I chose to implement a turn-based MMO with an HTTP server
(without using websockets, AJAX, etc), or based it on (some vanilla derivation
of) DikuMUD.
Do they both manage and provide some representation of some abstract
simulation? Probably. Do they both offer some level of persistence? Possibly.
Is an HTTP server, which is designed to serve requests, the same as a TELNET
interface designed for bidirectional "text-oriented" communication?
Only if you decide to abstract everything into "datastreams" (with little
regard for time), which Mr. Koster appears to have done, and conclude that only
the clients representation of that data changes significantly.
I'm a Pepper too, btw. (For the record.)
