Script conventions – Ylands

Naming

Conventions are inspired by Java Script. These conventions are meant to make reading of others people script much easier, but they are completely voluntary. In other words, you can name the variables and instructions any way you like and the script will still work, but if you plan to share your code with others, sticking to some conventions (even other than this) is considered a good idea.

Lower Camel Case - Names of variables and custom instructions should start with small letter, e.g playerHitpoints, getPlayerHitpoints

Variables

Variables are of 3 types

Global

• Variables visible from anywhere in the script
• Their name should start with "g_" prefix → e.g.: g_playerCountCurrent

Member

• Variables intended for use in the scope of owner entity
• Their name should start with "m_" prefix → e.g.: m_playerXP

Local

• Defined by local variable instruction
• Variables used in the scope of one method (i.e. within one stack)
• Parameters of custom instruction are used only in the scope of that instruction, so they are local from their nature
• No prefix → e.g.: playerHealth

Storages

Name

• Global storage - start with prefix GLOBAL → e.g.: GLOBAL_gameManager
• Entity storage - start with prefix ENTITY → e.g.: ENTITY_magician

Variables

• Global Storage - variables in global storage are considered global
• Entity Storage - variables in entity storage should be threated as member

But of course both storage types can contain member and local variables for internal use → their naming convention is up to designers decision. But variables intended for outside use should follow aforementioned convention.

Other game logics

Use common sense, so that naming will help you and others to easily identify the purpose of the particular game logic. Name does not have contain its type in name, because colors and icons help identifying that.

---