The Museon Manifesto

From Museon Softcode Package

Time and again, people have told me "MUSH is dead." In most cases, it means that they themselves have lost interest, burned out, or simply failed to adapt to the changing environment.

People come and go, get jaded and burn out; games start, and sometimes flourish; others close before they open. The reality is that MUSH (and MU* of all varieties) will be with us for a long time to come.

The time-consuming process of starting a new game can be daunting, to say the least: there are help files to write, code objects to deploy and change to fit the particular genre, and politics to overcome. One must find staff, coders, and players; and, most importantly, be workable for a game to succeed. One of the more difficult challenges is writing code.

Coding can include everything from the "basics" (such as a softcoded +who command, which most players take for granted), to involved character stats generation systems, combat code, and more. Each game has its own specific set of needs in this arena, but in most cases this is responded to by attempting to find coders who can work full-time or part-time. While this can work, there are several drawbacks:

• There are more games than coders. Not every game will get their own coder, and coders are sometimes unable to handle more than one game.
• Being in short supply and high demand, coders often take on more projects than they can handle.
• Not all code projects are created equally. The quality of completed code isn't known until a game has become dependent on it.
• Coders may leave suddenly, mid-project, for many reasons, including game or RL related issues.
• Building a game from scratch often means creating new versions of commands and systems that have been written before, which means a lot of energy goes into duplicated efforts, ie, reinventing the wheel.
• Most of these one-off coding projects do the same things in very different ways, and very few are ever documented. Many times, even the original coder won't understand the code.
• Coders come and go, and often an incoming coder would rather scrap a half-finished system and start from scratch, taking a game back to square one.

This is by no means an exhaustive list, but it helps to illustrate that the current methods leave plenty of room for improvement.

The Museon project is an attempt to provide one possible solution to these problems. This isn't the end-all be-all, but hopefully the results will be helpful to some people. The idea is this:

If every game needs coders, and there does not exist a 1:1 relationship of games to coders, there are three possible solutions:

1. Have fewer games. Not exactly a viable option.
2. Have more coders. Tricky, as coders don't grow on trees.
3. Have coders write code that is used on more than one game.

We're definitely going to try and tackle #2, offering educational resources (classes, tutorials, encouraging code discussion). However, the main focus at this point is the third option, and figuring out how to make this work.

• This is quite an ambitious undertaking, and will require a great deal of effort to keep it progressing, and on track. Here are some thoughts on the subject:
• Start with discussion, both general and specific, both in terms of user functionality and good coding practices.
• Define projects and groups, where projects outline a specific development effort, and groups designate which people are working on these projects.
• Develop standards and conventions to be used across all projects, so that resultant code is easier to document, has greater interoperability, and so that duplication of effort can be reduced.
• Start each project with a discussion and subsequent formalization of goals, which will help maintain its focus.
• Start each and every project with a clear understanding of roles and responsibilities of the members of the group working on it.
• Code should be beta tested and reviewed by other Museon participants before being officially released. Feedback and evaluation, modifications and fine tuning should all be part of the process.

Again, this is still just the beginning, and the points listed here do not attempt to cover every possible issue. This should hopefully demonstrate the spirit of the ideas on which the Museon is founded.

(original rough draft written by nails)