Script conventions – Ylands

From Bohemia Interactive Community
Jump to navigation Jump to search
No edit summary
m (Text replacement - "[[Ylands " to "[[Ylands:")
 
(9 intermediate revisions by 2 users not shown)
Line 4: Line 4:
'''Lower Camel Case''' - Names of '''variables''' and '''custom instructions''' should start with small letter, e.g playerHitpoints, getPlayerHitpoints
'''Lower Camel Case''' - Names of '''variables''' and '''custom instructions''' should start with small letter, e.g playerHitpoints, getPlayerHitpoints


==Variables==
== Variables ==
[[Ylands Tile category - Variables|'''Variables''']] are of 3 types
[[Ylands:Tile category - Variables|'''Variables''']] are of 3 types


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


===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
*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
*No prefix → e.g.: playerHealth
*No prefix → e.g.: playerHealth


==Storages==
== Storages ==
===Name===
=== Name ===
*Global storage - start with prefix GLOBAL → e.g.: GLOBAL_gameManager
*Global storage - start with prefix GLOBAL → e.g.: GLOBAL_gameManager
*Entity storage - start with prefix ENTITY → e.g.: ENTITY_magician
*Entity storage - start with prefix ENTITY → e.g.: ENTITY_magician


===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.


==Other game logics==
== 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.
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.




----
----
{{Ylands scripting navbox}}
{{Navbox/Ylands}}
{{DEFAULTSORT:{{#sub:{{PAGENAME}}|7}}}}
 
[[Category: Script: How To]]

Latest revision as of 17: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.