What is stopping bge from becoming a proper game engine?

Game Engine Game Engine Support and Discussion
21

So are we actually affecting the outcome of what will happen to BGE? Because usually it doesn’t seem to be the case and these discussions are reduced to nothing but trivial chit-chats based on rumors that invite even the most uneducated users.

Anyway for me BGE is awesome as it is. The ENGINE is not getting in the way when people want to make games and offers amazing set of tools for it. OK, not all eye-candy you see on other development platforms is as readily available, but it should be accepted BGE is not for those cutting edge graphics. The same with mobile platform releasing.

I don’t know anything about the codebase, I’m just a game developer. If it’s in bad state then sure, it should be rewritten even at the cost of backwards compatibility (it’s not like it has been compromised earlier, and for a reason). If that makes BGE more lucrative working site for volunteer code improvements even better. If there are little resources to do it then do it a little. Moreover I hope they aren’t reading the amount of BGE coding volunteers as the measure of potential of the engine.

I wouldn’t overhaul the engine in one way or the other. I like BGE where it currently is. I’m not sure how to read Ton’s quote. Is that a statement against improving BGE so that it’s comparable with Unity etc. (which I totally support) or a statement against keeping BGE branch at all in Blender (feels bad man) ?

Losing BGE would be just real pity. The engine has a huge edge in workflow compared Unity or UDK and it shouldn’t be so condescending. And it really is big. Export-importing a cube with diffuse map to another engine is not too hard but when you want to push your organic model revisions and tests out and have to manually correct and fine tune every single one of them in the game development software it gets really boring and pointless. AND nothing ever looks the same. Of course you are free to trade other parts of your workflow too, and soon you have spent thousands of dollars per desk just to minimize the workflow penalties.

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

Quotes like these I won’t agree with. The fact that some huge commercial giant does a feature more fluent or in greater control doesn’t mean your system is “substandard” or bad. After all it’s nothing but arms race. After something is achieved they strive for better stuff and so it goes on. Nothing is ever “finished” or “best”. Should GIMP or some feature of it give up because of Adobe Creative Suite that steamsrolls everything? Or OpenOffice compared to MS alternative? No, this things were set up to offer a free and independent alternatives to begin with. The fact that they can’t shoot for same quality doesn’t make them invalid.

I ask you: Where are the game developers that had to leave BGE because their project was too big for it? Have these people finished their project thanks to using another engine?

I’ve watched the game developing scene for almost 15 years and one thing that never changes is that people are just unproductive, think too much of themselves and get greedy and proud. Most projects failing is not because engine or platform was bad. BGE has got to stop taking the bashing and beating from noobs that step into the world of game development knowing nothing and expecting to just pour out AAA-quality games because magic. Of course nothing but a faceplant can come out of it. Every platform gets them, even the best.

Recently I was involved in Unity (soon to be kickstarter) project and I can tell that also people over there are at loss of skill, lack of tutorials and looking for an easy magic solutions, which are not available. Even the pricey asset store stuff is often not exactly what you need, you want to tweak it but it’s almost as hard as making something from scratch. They are frustrated because of lack of documentation and support, they are forced to try everything until they hack together something disfigured that barely does what they wanted to. Unless they pick themselves up and finally properly plan the feature, research examples and theory and code the exact thing they want. It’s how you make games.

I’ll just C/P this in the future threads…

22

Anyway for me BGE is awesome as it is. The ENGINE is not getting in the way when people want to make games and offers amazing set of tools for it. OK, not all eye-candy you see on other development platforms is as readily available, but it should be accepted BGE is not for those cutting edge graphics. The same with mobile platform releasing.

Actually, a few of the features I choose to integrate ended up not working (compound physics and getReactionForce)

I love it, but there are some clean ups needed for me to even release,

force = own.getReactionForce() is in the api and not existant

if you end a compound object, after attaching children and removing them blender crashes (or at least in my use case)

23

-It has a terrible visual programming design, when compared to construct2 or multimedia fusion. Its much harder to read and debug.

  • It cant compile to html5. Most inide engines today compile to html5, because it automatically makes the game multiplatform and even capable of running in a browser. Of course it also has to be optimized
  • Poor debugging tools
  • still relies a lot on python if you need to do anything too specific
  • imo needs a complete rewrite/update

if you want to cater to the entry level indie developer, you gotta change some things and be more competitive with whats out there. Try to learn from it.

24

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

Python for Ogre3d is outdated.

25

Is that your definition of a “proper game engine”?

26

When it comes to the lack of developers, one issue here is that few have been granted commit rights by the BF, so they have to post their changes to the patch tracker and endure a long wait until it is reviewed (which is also an issue with the Blender project in general).

Now with Brita’s help, a few more patches are now being committed to Master like one related to the applyImpulse function just today. There are people who have shown genuine interest in reducing the backlog of bugs as well as cleaning up and reorganizing the codebase and we need their help if the BGE has any chance of avoiding deprecation.

If it all fails on that end, a fork could be made where the people who have tried to help before can more easily get their code committed and we essentially get a version of Blender where a lot of non-game related stuff is ripped out (and perhaps we can eventually give code from that fork to the BF).

27

any word on getReactionForce?

it seems like you could just tally all added per frame?

28

I just checked the developer site and a new debug API is currently under review (submitted by HG1).
https://developer.blender.org/D635

  • imo needs a complete rewrite/update

On the updating part at least, here’s the link for LordLoki’s cleanup (currently under review).
https://developer.blender.org/D625

At the least, this covers the need to get the code organized, because unorganized code can turn off a potential developer in an instant.

29

I never said that substandard was lesser than commercial engine provision. There’s an individual benchmark of good and bad code/ features. Things like Recast are useful, but they’re not implemented in a friendly manner, and bugs are near impossible to address. Don’t add particle systems unless you’ve thought about it first - anyone can write good-enough code… Until you need to fix bugs / add new features, then you might as well start again cough, BGE.

30

@agoose77
I would’ve used another engine but I couldn’t find one for what I was looking for - C, PyPy3 with CFFI-based bindings*, modern OpenGL. Naturally I’m avoiding having to write as much code so I’m recycling parts from the BGE, mainly the Rasterizer (which is relatively clean); I’ve also taken account into various design ideas to streamline things like using DNA/RNA as storage. I would’ve used the BGFX library but it implements its own shader language which IMHO is not a robust solution, among other things.

Essentially, the engine is still based on the Blender file format and directly uses its data structures since IMHO that is what makes the BGE unique. All other game engines, internally use their own format, which requires converting from Blender to said format, which makes it less robust. For example, Panda3D uses eggs, I believe. Once I have the default blender scene up and running, I’ll announce it in the resources section.

*BTW, with PyPy and the CFFI bindings, it’s quite fun actually, you should check it out ;). For example, I’ve compiled Blender as a shared library and I can virtually access all of the C API from Python. You could go so far as to recreate Blender if you wanted…

@Akira_San
IMHO, Ogre is overengineered. Horde has a clean design (made by a CryEngine dev) but it’s not active and idk about the EPL license. BGFX, specifically a rendering library, is clean also but tries to support every type of backend which IMHO leads to overengineering, bloat and uneeded complexity. PyGame is just underpowered.

Generally, specific = more control, so either more logic bricks are needed or you gotta program…

From what I’ve seen, it seems like indie developers prefer to avoid programming at all costs, and would rather learn GUI-based tools. It may be the most convenient (shortest learning curve) but it’s not always the fastest nor the best long term solution. It also limits what is possible and ties the developer to the program since the tools are specific.

Understandably, they want to avoid going into the engine code so open-source is simply not an attractive solution and has minimal bearing. Idk if this is because a lot of indie developers are actually not programmers or they don’t have the resources to hire a programmer, but it’s a shame since programming is a fundamental highly-transferrable skill. Maybe the industry moves so fast that it’s not worth it; the mobile market is pretty volatile.

31

If anyone’s interested, there’s another thread in the news forum that contains a point indicating why it may not be such a good idea (in the near future at least) to simply remove the BGE.

If the developers removed the BGE, that means those wanting to use Blender to make games will likely have to rely on having a good .fbx file exporter to get their assets over to another engine, but there is one potentially formidable problem with that.

That problem is that Autodesk controls the format and they are a company that’s not very receptive of the idea that Blender could take a chunk of the market that they are trying to expand into, that means that through the creation of trivial changes and the like, they could potentially cripple Blender’s I/O abilities (and thus your ability to export to engines like UE4), almost overnight (case in point Ideasman42 already finding a small piece of functionality designed to make it so only Autodesk can write valid files).

In this case, the only reliable way would be for a new Open Source engine to step in and give it a way to read Blender’s native .blend format, at least that would be something that Autodesk can’t mess with.

32

Isn’t that where the BF has been focusing its development efforts on - improving FBX support? (That post also demonstrates my earlier point about the issues having to convert between file formats.) I’m suprised more of the game engine companies haven’t contributed to developing the exporter other than Valve I think.

However, I agree with you, an open standard would be better. The BGE has existed this long for a reason, so despite the current status of the BGE, I’m sure another open-source project will rise to take its place.

33

BGE2 = mit 3.0

Bullet 3

Render = modern openGL

???

can’t someone hack one together lovingly?>

34

Yes, the BGE will simply have to stay put until there is a rock-solid method of using Blender to interact with another engine that is not at risk at being yanked away or messed with.

If you think that would be easy, then let me remind you that solid interaction with an external engine was what was supposed to happen when Yo Frankie! was being made and the BF wound up having to develop the BGE itself to save the project.

The BF simply cannot take the risk of having a wide open void in terms of servicing game developers, because using the BGE is something that works now and it can’t be replaced until the new solution is complete and reliable.

35

@BPR - Nope, I think not. If it were that simple, anyone could / would have done it, but there’s a lot more to it than hacking together a 3D engine.

Hmm, this sounds interesting, indeed. Got a Github or Google Code repo yet? How far along is it? Is it literally Blender that’s been modded, or is it an external engine that can “run” blend files? =o

@Ace - You make a good point in terms of fbx being a proprietary file format that could prove problematic in the future. I certainly wouldn’t want to see only FBX being supported, and only Autodesk software being able to write that format. I’d have to look up some more info about this, though.

36

As far as I’m concerned, the main thing really preventing the game engine from being “proper” (by which I assume you mean that it had been used to create a AAA game) are the game developers themselves. The engine is open-source, leaving anyone to tamper with it as they please. Now, the problem with that is it is incredibly difficult to do so, and the engine is one hell of a mess in terms of code (it has been developed by so many people with so many different styles of coding over such a large period of time that many techniques are outdated). The engine essentially does need a full rework in my opinion. It’s a lot of work, but the results would be stunning.

That being said, cross-platform support would help the engine tenfold in terms of popularity, as would a better physics engine, logic brick system (like HIVE or kismet) and getting rid of the licensing issues.

The main thing that needs to be fixed as far as I am concerned is that the game logic and physics don’t run on a tick system, but rather according to the rasterizer’s framerate – resulting in the gameplay experience being different on every device

37

Personally, I am intrigued by the methodology with which the UE4 engine is going by, but what would prevent me from using it and sticking with the BGE is the reminder that we’re reliant on Autodesk when it comes to getting assets into that engine.

The main thing that needs to be fixed as far as I am concerned is that the game logic and physics don’t run on a tick system, but rather according to the rasterizer’s framerate – resulting in the gameplay experience being different on every device

I think the BGE API has functions that would allow you to change the number of logic tics. per second based on the framerate (not as tightly controlled as what Agoose77 wanted to do, but it should help to alleviate such situations).

38

the physics engine is good, it’s the wrapper that appears not well connected

39

It does, however not very well. It causes the engine to crash if the frame rate happens to hit 0. Also, logic.setPhysicsTicRate() works according to 60fps, as has been discussed in a recent thread I started inquiring it. It should indeed be at a far deeper level of the engine.

40

Interestingly, if you want to “tamper” with it, I’ve a patch that lets you do this.