What is stopping bge from becoming a proper game engine?

According to the roadmap, Ton says:
“What should then be dropped is the idea to make Blender have an embedded “true” game engine. We should acknowledge that we never managed to make something with the portability and quality of Unreal or Crysis… or even Unity3D. And Blender’s GPL license is not helping here much either.”
What is stopping BGE from becoming a “true” game engine? It has most of the features needed for a game engine doesn’t it? So is it just the license that is the problem?
With a couple addons and 2d filters created by the community, you can easily achieve a good looking game, not to mention the games published through BGE which have gone through to the steam greenlight.

That wasn’t about the BGE becoming a proper game engine (it already is), it was about removing the BGE altogether in favor of an ‘interactive engine’ that would be more a tool for artists and animators. In other words Blender would no longer have the ability to make games and people here would have the choice to either use Blender as just an asset tool with another engine or find a completely different hobby.

That was then though and it was open fully to possible changes, the development right though seems to be going the route to preserving the BGE’s existing abilities while cleaning up the codebase so as to make it easier to maintain and less prone to new regressions.

Most of us agree that the roadmap isn’t going to change, at least to the extent that we will port any code. At the moment there are two different development efforts, one to restructure the internal BGE code so that we might find some common ground with an interactive engine later on / a fork can be maintained, whilst the other is looking at making a user-friendly integration of another engine (my choice is Panda3D).

The license for the BGE really isn’t a problem. There are very few developers who can say “I stopped using the BGE because the license was restrictive”. Most people will say “I wanted more shader control”, “I wanted more advanced particle systems”, “I wanted more control over the engine with Python”, “I wanted better lighting options” or other feature / functionality issues, rather than the license. After all, many don’t get that far.

The BGE has many features that a commercial engine is expected to offer, but they aren’t all:

  • Functioning
  • Reliable with other features
  • Easy to maintain / maintained
  • Performant

Typically with game engines, it’s all or nothing - don’t implement a feature if it will be substandard.

Provided that there is some means of using Blender as an interactive editor to a game engine, I don’t see there as being a problem what that engine might be.

The BGE is falsely named- it’s really more of an interactive rendering system. Come 3.0, we’ll most likely see BGE changed to “Interactive Render mode.” In this statement, Ton recognized that the BGE just doesn’t have to power to meet the standards of industry standard engines like Unreal or Cry Engine. As he said, it can’t even meet the capabilities of Unity 3D.
I personally would never make a game I’m intending to make a profit off of in BGE. Unfortunately, my project leader has chosen to use Unity, but we at least don’t have the constant limitation of frames we would have if we made it in BGE. I’m glad that Ton knows this, but that’s just my two cents.

Logic could be made to be amazing, it was gutted when it left the studio,

second off, the render is all that is bad,

Logic is smoking fast,

Bullet 3 is on it’s way.

we need a better render, and bullet 3, and the ability to choose sensor variables as field inputs,

Ray---------and--------property target=Ray hitObject


that is all,

A decent chunk of that is simply because the code looks very uninviting with functions and files being everywhere instead of being grouped together in a logical structure. (like the Logic Brick code files being in two different spots, an issue that LordLoki is already working on).

Some people have spent a lot of time on their projects, what will they do if the BGE disappears, will they just have to accept that they wasted years of their life for a dream that will never be?

The only condolence would be that the Unreal 4 engine will likely become the indie engine to rule them all by that point (it’s already pulling users away from Unity). I would fully support a monopoly by Epic Games since it would also be backed by a legion of developers contributing to the code. Come to think of it, some of my games could use a nice rethink of how I want them to be anyway, but that assumes that Ton even has the ability to get a proper .fbx exporter working which might be dependent on what Autodesk does (and they’re not all that receptive to Blender).

The thing is, if Autodesk does something with their .fbx format that cripples Blender’s I/O abilities, then the BGE will have to stay, because that’s the only painless way that users will be able to actually make games.

Most people use Bullet 2, and Bullet 3 won’t bring much apart from GPU support, which has pros and cons. Physics isn’t a show stopper at the moment.

Logic is fast because it doesn’t do anything, and most users won’t push it to the limits. The logic brick system is highly limited though, and is a push factor if the Python API isn’t strong enough (which it isn’t).

Once you remove rendering and physics, you don’t have a game engine, so even changing one of these is a big task.

With dropdowns to select sensor properties you can handle much of the ai with logic, also there is no ability to handle lists currently, or object keys, if I could evalute a list based on another property etc, you could use my logic based for loop to manipulate data with logic.

BPR, I’m almost positive that the ability to specify elements of logic components in other components is something that can be done with nodes. Please consider it before suggesting an overhaul to the logic brick system.

AFAICT, there are definitely some things that need to be fixed with the BGE, but it seems like even if Panda or something ends up being the “guts” of the engine that Blender runs, the code-base might get rewritten first, which is definitely a plus.

Something I’d like to see would be the ability to approach everything from Python by just providing a class instead of doing it ourselves through the current mutation hack.

hmm, this is sort of sad considering the work the foundation put into it, i guess us bge users will have to make do with the older versions of blender. Not that this is really a problem anyway considering the default blender render engine is becoming less and less important and cycles is taking over.

I agree, the BGE is heading towards deprecation and I highly doubt it’s going to change. I believe most of the Blender-primary users (the majority) would like to get rid of the BGE so development is focused solely on Blender.

For the people that invested into the BGE, well as they say, the BGE is open-source so their dreams need not die, however they will have to put more work into it whether maintaining it or forking it themselves when the BGE is recycled.

Logic bricks are the least of the BGE’s issues…

Multiple Issues with the BGE
One of the issues with the BGE is the development process. Moguri is pretty much the main developer of the BGE and thus he shoulders all the administrative tasks like code reviews etc., and of course it’s all voluntary. So it’s a lengthy slow process to get patches in. All in all, it’s difficult to contribute and also to become a developer. Naturally, this discourages and frustrates developers, both from personal and anecdotal experience.

Understandably, to become a developer, you need to be familiar with the codebase. The problem is the codebase is a compete mess which makes it difficult to understand and write good code. It should’ve been refactored long ago in conjunction with Blender. So today we’ve built layers upon a rotten codebase. Unfortunately, the amount of developers has shrank so we also lack the manpower to address it, and it only gets worse as time goes on. Again, nobody wants to sift through nasty code.

Having recently become familiar with the codebase, it’s feasible to cleanup things here and there, but major changes will require significant time due to A) lack of manpower, B) the design of the BGE itself. With point B, I mean generally when implementing new things you don’t want to modify the existing codebase so as to break backwards compatibility. Normally this is a good thing, however if the codebase is never refactored periodically, this eventually rots the codebase, as we see now.

A simple example: the inconsistent naming of the API. Changing the format of the names would break scripts but if a refactor had happened long ago, it would’ve been cleaned up and the precedent set.

Personally, I have given up on the BGE :frowning: (writing a new engine…). This was my personal issue with it - the BGE has fundamental issues that need to be addressed but it can’t happen for whatever reason, lack of manpower, the BF’s goals, etc. so in the meantime we keep adding on to the ball of mess which makes it increasingly difficult to maintain, etc. Finally, all of this lowers the potential of the BGE and thus less likely for developers to utilize the BGE. IMHO, this is why the BGE is not a “proper game engine”.

I understood it that way:

The (future) BGE will be used to do all the preview that currently a separate preview is rendering.

SO it is just another use case (similar to the trials to use the game engine as for physical simulations which are no games either). This should not prevent this platform to be used to create games.

The benefit is, that there are not two nearly-realtime renderer in one application (preview + bge).
Another benefit is the features of Blender (all this little checks and buttons) are much better integrated into this renderer. Surly there will be features that are simply not sufficient (raytracing …) even now.

Indeed there is the danger it is developing to much towards the preview purpose. But I think with a clean architecture this should not be a big deal.

A I said, this is my opinion.

Be careful falling into this trap; writing an engine is a good solo project, but it’s usually an unrealised goal :slight_smile:

I wouldn’t say it’s as dramatic as BGE just going away. Ton intends- from my understanding- to change the title to better represent it’s function. I believe that Ton knows exactly what the BGE is and means to its community, but has no intention of making it more than that. It would be an unrealistic goal to try to make it meet the standards of Unreal, for example, while he could just update the exporter to make Blender work more in tandem with UE4.
I’d probably say that Ton would like to improve on BGE, given what it is to many of us, he just doesn’t expect a complete overhaul to ever happen. Look forward to new features though.

The BGE won’t integrate with Blender, so it will be a rewrite in any case. It is unlikely that this rewrite will focus on game development, so features such as path finding are less important than, say, particle systems.

Not this thread again <.<

How do you regulars just go through the same thing every time?

Personally, I have given up on the BGE :frowning: (writing a new engine…)

Are you going to use Ogre3d?

Well, I think everyone’s concerned and trying to figure out the best way forward here, Kheetor.

Ton’s idea sounds like a rewrite of the BGE, but if the code-base is bad, then it needs to be refactored in any case. It might not be possible or feasible to do given the current amount of developers, so it might be efficient to present the case to Ton as the next big project.

Rather than a movie or anything like that, have everyone work on refactoring and cleaning up the BGE’s code-base, breaking compatibility wherever necessary.

@Akira_San - If you’re interested in Ogre3D so much, there are Python bindings available to it, to my knowledge.

The logic bricks need the ability to do this

Property actuator
Propertty 1 =List
Index=property 2—and------store property from list as property 3


Property is on list
For items in list(requires expression evaluation)
Property is not in list

So you can perform for loops using logic.
This would make for almost instant logic using C++ handled data

Render is scattered a bit, Moguri or someone as familiar with the code, needs a super code ninja to direct , who has a lot of time and is a great coder, (unless moguri has the time himself) to refactor in a short time.

Python is still crucial for anything outside the ability of logic, but logic is made to be fast at what it does (and it is)

If anyone is going to make nodal logic IT MUST connect up to the C++ handles like logic nodes do.

Render=not modern
Physics=bullet is amazing but not well integrated
Logic=amazing but potential is untapped
Nodes=not yet ready

Fixing what we have is an endevor, but I am unsure if starting over is any better.

I wish there was a basic flowchart describing what conditions the source and or binary files could be distributed vs using different licenses and libraries.
I seem to keep reading conflicting or out of date posts about what conditions the files can be distributed under different licenses, then I dont trust what I read.

I havnt run into any problems with bge yet making basic test demos, if sensors run out of options I use the python functions.
Though ive only made 3 basic game types so far.

I tried to compile a basic demo using the compile addon, the runtime library was 40mb on windows which was a bit disappointing, but not too bad if you make a big game I guess.
I dunno, they are my thoughts, though im pritty new to bge.