[MUD-Dev] MMORPG/MMOG Server design

[John Buehler]

Sean Kelly writes:
> On Wed, 5 Mar 2003, Caliban Tiresias Darklock wrote:

>> The single biggest obstacle I face when writing code is my own
>> prejudices. I commonly view the next guy -- whether it's the end
>> user or another developer -- as a sadistic bastard who will not
>> only completely misinterpret the purpose of the system, but
>> actively attempt to break it in some misguided attempt to prove
>> his superiority. In cases where the operations are not
>> time-critical, this approach tends to result in well-documented,
>> robust code that simply doesn't break. In time-critical
>> operations, however, it just bumps up the hardware
>> requirements. A lot. In cases where your goal is to provide as
>> many parallel operations as possible, you also reduce the
>> capabilities of the software.

> If you ask about library robustness in a C++ forum, the popular
> answer from STL developers is "document the requirements and
> limitations and woe unto those who don't follow them."  Because of
> the potentially diverse application of the STL, the designers
> cannot make any guesses about or optimize for any specific uses.
> The result is that the STL contains little or no error checking
> and all requirements are documented.  IMO this is a perfectly
> reasonable approach, though it can lead to disaster if your
> library is being used by inexperienced programmers.

In our component research at Microsoft, we went the route of
documenting preconditions.  The documentation was then processed
into the code that checked the preconditions (to ensure that the
documentation was correct and to save the hassle of coding up
mindless boilerplate) and the preconditions were checked on every
call unless explicitly turned off.

Precondition checking would only be turned off after testing was
completed on the caller down to the point of 100% code and arc
coverage (we weren't gonna try for 100% path coverage).  So long as
the preconditions for the calling code were satisfied, the called
code wouldn't be invoked in a way that violated its preconditions.

Next step: leave the preconditions on the calling component active
until the caller of that code has been exhaustively tested.
Naturally, the preconditions can only be reliably turned off for
trusted clients (i.e.  tested clients).

There's a reason we went with small components.  This kind of
development doesn't like complexity at the component level.
Abstract models get too complex, the preconditions get verbose, and
testing all code and arcs takes an eternity.

As stated in this thread already, it's important to understand the
problem space that you're tackling if you want to go this
structured.  If you don't, then component contracts become fluid,
and you're constantly refactoring or just plain redesigning your
system.

JB


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev