You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is to design how the scene's nodes can be accessed through aliases, reducing the amount of code needed for reaching out a descendant node, or the root of the tree, or even a sibling node, since this type of operation is widely used for the game's logic.
Keeping the Lua way of programming, every scene will have two local tables used to access the tree’s nodes. They are the _R table and the _S table and they allow us to access the root node of the tree and the current node been processed by the engine, respectively.
The root node is so named like this because it is the oldest ancestor of each node in the tree. So its table alias _R will give us access to the entire scene tree by simply referring to the name of the child node and, like wise, the child node's own children, descending from the top most parent node to the deepest child node.
The local _S table is a lot alike the _R table. The main difference is its conciseness that allows us quick access to all current node's children. That is because the scene node is in front of the root node (or below it, depending how you think about such tree), and its main purpose is to interact quickly with its children. Therefore, using the _S table to access sibling or ancestral nodes does not bring much of an advantage for the developer, in which case the _R table should be used instead.
Following below is an excerpt for some of the the designs I have so far, showing how those tables can be applied on real game logic code.
The following examples presuppose this sample tree and has the Hero node as the current node running the Lua script so that the _S table is an alias for the Hero node.
localclass=require'lua.class' -- Import the system class librarylocalSprite=require'godot.Sprite' -- Make sure to import the base classlocalMain=class.extends(Sprite) -- Create the user subclassfunctionMain:ready()
_S.Fighter.MachineGun.load( _R.Supplies.Ammunition.get() )
-- The above line of code is equivalent to:get_node( 'Fighter/MachineGun' ).load( get_node( '/root/Supplies/Ammunition' ).get() )
self.Fighter.MachineGun.unlock() -- _S table can be interchanged with the 'self' keywordendfunctionMain:process(delta)
if ( _S.HealthGauge.level() <20 ) thenapply_first_aid_kit( _R.FirstAidKit )
-- The above line of code is equivalent to:apply_first_aid_kit( get_node( '../FirstAidKit' ) )
endendfunctionMain:apply_first_aid_kit(kit)
-- do some life saving with the kit-- ...endreturnMain
Please share your thoughts on this idea or show us a new idea that you come up about this topic.
-- Perbone
The text was updated successfully, but these errors were encountered:
So there is this new concept called "unique node" that facilitates access to a node by its name only, without needing the full path.
I don't know if I really liked this idea, but if I end up implementing it, here's how it will work with Lua.
There will be a local table called _U that will contain the nodes configured as unique, allowing quick access to these nodes without the need to inform the full path.
root
/root/Hero
/root/Hero/Fighter
/root/Hero/Fighter/MachineGun <== This node is unique
/root/Hero/HealthGauge
/root/Supplies
/root/Supplies/Ammunition
/root/FirstAidKit
It is a Lua-like way to provide a Godot-like feature, so it seems pretty good. _U Is the localized string (translate) function in FiveM but that's pretty obscure so it probably doesn't matter unless someone tries to port FiveM to Godot.
The idea is to design how the scene's nodes can be accessed through aliases, reducing the amount of code needed for reaching out a descendant node, or the root of the tree, or even a sibling node, since this type of operation is widely used for the game's logic.
Keeping the Lua way of programming, every scene will have two local tables used to access the tree’s nodes. They are the _R table and the _S table and they allow us to access the root node of the tree and the current node been processed by the engine, respectively.
The root node is so named like this because it is the oldest ancestor of each node in the tree. So its table alias _R will give us access to the entire scene tree by simply referring to the name of the child node and, like wise, the child node's own children, descending from the top most parent node to the deepest child node.
The local _S table is a lot alike the _R table. The main difference is its conciseness that allows us quick access to all current node's children. That is because the scene node is in front of the root node (or below it, depending how you think about such tree), and its main purpose is to interact quickly with its children. Therefore, using the _S table to access sibling or ancestral nodes does not bring much of an advantage for the developer, in which case the _R table should be used instead.
Following below is an excerpt for some of the the designs I have so far, showing how those tables can be applied on real game logic code.
The following examples presuppose this sample tree and has the Hero node as the current node running the Lua script so that the _S table is an alias for the Hero node.
/root
/root/Hero
/root/Hero/Fighter
/root/Hero/Fighter/MachineGun
/root/Hero/HealthGauge
/root/Supplies
/root/Supplies/Ammunition
/root/FirstAidKit
Please share your thoughts on this idea or show us a new idea that you come up about this topic.
-- Perbone
The text was updated successfully, but these errors were encountered: