lots of text!
This is a typical OOP approach. You have Objects which can do something.
How you trigger this “do” depends on the interface the object provides. The interface can be for example your three properties.
The “user” of the object needs to know this interface. E.g. it needs to know it has to set “active” to True. The user does not care how the object acts on that. It only cares it does something.
BTW. There is no need to limit anything to three properties. I’m sure you thought about them really much and you discovered that it fits to nearly each object.
But I think you mix different tasks here.
Selecting a objects is necessary for a user (usually the player) to determine what object to interact with. There can be multiple users at the same time with independent selections at the same time. E.g. The player opens a door while an NPC drives a car. Which means the player selects the door to be opened, the NPC selects the car to be driven.
If you go further down you see you need a selector which can select one or more things (without actually touching it). The selector provides the user (player) with the currently selected objects. It also offers options to select other objects.
All of the that does not involve any other function as active objects or so.
The basic is:
Selector — selected objects —> User
B) Running Actions
This is what the Object exist. It does something. Usually it is simply visible. You do not need to do anything for that the 3D engine does it for you. If objects should collide or fall - The Physics engine does that for you.
The object should perform tasks (motion, reactions etc.) you use the Logic system to establish a behavior.
This is a typical programming task: The object acts on input (=events).
Example: On Open Requests a door plays it’s open animation.
If necessary the object triggers other objects an expects them to do something.
C) Using Objects
Using objects means one or more objects interact with each other.
Example: When touching a switch -> the door should open
The door does not care what touches the switch not that it is a switch. The door only cares the Open Request it receives from the switch.
This means the switch generates an OpenRequest at the door.
User – Request --> Object
This request is an
For interaction with other objects an object (user) needs to know how to interact with the other objects. E.g. A door accepts a OpenRequest. That can be a message, a property, a call to a Python module or whatever.
Both involved objects know this interface (the OpenRequest). The switch knows how to send it, the door knows how to receive it and what to do with it.
An object can have multiple interfaces. For example the door can have these interfaces:
The switch knows of:
A key knows of:
User — Interface — Object
Where is the selection?
The selection is what the user has chosen to interact with.
E.g The opener’s selection is the door.
The simplest case: it is hardcoded and will never change.
Complex situation (like a remote control) the switcher opens all doors within a specific range.
More complex situation (like a remote control) the switcher opens all doors within a specific range with a specific code.
The key unlocks doors within a specific range and with a specific code. This means a key does not unlock all doors even if all doors have the same “unlock” interface.
Anyway, this principles are already present in the BGE. You can simply use the logic bricks (but you are not restricted to it).
Object = Game object (or group instance)
Interface = properties, messages, code (your choice)
Behavior = the logic bricks
Interaction = one game object requests another via your defined interface.
Coming back to your idea:
Active, selection, execute are more states rather than interfaces.
If an object is active or not should be the decision of the object. Other object can request a state change (activation/deactivation) if the object does that is up to the object.
Example: the actuators.
They can be active and inactive.
They activate on activation signal (True Pulse) but they might run for one frame only (Property actuator) or
run until they receive a deactivation signal (Motion actuator) or
they continue until finish ignoring the deactivation signal (ActionActautor).
You can do the same with your logic.
see above. I do not think that one selection property is enough as it restricts the selection to one user. But it is an option.
I think this is the same as Active.
Nevertheless, it is a good idea to create similar interfaces. This makes development much easier. It is important to document the interfaces (e.g. “expects property ‘active’ to be true to play open animation”). The BGE is not really good in documentation support.