[Bf-gamedev] Bf-gamedev Digest, Vol 15, Issue 5
Angus Hollands
goosey15 at gmail.com
Thu Jan 29 19:58:27 CET 2015
Whilst I do not defend how we currently handle Python inside the BGE, I
don't think that this is the best solution to fixing such problems.
My primary concerns are thus;
1. Bloat. Moving OO centric code from the objects they're concerned with to
a generic interface both creates a heavy header to link against, as well as
removes the OO paradigm of related functions with their concerned data.
2. Code duplication & Interface. This solution addresses two different
parts of the Python API - where it is defined, and seemingly where it is
being called from.
I prefer to look at the problem in a more generic manner. The current
scripting problem is that Python is embedded in the BGE, which is
undesirable (inflexible). In addition to this, We're still using partially
user-defined bindings, instead of more extensible wrappers (see Panda3D's
API generator). Addressing these two concerns makes things far more
interesting to work with.
In a more general sense, there are quite a number of systems which assume a
specific design paradigm, and once we start distributing out these systems
the BGE may better have benefited from a more involved consideration for a
redesign.
Nice work, nonetheless, you took your time to actually explain your ideas
:)
On 29 January 2015 at 11:00, <bf-gamedev-request at blender.org> wrote:
> Send Bf-gamedev mailing list submissions to
> bf-gamedev at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.blender.org/mailman/listinfo/bf-gamedev
> or, via email, send a message with subject or body 'help' to
> bf-gamedev-request at blender.org
>
> You can reach the person managing the list at
> bf-gamedev-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-gamedev digest..."
>
>
> Today's Topics:
>
> 1. A new script interface for bge (in theory) (pgi)
> 2. Re: A new script interface for bge (in theory) - A small
> diagram (pgi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 28 Jan 2015 21:20:33 +0100
> From: pgi <pierluigi at tukano.it>
> Subject: [Bf-gamedev] A new script interface for bge (in theory)
> To: bf-gamedev at blender.org
> Message-ID: <54C94491.1000902 at tukano.it>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I hereby propose a new script interface for bge. I will also take care
> of it - once I figured out a couple of runtime issues with linking and
> resolving names. No coding needed, just ideas.
>
> Currently bge scripting is done in Python. To be clear, that's perfectly
> fine: it makes sense to have one scripting language - and not a hundred
> - and it makes sense for it to be Python.
>
> Here's the problem I see though.
>
> The interface between the engine and the scripting layer is spread all
> over the place. Each engine element has its own little subset of the
> whole thing. The thing is in fact so tightly integrated that changing it
> would be a major undertaking.
>
> Instead of doing that i made a couple of experiments with adding a new
> interface that will, with time, replace the older one. It can be made to
> work.
>
> This is how the new system would work - more or less.
>
> The engine presents itself to the scripting interface via a big
> collection of functions, much like an opengl interface. Things like this:
>
> class ScriptInterface {
> public:
> long findObjectId(std::string name) { ... }
> int getObjectType(long id) { ... }
> void setObjectLocalLinearVelocity(long id, float x, float y, float
> z) { ... }
> void getObjectLocalLinearVelocity(long id, float* buffer3) {
> ...something... }
> ...and so on forever and ever...
> }
>
> So it's a huge set of relatively small function, defined in one file.
> This is used by the scripting system to get data from the engine.
>
> The script layer is defined in a dynamic library, with a interface like
> this:
>
> void start(ScriptInterface* si)
> void tick();
> void stop();
>
> From the engine side, the scripting layer is then activated and ran
> like this:
>
> ...when the engine starts:
> scriptlibrary = load_the_dll
> ScriptInterface* si = new ScriptInterface(ketsy, scene list, maps,
> whatever is needed);
> scriptlibrary.start(si);
>
> ...for each frame
> scriptlibrary.tick();
>
>
> ...when the engine quits:
> scriptlibrary.stop()
> unload the dll if necessary
>
> So there's very little to change in the actual code of the engine, and
> that little is just adding a couple of lines.
>
> What's in the dynamic library.
>
> In the jvm version:
>
> start(ScriptInterface* si) -> stores si, starts the jvm, load the jvm
> script interface (a java class, BGEScriptContext)
> tick() -> tick the BGEScriptContext, which in turn ticks all the scripts
> loaded on the jvm side
> stop() -> signal the scripts to stop, kills the jvm
> ...
> one jni function for each ScriptInterface function, like:
> JNIEXPORT jlong
> Java_org_blender_bge_scripting_BGEScriptContext_findObjectId(JNIEnv*
> env, jclass cls, jstring name) {
> long id = scriptinterface.findObjectId(stdstringname)
> return id;
> }
>
> This is a trivial 1:1 mapping.
>
> The third part is this BGEScriptContext class, which looks like this:
>
> public class BGEScriptContext {
> static { System.loadLibrary(...the aforementioned dll...) }
> ...for each ScriptInterface function
> ...the corresponding static method, like
> public static native long findObjectId(String name);
> public static native void setObjectLocalLinearVelocity(long id,
> float x, float y, float z);
> ...
> }
>
> Another long, boring but still very trivial 1:1 mapping.
>
> And that's it. Once you have this big java class in place, all the
> languages that run on the jvm can access the bge engine functions. You
> can have it in python scripts:
>
> import BGEScriptContext
>
> id = BGEScriptContenxt.findObjectId(name);
>
> in java, in scala, in lua, in javascript. More so, on top of the raw
> BGEScriptContext one can build a structured interface, without the need
> to interfere with the engine code. So one can have a Scenegraph type
> that gives the scripters access to BgeGameObject types (that the
> scenegraph will secretly build from ids).
>
> Advantages i see over the current system.
>
> From the engine perspective:
>
> 1. the script interface is defined in one place, which makes it easier
> to maintain, extend and - in case of an excess of love - transplated as
> it is in case of radical upgrades to ketsji
> 2. the engine doesn't have to know how the scripting interface runs, it
> just loads a dll and calls a total of four functions.
>
> From the scripting perspective:
>
> 1. because of the dynamic linking, the script counterpart can be
> replaced (wanna pass from jvm to mono? Just create a new dll with the
> same load(ScriptInterface), tick() and stop() functions. Well, at least
> that how I think dll works.).
> 2. using a proper virtual machine allows to support multiple languages
> with a single interface to maintain. That's for free. For the jvm, once
> you get that BGEScriptContext class in place, you can code in Python,
> Java, Javascript, LUA, Kotlin, Scala, Pizza, Prolog (there is still
> someone using prolog!), C, Pascal. Take that Crytek.
>
> And I sincerely hope this mail doesn't come back from the mailing list
> serve, flagged as spam, because it took me a long time to write it.
>
> I'd like to know if anyone has any thoughts on this subject.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 29 Jan 2015 02:31:22 +0100
> From: pgi <pierluigi at tukano.it>
> Subject: Re: [Bf-gamedev] A new script interface for bge (in theory) -
> A small diagram
> To: bf-gamedev at blender.org
> Message-ID: <54C98D6A.5010908 at tukano.it>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> I have produced a diagram to help explain my mumbling.
>
> Here's the link
>
> http://www.tukano.it/blender/TheDiagram.pdf
>
> Diagrams are professional, so this idea becomes automatically a good one.
>
>
> ------------------------------
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
> End of Bf-gamedev Digest, Vol 15, Issue 5
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20150129/aab445e3/attachment.htm
More information about the Bf-gamedev
mailing list