[Bf-gamedev] Refactoring BGE code (to accomodate a new design)

[pgi]

So, it's time to show Ketsjii some love.

First things first: I'm not proposing to make a new engine that will 
crush all AAA proprietary code multibillion companies out there. I only 
secretly wish that :D.

As a matter of fact I'm not even proposing to make a new engine.

What I'd like to do is to refactor the code of bge. From jargonese to 
human, refactor here means to take the existing code and move, rename or 
split existing classes and functions, in a way that preserves at 100% 
the current set of functions, as perceived by the user. Bugs included.

The purpose of this bare transformation of code lines is not only to 
make the code "easier" to read (easy is a relative thing) but also to 
prepare the engine for future upgrades.

For some of the issues with the code I link to the blog post written a 
while ago by Moguri here

https://mogurijin.wordpress.com/2014/06/12/why-is-the-blender-game-engine-difficult-to-maintain/

As targets for the refactoring I would also point the several 400+ line 
functions that have no performance reasons to be there or the use of 
instance members as result buffers for callback functions that make the 
code flow pretty hard to follow.

What do I mean with "prepare the engine for future upgrades". Simply 
put, to give to the code a more standard layout. One can take Game 
Engine Architecture, get the functional units that compose a (modern?) 
Game Engine, try to superimpose that schematics to the bge and he will 
find himself with a bit of a puzzle.

I firmly believe the uncommon structure has quite some responsibility in 
the slow pace of the development. I make two examples - to make it short.

Game engines have assets managers. The asset manager is the unit 
responsible of feeding the engine with static informations about the 
world it has to simulate. It takes resources of all kind and formats 
(models, relationships, scripts, images and so on), translates them into 
data that the engine can read and manipulate if necessary, feeds the 
engine with that data when required.

So where's the AssetManager of bge? There is some of it in the Converter 
package, some in the Physics/Bullet package, some in the Ketsji 
package... data conversion happens a bit everywhere. That is not a 
problem, at all. Until you want to change things a little. Let's say 
that I want to add a function that updates the material displayed in the 
engine when the material changes in blender. You go to the AssetManager, 
because conversions happens there and links between asset materials and 
engine materials can be registered and found. In bge is quite a task to 
find out who's converting the data, who has a reference to the converted 
material and who knows where the link between the two is.

Game engines have input managers. The input manager that signals from 
external processes and converts them into semantic events for the 
engine. Usually it's for the hid devices (mouse, keyboard, 
controllers...) but is can also be used to parse network inputs.
BGE has not input manager. Input management is a stage of the engine 
loop that acts directly on input devices. Input devices are both input 
devices and logical managers of inputs. If you want to add a source of 
input, you go to the InputManager, to capture the raw input and 
translate it into meaningful signals that the engine will query later 
on. In bge it is a little different.

So here's the proposal. We find out a more common architecture for the 
engine. We can take one of the many examples (well, not so many really), 
strip out unwanted things - like AI Management Units, Multiplayer 
Network Managers, GUI Layers, specialized renderers and so on, we keep 
what matches the current set of functions and we push the current code 
in that new layout.

I think that the functions bge currently has can be constrained into the 
following units:

1. GameLogic (but some will forcibly remain in the objects, due to the 
python mappings)
2. Rasterizer (Renderer)
3. SceneGraph
4. AssetManager
5. InputManager
6. PhysicsManager
7. Engine

And each unit will further organized to match some sensible structure to 
be defined.
The layout should take into account what is going on with other parts of 
blender (like the viewport and I don't know what else).
I have no problem taking care of the coding part.
Because it is quite a big transformation, I'd like to do it in chunks, 
periodically submitted to review.
Being quite obnoxious with diagrams, I will start by writing down the 
schematics of bge as it is - a thing that might come handy in any case 
and that will help me bashing the keyboard.

I'd like to have some feedback, resoucers or articles to check for, 
ideas and and (mandatory) agreement on the new layout of the engine.
Or a slap in the face, I might very well be wrong on my assumption that 
the current design is a mess. But I could point out that it has been 
probably a data driven design because I see the logic of it and its 
typical problems.

Cheers, all the best and stuff

pgi.