Script conventions – Ylands
mNo edit summary |
No edit summary |
||
| Line 12: | Line 12: | ||
===Member=== | ===Member=== | ||
*Variables intended for use in the scope of '''owner entity''' | *Variables intended for use in the scope of '''owner entity''' | ||
*Their name should start with "'''m_'''" prefix → e.g.: m_playerXP | *Their name should start with "'''m_'''" prefix → e.g.: m_playerXP | ||
===Local=== | ===Local=== | ||
*Defined by [[Ylands Tile - Variable local|'''Local Variable''']] instruction | |||
*Variables used in the scope of one '''method''' (i.e. within one stack) | *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 | *Parameters of '''custom instruction''' are used only in the scope of that instruction, so they are '''local''' from their nature | ||
| Line 28: | Line 27: | ||
===Variables=== | ===Variables=== | ||
*Global storage - variables in global storage are considered '''global''' | *[[Ylands Game logic - Global storage|'''Global Storage''']] - variables in global storage are considered '''global''' | ||
*Entity storage - variables in entity storage should be threated as '''member''' | *[[Ylands Game logic - Entity storage|'''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. | 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. | ||
Revision as of 17:55, 3 December 2018
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.
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.