Script conventions – Ylands
Lou Montana (talk | contribs) m (Lou Montana moved page Ylands Script conventions to Ylands:Script conventions: Text replacement - "Ylands " to "Ylands:") |
Lou Montana (talk | contribs) m (Text replacement - "[[Ylands " to "[[Ylands:") |
||
| Line 5: | Line 5: | ||
== Variables == | == Variables == | ||
[[Ylands Tile category - Variables|'''Variables''']] are of 3 types | [[Ylands:Tile category - Variables|'''Variables''']] are of 3 types | ||
=== Global === | === Global === | ||
| Line 16: | Line 16: | ||
=== Local === | === Local === | ||
*Defined by [[Ylands Tile - Variable local|'''local variable''']] instruction | *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 27: | Line 27: | ||
=== Variables === | === Variables === | ||
*[[Ylands Game logic - Global storage|'''Global Storage''']] - variables in global storage are considered '''global''' | *[[Ylands:Game logic - Global storage|'''Global Storage''']] - variables in global storage are considered '''global''' | ||
*[[Ylands Game logic - Entity storage|'''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. | ||
Latest revision as of 16:35, 16 November 2022
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.