Topic was automatically imported from the old Question2Answer platform.
Asked By
Varven
Hi,
after few weeks of programming my project it becomes huge and i’m start wondering how to write good and readable code. Do you guys know what is the good way to store variables like premium currency (for real $) or player gold which are using by a few scenes / scripts in a project?
At this time i have solution with global script that stores a dictionary (database).
For example: I have three different scenes and one value to manipulate. In “Panel1” node i have function that changes gold value per second. In UpgradePanel i can buy upgrades for earned gold and, by pressing ResetButton a can reset gold to zero. Each script has access to “database” by my global script.
Game
MainScene
Panel1
UpgradePanel
StorePanel
GUI
ResetButton
I think its not a good solution when we can change game values form each script in of the project. Maybe should i store them in the “Game” node? But what if i will be needed them in some separated scenes?
The second question is how i should store node paths. I don’t like to have twenty lines of code with node parent vars in each script. So in my global script i have created a function that can return a path of each main node. For example, to get Panel1 path in BesetButton node only what we have to do it is call: GameManager.get_scene (“Game”). Panel1 (main parent node “Game” has var references written to all of his children). It also works when I try to get some separated scene like “Game2”, “Level2”. Is it a good way or i should change it?
For the gold management, it sounds like you need access to it from many areas in your game. For simplicity, I might put both the data structure that represents the gold and the functions used to manipulate it all in an autoloaded singleton - especially if those manipulations are somewhat complex. Then, rather than individual scenes directly manipulating the global data structure, they’d just call on a single set of global functions to do that manipulation (increment, decrement, reset, …)
That has a number of advantages, including:
You’re not writing repetitive gold manipulation code in multiple scenes
You’re not mistakenly incorrectly handling gold manipulation locally
The gold data structure and functions that manipulate it can be run / tested independently of the rest of the game
Regarding your node name references… I’d first ask why you need such intimate knowledge of scene structure of your game? Ideally, each scene should be completely autonomous and able to function on its own. When you do need access to some unrelated scene element, the use of signals keeps that connection very loosely coupled, which makes for easier development and maintenance of your code.
If you do some poking around for Godot best practices, you’ll see references to something deemed “signal up and call down”. That’s a good general principal that says if you’re trying to access something in a child node, a direct call to it is generally OK as a parent is responsible for its children. However, if you’re trying to access something up the tree, you probably shouldn’t be making a direct reference to it, as that structure could easily change at some point in the future, breaking your code. In that case, use a signal.
Also, like all “best practices”, it’s just a rule of thumb - not a requirement.
