Same reason why almost no game engine in existence (including the BGE) uses a custom physics engine (ie. one just for the engine), a good quality one is difficult to code and it’s not easy to find someone with the math knowledge needed to expand on one.
It gets even tougher once 3D is thrown into the mix (because let’s face it, physics are supposed to be standard issue in 3D game engines now). Godot could then have unified physics for both 2D and 3D through Bullet’s axis constraining options.
I do agree, Godot could become the engine that the FOSS world has been waiting for (even I may have to move over if the development continues to go as well as you say it is), but it needs a bit of work and polish first.
Pretty much any decent game engine nowadays doesn’t require you to do that also… You jump right into game development.
Yeah, I don’t know if Godot is a good option, I don’t know a single person using it and it seems even the original devs kinda abandoned it.
What? I didn’t know that! I think it’s been in development for kinda a decade. How can it still be in Beta? Perhaps only the new features are Beta?
Nah, using 3D physics for 2D stuff is just plain bad. That’s why Unity added Box2d in v4.
Also, another option to look at (already mentioned here) is Polycode. It allows you to program in C++ for extreme speed or in lua (personally, I don’t like lua, but my personal preferences don’t matter), supports 3D and 2D stuff, uses box2d for 2d physics and bullet for 3d, supports a shitload of formats through assimp, imho polycode does a lot of things even better than Unity, however, the development is really slow and I have no idea on how it performs in terms of graphics (speed and features). There’s not even binaries what surely scare 97% of people.
To note, Godot has only recently become open source (the source release was last Summer), so it’s basically the first true open source release that’s in beta.
Before that it was a commercial product. True, it did fail as a commercial product, but the same was true for Blender around 12 years ago.
Libraries are not the language. If you claimed that good libraries make programmers more productive, there would be no disagreement, but you argued that C# is generally “more productive” than C++.
Nah, using 3D physics for 2D stuff is just plain bad.
No, it’s not.
If the existing physics engine satisfies actual requirements, for the vast majority of independent games, it’s perfectly adequate, and there’s no need to spend any effort on integrating Bullet.
But it would make the future of Godot’s physics capabilities dependent on whether or not the team also has a coder who can maintain it and work on expanding it. By this logic let’s just keep the BGE as is in Blender since it’s already suitable for many different projects (see the Finished Games section) and just needs a bit of bugfixing and cleanup work to keep it that way.
It seems like we’ve run into the reason why no one has created a truly viable game creation solution for the FOSS world yet, everyone has their own idea of what an engine should be (with their minds not changed easily) and this type of disagreement is why none get big development teams like Unity and UE4. The only thing everyone here really has in common is that we’ve all made use of the BGE, so let’s just work on improving the BGE then and make it the solution for FOSS game development (since people can’t even seem to agree on how to help develop Godot).
As long as strong disagreement among almost everyone who knows C/C++ code is there, there is never going to be a future for FOSS when it comes to making games.
You assume that Godot’s physics engine would require maintenance and expansion - I think it’s highly unlikely.
As for the BGE: I don’t really follow your logic there, because existing BGE problems (some of which were listed by agoose77) are far from trivial, and therefore not something than can be resolved with just “a bit of bugfixing and cleanup work”.
If those who still want to work on the BGE code were allowed ample room to at least start the process of getting the code to a better shape (as seen here and here), then we will see if the BGE code can be upgraded enough to make it attractive to developers.
Also as seen in those links, the problem again goes back to the slow and somewhat crappy system that is BF patch review at the moment. There has been talk about improving the process, but we will see how far that goes to resolve things.
A lot of people may not know right now that a number of potential bugfix and cleanup/enhancement patches are stuck in the tracker waiting for a reply or at least an acknowledgement from the core devs. This same issue has also been hobbling Blender development as a whole and thus is an issue of interest for everyone in the community (which means you’ll still likely run into it if you’re only using Blender as an asset and a level editor).
Allowed by whom? I mean, I can’t imagine that they would need permission from the Blender Foundation to “at last start the process”. However, even if the BF was actively antagonistic (which doesn’t appear to be the case), how could they stop anyone from making a new branch, and merging in all the changes?
Luckily, there’s several constraint-related patches in the review tracker that include fixes (which may solve your issues).
I do recall that there was a brief ‘fork’ that had a number of BGE fixes (which almost all of them made it into master), perhaps it would be worth trying again?
Careful with your terms: Software regression, the appearance of a bug which was absent in a previous revision.
Can we do a temp branch to demonstrate the full power of the bge?
Yes, you can build Blender. The “full power” of the BGE is exactly the same as what you’re using at the moment, give or take a few patches.
I want all the low hanging fruit, but stable as 2.69…
Please, try to avoid using nonsensical expressions like this; It’s not for personal reasons, it just obfuscates your meaning and is at times barely relevant to the actual topic of discussion, serving only to suggest your unfamiliarity with what’s being discussed.
I think this is the sticking point; those who are happy working on the BGE codebase are not happy with the extent of the structural change required. At this point, any significant changes required to address a number of awkward bugs (particularly in the rendering /physics side of things) warrant careful consideration for redesign, and represent a large obstacle in the development process - these things can’t be rushed or we end up creating the same problems we’re trying to fix, and when this is realised it isn’t too much further afield to suggest it’s not worth writing someone else’s code in your own engine for the sake of preserving its history.
low hanging fruit = easily integrated features that don’t break anything
full power of the bge = rendering performance of more modern engines like the render call batching etc proposed but incorrectly or not fully implemented
the newest versions animation system is different than the old, complicating migration to the point of reanimating every action in my game…
I would sacrifice some flexibility for more raw power in a few areas. (like rendering)
low hanging fruit = easily integrated features that don’t break anything
That might be what you mean, but when reading it it comes across as hyperbole, better to write clearly in the first place.
full power of the bge = rendering performance of more modern engines like the render call batching etc proposed but incorrectly or not fully implemented
That’s not the full power of the BGE, but rather an idealised objective for a game engine’s feature list.
What I was meaning was ample room provided by the current system, the system of development currently in place by the BF, that new developers and the majority of volunteers have to go through to get any sort of code into Blender, period.
For areas that do not see development by a member of the core team, the process is a slog, this can be seen by the large number of volunteers who never again show up in the development scene for any part of Blender because the system doesn’t facilitate well for potential contributions. It does seem to be getting better to some extent, I can give you that, but it still has a ways to go.
This hobbles development not just for the BGE, but also for the Blender Internal renderer, the modifier system, the interface, the list goes on.
@Goran: Using a 3D physics engine for a 2D game is like removing the wings of an airplane to use it as a car. There are even commercial games using it, but it’s common sense among game developers that it’s a bad practice*. I see you’re not even a little bit reasonable, so I don’t expect you to understand that.
*Since I need to ‘prove’ everything, even the most obvious stuff, just look at Unity forums and feedback. You’ll find at least 10 successful developers backing that up.
@haidme: Are you saying that BGE provides the same features as Unity? I think it’s obvious you can make bad games with good engines, but making good games with bad engines is a totally different story.
I’m outta here. This thread is getting depressing. Better spend my time elsewhere (e.g.: writing my own ‘proprietary’ engine).
No…man, the point is - Blender GE have capabilities of a moderate engine from 2006 and yet I haven’t seen a single game, that even slightly resembles a humble commercial game from that time. So in order to make any of the BGE developers to upgrade/develop/invest time…or whatever to this engine, first we need to show them it it is worth it. I’ve seen this kind threads many times and it is always the same…“we need this, we need that…but we can not do anything valuable with it”, so what is the point.
If I was Ton I’ll do exactly the same thing with this engine, and that is because the community is only complaining and doing nothing worthy.
