Pour command

[Sanvean]

Just to clarify - I think it's great to see ideas posted on the board. Sometimes they're things that haven't popped up before and they spur the coders into doing something new and interesting.  If you look back at the weekly updates over the past few years, there's actually a lot of ideas that got implemented due to discussion on this board, mostly by Nessalin.  

Other times the idea or ideas may fade into obscurity and move to the dim nether regions of the board.  If it's an idea you really like and would like to see in the game, feel free to email it to me and I will enter it into our database of bugs and ideas. It may fade into obscurity there as well, but it has a better chance of a coder looking at it. There's a little under 1000 entries in it at the moment, just so you have some idea of the scale of things.

When we're looking at coding, things that influence whether or not to do it include:

1. Ease of coding.  A lot of times people will tell me that something is very easy and sometimes it is, other times not so much.  Sometimes a change made in one place will affect other pieces of the code in an unexpected manner. Big complicated projects often have to wait until someone has a lot of spare cycles to devote to them.
2. Impact on the game. Does it affect a lot of people or a small number?  Something that affects a lot of people is more likely to get worked on. Is it something that means we need to take the game down for a while to do? That's negative impact, and something would have to be pretty darn high in other areas to justify that.
3. Amount of work involved. How much gruntwork, in the form of updating or building objects, or producing documentation, is necessary?
4. Urgency.  Is it a feature that is currently unusable?  Then it's high priority. Is it something that works, even if suboptimally or has workarounds right now? Lower priority.

For example, I made a change recently that affected only the Tan Muark players. Low impact and urgency, but it also took me about ten minutes to do, had no additional work involved in it, and was a nice, cool little atmospheric touch. Brewing, for another example, while high impact and involving relatively easy (but extremely lengthy and tedious) coding, also has a very large amount of work involved and is low urgency because it works for the most part and many people use it in the current form.

I've posted from our mission statement before, and will recap the section on our priorities:

The priority list for working in any area of the game, whether it's coding, quests or building, are:

1. Stability: Increasingly, we're working towards less lag and longer uptimes. Being able to use the testport to test possible crash bugs will move us even further in this direction.
2. Balance: Making sure code and building do not unbalance the game. This is pretty important, because (as noted above) a seemingly small change can end up having a major impact.
3. Consistency: Adhering to the existing documentation. while continuing to expand it. Making code and syntax consistent overall.
4. Accountability: Discussing changes ahead of time so there is a consensus on them. Documenting changes thoroughly and letting people know what's new so they can incorporate it in their quests and building. Coding things that are useful to other staff members, and making sure there are no bugs in the code which create problems for people running quests or building.
5. G-Factor: Things that make players go 'Gee-whiz, that's cool!' Anything from a small building detail to a slick piece of code or an inventive, atmospheric quest.

Our coders are at different levels of skill and enjoy working on different things.  I'm at the lowest level - I can mess around and change some stuff, but a lot of projects are way beyond me.  And the really skilled folks aren't as interested in the tedious tasks - they want something challenging - an interesting puzzle to solve.  

Beyond all that, most of us have other mud work to do as well as our pet projects, and even that's aside from the tedium of RL, like fixing dinner, doing laundry, working for a living, or the occasional social excursion.  In my opinion,  the amount of work that goes into the mud on a weekly basis is impressive, and expecting a new code innovation every week a) is unrealistic and b) is too fast. I'd rather see people work slow and focus on quality than whip out a new skill every day, and I'd like to make sure stuff gets discussed and tested thoroughly before it goes in.

And silt skimmers actually are a priority for me. so I keep nudging the more skilled coders about them. I have some plans for them...*schemes*

So I don't mind people proposing ideas. I'm not so fond of the insistence that pet project a, or b, or c is the most important thing in the world and should be worked on before anything else, and even less fond when that's used as a way of saying all the staff are lazy bastards. Because I know from experience that we're not.