====== Naming Conventions ======
==== Scripts ====

==== Variables and functions ====

Following a standard of identifier naming conventions in your source code helps during maintenance, integration, and group collaborative projects.

When source code has been gaining dust for a few months and you need to go back to make a change, or someone new takes over your source code, its beneficial to have followed a recognized standard in your naming conventions. This way you know that "sName" is a string that's probably someone or something's name, and not have to dig through code to find out if it was "__NAME", "name", "Name", or any one of the other derivitives.

Variables should note their appropriate data type at the beginning of their name, followed by intercapitalization (Hungarian notation). A table of naming prefixes appears below.

^Type        ^ Prefix ^ Example ^
|action      | a  | aKill|
|effect      | e| eConPenalty|
|event 	     | ev | evAttacked|
|float       | f  | fResult|
|int         | i  | iAge|
|itemproperty| ip | ipProperty|
|location    | l  | lJumpTo|
|object      | o  | oPC|
|string      | s  | sName|
|struct      | str| strPerson|
|talent      | t  | tSkillHide|
|vector      | v  | vVelocity|

==== Scripts ====
All Cerea scripts begin with C\\
next is type of script:
^ Letter ^ Description  ^
| a  | action taken in conversation  |
| c  | conditional in conversation script  |
| e  | Entry  |
| h  | Hook |
| i  | Include file  |
| n  | NPC/PC  |
| p  | Placeable / door  |
| x  | Exit  |

followed by a _g_ for generic, _m_ for module scripts or _tag_ where tag is [[builder tag]] for non generic scripts\\

followed by script type:(only for generic scripts):
^ Letter  ^ Description  ^
| a  | Area          |
| c  | Creature      |
| g  | Guild         |
| i  | Item          |
| m  | Money         |
| n  | npc           |
| q  | Quest         |
| t  | Trigger/Trap  |
| v  | Variables     |
| w  | Weather       |
| x  | XP/level      |
| e  | Examine/Manipulate |



Followed by actual name(all scripts)\\

so builder weby building a placeable script that does a special teleport, name could be:\\
cp_weby_telehome

==== Dialogs ====

Will have names like \\
cd_tag_more \\

with tag being the builder tag and more being the name/explanation of the dialog.

It is strongly recomended to use the form:
cd_tag_area_unique   where the area is the area of the NPC/thing using the convo

==== Placeables ====
Placeables should have tag,resource name and template resref all as:
cpl_tag_unique

You should set the classification correctly, see the classifications heading in this page.

It is strongly recomended to use the form:
cpl_tag_area_unique   where the area is the area where it is used.


==== doors ====
All transition doors should have unique tags on the form d_tag_unique

You should set the classification correctly, see the classifications heading in this page for any doors in the palette.

It is strongly recomended to use the form:
d_tag_area_unique   where the area is the area where it is used.

==== items ====
all items should have tag,resource name and template resref all as:
i_tag_unique  or if it is a quest item it should have qi_tag_unique

You should set the classification correctly, see the classifications heading in this page.


==== Waypoints ====

==== triggers ====

==== encounters ====


====== Classifications ======

===== Items =====
for items the classification is the thing to try to make meaningfull. You should add | and your buildertag as minimum to the given ones, you can add undercategries under them, thus forexample all the keys for a given quest with many keyscould be in c-Quest|weby|keys|manykeyquest

NPC items should be under: c-NPCitems  (these are the items worn only by NPCs/creatures and should have Base = -1)
all kinds of keys should be in: c-Keys
all generic quest items should be under c-Quest

The below categories should not contain any quest items or items without Price(and Base).

tools should be in: c-Tools\\
armors: c-Armor\\
boots: c-Boots\\
gloves c-Gloves\\
cloaks: c-Cloaks\\
potions: c-Potions\\
traps: c-Traps\\
jewelry: c-Jew\\
hats: c-Hats\\
clothing: c-Clothing\\
blunt weapons: c-Weapon-blunt\\
ranged weapons and ammo: c-Weapon-ranged\\
bladed weapons: c-Weapon-bladed\\

===== Creatures =====
==== NPCs ====
NPCs should be in a path  c-npc-(mainareaname/groupname)\\
Generic ones:\\
c-npc-Banditpass \\
c-npc-Cerea\\
c-npc-Vesper (should definitely use subcategories here)\\
c-npc-NayeBay\\
c-npc-Gohem\\
c-npc-Greiburg\\
c-npc-Greywoods\\
c-npc-Dyoa\\
c-npc-OrcValley\\
c-npc-GoblinValley\\

Current group based:(if you make a npc group of some sort, feel free to add a new one like this for them)\\
c-npc-Bandits\\
c-npc-Barbarian\\
c-npc-Belwar\\
c-npc-Corsairs\\
c-npc-Darkelf\\
c-npc-Dwarf\\
c-npc-Gypsie\\
c-npc-Hobbit\\
c-npc-Monk\\
c-npc-Pirates\\
c-npc-Scavenger\\

==== Other creatures ====

Creatures should likely go to one of these: (again feel free to do subcategries)

c-Animals\\
c-Demons   (and other planars)\\
c-Dragons\\
c-Elementals  (also for elemental beings)\\
c-Ghosts   (note that ghosts should have spirit override on and not be unlife)\\
c-Giants\\
c-Gnoll\\
c-Goblin\\
c-Kobolds\\
c-Lizardfolk\\
c-Orc\\
c-Wisps\\
c-Unlife-lesser (skeletons, zombies, ghouls, mummies and such "stupid unlife")\\
c-Unlife-greater(vampires, Liches, spectres and other "smart unlife)\\

or a similary named category

Also there is the c-Quest category for creatures that might break things if spawned by DMs..
in the quest category is is defintely suggested to use c-Quest|buildertag|questname for organisation   


====== Programming conventions ======


===== Indenting and Overall Structure =====
==== braces ====
A starting brace appears on the same line as if or such, so an "if" statement would be structured as follows:

<code c>
            if (TRUE) { 
                 // ...
            }
</code>

==== Statements on line ====

Only a single statement should appear per line. An exception would be when readability is greatly enhanced, for example in a "switch" statement:
<code c>
            switch (iCondition) {
                 case 1: sVariable = "one"; break;
                 case 2: sVariable = "two"; break;
                 case 3: sVariable = "three"; break; 
            }
</code>
==== Indentation ====

Statements should be indented an appropriate number of levels according to the nested depth. So, an "if" statement in our void main would appear as follows:

<code c>
           void main() {
                 if (TRUE) {
                      // ...
                 }
            }
</code>
==== Whitepace ====

(optional) Smart use of white space and carriage returns can help break up a large function call or nested function call, making it easier to make changes to and read.

<code c>
           action aConvo = ActionStartConversation(
                 GetObjectByTag("SOME_TAG"),
                 "Hey you!",
                 FALSE
           );
</code>

===== Identifier and Function Declarations =====
==== Declarations ====
In general, identifiers should be declared at the top of the function. This makes it easy to find the identifier's type and it's initial value. If an identifer is only used once, inside a small block, it can be declared at the point where it is used.

==== Case ====
The names of functions should Capitalise the first letter of each word.

<code c>
         int DoSomething(int nKills) {
                 return nKills - 9;
         }
</code>

===== Conditionals =====

==== Boolean ====
Use "iCondition" (or "!iCondition") is used.

<code c>
            int iTest = TRUE;
            // boolean test:
            if (iTest){
                 // ...
            }
</code>

===== Commenting =====
==== Minimum required ====
Each script should have general purpose at top\\
each function should have its purpose and arguments and return values documented\\

==== Recomended ====

Each major variable in the functions documented.\\
each major part of the function documented as to what it does(includes loops, calculation blocks and such)\\

====== Display name conventions ======

Any additional information to help DMs and builders should be in { } in the name. Thus is is much metter to have: robber {ranged} and robber {melee} than just two "robber" entries that way the dm will know what of those to place close and what far..
===== Areas =====
should have the Mainarea:subarea type set as display name.