Originally Posted by elmeunick9 View Post
Would you please explain which diferent aproches are you taking and why? Thanks.
I still didn't invest a lot of time in your system, but here is mine:

- Managers are classes that run logic on a set of events, they are all organized from a hierarchy: at the very top sits the RootManager: it distributes the "first calls" to everyone below it. From there you can incorporate different managers that will try to run at "game level". Events range from start, pre_draw_setup, pre_draw, tick, post_draw, to finish. Sub objects managed by specific managers are also extended to provide new events in addition to the firsts (Stages have a load and ready events for instance).

- Stages that do the scene's job: scene do complicated stuff behind the hood, but to BGE user they are mainly a collection of objects. But swap scene, lose your logic: you need to restart the thing in the next scene. So I implemented Stages that would work a bti like Scenes. Stages are not implemented like they should yet, but I'm learning at the same time... Trial and error :/

- Define a class that will be automatically applied to the gameobjects: you fully describe your logic for that class in its methods, and some EntityManager watches entity events and apply the correct classes to the linked objects (link by name, property, or any filter you'd like).

- Assets: basically the same as the linked classes, but more specific. You define a specific object, and can instantiate them from code, like MyAsset.Spawn(), the spawned object will be of type MyAsset, automatically applied.

- LibLoad manager kinda: You can define dependencies in stages to auto libload everything you would need. Can also async libloading just by asking, wait for the "ready" event to be called to know when it is finished.

- Support for threads in a Thread manager: Use the base classes I built in, they behave almost like basic threads, but I provided functionnalities to monitor them and terminate them almost automatically at the end of the game (no more remaining threads in the Python runtime because you forgot to kill it). You can still mess things up tho, so even if it is easier, it is not recommended, but its there

- Support for coroutines (I need to do a bit more work there tho): Instead of using threads, I added a "function spreader" that takes a Python generator as input and iterates one iteration per frame at the time until the coroutine terminates. Its awesome for cooperative parallelism.

- Just added somewhat of a submodule to "easely" add new materials to objects using shaders. I'm still tinkering.

- Action mapping capabilities: Input is a problem, and dynamic mapping is the solution. But I extended the implementation to not be reserved just for the input. Input management uses the mapping system to retreive the correct callbacks, but any module/system could bind to the mapping system and fetch the same callbacks, but for another use. (think using the same mappings for both a player controller or a bot, they just bind to the mappings and trigger them).

Now, these are the key points I could think of, keep in mind that I'm still improving features, because I'm testing it with what I can think of and rework some of the things that could be better.

If you want a live example, you can take a look at https://gitlab.com/bgez/demos/BGEz_LandGen, its a short demo I made using BGEz a few weeks ago (maybe a month ago ?). Anyway, the logic is not that hard to grasp, just take a look at the folder named "MyGameLogic", use some editor with a tree view, should be fine to read. (Also keep in mind that some things are still moving around in the framework, everything that seem ugly shall get reworked).