What will UPBGE bring in the future / Pros and Cons of the app

Game Engine Game Engine Support and Discussion
1

This isn’t a feature request or wishlist for UPBGE, but a question about what UPBGE may bring in the future.

For example:

  • What will UPBGE bring?

  • Any fixes/performance improvements

  • Other features

Currently, new UPBGE versions are released weekly in a form of “nightly” or developmental builds. Due to these being in development (beta), they crash more frequently, but are constantly being refined until they are deemed stable enough to be released.

From my experience, there are several pros and cons with UPBGE:

Pros:

  • You get very beautiful materials if you know how to do the shader node editor. This can lead to extreme realism, but is very hard on the CPU.
  • Inherits all of Blender 3.0s features.
  • Can be expanded upon with addons.
  • You can expand your games with Python, an easy to learn language (GLSL is much harder but possible).
  • All logic bricks are there.
  • Does not break too much compatibility.
  • A few of the python error messages now give better descriptions for example, “perhaps you meant ==?”
  • The program is easy to learn, and is free.
    Cons:
  • Slower than UPBGE 0.2. This is due to how Blender 3.0 works, and that Blender 3.0 was never designed with a game engine in mind.
  • It may crash: UPBGE isn’t perfect, and not all programs are perfect I get that. It can crash quite a fair bit, especially when managing bones due to the way it “skins” them. 0.2.5 crashes more than 0.3.
  • Slow with a lot of verts during gameplay. This is due to it trying to draw everything on screen.
  • May stop upon starting the game: This could be due to RAM issues or a shader compilation. This happened to me 3 times. The framerate appears to be stuck at 1000% when this happens…
  • Overwriting a blend file with UPBGE will make it unusable with non-UPBGE Blender.
  • Uses a lot of RAM.

If I got off topic, sorry. What will UPBGE actually bring in the future?

2

Game engine wise, a easy workflow for making simple games. Vulkan port is also on the table, possibly in the near future. No deadline to my knowledge though, but that might be because it’s Blender oriented and not UPBGE specific.

Vulkan will supposedly help with performance, for those who have devices that are powerful enough to use it.

Have you tried baking to see if that helps?

You forgot their cool logic-nodes, which, most of the UI and Python source they legitimately ripped from Armory source like they did with the old Armory website. Some may argue that the UPBGE team likes to “borrow” other people’s stuff. Roughly 80% of their source is from Blender or even BGE source, most of which they didn’t create (some of them did a few BGE commits for Blender).

Spot on, see here:

I’d say that ties in with this:

To be honest, since UPBGE isn’t officially incorporated with Blender, nor is it based on an add-on framework, it’ll probably never be fully compatible with Blender.

3

So, “the didn’t write 80% of the engine”

It’s easy to maintain this way.

Do you do git merges?

Also, yes blender code is good and getting better ever day, extending upbge.

Sharing code is good in this instance brother.

4

This topic again? I’m game for repeating myself.

The pro of UPBGE is Blender integration…
the con of UPBGE is also Blender integration.

It’s a pro because you can extend Blender, and it’s a bigger con because Blender is absolutely monolithic and lacking a C/C++ API, so you’re forced to compile your own build.

Or (at least bpy-side) you could write a plugin using the poorly documented as_pointer trick, which also requires monkeying with the Blender source as a lot of headers give you nothing but opaque effyn struct typedefs. Yeah, back to square one.

So the viable option: you can get away with writting a lot of code in python and then moving the bottlenecks to C, or use Cython. This is fine on paper, but not the ideal scenario.

I would push for just abandoning nodes and python for game logic altogether and moving to a C++ API instead, but I already tried it and no, it isn’t viable either: you still have to recompile the engine, else you’re beholden to the overhead of foreign calls.

I mean, oof. Yeah, but–

armature_transform_recurse(&arm->bonebase, mat, do_props, mat3, scale, NULL, NULL);

Besides the screen-wrapping line, nigh tenfold args func going recursive and handling the inner loop with a fooken macro; I give it the frowny face. It’s not that my own code is exemplary, it’s just not… whatever this is.

Syntactical pettiness aside, the software is good in terms of what it does, and generally it does so efficiently, so many bonus points and kudos well deserved.

But as far as the source goes… yeah. I doubt I’m the only one who doesn’t even want to be touching the damn thing.