OOP Paradigm in the Blender Game Engine

Game Engine Game Engine Support and Discussion
#1

Good day

I have only recently gotten into the whole Object Oriented Programming mindset after finally learning how to do it, but I am having trouble implementing it into the BGE, as none of the types appear to be writable (I am obviously doing something wrong).

Does anyone have any projects they would like to share which use OOP? I’d like to see some examples as to how it’s done right, and hopefully learn a thing or three.

Some thing’s I’d really like to see examples of:

  1. State management
  2. Interaction between objects
  3. Storing properties (do you use the game logic editor or set values through script or a mixture of both).

Hope I’m not being too demanding.

Cheers

#2

Look at BGECore Framework. The problem with this is that there is no game to actually see how things should be implemented, but you can see how things are implemented in the core so it’s something.

  1. State management

States are usually attributes of behaviours or other classes (that aren’t behaviours). However most of the time those are modified usung a setter instead of directly (unless it’s the instance itself tham modifies them).

  1. Interaction between objects

Not somthing common to see in BGECore source, but basically if you have a snipper, the snipper has a “SnipperBehaviour” (or something alike). When you pull the trigger (you check if a key is enabled and then call the method “pullTriger()” of the behavior, you do that from the scene behavior), that instance does a raycast to check if it’s colliding with anything that has an “Enemy” property, that’s on an “Enemy” list or something like that. When the raycast returns an object that meets the conditions you call the “bulletInpact(x, y, z, other arguments…)” of the AI behavior (or any other behavior that represents an human being).

  1. Storing

I don’t know if you meant saving data or storing the data on memory. For the first:

You basically save the attributes of all the behaviors that you consider rellevant. If you where to save everything next time you load the game it would look exactly like when you left, including if you let some menu opened where there was in item selected on the inventory. That’s usually not what you want to happen so you need to see what’s worth saving and what souldn’t be saved. Usually if there is a Player behavior, that’s worth saving, the state of a menu isn’t.

For the second, you just store object behaviors on a dictionary inside the scene behavior (should be unique for scene), and you can optionally save other behaviors inside an object behavior attribute. For example inside a Player behavior you can save a ControlFirstPerson Behavior and a PlayerAnimation behavior.

But of course this is just how I would do it, there are other ways to do good OOP in BGE.

#3

Oh wow this is brilliant. Thank you!

#4

Ahh so that’s what you mean. Well as you may’ve guessed I don’t use object properties, at all, not a single one, I use attributes.

The only exception to this is when I want to send data to BGE scripts that is on the Blender interface but BGE doesn’t have acces to it, for example text object alignation.

Edit: Ok, there is another exception wich is when there is no other way arround thanks to BGE limitations (again). For example if you want to make a raycast that only works on some objects, the destinction is internally done through an object property and I can not change that from Python (I would have to re-implement the raycast in python, wich would be slower and a waste of time).

Notice that it also happened with 2dfilters (uniforms are designed to work with object properties), fortunately I managed to find a way to modify uniforms using Python attributes so now that’s what I use.

#5

I would have to re-implement the raycast in python

BVHtrees
You may well be able to make it faster, as objects don’t have to be physics objects to use that method. However you will have to manage Z-order yourself.

Well as you may’ve guessed I don’t use object properties, at all, not a single one, I use attributes.

And how do you initialize those attributes? Say you have 10 similar objects but each start with a different health, (or some other simple data). How do you tell each object what this is?

#6

I didn’t know that API. In any case you still have to implement it (thanks to this may be much easier, but still).

And how do you initialize those attributes? Say you have 10 similar objects but each start with a different health, (or some other simple data). How do you tell each object what this is?

Behavior, not object. My objects doesn’t hold any data that isn’t part of the KX_GameObject, so I don’t initializate anything on them. They don’t even hold wich behaviors use them, that’s done on a behavior too.

Usually similar behaviors start with similar data, so usually you do that on the definition of the behavior. If that’s not the case then you do it from the scene behavior after creating the behavior. If you want to initializate it with diferent values (instead of changing them just after initialization, wich in most cases is fine) you have several options. Crating a subclass, using the class attributes to initializate the instance attributes, a fake init() with all initializations to None and then run the real init() at the end of the frame (overriding only attributes with None).

And probably the best known, unpacking the arguments of the constructor/initializer. You can also use a dictionary as argument and add all the elements of the dictionary as attributes.

So there are at least 5 diferent ways to do it, pick your favorite.

P.S. Thanks to initializating things in python, you also get acces to all the power of python when initialization. For example you can make a grup of enemies spawn with random health, (or make some of them random and others not, or apply any experssion you want, hell you can even make a function that returns how likely is an enemy to have health insurance and decide it’s initalization value based on that).