[Bf-gamedev] Bf-gamedev Digest, Vol 15, Issue 5
pgi
pierluigi at tukano.it
Thu Jan 29 21:50:33 CET 2015
On a more general scale, what I would like to do - and I'll be shameless
enough to propose right after the conclusion of the next dev irc meeting
- is this.
1. come up with a new design for the engine
2. refactor the current system to constrain it into the new design. A
pure refactoring of the code, no functions added or removed, just moving
stuff. From the perspective of the user, the program will still work
exactly as it did before.
3. upgrade the subsystems where needed.
At that point things start to change.
I believe it is possible because I'm reading a lot about game engine
design lately and they have a common core that maps more or less to
ketsjii. In fact the scripting part is the only one I can't fit in
because there is not this unified scripting interface.
I confess that I don't see the current mapping of script functions to
object members as a benefit, not even from a design perspective. Each
object has two interfaces, defined in the same place, for different
purposes.
I'm not saying that scripts would have to be written using the set of
functions defined in the headers, not at all. Once you get rid of the
python interpreter you can reconstruct the current object based api, in
the same way game engines are built on top of the opengl interface,
using the "native" language of the vm (C# or Java but I would choose the
jvm because it is gpl).
Code duplication is a bad bad bad by product of my proposal. I can't get
rid of it. In fact, in the prototype I have, the same set of functions
appears not two but three times.
Once in the header, once in the engine and once in the dll.
I didn't try but I think I could get rid of all three layers but in
doing so I would tight the engine to the scripting vm, repeating the
same mistake (I can't help but seeing it like that) that has been done
with the current api. And you don't really want to have JNI code in your
engine objects.
I'll look into Panda3D API generator. As a side note, my problem with
python is not really a problem with python but with the question: how do
I run those scripts on android?
On 29/01/2015 19:58, Angus Hollands wrote:
> 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
> <mailto:bf-gamedev-request at blender.org>> wrote:
>
> Send Bf-gamedev mailing list submissions to
> bf-gamedev at blender.org <mailto: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 <mailto:bf-gamedev-request at blender.org>
>
> You can reach the person managing the list at
> bf-gamedev-owner at blender.org <mailto: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 <mailto:pierluigi at tukano.it>>
> Subject: [Bf-gamedev] A new script interface for bge (in theory)
> To: bf-gamedev at blender.org <mailto:bf-gamedev at blender.org>
> Message-ID: <54C94491.1000902 at tukano.it
> <mailto: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 <mailto: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 <mailto:bf-gamedev at blender.org>
> Message-ID: <54C98D6A.5010908 at tukano.it
> <mailto: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 <mailto:Bf-gamedev at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
> End of Bf-gamedev Digest, Vol 15, Issue 5
> *****************************************
>
>
>
>
> _______________________________________________
> 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/f0c5f9f6/attachment-0001.htm
More information about the Bf-gamedev
mailing list