Area design/implementation

[Danelin]

One thing that Cat bemoaned back in the day was that the original zone creator tool which lance had coded did not have a method of dynamically reassigning unique ID#s to rooms. This meant that only one person could effectively code areas at a time, and that unique content for a given board was not possible.

Now, I know many SYSOPS had a tendency to go hex edit certain values, like the experience value of the boatman in newhaven on the BBS where I GameOPed. The boatman didn't fight back, and had a moderate number of HPs with very high health regen. This allowed anyone with sys goto the ability to rapidly advance their character and prevented genuine newbies from being likely to kill him, and due to training restrictions even if they found out it only let them advance a small amount. (4th level? it's been a long time)

What would be nice to see at later stages of implementation is the ability for either people who own servers to have the ability to code/recode areas and implement changes easily on their own boards, and perhaps to make their own area/quest expansions which could be shared between different greaterMUD communities, while still allowing for any content created and distributed by the original staff to be added. (obviously this could result in a need to relocate room connections, but perhaps putting something that prioritizes 'main updates' from the creators over local areas, then allowing the local owner to modify their rooms so that they are relocated appropriately? I'm not really hip on programming so I don't know what is or isn't exactly possible or how it could be implemented, these are just some ideas of mine from way back.

Another thing that would be nice to see is a way to have an option for unique items to instead have a rate of entry into game modifier, such that you could say make it so a new ruby necklace could enter the game once every X number of days the server is running. This would keep items from being massively common, and still make it so more than one individual has the potential to obtain these items on a given server/game.

Danelin

[DeathCow]

Unless something happens to change my opinion,  we're going to go from realm consistancy over "unique."

[The Crazy Animal]

Unless something happens to change my opinion, we're going to go from realm consistancy over "unique."

Editing has just as much helped keep mmud alive as its consistency has, so there is no reason why we shouldn't support or help dedicated sysops/players in their attempts to create an editing community. This is really has little to do about the consistency of the baseline game but teaching the methodology of the coding of it to ensure there is a steady supply of capable data coders and content contributors.

What would be nice to see at later stages of implementation is the ability for either people who own servers to have the ability to code/recode areas and implement changes easily on their own boards, and perhaps to make their own area/quest expansions which could be shared between different greaterMUD communities, while still allowing for any content created and distributed by the original staff to be added. (obviously this could result in a need to relocate room connections, but perhaps putting something that prioritizes 'main updates' from the creators over local areas, then allowing the local owner to modify their rooms so that they are relocated appropriately?

This isn't as much of a problem with the newer editing software as it use to be.

I actually would like to see greatermud have an editing community that can make quality edits rather then the 10x exp junk hack and slash stuff that was so over done in mmud's editing community. I was thinking that if an editing community for greatermud is put into place there should be a rating system put in along with it. This would be so that all the submitted edits could be judged to weed out the edits that are either badly coded or otherwise unbalance the game. Along with that there could also be some thing like monthly contests run for best edits. I can't say if something like this would ever be done but its a nice thought for the future.

[Danelin]

The ability to add more 'real' content to the game is definitely the main reason I mentioned this. If an editing tool similar to the way rooms are added within TADS were to be created, it would permit for creation of quality content by relatively low programming knowledge individuals.

IE players like me :p

I submitted a few potential area designs to WCC back in the day. I'm not sure if any of my ideas were ever actually used in any way other than the name 'Nekojin' for the cat race, but I do know that designing an entire area on graph paper and notepad, then driving to canada with printouts to give it to Mike and Co. over dinner was fun, but a good software tool would be better.

[The Crazy Animal]

The ability to add more 'real' content to the game is definitely the main reason I mentioned this. If an editing tool similar to the way rooms are added within TADS were to be created, it would permit for creation of quality content by relatively low programming knowledge individuals.

IE players like me :p

The system in place is is easier to use then TAD as its mostly data entry rather then all being typed in as scripts. This is because unlike TADs the system ours has a strong set of game engine rules that apply known data sets into the game which takes out the need for complex repeditive scripting and defines for the simplest of actions.

Eventually we will be moving over to our own editor rather then using NMR (latest standard in mmud editor). Hopefully when we get to that point the new editor will help extend the ability of the editor to develop content by being more intuitive in the way content is designed and added into the game.

You can see the starting ideas for this new editor here:
http://www.greatermud.com/wiki/index.php/Idea:GreaterMUD_Editor

Plus we are looking to make more of the game engine functions into soft-coded data sets rather then hard-coded so more things can be changed or added on the fly rather then needing to be re-coded each time which was the major problem with mmud.