BDX: Potential blender engine, with mobile and HTML5 export

This is a small/simple engine that I’m presently developing for blender, built on top of libgdx, and gbullet. It’s still far from being “release-worthy”, but it’s already capable of supporting small games, like “99 Bottles”, which is my latest, and which you can play in the browser, or on your android device.

You can watch me demonstrate the blender workflow in this video:

I would really appreciate some feedback from the BGE community, relating to the general ideas presented, the workflow, the programming model, your personal priorities in that context (feature wise).

The information you provide now can help me better steer future development, and ultimately deliver a viable v0.1, to serve as a solid foundation for more involved open source work.

Also, if you have any questions, I would be glad to answer them (if I can).

Thanks.

Is it gpl?

Does it support Logic brick export?

If not how do you handle events?

It looks great for being so early in development!
I downloaded your game to my Galaxy Nexus; It’s as frustrating as its it addictive :stuck_out_tongue:
I have some questions:

  1. Do you think you could explain how it is exported? Does it retain its .blend format? What about GPL licensing etc.?
  2. What does and doesn’t work in comparison to the current engine?
  3. Are logic ticks taken into account with your implementation to libGDX?
  4. Do you think that Python could be used to code instead of Java (obviously to be converted to Java to work with libGDX)? – I, personally, find languages like Java and C++ messy, whereas ones like Python and PHP are clean.
  5. How’s performance in comparison to Blender?
  6. When do we get to play around with it? :stuck_out_tongue:

Edit: Guess sdfGeoff was writing at the same time :stuck_out_tongue: Sorry for double questions!

Is this only 2D or 3D will come later? Im more interested in Android/Ouya development. Its good that it supports Android.
Im interested in developing 3d games with cell-shaded stile + handpainted textures.
Easy api to understand, bge got one. :slight_smile:
Build in features to ease the development process. Ok, thats my feedback!

OK, I posted on the YouTube channel that I like this, but I’ll get a bit more technical.

I also would like to know more about the licensing. I’m assuming it’s not GPL, and probably something like MIT (just guessing). EDIT: This isn’t a question that hasn’t been asked, so I cut it out.

The massive cross-platform compatibility is excellent. Working on Web, PC, and mobile is great.

  1. I don’t like Java as much as Python, but I don’t think I’d so much mind learning more if the game engine and API was easy to learn (which looks like it is). Java is more strict than I’d like, but its limitations could also mean speed gains for some concepts overall (if I’m correct), so it might be a necessary trade.

  2. How many of the BGE’s physics options are available in BDX at the moment? I notice you used Ghost to make bottles fly through the ground, so it seems like at least a couple of them are working, right?

  3. What’s your priority list look like? How far up on the list is an equivalent “GLSL” mode with per-pixel lighting and shadows?

  4. How long in development has it been? It’s just you developing it, right?

  5. No logic bricks or any graphical coding language at the moment, right? Just the Java API? If you were to go with a logic-based coding method, I would recommend nodes over the logic bricks - what are your views on the matter?

  6. Can I play around with it a bit? Alternatively, can I look through the API to see what’s supported so far and how it works overall?

  7. Do you plan to make it open-source?

  8. Do you plan to implement particle effects, or leave that up to the developer (user)?

Suffice to say, I am very much so interested in this.

P.P.S. After trying the game out, the game seems really difficult!

This is still a work in progress, so there is no license at the moment. However, if/when I release v0.1, I will probably do so under Apache 2, which is a permissive license used by libgdx.

Does it support Logic brick export?

No. I could write the code to do that, but I lack the motivation to do so, for two primary reasons:

  1. The logic brick system, as it currently exists in blender, is deeply flawed.
  2. I doubt the overall utility/benefit of visual programming languages (as far as game development is concerned).

If not how do you handle events?


if (eventOccured()){
    performRelevantAction();
}

Yes.

Compile seems to take a while for such a simple game. How well will it scale?

Note that everything you see in the video is running on a 7 year-old laptop … And I’m recording on the same system, while everything is running.

That said: The underlying frameworks (libgdx especially) are a bit slow to start, as is the JVM in general, so even though the compile process is fairly fast, there’s a constant upfront cost in simply loading a Java program.

The export stage, from blender, should have a negligible impact on the overall speed of the launch (unless you have a really massive scene, with a lot of complex geometry).

What constraints are there? In the past, I’ve found java programs tend to take up a lot of ram (when compared to similar programs not in java). When dealing with 3D scenes, this may impose very hefty polygon/texture limits. Have you done any stress testing yet?

I haven’t really done any “stress tests”, but since libgdx utilizes lwjgl to interface with the graphics hardware, there should be virtually no additional memory overhead, as far as geometry and textures are concerned.

The limits on that front are imposed by the hardware; It has very little to do with the language.

What features from blender are/aren’t integrated? Bullet is, and multitexture is. How about modifiers, more complex materials (eg blend modes between textures), animations, skeletons …?

I don’t support modifiers, but it should be relatively straightforward for the export system to apply them, and subsequently export the resulting mesh.

More complex materials will have to wait until I figure out the basics of the shader system (it’s very important to get that right), so that will take a while, but I have some nifty ideas that could offer a lot of flexibility to developers, and make it all worth the effort.

Skeletal animation is possible, as libgdx already supports it, along with hardware skinning, but I’m not really sure how their data format works in detail, and I’ll need to know that before I can do the proper export/import with my .bdx format.

In short: Imagine the minimal feature set required for a game like 99 Bottles -> That’s basically all that’s available at the moment. It’s quite a lot, but it’s less than 25% of everything that’s available in the BGE.

How does it handle loading the 3D models? Are they read from the blend file, or are they exported to some format? Does/do you have plans to support dynamic loading?

Blender scenes are exported to .bdx files (json), which the engine can then load.

Dynamic loading is already available, in a way, because you can load any .bdx file, at any time, and use whatever object exists, in any given scene.

Same for textures. Can/does it read those from an external source, or is it built into the compiled program?

All the data is external.

When can I play with it? I’ve been wanting to remake skypilot for browser for a while now…

There’s still quite a bit of work to do until I can ship something that people can just download, install, and use.

So, it’s not just about the basic features. I also have to package everything for cross-platform distribution, and I have to write some documentation, and a lot of other things that seem small, until someone actually needs to deal with them.

Best case scenario: A few months, for v0.1.

PS: Nice game, and nice landing!

There is no distinction between tickrate and framerate in BDX, which is set at a hard 60 hertz, as enforced by the libGDX render step.

Do you think that Python could be used to code instead of Java (obviously to be converted to Java to work with libGDX)? – I, personally, find languages like Java and C++ messy, whereas ones like Python and PHP are clean.

There is a JVM implementation of Python called Jython, which would make that possible, but you wouldn’t be able to export to HTML5, because the GWT transpiler can only operate on Java source code, to generate valid JavaScript.

Regarding your clean/messy comments, relating to mentioned languages: There is nothing “clean” about PHP (I don’t know where you got that idea), and as convenient as Python can be, there are a lot of problems that statically typed languages can uncover at compile time, that would usually manifest as very nasty runtime bugs in dynamic languages.

How’s performance in comparison to Blender?

Comparable. :slight_smile:

…?

It’s already 3D, as you can see in the video.

Easy api to understand

Yes, of course. That is one of my highest priorities.

Well, what’s “necessary” depends on project requirements, but yes, “strictness” provides a number of optimization possibilities for the compiler, and that can have non-trivial performance implications.

Also, Google is really pushing Java to some crazy edge on android, with an advanced virtual machine, and some crazy JIT scheme that can (I’m told) perform miracles.

How many of the BGE’s physics options are available in BDX at the moment? I notice you used Ghost to make bottles fly through the ground, so it seems like at least a couple of them are working, right?

Right.

Currently supported bounds are TRIANGLE_MESH and SPHERE, with BOX serving as a default for everything else.

Currently supported bodies are STATIC and DYNAMIC, with RIGID_BODY serving as a default for everything else.

I didn’t need anything else for my small project, so I didn’t bother adding it in, but I can support any bounds/bodies available in Bullet 2.72, which includes virtually everything listed in the physics panel.

What’s your priority list look like? How far up on the list is an equivalent “GLSL” mode with per-pixel lighting and shadows?

I’ll have to refactor a lot of hacks that were made specifically for 99 Bottles, and my personal system setup. Then I’m adding basic F-Curve animation, after which I’ll probably start work on the material system (which will have to be supported by the shader system, which will take a lot of time to do well).

Then I need to finalize the API (for v0.1), make sure that I can package everything for cross-platform distribution, with the latest version of each dependency (there are a lot of dependencies involved, and while I think I can manage most of them with gradle, I’ll probably have to do a lot of work there).

To be honest, fancy graphics are at the bottom of my priority list, so it’s likely that you’ll see v0.1 without default lighting or shadow schemes.

However, I will expose a compositing pipeline, which can be tailored for specific materials, and for the frame buffers to which they are rendered. From there, I don’t think it will be all that difficult to create a basic per-pixel lighting and shadow mapping system, but that’s some time away.

How long in development has it been? It’s just you developing it, right?

Yes, it’s just me, and it’s been a little over 2 months.

No logic bricks or any graphical coding language at the moment, right? Just the Java API? If you were to go with a logic-based coding method, I would recommend nodes over the logic bricks - what are your views on the matter?

My views are outlined in this blog post.

In short: I don’t see the value in visual programming languages. However, if someone wanted to build that functionality, they certainly could, and they wouldn’t even have to deal with BDX internals, because they could just write a “NodeNet” component.

Can I play around with it a bit? Alternatively, can I look through the API to see what’s supported so far and how it works overall?

Not yet. It’s going to take a few months, at least.

Keep in mind that I’m new to libgdx, and the whole Java ecosystem that it depends on, so I usually have to do a bit of research before I can implement anything.

… I wish this stuff was easier.

Do you plan to make it open-source?

Yes, of course. Considering how much I’ve benefited from Open Source software, I really can’t imagine doing anything else.

Do you plan to implement particle effects, or leave that up to the developer (user)?

I think that should be left to the user.

Suffice to say, I am very much so interested in this.

It’s motivating to hear that, especially from you.

After trying the game out, it seems really difficult!

He, he, yea, I tailored the difficulty to my own ability, which was buffed-up through constant testing.

Probably not the best idea in the world. :smiley:

Wow, Goran, I’m impressed. I’m very much interested also, not that this means much, because I feel I’m very slow at programming. And so I don’t think I could really make great games generally.

I can only say that it would be great to have this engine as an extension of Blender, especially because it’s compatible with android (and other platforms).

Sad to hear that it is locked to 60Hz :frowning:
What does BDX do with physics and logic if the device running on it happens to be a 75Hz panel, or if it can’t do 60Hz (like an older phone)? Does it just run slower?

I thought, libgdx is only for 2d games!

I think that should be left to the user.

To make one engine more usable, you must provide with build-in features to ease the game development, so that the game developer could just start creating the game(writing game logic), rather than adding missing features. Those missing features are no special, but the all known.

^ Eh, being that the engine itself seems to be coded in Java, making a particle system in the engine itself probably wouldn’t really have any performance gains. If there’s no performance gains, you might as well make a particle system yourself.

If this component system is as easy to use and setup as Goran’s example code seems to be, then it probably wouldn’t be too difficult to make such a custom particle system. It could be done as an
in-engine application" (where you would load the particle editor “game”, configure your settings, save them out, and them load them into your actual game), or could use Blender’s built-in particle system’s settings to configure the game’s particlecs. Although, the game particle system probably wouldn’t use nearly as many of the options that Blender allows, so this might be awkward to manage (kinda like how the current Blender Game rendering option doesn’t use a lot of the Material settings, or any of the existing particle settings).

Speaking of which, Goran, how exactly does this component system in your code work? Is it built into the engine, something specifically for your 99 Bottles game, or is it something that LibGDX offers (and so you just pass it through, so to speak)?

I have another question/suggestion: Are you going to make this open? If so, why not upload it to, say, GitHub for others to contribute? They might be able to add features, fix problems, improve things, test it and just generally speed up development.

^ He said that he wanted to make it open-source, but it looks like he has some things that he wants / needs to do before then (finalize the API, fix the hacks that he used to make 99 Bottles, implement a basic material / shader system, package the dependencies, etc). So it seems like it’s just not ready to be uploaded for others just yet.

Two bits of good news:

  1. Having a realistic notion of where you stand, as a developer, puts you in the upper 25% of all developers; The other 75% are typically delusional children, working on some AAA clone, or something equally impossible for their current skill level and/or the resources at their disposal.

  2. You don’t have to make some “great” game, as long as you make something fun, or something that you can learn from.

I think libgdx limits the framerate to 60, but if it just follows vsync, and the panel refresh rate happens to be higher, I will “artificially” cap it at 60. If the device is too slow to hit that target, the game will simply run slower.

Using some kind of “time-based update” approach seems to be the common advice in these matters, but I think it’s actually the wrong path: While bullet can already interpolate over any time delta, the rest of the engine would have to be be programmed to do so. The operation itself is not that complex, but the fact that you’ll have to perform it, for virtually every state altering event … It complicates the codebase, and it still doesn’t solve the problem completely, because user logic can continue to alter state irrespective of “time”.

It’s much simpler to just define a reasonable “hard target”, which most devices can hit.

Are you going to make this open? If so, why not upload it to, say, GitHub for others to contribute?

As I said, and as SolarLune restated.

I thought, libgdx is only for 2d games!

Surprisingly, it does offer a basic 3D API. It was a fairly recent addition, from what I understand.

I find the term “particle system” to be somewhat ambiguous (conceptually). I mean, it could be as simple as an empty, spawning textured planes (set to halo) at some pre-defined initial velocity. Right?

Is a particle system defined solely by the optimized, in-engine path for particle simulation, or are there other factors that make it distinct from general engine capability?

Goran, how exactly does this component system in your code work? Is it built into the engine, something specifically for your 99 Bottles game, or is it something that LibGDX offers (and so you just pass it through, so to speak)?

It’s something I decided to build into the engine, because it’s such an effective tool in managing complexity, without being too complex itself.

A Component is simply a state machine, with states defined as you see in the video. Every GameObject has a main method (called by the engine), with the following implementation:


public void main(){
    for (Component c : components){
        if (c.state != null)
            c.state.main();
    }
}

You can override main, of course, and bypass the component system to use whatever methods you prefer, but I would recommend using components.

I see. So you gonna have to code a scenegraph and frustum culling. I like the idea of the game engine and java is not hard to learn as long as i just have to make game scripts(writing he game logic). :slight_smile: I could support the game engine as long as there is an ease… Like having build-in features.

Well, I think a good particle system runs underneath the user’s code because it’s faster usually than the scripting layer on top (in the BGE, for example). Given your entire engine runs on Java, though, a user’s particle system might run comparably fast compared to a built-in system, so it wouldn’t be as big of a deal to make one “on top” of the engine, rather than inside of it. Does Halo work in your engine across different cameras and viewports?

And components sound interesting. I did behaviors kinda similarly in Gearend, so I think I got the idea behind them. I really like working with them as re-useable blocks of code as opposed to writing each piece of logic myself.

Typically the important concept that distinguishes a component system from the usual entity concept is that they are much more lightweight. It would be foolish to consider a particle as an entity, so with more separated ecs designs, a particle system is a component, rather than a collection of entities within a system.

I don’t plan on writing a scenegraph, because I don’t feel it’s necessary, and frustum culling is already supported by libgdx, so it’s not something that I’ll have to implement myself.

BDX cannot create additional viewports at this moment. However, when I build that in, I will probably write a bit of engine specific code to refresh Halo objects before the next viewport is rendered.

Neither abstraction is sufficiently similar to the other, in terms of purpose, to make “weight” a relevant distinguishing factor.

It’s like comparing apples to apple carts.

It would be foolish to consider a particle as an entity

Not if it’s affordable, or if a particle actually requires the capability of an entity.

At such a point, what you are considering is less like a particle, and more like a ‘textured object spawned to face the camera’. A particle Is usually only important in the context of other particles, composing the system.

You would probably want to customize a particle system in such a way that it probably be best to make your own. This has been my idea for a long time, even though there are the add-ons. Which comes to my question: would people be able to and allowed to commit add-ons in the future?

I think particles should be for later discussion, cos right now its only the start of the “ge”. So i would say support for armature, animation, shaders, api work, but still a fake particles could be added, just like this -> http://www.tutorialsforblender3d.com/GameDoc/Texture-Animate/Animate_GLSL_Step_4.html