Working on an engine and just pitching an idea, I’ve migrated from python to java, along so I’ve ported a game engine I was working on a while back (link here)

The problem was most of my opengl work was just blah in python. I really like how blender’s game engine is very elegantly event driven from a UI and I took that idea and started playing with it in python.

So here is a little food I considered, since I am working on my own game engine, why not intergrate into Blender (sorta) Blender’s GE button has its own window and it wont be hard to create me own via Blender’s Python API (BGL, Draw). This would allow users to use Blender to create game still, but be ported to Java, and java runs in a lot of places.

The UI would just write java code and compile @ runtime into java byte code. This way you can start working on a game in Blender and if the UI is not doing what you want, take the source its generated and work from there.

Now what about the source? Java compared to Python is a lot harder, well there is Jython, python synax accessing Java libraries. And I can embed python scripts into the java generated game.

On top of that there is Project Darkstar, a perfect game server for MMORPG’s developed in Java. There is also Java Web Start, making it easy to launch games from any browser. Not only that it takes care of version tracking, so lets say you’ve updated your game and using Web Start, anyone playing your game via web start will get the updates as soon as you upload it to the net.

Here is a sample unit test via “Darkcore” in Java

        Reader d3m = new Reader();
        // What coord to look (0.0, 0.0 0.0) is default
        camera.setView(0.0f, 0.0f, 0.0f); 
        camera.setPosition(3.0f, 3.0f, 0.0f); 
         * Usually don't need this but I use Blender & lazy to rotate 
         * models. API should be changed to "setAxisUp"('z', 1)
        camera.setLookUp(0.0f, 0.0f, 1.0f); 
        core.Cube cube = new core.Cube();
         * Assigning textures shouldn't need "world" but it will do for now =_=
        cube.assignTexture(world, "64x64.png");
        cube.setScale(0.5f, 0.5f, 0.5f);
        core.Mesh suzanna = d3m.Parsed3m("src/data/models/suzanna.d3m");
        //suzanna.assignTexture(world, "64x64.png");
        Light lamp = new Light();
        lamp.setPosition(3.0f, 3.0f, 0.0f);
        // Notice 64x64.png is the name used to put textures on the models

If your still reading below here wow :P. Yes there is jMonkey & Xith3D game engines, but there are certain things I would like to have the API accomplish. For example loading suzanna, it doesn’t have to be from a local file, it could also load from the net “

:eek:Woah, that’s what you’ve been doing all this time? Haven’t seen you, like forever.

Heh, idea’s good by me. I welcome all these different futures utilizing the Blender GE. Maybe try to get in touch with other developers as well, so that us users can just be able to create the game in blender, and have all that ported out to different renderers/engines with minimal structure changes on the user end.

Jason Lin

Thanks for your support :slight_smile: everything is far far far from being close to have something working, as I still have the Blender GUI to do over my current engine.

If you would like to follow my updates, you can follow my game forum:

:frowning: Sorry you have to register (painless dont even need a valid email or comfirmation)

And now for a suzanna momment :evilgrin:

This is a little more explanation of what Darkcore is. Its meant to be a game engine with a built-in render engine. Unlike Orge and Crystal Space this does not tie into Blender GE directly. Instead meant as a migration tool to produce games in blender without the traditional game logic bricks. So game will not be able to be running on Darkcore without reproducing the logic bricks. However most of the python scripts will be able to be ported over. The true intent of Darkcore is to allow the developers to migrate using the same GE Python API with enhancements or move out from GE’s logic bricks into a Java environment for more flexibility and enhancements.

I just spent the last 2 hours implementing Jython as well as some Blender GE API for the demo below.

public class Main {

    public static void main(String[] args) {
        World world = new World();
        Scene scene = new Scene();
        Camera camera = new Camera(); = camera;

        camera.setPosition(5.0f, 0.0f, 5.0f);
        camera.setLookUp(0.0f, 1.0f, 0.0f);

        Mesh suzanna = Reader.Parsed3m("src/data/models/suzanna.d3m");
        suzanna.assignTexture(scene, "64x64.png");
        String pycode = new String(
                "co = GameLogic.getCurrentController()
" +
                "own = co.getOwner()
" +
                "rot = own.getRotation()
" +
                "rot[1] += 0.5
" +

        Light lamp = new Light();
        lamp.setPosition(5.0f, 5.0f, 0.0f);
        Light lamp2 = new Light();
        lamp2.setPosition(5.0f, -5.0f, 0.0f);
        lamp2.setColor(0.5f, 0.5f, 0.5f, 1.0f);
        lamp2.setSpecular(0.0f, 0.0f, 0.0f, 0.0f);


If you notice the pycode variable, you should notice some familar stuff :P. Thats python code powered by Jython 2.2.1:

co = GameLogic.getCurrentController()
own = co.getOwner()
rot = own.getRotation()
rot[1] += 0.5


I don’t know why you couldn’t just add features directly into the current BGE, developers working on their own engines is one reason why the current BGE isn’t developed as much as it could be.

Why have all these competing projects when we can have all focus on the current BGE (competing projects like your project, BlendX, ect…)


BlendX main goal is not the same as mine. Yes they want to improve logics, generalize render api to impliment other render engines but in the end you still stuck with a crippled GE. Reason being is there will be a legacy they’ll need to support, not only that Blender GE is c++, Blender GUI is C. So implimenting the features I want would result is a much longer development time. Plus blendX is meant to be built into blender directly, this is something I do not want, the ability to not only migrate your game code but also migrate which application can tie into this. For in a certain sense, the Game Gui for building logic bricks would be programed into Max, Maya, Lightwave, etc.

I have messed with Blender GE code and I’ve seen its render engine, its a real mess and its a big reason why GE Python code is so crippling as far as accessing certain attributes and just having the dynamic ability. Having that legacy truely burdens the overall progress of improvement.

So in the end BlenderGE is a mess, and a large reason developers would rather develop our own solution is because of that. Also as far as release cycles, I would have to compile blender for windows/mac/linux and so on. Where if I use Blender’s Python API to build GUI in blender’s script panel to manage your game world I could release fixes that would be cross plateform and just faster paced development (gui would be in python). And because the game engine would be in java, not c++ I again wont have to compile for multiple plateforms and be able to produce a more productive release cycle.