BGE capabilities?

Hi, I’m new to forum, but not to blender as animation software. I want to ask what are the limitations of BGE?
I searched a lot for screens, videos or info , but those are old. Like Super Mario Recreation. I’m curious is it possible to achieve quaility of graphics similar to Unity 5? I know that me and my pals have to code in pyhton alot to get smooth 60 fps :wink: Is it good choice to pick BGE for complex 3d games? I mean we want to make games in art style similar to or nintendo’s wii u new zelda :wink: Not so complex like cryengine :wink:

That style is going to depend largely on your artists. Maybe you’ll need a graphics programmer for some GLSL magic.

Before starting a new blender project I’d ask myself these questions:
-Will it need headless support?
-Will it have lots of animated characters (>10) onscreen at once?
-Will it have lots of particle effects?
-Will it be published to browser or mobile?
-Will it need fancy stuff like volumetric lighting, large terrains, fields of grass, cascaded shadow mapping, or deferred rendering?

If you answered YES for any of those, I would consider a different engine.
Also BGE is no longer actively developed. There’s UPBGE but I can’t comment on the current state of that.

upbge is investigating how to proceed on armature skinning

upbge has geometry instancing, and on a small map made of tiles it made a difference of 10 ms (where 16ish ms is 60fps)

they say they are adding static draw call batching, freeing up more resources to be used elsewhere.

All in all upbge is growing and works well for me at the moment,

As for god rays in the bge, if there is something missing for the feature, add it to the upbge issues page.

the more developers we can attract by making quality games the better.

hordes of actors not animated using armatures is possible now,

also using armatures with FK is much cheaper than using IK
(same in unity I belive as well*)

many engines don’t even support ik right?

It’s not great but it’s also not bad. You can achieve pretty decent results with it.

Anything has limitations. Can you be more specific?

This depends more on you than on the game engine. Unity is a game engine as the BGE is a game engine. Game engines do not make graphics, they have graphics features due to there 3d render engine. The render engine provides the graphics features you can use. And yes, the features are pretty much the same.

Still, graphics depends on you.

What specific features are you looking for?

Unfortunately this question shows missing game development skills and low experience to the topic. This is not bad, but you should be careful in interpreting forum posts.

There is no direct relation between writing code and the frame rate of a game. There can some loosly coupled dependency.

When you write a lot of python code you might master Python in future.
-> When you master Python you will be able to get into the BGE API.
-> When you can use the BGE API you can write custom logic bricks for your game.
-> When you know how logic bricks work you can use custom bricks.
-> When you know how logic bricks work you will be able to describe behavior of objects in your game.
-> When you know how you can describe object behavior you can describe the game’s behavior.
-> When you know the game’s behavior you should recognized there are more aspects beside behavior in your game that eat processing time.
-> When you know how the game runs you might be able to identify processing bottlenecks.
-> When you know the bottlenecks you might be able to find more efficient solutions.
-> When you are able to find efficient solutions you will recognize solutions are usually not Python. [#1 bottleneck is render overload.]

I suggest you start learning how the BGE (or any other game engine) works. With that knowledge you should be able to find out how much processing time your game spends on each single aspect.

Coming back to python. The members of your team which want to describe behavior should learn logic bricks, Python and the BGE API. You can start without python, but it be will needed sooner or later. (No you do not need C/C++ that is a different development level).

The other members of your team can focus on other aspects of your game such as, creating meshes, textures, materials, animations and create sounds, write stories and dialogs, translate text, manage progress, buy pizza, cleanup files, ensure nothing gets lost, manage project homepage, communicate with each other and many more.

How many team members do you have?
How manages the project?

It your skill level it does not matter.

The art style is no problem as long as you are able to create such art (with low polygon details indeed).
I do not know new zelda.

The biggest obstacle that results in failed game development projects sits in front of the monitor. Do not worry I have my bag of fails too. They 100% failed because of me rather than because of the tools.

[Cryengine is no game. It is another game engine. This makes it a bit difficult to compare complexity with a game.]

Before you chose a game engine, do you have any concept regarding your game?
Or do you randomly play around and look what happens? This is not wrong, this is how we learn. Typically this is the fun part. Unfortunately it does not necessarily result in a finished game.

Developing a game is not like playing a game :p.