[Bf-gamedev] A new script interface for bge (in theory) - A small diagram

[pgi]

Btw i have a working prototype integrated so things are not anymore in 
theory, now I know it also can work. That it also is a reliable 
implementation of a clever design is much less certain. I can provide a 
zip if that might help claryfing this thing. I'm not also saying "hey, 
tomorrow we zap this thing in", it's a design discussion.

I understand the modular design of the engine and I do agree that, in 
general, one big set of functions in a file is not a good idea.

There is no concurrency in the diagram at page 2 (which apparently 
didn't clarify things). Mixing uml notation with flow diagrams probably 
didn't help much. Sorry.

The system is fully sequential.
The engine starts, instantiate an IScriptInterface, load the script 
interface passing a pointer to it.
It enters the main loop, for each frame it ticks the script interface - 
which represents the logic update pass of the engine.
The script interface ticks the scripting units.
Each unit does what it needs, if it has to get or set data used by the 
engine, it does so by calling (directly or, as I think should be, using 
an oo api built on top of the low level IScriptInterface).
After the last script unit has been updated, the green thing, the script 
manager, returns the control to the engine.
The engine completes the current frame and starts another loop.

I like the door metaphor and the way I see it is that the big chunk of 
functions is the door between two rooms. You take out that and you have 
big one badly shaped room.

I can't fathom how you don't see the definition of the script interface 
inside the code of the engine components as a gigantic problem because 
it is, it is not a feature, it is a design flaw.

I think that providing the engine with a unified scripting interface is 
a sensible design choice because of the benefits of decoupling.

And the big file also addresses documentation problems. It's one place 
for one task.

I agree that the api might need smaller fixes and there is for sure a 
lack of documentation but fortunately I have enough experience to know 
where exactly the engine is lacking and I also know what can be done 
about it, so I'll do this instead.

On 29/01/2015 19:43, brita wrote:
> Skimming through your text and diagrams..
>
> you are attempting to provide 'one big file with the API', instead of 
> the bits, as is now.
> One big file is seldom a good idea and, in this case, the BGE is 
> designed in modules and objects. The python API reflects the Object 
> Oriented programming that is inside. It should be modular and in bits, 
> it is intentionally designed this way. OpenGL is designed in a 
> different way.
> this means that you shouldn't do  function(objectid, args), but 
> object.function(args)
>
> next, you are splitting of the API from the engine into a separate 
> shared library. why? (and take care, because dlls are the windows 
> version of shared libraries, blender is multi-platform).
> the API is a door to interact with a system. doors should be provided 
> along with the room, they are a part of it.
>
> the third thing is your focus on start, tick, stop.
> The GE loop currently is not prepared to be controlled externally.
> Look at your diagram in page2, you have concurrent arrows, who 
> controls the call of a next frame?
> Is it even useful to control it manually?
>
> all this said, the python api for the ge is incomplete and has many 
> things out of place.
> as a suggestion, why don't you try to fix smaller things in the 
> current API, starting by lacking documentation, if you will. until you 
> have enough experience to know where exactly it is lacking and what 
> you can be done about it.
>
> --
> Inês Almeida / brita_
>
>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20150129/cf245653/attachment-0001.htm