Thank you for taking the time to read the coder rules page.

This page doesn't cover any of the D&D rules. It is instead focused on the coders' code of conduct. These rules are intended to protect the players' interests, and preserve the balance of the playing environment. The rules are presented in no particular order of importance.

This is a lengthy webpage because an attempt has been made to explain the thinking that went into each rule, rather than just presenting a short bulleted list.

Please note:
Persons interested in applying for a coding position on Coastal Legends must first read these rules and agree to abide by them. The process of applying for a coding position is described elsewhere on this website.

Coder Bodies and Equipment
Coders on Coastal Legends are mortal. This means you may become killed in combat, and lose a level as a result. If this happens, it does not impact your coding position or abilities.

Coders are allowed to have special equipment -- better weapons, better armour, and so on. These items, however, still fall within certain limits. It is not permitted to create a sword +10 that does 3d100 damage! Examples of what is permitted will be contained within Grey's "wizitems" directory. You are welcome to copy these items and change the descriptions to suit your tastes. Please do not, however, make them more powerful than they already are.

Finally, coders are asked not to change their stats, hit points, money, skills, experience, feats, etc. except as provided through normal level advancement. The reason for this rule is explained in the next section.

The first mistake many new coders make, especially those used to playing on no-rules "diku" MUDs, is cloning a level 50 monster with 1-HP in their workroom and killing it... over and over again. Other coders or an Admin will eventually find out about this and ridicule you. An Admin will remove everything you gained and make you feel silly. Don't let this happen to you! :) If you wish to advance, please do so "normally".

Coder Campaigns and Adventuring Companies
Players perceive coders as having the potential to abuse their powers by influencing the outcome of a battle. Even though this won't happen, thanks to the above rule, not every player will read the coder rules (or believe they are followed). To avoid unnecessary complaints, coders are asked not to belong to a Party consisting of regular players, or to team up with regular players in combat (except in a MUD-wide "Event").

Coders are, however, permitted to form their own Parties -- consisting entirely of coders. Coders are welcome to write adventuring areas for high-level players that would also be challenging for coders. Coder Parties are welcome to play as normal players in these areas. If you choose to do this, please don't "help" yourself by altering that red dragon's hit points from 200 down to 5 (aka: cheating).

Suiciding
A coder's status is stored in a central database, not in the character save file. As as result, if you're not happy with your character, it is possible to suicide and start over -- while retaining your coder status.

If the reason for your suicide is because you're resigning, for whatever reason, please send Grey a mudmail informing him of this! The last thing we need is a player obtaining instant coder status because he/she picked the name of a former coder whose status wasn't changed in the database.

Usage of the Clone, Dest, Update, Goto and Summon commands
Coders are asked not to exercise their coder powers in front of players, unless you're fixing a bug.

If a player has lost an item, as a result of a verifiable bug, it is permitted to clone a replacement item for the player. It is also permitted to give the player a refund in Guilders for the lost item's normal retail value if, for whatever reason, it is not practical or possible to come up with the lost item.

It is not permitted to clone items or Guilders and give them to players "just to be nice". This is player-helping, which is discussed in the General Conduct section below.

The Summon command should not be used on players, unless you're rescuing them from a buggy room, or acting in an Enforcement capacity (discussed below in the "Enforcing the Player Rules" section). Summoning players for the purpose of sheer harassment, or "just playing a joke", will be considered abuse of coder powers.

Magic Spells
All magic spells available in the game are coded by Grey. If you wish to add a spell to the game, please first submit your spell idea to Grey in writing (via mudmail is fine). If your idea is approved, you will be given further instructions and tips on how to implement your idea.

Coding spells is a big deal -- either because of complexity of coding, or because of perserving game Balance. The Dungeon Master Guide has an interesting section on things to consider when inventing new spells. This section deals entirely with game Balance, and should give you some clues into what goes through Grey's mind when a spell idea is suggested.

Technology
Electricity does not exist in the Coastal Legends "universe", except naturally (lightning) or via magic (the cleric "Call Lightning" spell). As a result, electrical "gadgets" or machinery should not be implemented.

The most advanced inventions in our universe's time could probably be considered: steel, the stirrup, and sliced bread. :) Simple machines, such as a windmill or river mill, can provide for sanitation (running water in your castle's bathroom) or basic industry (a miller making flour for a bakery).

As a coder, your primary focus shouldn't be on technology; it should instead be on building interesting areas for players to explore. Expanding the world and designing fun and challenging player encounters is our number one priority on Coastal Legends!

"Wiztoys"
Most MUDs have some kind of rule about wiztoys, so here we go! A "wiztoy" is an object containing commands that are useful for coders to have. For example, you might wish to write a "room scanner" that displays the HP/MaxHP of all living creatures in the room with you. These items are okay to make, provided these conditions are met.

1. wizardp() is checked so the item may not be used if it falls into a player's hands.
2. The item does not provide functionality reserved for game admins only, or otherwise attempts to bypass a security feature of the MUD.
3. query_invis() returns 1 if !wizardp(this_player()). This will prevent players from noticing the item in your inventory, or seeing it if you've accidentally dropped it.

Playing the Game
It is up to you whether or not you continue to "play the game" once you become a coder. You can stay in your workroom and just code, you can apply to become a DM, or you can participate in an adventuring company (Party) consisting of coders. The only restriction here is you can't be a member of a Party containing regular players.

Coders have gobs of roleplaying opportunity, if you wish to exercise it!!! Each coder can be assigned 1 or more Outside "grids" (this will be explained to you in more detail if you become a coder). Your "grid" may be a kingdom or a barren wasteland... it's up to you! (Based on which you want, Grey will assign you the appropriately-located grid). You can be a king, baron, princess, mayor, inigmatic lone wizard, evil child-eating witch, or whatever! In essence: you have the opportunity to assume political leadership within your assigned area. Roleplay it to your heart's content! Or, at your option, you can be the king's (an NPC in your grid) advisor who secretly controls everything behind the scenes. Get my drift? Ask and ye' shall receive! Have fun :)

General Conduct
As a matter of professional pride, coders do not directly "help" the players (this is Grey's subtle way of saying DO NOT DIRECTLY HELP THE PLAYERS!). This kind of "help" doesn't mean rescuing somebody from a coding bug, which is certainly allowed and encouraged. The "help" not permitted is:

• Giving players free money or equipment (except as a bug refund)
• Giving out a solution to a quest or encounter. If players ask you for hints, tell them you can't give them any.
• Cloning or desting NPCs on demand.
• Adjusting player stats, hit points, skills, feats, and so on (except as a bug refund).

The "bugrefund" command should be used to record when you're assisting a player due to a bug. This helps us track and prioritize the most severe bugs, and it also saves you from having to explain things when the cheat logs are checked :)

Coder Secrets
Coders have their own chat channel. What is said on that chat channel is meant for coders' ears only, and should not be repeated to players.

The details of how certain code works should not be divulged. This means if a player asks you a question beginning with "how exactly", an "exact" answer should not be given. :) It is not important for players to know combat formulas, how exactly bank interest or robbery is calculated, and so on. This is part of the risk and mystery of playing a game.

Coastal Legends was designed with the Dungeons & Dragons 3rd Edition rules in mind. A large percentage of the formulas implemented in combat, spells, skills, feats, etc., were implemented exactly as published in the 3rd Edition rules. Without a doubt, some players will purchase the books and read the formulas for themselves. If they choose to purchase the books and figure out how things work, that's perfectly okay. But just as in the real D&D game, where the DM makes his die rolls secretly behind a cardboard screen, so do we conceal "exactly" how things work.

From time to time, at Grey's discretion, certain code snippets will be published on the Coastal Legends website. This is really the single exception to the above rule.

Enforcing the Player Rules
Coders are permitted to enforce the Player Rules (described elsewhere on this website) at their discretion, within these guidelines:

• Multi-playing and triggers.
  You may test for MUD client triggers or multi-playing, provided the player is either within a Party you're the DM for, or the player is within one of your assigned grids. You may not summon a player into your grid for this purpose.
• Abusive behavior, or giving out Quest solutions.
  You may take action if the player is within a Party you're DM'ing.
• Excessive profanity over a public channel.
  You may take action if all Admins are idle (or not logged on).
• Bug or loophole abuse.
  You should report the abuse to an Admin. Do not take action yourself, or alert the player that you know. We investigate such abuse secretly, and allow the activity to continue for a while so we can monitor and document it (and eventually plug the loophole or fix the bug).

If the above conditions apply, you may take action. Commands will be provided which enable you to turn off a person's public channel, or punish the offender in a roleplay-ish manner (such as summoning the town guards).

Regular coders do not have the following abilities. These are reserved for Admins only:

• Banishing a player from the game, temporarily or permanently
• Putting an IP address on site registration status
• Notifying a player's ISP of abusive behavior (this action is only taken in extreme circumstances, where a player has not only violated our rules, but their ISP's rules as well... such as trying to hack into our machine, or creating "f*ckyou" character names. This action has been taken only 3-4 times over a 5 year period).
• Seizing equipment, money, experience, or adjusting stats.

Finally, when exercising your authority granted by the above conditions, remember that your actions will be interpreted by the player community as representing Grey and the entire coding staff. Please take this very seriously! If coders don't remember this, complaints regarding coders overstepping bounds, going on "power trips", treating legitimate players rudely, etc., will eventually reach Grey. Or, bystander players who witnessed the abuse will become frustrated and leave. We really don't want either of these things happening :)

The bottom line: act with restraint and maturity, and you shouldn't run into any problems. In Grey's 5+ years of administering coremud.org, some "bad apple" players have come and gone, so conflict is unavoidable. What is avoidable is problems resulting from poor judgement on behalf of the coding staff.

Code Ownership, and Usage of the FTP Server
Coders may use the FTP server to transfer their files to and from the MUD. This is a convenience which greatly speeds up coding time! (It allows you to write code in your favorite full-screen editor at home, rather than using "ed" within the MUD).

Code you didn't write yourself should not be transmitted or copied without obtaining prior permission from Grey, or the original author.

"Borrowing" files from the /std, /secure or /daemons directories is especially forbidden -- this code should never make its way onto another MUD! Aside from the basic code which came with the Dragon's Den 1.1 mudlib, the contents of these directories where custom-written (or WAY modified) for this MUD by Grey. A lot of personal blood, sweat and tears went into this MUD! Please help ensure it doesn't become diminished by finding its way onto 500 other MUDs.

Inactivity
If you know you're going to be inactive for an extended period of time (not logging on for a month or more), please notify Grey. "Real life" should always take priority over a MUD, so if situations arise where you can't participate here, that's expected and understandable. All we ask is that you "keep us in the loop".

If a coder doesn't contribute to the game anymore (for example, not DM'ing or writing non-wiztoy code for a period of 3-6 months or more), that coder is at risk of becoming demoted to regular player status. MUD development is a "use it or lose it" discipline... if you stop participating in coding, after a while you'll find it a lot harder to get started again. That's because Grey is constantly tweaking and refining the MUD, adding new features or making enhancements. If you don't keep up, you'll become frustrated and will lose interest.

Or, in extreme cases, "Spokanitis" can set in if a person stops contributing... for whatever reason, the soon-to-be-ex-coder decides to delete all his files and go down in a blaze of "glory" (to Hell with everybody else on the MUD, and all that!).

The bottom line: if you're feeling either frustrated or bored, please let Grey know before it becomes a problem. Another project can be found which suits your interest better, or if you're frustrated, perhaps a peaceful resolution can be found.

The above rules are intended to preserve the quality of the game for everyone. That's really the "spirit of the rules", so please keep that in mind when considering exploiting a legalistic loophole. :)

If you have questions about the coders' rules, please ask. I would prefer to take the time to explain the rules, rather than spend even more time dealing with the alternative!