Hi everyone!
I’ve built a modular UPBGE demo using only python components (no logic bricks). The entire file was created with only 335 lines of code. The system allows for activity dependencies within blue-prints, creating dynamic, visual and logical flow.
Python Components are definitely something to get into if you are using UPBGE!
Video: https://www.youtube.com/watch?v=4tMnLFSpmfo
Free Download: https://www.thatimster.com/#pg=resources
Hope its useful 
This is a fantastic resource Thatimster! Thanks for the demonstration. I’ve used the FirstPerson.py component as a starting point for my next project. I left your Header comment at the top of the script. Are there any other considerations I should keep in mind regarding your work here? Credit matters to me.
I didn’t actually write the FirstPerson script that was done by Uniday Studios
Here is the BA thread: UPBGE Templates! (First Person, Top Down, etc)
Feel free to use however you like, I am not worried with credit.
Oop. Ha ha ha, ok cool, I’ll mention it to him too. Still, good application.
Please, can You short explain whats the advantage of using Py Components, instead a Controller Brick with Script. Do i need to upgrade my Project in progress?
Thank You,
Doc
There are a few major advantages:
The major disadvantage is that you have to code any logic sensors/actuators that you could previously plug in (e.g. raycasting, near sensor, path-finding etc.). I haven’t used it a lot though so there might be work arounds for this.
I think components are a good idea, however they should just be properties in each item, and a ‘factory/visitor’ constructs the scene and tracks what objects are running components, and runs functions in the script based on the content of the object.
this way you have only 1 script overhead instead of 100’s
Thank You Thatimster and BluePrintRandom.
This is a major different in building Games as i’ve done it before. Please excuse but i want understand.
An aditional Question i have:
I allways tryed to run Scripts as less as possible and only if needet. (Only if Sensor firing etc.) So i avoid animation - and supervisor - Scripts, because they has to run all the Time.
How is it with Py Components? Can i use them in every Case? Is there still a Loop, and asks for Event? Like a supervisor Script? Because for me, it looks like. I’m pretty sure it works otherwhise as i think. Sorry, i just want to avoid to do something elementary wrong.
Blah blah maybe off topic:
You could have a mix of both (bricks and components).
In true Entity/Component/System systems (ECS) the components are just data markers attributed to game objects, then some kind of manager system when running would iterate over the objects having some components.
For instance, in Unity, cameras are like an empty on which you install a Camera component. The rendering system would be aware of all game objects with the camera component and track the active one for the rendering.
In the BGE, a Camera is a specific subkind of game object that the scene tracks to make the render.
The ECS system would be more modular in the way that you could come up with your own set of Systems and Components, so much more modular. Of course such an engine usually provides the basics to make games, so you must have at least a builtin rendering system, maybe that could be overriden.
Anyway, Components in UPBGE look like Unity components (MonoBehaviour): they aren’t just data (although they can store data, that you can parameterize in Blender’s UI when editing your game). The components also execute a bit of logic on two events: on start (once), and on each logic frame (everytime).
If I am not mistaken, currently components that don’t implement the update method will make the game exit, because the engine expects the objects to have both start and update methods. So you will have to create a function that will be called but do nothing. Maybe a waste of processing, even little, but so far no one really needed more. (Bear in mind that the perf impact that this has is absolutely negligeable unless you have in the 1,000,000 objects with components).
On the other hand, you could have a component to store data, and access them from a Python controller script on a particular event, doing some processing at that point (instead of on each frame). That’s what I was thinking about when I said you could do both (bricks and components).
But you should just use what you feel more comfortable with, unless you want to share around, components usually have less requirements when sharing them, when bricks you might need a specific brick setup that could bring problems in your current design. Although components can have their issues depending on the way they solve the task they are meant for.
As mentioned by @wkk, components act more as a data container, but can easily be extended to have controller aspects. That being said, if you just want to initialise them without running an update method, you can simply put “pass” under the update function.
Interrupt based triggers for code are undoubtedly the most efficient way of doing things (you only want stuff to run when it needs to). However even logic brick sensors need to be checked every frame, usually heavy sensors (near, radar, mouse over any) will be more expensive than a more primitive python function (calculate distance, raycast etc) run every frame. That being said some logic brick implementations are faster because they are written in C without the python overhead. Again you need to find a good balance.
As far as I’m aware the update method of all python components have their update method run every frame, no event or supervisor script is available to manage efficiency (yet). Logic implementation in some cases may be better because you can control how often the scripts update (tick rate).
Again it all comes down to using the most appropriate / efficient tool for the current task, there is no superior method for every scenario.
Then, i wasn’t so much wrong with my assessment. I knew, some Sensors are expensive. But, because they are compiled Code, i thought they are always faster than Python. So, there are exceptions. I’ll keep that in Mind. Balance is, once more, the magic word. That will help to notice if Py Components could be a better Solution. Thank you.
with batched raycast exposed, we could raycast a whole list of objects and do it faster than a ray sensor I bet.
it’s not currently wrapped however.