MUD Code Update Life-cycle

I'm sure some of you probably wonder how we chose what parts of the code to update, what has priority over others, etc. So, that is what I'm going to talk about.

The first stage is, of course, coming up with the concept of what needs to be coded. These concepts can come up from suggestions from the mortals (you guys), on the forums, in-game, or can be an idea hatched by an immortal.

The second stage is discussion among the immortals about the concept itself. The kinks and issues are figured out and solutions, or at least possible solutions, are brought up. This is where most code update suggestions actually die due to them either being wildly unreasonable or providing a serious disturbance of the balance of the game mechanics. However, just because it dies does not mean it'll always be dead, something in the future could change and an idea may be revisited later. Case in point: strong/gifted channeling.

Once it's survived the 2^nd stage, it's on to determine priority. Priority is determined mostly on the complexity of the update vs. the time to implement vs. its importance. If we have an update that is not important but can be done in a few minutes and is simple, it is likely to get a high priority just because its easy. However if it's a very large and complex update, and it isn't important or doesn't add much to the atmosphere of the game (e.g., breaking rooms into sub-rooms so people in the same room can be grouped differently and not hear each other), it will deemed a low priority task and very likely might never see the light of day.

Bugs are given a high priority and bugs that result in crashes are granted a Very High priority. Most very high priority bugs are fixed shortly within the time of the initial crash.

Once a priority is chosen it get placed on the to-do list and slotted into one of several categories: the " must be done now" (currently the only task like that which isn't a bug fix is the slag command), the "work on these as you get time" (mostly larger 1-2 day coding projects followed by a couple days to debug them), and lastly "don't start these yet" which are the larger, upwards of a month or two projects. The channeling update was one of those.

Large updates are done singly; we won't work on 2 major updates concurrently because of the nature of the task and the resources we have available. However we will throw a bunch of small 1-2 day updates in with the Major release as well. This gives the programming peoples (myself, Kimadi, Luthien) time to take a break from the major task and for Kimadi to fix everyone else's code.

Once the major update is complete, any minor projects being worked on are finished and everything is tested and then promoted to the live player port. Usually, after any major update, we discover after we go live that you mortals did things we didn't anticipate and so we have a round of fixes as a result.

We don't like to start a new project until after the bugs have been worked out so we're not maintaining more than 2 separate code bases (the live code base and the test code base). But once bugs are worked out and the mud is stable again with the new feature then programming begins on the next update.

With the amount of time/effort/work and money that goes into this and with none of us getting paid, it's a miracle that it still happens at all. With Kimadi joining the team we hope to see an increase in the amount of bug fixes and real updates.