I looked at your file.
It is really nice that you named all the logic bricks. It makes it much easier to read the logic.
Unfortunately it is still quite complex. A good reason to updated the BGE Analyzer.
The problem you have is that you make the LaserColorSide* the primary source for the color value.
MenuBackground is always running “MenuSettings”:
-> the properties of the LaserColorSlider are after scene loading always set to default (black)
When you remove the scene your loose the LaserColorSliders with their current values.
When you load the Menu scene again. New LaserColorSliders are created again with default values.
This code always replaces your “global” variable with the properties from the LaserColorSliders as long as they exist.
I think this is a design issue.
Think about following:
A) where should the laser color be read
B) where should the laser color be write
C) where should the laser color reside
Each of these are complete separate tasks. They only interconnection is the laser color itself.
lets play with it:
I guess one or more lasers should use read the laser color.
Question: when to read it?
Do you want the laser color be displayed at the Menu scene (as a preview)?
Maybe you want to store the laser color to disk? Which means a saveLoader needs to read it.
You see there are multiple game objects which want to read the laser color. This is a one-to-many relationship.
Each single laserColorSlider sets the laser color.
Maybe you want preset buttons?
What about numerical input (text fields)?
Should a saveLoader write the LaserColor which read it from disk?
Again we have a one-to-many relationship on writing.
The number of readers and the number of writers does not need to be the same.
Where to place the laserColor?
If you answer A) with “Only one laser!” this laser would be a good place. But the laser might be disappear and the laserColor with it.
Currently the laserColor resides at the LaserColorSliders. When they disappear the laserColor disapperas too. This is what you have now.
You tried to place the laserColor at Gamelogic (bge.logic is an alias of GameLogic). This is quite a good idea as this module will remain until the game ends. But it is not a natural place for it. There is no relationship between laserColor and GameLogic.
You can leave it there or place it:
- at an game object that remains throughout the game run (e.g. an object in the main scene). Switching scenes might be a problem.
- at a python module specifically for this purpose (as mentioned earlier)
- in a container which is placed at a Module or a game object. A container can be a dictionary (e.g. globalDict)
Regardless where you store the laserColor. You need exactly one storage that should be the primary source.
Readers A) can read this storage.
Writers B) can modify this storage.
You just need to decide WHEN they do that.
A natural time is readers read the storage after a writer modified the storage.
writer -> storage -> reader, reader, … reader
This is quite easy to do. You already have such a concept: Messages.
Please read the BGE guide to Messages. If you read this you might have notified that your slider logic fits pretty well into the health bar logic.
But the slider is not the health bar, it is the value provider. The storage is the health bar. It does not need to be visible.
I recommend to do following:
- on creation it reads it’s property values from the storage (currently it remains at the default value)
- on using (animation) it writes the current property values to the storage (as you already do)
- after using it sends a message “laserColor changed” to ALL objects. If there is a reader it can refresh after receiving this message.
- on creation it reads the storage and colors its mesh
- on receiving “laserColor changed” it does exactly the same.
You can let the storage send the update message rather then the writer. If the storage is no active game object it can’t do anything (GameLogic is passive). So you would need a “control” object which performs the update notification.
I hope you are not to confused
It is much text right now.