[Scrymud] Developer Coordination, Goals, Organization, Standards, Extensability, blah de blah

[Edward Roper]

Alrightie then =)

After talking with just about everyone who has anything to do with ScryMUD
code it has become rather apparent that it is time to become slightly more
organized. The code is currently under moderate to heavy development by
several people and we've all tended to do this development in a cave. It has
also become clear that the ScryMUD engine is about to undergo a huge redesign
through which large portions of the code will change completely.

I've heard people talk about extensibility others about speed. I think we all
need to come to some sort of mutual agreement and understanding. I also
suggest that create a very detailed design spec before _any_ of this is
started. There's nothing worse than investing many man-months in a project
only to re-tool six months down the road, yet again ripping out all of the
code that was just written.

I'm not suggesting we introduce any sort of b.s. corporate style beuracracy
into this project as it would be highly unmotivating. This is after all an
open-source project written and maintained through a collaborative free-time
effort. I'm simply suggesting that we actually generate some collaboration.

I'm going to address some high-level concerns and issues in this e-mail and I
fully hope that there will be comments and discussion generated from it.


1] Coding Style Standard
   

*       INDENT: 3 spaces for nesting indentation, this means:
                int main() {
                   printf();
                }
        Soft tabs: all spaces for indentation, NO TABS

*       NO TERTIARY OPERATORS: Grock said so.

*       ALWAYS USE BRACES ON CONDITIONALS: even if they are 1 liners, i.e.
        This is another Grock said so.

                if ( pc.isHungry() )
                   pc.doSomething()

                Should Be:

                if ( pc.isHungry() ) {
                   pc.doSomething()
                }

*       I believe Grock uses the default emacs format style, perhaps he said
        K&R style. I don't remember, he's going to have to clarify on this
        one.

*       I personally would somewhat like to see us use K&R's rules on brace
        placement, but I'll leave that open for discussion. I'm pretty sure
        it's not the way it's done now, so maybe better to not fiddle with it.

        These rules state:

        if ( x is true ) {
           we do y
        }

        int function( int x )
        {
           body of function
        }

        Note that the closing brace is empty on a line of its own, except in
        the cases where it is followed by a continuation of the same
        statement.

        do {
           body of do loop
        } while (condition);

        if ( x == y ) {
           ..
        } else if ( x > y ) {
           ...
        } else {
           ....
        }

2] Extensability & Speed

        I believe that code which is extensible and easily maintained is
        better than difficult the extend and maintain code that runs twice
        as fast in 90% of all situations. My vote is that ScryMUD falls into
        that 90%. There are some places in ScryMUD that can and probably
        should be optimized, but not at the expense of extensibility.

3] Portability

        I havn't tried in a while but I would like to see ScryMUD compile and
        run on at least the following platforms:
                * Linux
                * FreeBSD
                * Solaris

4] Configurability

        After a quick glance I've found about 50 different MUD codebases and
        1,728 running MUD servers. Pretty much every one of this was written
        with one persons needs in mind, one type of environment, one set of
        rules. The licesnses vary and most of them are the results of building
        upon someone elses codebase. Personally I find this ridiculous.

        I believe that while we are in the process of redesigning core
        components of ScryMUD, we should make it as configurable and flexible
        as possible. Whether or not we plan on using a feature a particular
        way I believe wer should provide an option. This would not only make
        the codebase more useful to others who wish to run their own Worlds,
        but would also make the codebase more appealing to MUD developers
        working on other MUD's who would be inclined to submit patches, etc.
        back to the main effort.

5] Modular code?

        This one is up in the air with me and I'm not sure if it would offer
        any benefit whatsoever, but I'm throwing it out there anyways. Dynamic
        loading modules via. libdl could offer the ability for "plug-ins".
        I've written code to do this before and it's not in the least bit
        difficult, or even tricky. It simplies requires a clear design from
        the start.
        
Anyways, in closing... I havn't proof read any of this and I don't even know
if it all makes sense. I'm at work and I've walked away from the keyboard
probably 30 times since starting it. Let me know if you've any questions and
by all means _please_ comment.

Toodlios,
Khaavren