[Very Test] Replacing the BGE script system.

Game Engine Works in Progress and Game Demos
1

So, I was making my game (a dungeon and dragons magic heartstone diablo might and magic kind of game) and I met my nemesis: I can’t stay focused. This is what came out:
Behold the moving box:

Which is not that interesting, even to me, but there’s a catch. This is the script that makes it move:

var scene;
var cube;


function start(engine) {
    scene = bge.api.findSceneByName("Scene");
    cube = bge.api.findObjectByName(scene, "Cube");
}


function update(engine) {
    var buffer = new bge.mathutils.Tuple3f();
    bge.api.getObjectLocalPosition(cube, buffer.values);
    buffer.add(0.01, 0, 0);
    bge.api.setObjectLocalPosition(cube, buffer.getX(), buffer.getY(), buffer.getZ());
}


function stop(engine) {
}

Web developers should recognized it on the fly. Javascript.

What is this madness.

Basically this is how the thing works: I took the codebase and added a second script system. Ok, it is intended as a complete replacement of the current one because I think the current one is godawful but I digress.
This new “LogicEngine” adds a couple of tiny classes in the bge codebase that define a plugin interface for external script engines (aka load a shared library).
It is, imho, a good start because you can take the bge code and remove from it all the “script” stuff. The pluggable system allows updates to the script api without having to rebuild the entire engine.
It also allows the engine to have multiple script modules: one might still be based on python3, one might be using Mono, mine will use the OpenJDK.
There’s a big pro in this variety. If you want to deploy the game on multiple platform, scripting is an issue because you can’t tell if the host platform will support. I’m thinking about webgl here: if the engine supports javascript as a “logic” language, you still need a webgl renderer but the logic is already done.
I’d like to stress out that having a plugin system allows the separate development of the script engine from the rest of the bge: the modified engine has no external dependencies, at runtime it looks up for the requested shared library, if there is one that satisfies the need of the scripts used for the game, it uses it, otherwise it starts and executes with no problem. It just doesn’t execute the logic defined with the new engine.

Issues.

None, on the technical side. I’ve not designed the ui panel that will allow the user to associate a script to an object or a scene or the entire game.
I’m using linux, so it’s currently working on linux but there are no reason whatsoever for it not to be translatable to windows or osx (in fact one only needs to add the dynamic library managament for windows, the rest is cross platform).
It adds the openjdk as an external dependency, meaning that the game engine is fully compilable and executable without it, but you need to have one to compile the script engine that uses the jvm and to run a game.

What’s the next step.

I know that a particle system is not feasible with the current python script system because the vm can’t keep up with the math. It’s not its fault, python does what it does with the magic of dynamic binding, which is wonderful until you start to have a gazillion calls per frame.
I’ll make a particle system with the current script api and then I’ll make another one for the jvm and this new script engine.
Will it be faster? If the answer will be “vastly” then the pro will be so many that I might start pestering the blender foundation about it. If the answer will be “a bit, but not too much” then it won’t be enough to force me having to deal with the blender irc channel.

2

nice work.

can your logic editor write code to this format?

3

I was thinking of allowing the logic bricks to make code that other game engines could use.The idea seems similar to me.Maybe it is my imagination.

4

Great pgi!. I will follow very close this development. Thanks for your efforts.

If it evolves in right direction I think It will have a great impact in the BGE/UPBGE web/mobile development.

5

New script system is great and all… but damn that game sounds awesome.

6

@BluePrintRandom
Yes, it is possible to translate an existing logic node tree into the code needed by the new script environment, the addon had a parser component that did that for the logic brick system, so it would just be a matter of adding a second one that does the same but for a different target environment.
I did kill that addon though because nodes are not a practical way to define the logic of a game (too messy).

@Lostscience
That looks like a definitively possible but different approach. The benefit of having scripts deployable to android or a webgl engine is a side effect of replacing the python interpreter with a general purpose virtual machine. What I’m looking for at the moment is simply a script system that is more flexible (pluggable, more languages available, hopefully better raw performances) and less taxing on the codebase (a single entry point, no dependencies at compile time on the engine’s side)

@lordloky76
If all goes well I will publish the relevant part of the system on github. It should be compatible with upbge, as a matter of fact I might move it to that codebase because the blender’s one I downloaded doesn’t look very stable (the viewport randomly complains about shaders)

@pqftgs
:smiley:

7

A thing that came to my mind just now. You can actually use the “logic system” to provide native (ie C/C++) extensions to the engine.
That requires some details of how the system does what it does.
The engine (KX_KetsjiEngine) acquires a new field (LogicEngineFactory).
When the engine starts, it creates a LogicEnvironment.
This environment represents what a LogicEngine sees of the blender game engine.
This environment contains (and exposes to the user api) a pointer to the KX_KetsjiEngine instance, so the logic engine practically sees everything.
With the environment in hand, the engine asks the factory to provide a suitable LogicEngine instance.
The factory checks the environment, determines which dll (if any) defines the requested LogicEngine, loads the dll.
The dll defined (by contract) a function that also takes a LogicEnvironment and returns a LogicEngine and it is by calling this factory function that the running KX_KetsjiEngine gets its logic engine.
A LogicEngine type has three functions: start, update and stop and these are called in the corresponding stages of the game engine.
And that’s actually the whole system.

There’s nothing that forces the “LogicEngine” to do logic stuff and do it in a virtual machine: it has access to the current KX_KetsjiEngine, it can be written in C/C++ using the full bge/blender api.

If, instead of having one LogicEngine instance per game engine instance we associate the game engine with a set of logic engines, we could have a “LogicEngine” written in C++ that creates and modifies the geometry of a terrain.

Does anyone sees any problem with this? Other than security issues - but we don’t have it with the current system either.

8

The BGE already allows you to call a Logic loop that controls the Game engine instead of the default loop. You can use this to run the engine. To from there you can call into a blocking method in your own C code that builds against blender to call nextframe.

Your “many logic engines” idea is just another way of looking at systems, in the same way that the BGE has input and physics systems. You could already do this :slight_smile:

E.g (excluding the module definition and includes)



PyObject* my_custom_entry_point(PyObject *self, PyObject *args)
{
    KX_KetsjiEngine* engine = KX_GetActiveEngine();

    while (true)
    {
        engine->NextFrame();
        UpdateSystems();
        sleep(1.0/60);
    }

    PY_RETURN_NULL;
}



import my_engine


def main():
    my_engine.my_custom_entry_point()
    print("Game is done!")
9

Well, I don’t want to give control of the main loop to a plug in and I certainly don’t want to involve a foreign execution environment (python in this case) in the process.

10

I really wish someone would write the logic bricks into the node editor and make them faster :stuck_out_tongue:

11

You’d rather use JavaScript over Python? I’ve never heard of that preference before 0.o

Aside from that, this is neat.

12

I’m really curious on how are you going to find time and motivation to re-write every CPython binding of every class. Because if your idea is to replace the scripting system by writing it in Python, it’s going to be really slow.

13

@Lucrecious
The idea is not to use javascript, I don’t even like it. The idea is to strip from the game engine codebase that part of the system that deals with logic - be it scripts or bricks or nodes - and have a separate, pluggable module to do it. You can have the exact same api, with python, as we have now, it will just be implemented differently, in a transparent way for the user.

@TwisterGE
I have no idea if I’m actually going to finish this thing. It’s not really a matter for motivation but of anger: I can only take so much of cmake, especially when it tells me that “stof” is not a member of “std” even though I told that damned thing to use c++11. I hate that thing, so much…

14

I mean, you can write this yourself without adding any code to BGE as is :slight_smile:

15

CMake is just a build system, not a compiler. It will only generate files for a compiler to know what to do. Don’t blame it.
Sounds like someone’s compiler is too old or partially supports C++11. MSVC for example, doesn’t fully supports it.

16

I understand the project, I was just confused by the pick of language haha

17

TwisterGE, I’m a happy person, I make fun of things. Don’t take everything I say as if I was serious.

18

It’s difficult to understand that through text.

19

Ah, no problem, just assume I’m a buffoon and you can’t get wrong :D.

Update. I’m kinda disappointed by the initial result, I was expecting much much more. I tested both systems with a particle simulation script. Basically there are 1000 transparent particles that are randomly moved, colored and rotated around. I’ve let them run for a bit to have the fps settle down then I recorded the following videos.

This is the upbge + standard python script environment (particle program written in python):

And this upbge + the new OpenJDK script environment (particle program written in Java):

It’s a bit faster but, as I said, I was expecting a lot more.
I should really profile the jvm to see what’s going on… but instead I’ll make a different version of the java particle simulation that uses more threads. Just for the fun of it :smiley:
I also want to try to make a second LogicEngine that uses the good old C++.

20

By the way, there are some side advantages I was missing a lot, and one is access to a profiler that can be attached to the script engine while the game is running. This is the jvm running that stuff.

http://www.tukano.it/images/jvm_telemetry.png
jvm_telemetry.png1407×876

http://www.tukano.it/images/invocation_profiler.png
invocation_profiler.png1407×876

Is your script killing the framerate? Launch the profiler, attach it to the game and you’ll know everything. I love things that work with a button! :slight_smile: