|
Code Design | |
There are lots of styles of code design on MUSHes, and a few issues to consider when designing:
Portability is something that most designs either design totally for, or not at all for. The choice really depends on the author's preferences and what the code is intended to do.
When I began designing my combat system, I decided that I wanted to make it portable so that I could share it with others in the MUSH community. It turns out that slightly later, a MUSH I was on needed a combatwiz and a combat system. I ported over the system I had with a minimal amount of effort (I had to change some hard-coded dbrefs -- port took literally a few days) and we were up and running.
At the same time, things that are very MUSH-specific, such as it's +who probably don't need to be portable. Everybody wants to code their own +who because nobody else quite has the "just right" +who code out there for your MUSH.
This choice is really up to the designer. If a designer wants to write portable code they will. If they don't, even if they write the system the code won't end up being portable, because there will be many many little small things that don't work cross-systems.
Writing flexible code is something that I can't recommend it strongly enough. Inflexible code does have it's place, but it is a very small place and really is only appropriate under certain circumstances.
So what does flexibility mean really? I'm using the definition that flexibility that says it is a which allows easy modification, additions, and removals. So for my combat system, it should be easy to modify it to use a different method of determining the winner of a battle, should be easy to add and remove commands as well as weapons from. It should be easy to create special-case weapons, and vastly different weapons (even to the point of using force/magic powers to create a barrier (armor) for yourself).
The biggest drawbacks to flexible code are that it takes longer to write and is more difficult to write, and that it is often slower than more traditional inflexible code.
This slowdown isn't a big deal unless the code will get called very often and hence need to be fast, such as access routines to get data out of a player's character data, or code to update player's "fatigue" factor.
Efficiency plays a big role in some systems, but a very low role in others. Unfortunately the systems that often need to be more efficient are the ones that really cannot be optimized without compromising either functionality or flexibility.
For example, a system that allows judges to +jail a player probably doesn't have to be that efficient; players shouldn't be getting jailed all that often. However, the combat system had better be reasonable efficient and fast, otherwise players are going to get fed up with machine lag and waiting whenever a large battle or two is going on.
The best solution to make code more efficient is to find a way to rewrite it, or eliminate the need for it altogether. Unfortunately this is often not feasible, and you just have to write the code. In this case, I have a list of helpful suggestions:
 |
Home | MUSH | Theory | Sitemap | |