I am building a game for learning perposes and I wished to know if I would be better off coding a class to handle certain things, such as bullets, or if I should do as both FPS templates do leaving things out of classes?
Thanks,
Lazer
When ever I’m working on a game, I try and tackle it with OOP techniques. For example, I usually have a player class. I also tend to attach the class to an object via a property like so:
gameObj["class"] = myClass()
## It can later be used like so:
gameObj["class"].doSomething()
Or, you could store a game object reference in the class, but be careful with this. If you delete the game obj and not the class, the class will have an invalid reference.
Does “doSomething()” read a sensor and/or activate an actuator? If so, you’ll have to run that function in the original script that connects to those logic bricks.
@ Manti
It’s possible to make your environment OOP friendly, but, it’s difficult to do it properly, because you can’t subclass the actual game object, and the entire system is based on the brick flow architecture: sensor->controller->actuator.
So, next to your class, you’ll have to keep track of the blender game object, and the controller execution flows, making the whole thing more trouble than it’s worth.
Lately I’ve been thinking that it’s better to just follow the “complex controller” methodology from the start, becuase that’s what blender was designed for, and that’s probably what you’ll be forced to do somewhere down the line.
from release notes on the wiki
experimental KX_GameObject attributes “sensors”, “controllers” and “actuators”
It works! at least what I tested, changed the key for a keyboard sensor, didn’t have the script connected to that sensor.
…Not working on my end.
Could you please make a .blend example?
This is all I tested, so this is the all I know works…
here’s how it works:
left key and right key to move the cube, when you press space it changes to be A and D. The sensors are manipulated with a script that uses gameOb.sensors instead of controller.sensors. And the script is only connected to the space key brick.
Attachments
change keys.blend (136 KB)
That is quite awesome
That’s nice, but that’s not what I pointed out.
I’m talking about the function, defined on a class, using sensors/actuators, but being called from a script on another object. You still can’t call an actuator from a non-active controller, and that’s limiting. However, even if you could, it still wouldn’t solve the “track both object and proxy class” bother.
Here’s a .blend showing the limitation:
Attachments
OOP_test.blend (133 KB)