I am trying to code what I can as I have more control, but as I am getting more into things I am getting confused on referrencing and clock cycles.
Lets say I have a HEALTHBAR object and a PLAYER object (HEALTHBAR being a child of PLAYER, not that it should matter).
Okay the HEALTHBAR has it’s own “healthbar.py” script which animates based on percentage, linked to the ALWAYS sensor
The PLAYER has it’w own “player.py” script which does game logic, linked to an always sensor.
What is the ideal method here? If I want to update the HEATHBAR object, should I call it from player.py (if I can even reference those objects and variables)
Should I create a class called “player” that has logic and healthbar in it?
I sit here asking myself "okay cycle comes through and says “Key X is pressed, do that logic” then I will get SPACEKEY is released(for the healthbar.py logic) that logic to is attached to a “always” sensor. Two ALWAYS sensors are going to eventually “bump” into each other giving not accurate results,
Well what about a game w/ multiple scripts and multiple objects? Is this all done via one script that calls other scripts/logic? Is everyone copying datasets from passive object to active object? Please help, what’s the recommended action to address this as best practice?
Thanks for any attempt to try and explain the best answer / best practice.
In general, you want each different type of game object to have its own script file. That makes the scripts more reusable and your code base more modular.
Also in general, you want to maintain your game’s abstraction and encapsulation. That means that it is usually ‘ok’ for a parent object to directly talk to a child object since the parent inherently knows about the child. It is also common for a child to know about the parent but it is also common that you don’t want a child object to know much about the parent so you can attach them to different types of parents. In your case, if the ‘healthbar’ is the kind that floats over a player’s head then it makes a lot of sense for it to be a child of the player and for the player to reference it directly. But I would suggest that the healthbar not know much about the player object so that you could attach the same healthbar to different kinds of enemies as well.
If the healthbar is the kind that is displayed in the HUD of your game, then it probably makes more sense for the healthbar to be a global object. In this case it could make sense for the healthbar to get its health amount directly from the player object or it might make sense for the player to report its health to the bar though a global object or a message.
As far as scripts bumping into each other, it doesn’t happen. The underlying C++ engine is not multi-threaded and neither is the Python script layer. The game loop goes something like this:
All Controllers are executed -> All the physics simulations update -> Results are drawn on screen.
You should consider that the Controllers (your Python scripts) are executed in random order. For your healthbar I don’t think it matters because both the player and the healthbar will update before they are drawn on screen. The worst case would be that the healthbar copies out the health of the player then the player updates and takes some health away (healthbar now has an incorrect amount) then the screen draws. The same thing can happen with the physics simulations. The way to ‘fix’ this would be to recursively loop though the controllers until everything agrees that they have accounted for all their changes. This is not feasible because most game systems would probably never settle into a stable state from frame to frame. Most games target to run at 60 fps or 30 fps. That means that any given object might have out-of-date data that is 16.6ms or 32ms stale. In practice, reading data that is 16ms late makes no difference because it doesn’t really matter if your healthbar updates 16ms later than it ‘should’. It also does not matter if an AI decides to shoot at position 10.01283 instead of position 10.01343. So in general, you update each object with the current state of the world and accept that you might be a little off.
If you need to ensure that something happens at a fixed time and that all scripts will see the same thing, then there are hooks where you can attach a script to be called after the scene draws. That is effectively right before the Controllers will be called for the next frame so if you update something there you know that all Controllers will see the same data.
That is FANTASTIC information, thank you very much for taking the time to explain. In my example above I was having the health bar logic all on it’s own (holding a key to determine a variable on a bar). However since it’s a HUD child of “player”, I am going to have the logic moved to update the healthbar animation and wait for “JUST_RELEASED” onto the parent.
I appreciate you getting into some more detail with the ms Lag time and how the main engine works. This was extremely useful.