I got 3 questions. I’m really struggling with this because I’m still on my Python journey. Please help me become a better game programmer.
QUESTION #1:
How do we go about activating an actuator when a sensor from another object is positive?
What I’m trying to do is the actuator of “OBJECT A” gets activated when the keyboard sensor of “OBJECT B” is being pressed.
QUESTION #2: (I have posted about this on my old thread but I think I wasn’t able to explain it further. Please pardon me)
I pretty much hate nodes (Thou I really love it when I’m prototyping). However, when nodes are getting pretty complicated, I’m getting confused with my noodles. lol.
I mainly use TIMER property and my question on this is. How can I script it with Python?
like:
if own[“timer”] >= 1.00:
cont.activate(actuator)
Is that right?
QUESTION 3:
I have written a script for my current project and I just want to share my script just to check how I am doing. What I’m doing wrong and how can I improve it.
PLEASE REVIEW MY SCRIPT ATTACHED BELOW. I’M OPEN TO ALL SUGGESTIONS.
I’m still not familiar with complex terms so please bear with me.
THANKS!
I hope I have explained it right. lol.
I really love receiving emails. Please come and say hi!
connect the sensor of OBJECT B with a controller of OBJECT A
You will see this creates dependencies between objects that are not really nice to look at and to manage. Therefore I would avoid it as much as I can. Sometimes it is simply not possible, e.g. one object senses the collisions an triggers logic of another object.
So here is another question:
All objects can measure keyboard input. Why do you need to use the sensor of OBJECT B?
When logic gets complicated it is time to think about isolating separate operations (that you most-likely mixed together into an unmanageable stew).
Python will not solve that. The operations are still there. What helps is that changing the description method (logic bricks to Python and the other way around) forces you to redesign the behavior already. So you can use the experience you gathered from the first solution to create a (possible) better second solution.
To answer your question “is that right?” - I do not know what you mean with “right”. “Mainly use TIMER property” does not tell me what should happen when.
You ever do anything wrong. You might write a script that makes the BGE not to behave as you think it should behave. (The curse of a programmer … the application does what you told it to do … not what you think it should do).
Remarks:
Please post text rather than an image. This allows us to quote your snippet
As a script this has way too much function definitions (I suggest to avoid function definitions in a script as it breaks the reading flow - the reader needs to jump around in the text which is very confusing). You can place function definitions on a module and import the module into your script.
As a Python module the module level code (module initialization) create dependencies to other objects - this is very dangerous. It limits the usage of this module to exactly one object of your game session. You can’t even reload the scene without getting problems.
There is not much sensor checking in your code. This forces you to run the code every time even when there is nothing to do most of the time (e.g. look at your “playerMovement” - how often is a key pressed?) Be aware code at that level should run at less as possible. Code that has no effect on the scene still eats processing power.
There is a lot of code repetition - this increases maintenance effort quite a lot (imagine you want to rename “hitStop”, or you want to add another condition).
You gave your functions descriptive names - that is good and helps understanding what you want the code to do
“playerMovement” and “playerSprite” indicate that you can classify this functions as related to “player”. How about separating this functions into an own module “player.py”?
I suggest to use verbs to name functions. This way it feels more near to native language (an operation is more explicit than a thing). E.g. “movePlayer” rather than “playerMovement”, or “playPlayerSprite” rather than “playerSprite”.
frame1 … frame6 -> latest when you have two objects that should be treated the same, you should think about a container (e.g. a list). Six of them are way too much. Imagine you need 100 more.
frameX - what should that mean? What is the purpose of that? What is the content of that variable? It is not the frame number as I would expect (and I would wonder why you need more than on frame number).
What does “weapon()” mean? A function can’t be a weapon. What behavior do you expect?
mouseTracker() is the only function definition that does not has dependency to a single object. I still suggest to use a verb to describe what it does (a tracker is a thing that does what? –> it tracks. So how about “trackMouse”). - oups correction, it still has the dependency to “tracker”. This is not easy to see and another argument against such dependencies (see above).
mouseTracker() does too much. It mixes repositioning the trackto target with activating the actuator. Why is it too much? You need to activate the trackTo actuator just once. It will track until you tell it to stop that. So you can simply use “always [no pulse] -> AND -> trackto actuator”. What is left? Repositioning the target to the hitposition on mouse move and mouse hit:
def positionToHitPosition():
controller = bge.logic.getCurrentController()
mouseFocusSensor = controller.sensors["mouse"] # the sensor with mouse over (any) mode
if mouseFocusSensor.positive:
target = controller.owner
target.worldPosition = mouseFocusSensor.hitPosition
You run this at the tracker’s target object. There can be as much tracking objects as you like. You configure the dependency between tracker and target at the tracker’s tracktTo actuator (rather than by your code).
