Well, we will see what happens on steam. 
I am making a game that is fun, eventually I will worry more about looking cool.
From my point of view BGE doesnāt need to be a AAA engine. It needs to be a engine focuses in small teams (1-10 people). With these small teams the timesaving of to use a COMPLETE suite from modeling, animating, scripting, testing, to be able to export an executable), avoiding coversions between suites, is a great advantage. I think it is its strongest point.
Thanks to that point we have games and demos like these (between others):
Dead Cyborg: http://steamcommunity.com/sharedfiles/filedetails/?id=92960780
Krum: http://steamcommunity.com/sharedfiles/filedetails/?id=347245948
I will escape: http://steamcommunity.com/sharedfiles/filedetails/?id=252822617
BGE Tech Demo:
Super Blender Galaxy Fan Demo:
BGE Realistic Forest Environment:
What he said. ^^^
Those look very nice for modern mobile games but not so much modern PC games
Yeah, the OpenGL is not modern, there is no batched draw calls, lighting needs work,
But it has evolved over the years, some consolodated effort could remove dependency on some off the older code.
If a rewrite were to occur I would want the exact same engine with no bugs and better performance. Like OpenGL 2.1, the most recent bullet engine, with a clean physics implementation. The logic events triggering script is amazing, however there are a few sensors I would add,
LOD Level sensor or the ability to set states on LOD change
Distance to camera sensor.
Actually, the graphical capabilities of the BGE have barely seen any extensions or enhancements in the more than 5 years since GLSL was added (the light data node, a new bump algorithm, and LOD is pretty much it). Overall in the last ten years, there have been only two major revisions and two other notable enhancements in the BGEās graphics capability (the introduction of multi-texture mode and the introduction of GLSL, 2D filters, and ability to write custom shaders).
The truth is that graphical improvements have usually been in the gutter as far as priorities go, there has been work for major improvements, but none of that have gotten into master. The BGE community is also one of the only notable game-creation communities on the web where the very presence of a real shading pipeline was considered controversial and āsimply unneeded fluffā according to some.
The topic is still about Blender Interactive not trying to save the bge 
In my opinion, they should be the same topic,
There has been many many many peoples time, and love in the code of the engine,
they want interactive mode to be independent of a standalone capable engine? Why?
do they have stock in unity or UE4?
Why not have both?
I say fix the bge, make blender interactive, and keep cycles and blender internal,
donāt throw stuff away, unless itās useless.
You either donāt get what it would take it to āfixā the BGE or you just donāt want to get it.
The people who have actually tried to work with the BGE source-code have said it plenty of times, fixing the BGE itself to make it a truly modern engine would imply having to do an almost complete rewrite of it. When the state of the code gets to that point it just becomes easier to create an entirely new interaction module for Blender (much like the mess in BI giving birth to Cycles because itād be about the same amount of work, but is more logical overall if you want state-of-the-art technology).
Just try to count the number of BGE bugfixes and enhancements that just created more bugs, the architecture is dangerously close to being a house of cards.
http://www.tukano.it/blender/TheDiagram.pdf
people are willing to do that.
I hereby propose a new script interface for bge. I will also take care
of it - once I figured out a couple of runtime issues with linking and
resolving names. No coding needed, just ideas.
Currently bge scripting is done in Python. To be clear, thatās perfectly
fine: it makes sense to have one scripting language - and not a hundred
- and it makes sense for it to be Python.
Hereās the problem I see though.
The interface between the engine and the scripting layer is spread all
over the place. Each engine element has its own little subset of the
whole thing. The thing is in fact so tightly integrated that changing it
would be a major undertaking.
Instead of doing that i made a couple of experiments with adding a new
interface that will, with time, replace the older one. It can be made to
work.
This is how the new system would work - more or less.
The engine presents itself to the scripting interface via a big
collection of functions, much like an opengl interface. Things like this:
class ScriptInterface {
public:
long findObjectId(std::string name) { ā¦ }
int getObjectType(long id) { ā¦ }
void setObjectLocalLinearVelocity(long id, float x, float y, float
z) { ā¦ }
void getObjectLocalLinearVelocity(long id, float* buffer3) {
ā¦somethingā¦ }
ā¦and so on forever and everā¦
}
So itās a huge set of relatively small function, defined in one file.
This is used by the scripting system to get data from the engine.
The script layer is defined in a dynamic library, with a interface like
this:
void start(ScriptInterface* si)
void tick();
void stop();
From the engine side, the scripting layer is then activated and ran
like this:
ā¦when the engine starts:
scriptlibrary = load_the_dll
ScriptInterface* si = new ScriptInterface(ketsy, scene list, maps,
whatever is needed);
scriptlibrary.start(si);
ā¦for each frame
scriptlibrary.tick();
ā¦when the engine quits:
scriptlibrary.stop()
unload the dll if necessary
So thereās very little to change in the actual code of the engine, and
that little is just adding a couple of lines.
Whatās in the dynamic library.
In the jvm version:
start(ScriptInterface* si) -> stores si, starts the jvm, load the jvm
script interface (a java class, BGEScriptContext)
tick() -> tick the BGEScriptContext, which in turn ticks all the scripts
loaded on the jvm side
stop() -> signal the scripts to stop, kills the jvm
ā¦
one jni function for each ScriptInterface function, like:
JNIEXPORT jlong
Java_org_blender_bge_scripting_BGEScriptContext_findObjectId(JNIEnv*
env, jclass cls, jstring name) {
long id = scriptinterface.findObjectId(stdstringname)
return id;
}
This is a trivial 1:1 mapping.
The third part is this BGEScriptContext class, which looks like this:
public class BGEScriptContext {
static { System.loadLibrary(ā¦the aforementioned dllā¦) }
ā¦for each ScriptInterface function
ā¦the corresponding static method, like
public static native long findObjectId(String name);
public static native void setObjectLocalLinearVelocity(long id,
float x, float y, float z);
ā¦
}
Another long, boring but still very trivial 1:1 mapping.
And thatās it. Once you have this big java class in place, all the
languages that run on the jvm can access the bge engine functions. You
can have it in python scripts:
import BGEScriptContext
id = BGEScriptContenxt.findObjectId(name);
in java, in scala, in lua, in javascript. More so, on top of the raw
BGEScriptContext one can build a structured interface, without the need
to interfere with the engine code. So one can have a Scenegraph type
that gives the scripters access to BgeGameObject types (that the
scenegraph will secretly build from ids).
Advantages i see over the current system.
From the engine perspective:
- the script interface is defined in one place, which makes it easier
to maintain, extend and - in case of an excess of love - transplated as
it is in case of radical upgrades to ketsji- the engine doesnāt have to know how the scripting interface runs, it
just loads a dll and calls a total of four functions.
From the scripting perspective:
- because of the dynamic linking, the script counterpart can be
replaced (wanna pass from jvm to mono? Just create a new dll with the
same load(ScriptInterface), tick() and stop() functions. Well, at least
that how I think dll works.).- using a proper virtual machine allows to support multiple languages
with a single interface to maintain. Thatās for free. For the jvm, once
you get that BGEScriptContext class in place, you can code in Python,
Java, Javascript, LUA, Kotlin, Scala, Pizza, Prolog (there is still
someone using prolog!), C, Pascal. Take that Crytek.
And I sincerely hope this mail doesnāt come back from the mailing list
serve, flagged as spam, because it took me a long time to write it.
Iād like to know if anyone has any thoughts on this subject.
Page 2 quote from gamedevMail
Btw i have a working prototype integrated so things are not anymore in theory, now I know it also can work. That it also is a reliable implementation of a clever design is much less certain. I can provide a zip if that might help claryfing this thing. Iām not also saying āhey, tomorrow we zap this thing inā, itās a design discussion.
I understand the modular design of the engine and I do agree that, in general, one big set of functions in a file is not a good idea.
There is no concurrency in the diagram at page 2 (which apparently didnāt clarify things). Mixing uml notation with flow diagrams probably didnāt help much. Sorry.
The system is fully sequential.
The engine starts, instantiate an IScriptInterface, load the script interface passing a pointer to it.
It enters the main loop, for each frame it ticks the script interface - which represents the logic update pass of the engine.
The script interface ticks the scripting units.
Each unit does what it needs, if it has to get or set data used by the engine, it does so by calling (directly or, as I think should be, using an oo api built on top of the low level IScriptInterface).
After the last script unit has been updated, the green thing, the script manager, returns the control to the engine.
The engine completes the current frame and starts another loop.
I like the door metaphor and the way I see it is that the big chunk of functions is the door between two rooms. You take out that and you have big one badly shaped room.
I canāt fathom how you donāt see the definition of the script interface inside the code of the engine components as a gigantic problem because it is, it is not a feature, it is a design flaw.
I think that providing the engine with a unified scripting interface is a sensible design choice because of the benefits of decoupling.
And the big file also addresses documentation problems. Itās one place for one task.
I agree that the api might need smaller fixes and there is for sure a lack of documentation but fortunately I have enough experience to know where exactly the engine is lacking and I also know what can be done about it, so Iāll do this instead.
No, people are willing to talk about doing it.
The fact remains, no one at the BF/BI cares much about the BGE, and I doubt anyone will convince them that itās worth the work to try and salvage. Itās just not a āgoodā game engine. Without a rebuild, itās unlikely that it ever will be. It had the chance to be, years ago when it was fresh and new, but it had little to no momentum from the get-go. Itās been left behind, back in 2007-2008 days. That may as well be decades in Computer Time. Itās time to let it go. Move on. There are a HUGE number of better options that the schedules of the Blender coders canāt hope to compete with. Ton knows this, and has said as much on more than one occasion. Blender canāt be all things for all people, and in terms of ācore feature setā, BGE is very low on the totem pole. As Blender grows in complexity without growing in developer free time, fat will need to be cut to keep it at a respectable level in terms of workflow and bug count. And as it stands, BGE is just about the fattiest piece there is on the Blender cutlet.
Actually I have seen longstanding bugs tracked down in the 2.7x bug fixes,
HG1 found the reason for physics crashes with rigid bodies,
PGI found that itās texture caching that causes libLoad to crash if you mix it with LibFree,
I found that the triangle mesh problem is in all engines, (falling through at speed) and to deal with it anything that moves faster then x size for scale, get a extra raycast.
What feature is broken?
2.73a has rigid bodies broken. I have actually been watching things stabilize.
I can shoot a missile at 1000bu a frame and detect itās collision,
You just cast a Ray from each corner and account for velocity.
Graphics is the horse that needs beaten.
I literally have been able to do anything I tried.
I can make a Ragdoll walk up stairs,
I donāt think people understand that the bge is not logic or python
It is logic and python.
You have to only call python for certain events,
Are more then one object using that script?
Then use a list that process all of them per frame,
What canāt you do that is not graphical?
^ ^ ^ What he said.
No, people are willing to talk about doing it.
- a hemā¦ cough
Btw i have a working prototype integrated so things are not anymore in theory, now I know it also can work. That it also is a reliable implementation of a clever design is much less certain. I can provide a zip if that might help claryfing this thing. Iām not also saying āhey, tomorrow we zap this thing inā, itās a design discussion.
@pgi seems to know what he is doing.
I asked him about 5 different things, from bugs to features,
he tracked down a long standing issue with libLoad that is as old as libLoadā¦
I recently checked the libload/free thing and it still crashes happily. Thereās a problem of invalid pointers in RAS material bucket (or something like that) after a libfree. I have submitted a detailed reportā¦ that has been merged with the previous one. It is a nasty bug to track down, even the debugger can only tell āsomething went wrong but I donāt know whatā.
OTO, if you have the .blend file and you can link it, I have a blender build with debug symbols on that i can run through the debugger to get the precise source of the problem.
he wrote patches for some of the issues and had them up in the tracker in a day.
He puts code where his mouth is.
I wish I were half as good.
Ok butā¦ does it really matter? I mean, you donāt want use the BGE to make AAA game. You probably donāt want to use Unity to do that either.
Does the BGE provide a engine to make games that does everything a indie game developer need? I would say that it has even more. I never saw a indie game that couldnāt be done in the BGE.
I donāt know about development issue and why itās really hard to maintain, but from a user point of view, itās working. Is that a problem to let it inside Blender?
Yeah, it does matter because the quality weāre seeing represents the limitations imposed by the BGE. Sure, people using BGE arenāt going to be creating AAA titles. On the other hand, who wants to be restricted only to last decadeās graphical capability on the PC? I donāt need to be creating a game with 60 hours of photorealistic environment and mocap animations in order to take advantage of the shaders, lighting, streaming worlds, etc that the BGE alternatives offer.
No, it doesnāt. It might for you, it certainly doesnāt for every indie developer. Take a quick browse through the Polycount forums to see the graphical assets and environment quality that indie developers are pumping out these days. The BGE is simply not up to the level that indie developers of PC games are targeting now.
Then, and I mean no offence by this, you havenāt been looking that hard. Overgrowth, Amnesia, Outlast, āThe Talos Principleā, āThe Vanishing of Ethan Carterā, āSir, You are Being Huntedā, hell even āThe Stanley Parableā lighting & graphics are above what one can expect to be performant in the BGE (given it lacks basic features like portal/cell culling and the like). Whether it be issues with streaming large worlds, limitations on shading/graphics, or simply the lack of industry standard occlusion schemes - the BGE is simply not a competitor to the alternatives indie developers are looking at (& using).
All this without even touching the amount of time & effort it takes to do with the BGE what comes as a standard feature of other engines.
Unfortunately, some of those games really do push the BGE about as far as it can go.
I do recall that the people behind I Will Escape had some difficulty making sure their gameās framerate was high enough, and I think they actually had to cut detail in a few places.
Krum; Edge of Darkness meanwhile gets very close to the most that the BGE can do in terms of the performance when animated characters are present (thatās why youāre not going to see large groups of enemies at once).
You will also notice that even BPR, who claims he can make the BGE do anything he wants to make, had to scale the scope of Wrectified back a bit because of a mix of BGE bugs and limitations. I think if only the BGE could start seeing a bug count that decreases rather than increase, it would still be a good solution for simple to moderately complex games. For very complex and intensive games though, it would probably need a rewrite. I would also note that in a few cases, the developer moved on to another engine after completing the project because he wanted to make something beyond what he thought the BGE could handle.
What really can be the kicker is that there are certain game mechanics that the BGE used to be capable of without tons of effort, but are abilities since lost to code-rot. In the 2.7x series at least, the BGE has perhaps lost more functionality than it gained.
Actually, the scale is the same, my issue was overcomplexity, I actually plan on using everything In my other version of the rig,
I had to understand how to eliminate about 300 logic bricks.
Basically, I just take the walking Ragdoll, drop itās actions, and in target the new rigs animation handles 
then align the New armature to a mix of the ground normal, hip orientation and world z, Ta Da.
My old action control used a lot of logic.
Also the scale is larger now, because I can have 100 actors, or 1 and it uses the same logic, you just change who the controller is,targeting.
So, multiple actors, multiple vehicles, taking control of enemy unitsā¦ Is all trivial now.
WASD mouse
1 and 2 keys
Mouse wheel up and down for fly mode (speed)
Attachments
MasterControlMouse (2x).blend (576 KB)
The BGE was always going to be PC based due to its ties to Blender which itself is PC based, so the BGE really belonged to the pre-mobile era (and where it remains stuck today). Personally, I always saw the BGE as an experimental outlet for Blender, to push it in new areas - at this point itās an overgrown addon that needs to be excised.
The BGEās primary advantage of being integrated with Blender is a double-edged sword due to the GPL licensing and limited platform support. Not to mention, the logic bricks arenāt anything special and very limited. In the end, there wasnāt much of an advantage at all, quite the opposite; good in theory, but bad in practice.
Game engines vary tremendously these days. Since we have all these new platforms, more widely and easily available than ever before, and different APIs, specialization is needed, which is why there is no shortage of game engines on the market, both open-source and proprietary.
Optimizing for mobile has a different set of constraints than for PC or for console or WebGL, etc. Sure, you can build an interface to abstract it all away, but that tends to make things difficult (any serious development should have a programmerā¦).
IMHO, WebGL is the best shot for cross platform development, but you could say it too is similarily pushing the limits of HTML, which was designed during the early bandwith-limited days of the internet.
TBH, nothing can really replace the BGE, for reasons I stated in my previous post, and because it was never viable from the beginning. There is no more speculating. Stop the mental masturbation madness! We all know what needs to happen - the BGE needs to die already so we can move on to more important things!
Blender is ready to take off and it canāt afford to support the extra baggage.