The number of commits is a poor measure of progress.
I think the current state of the BGE is a testament to that fact; even when commits were plentiful and frequent (if there was ever such a time), the core problems were not addressed, and it was all just adding to the ball of mud.
It’s the quality of the work that matters, not just keeping busy.
enough Blender users might give a strong argument to tighten the bridge between it and Blender.
The number of Blender users, and the strength of their argument, is largely irrelevant.
Unless there’s someone who actually has both the will, and the ability to deliver substantial integration improvements, nothing will change (or, at least, I think it’s highly unlikely).
In my time using it, I’ve found a few bugs, including ones that crash the engine. Unless those bugs have been fixed in the last week or two, they probably are still there. Not a huge deal, though. The engine as a whole is pretty solid, and the documentation and core features have been getting better. However, I think it’s still got a ways to go to get to the BGE’s level of overall capabilities.
The difference is that Godot’s bugs get fixed on a regular basis while it isn’t so for the BGE, they also have a much more solid architecture so there will be less of a chance of things breaking whenever a feature is added.
There are other things, the rayCast node is like a souped up version of Blender’s ray sensor (can go in any direction and has a visualization), the editor is more WYSIWYG than Blender’s viewport, and the scene instancing design is brilliant because you can have a very complex object setup and have it behave like one unit in the level scene.
I can’t say for sure as of yet what the weaknesses are because I’m not too well versed in GDscript yet. I can tell you that some of the crashes is due to the code parser failing to catch genuine errors and even then, it just crashes the running game and not the editor.
As for the BGE being dead, I can’t say for sure if it’s truly dead yet, but it’s not a good sign when any developer interest falls by the wayside the moment they take a good whiff of the code.
This I agree with.
the BGE doesn’t need any new features right now, because if the codebase is ever fixed as it ought to be the new features would need to be reworked or lost.
It might be good to go with a project like GODOT which is just starting out and has more chance of being built “the right way” from the start, but something tells me that in 7 years time there will be threads like this on the GODOT forums complaining that the engine is “broken” and prospective coders will be lured away to some other new project with the promise of getting it right next time.
Unemployed coders are usually inexperienced coders and those are just the sort of people who will make the same structural mistakes which plague the BGE.
I’m just going to keep on using the BGE for now, as it’s the best platform for me to keep learning and developing my skills. I might switch to something like GODOT in future if I feel like I’ve got nothing left to learn from the BGE.
I agree for the most part (though there are downsides to those advantages you mention). Though it probably can execute logic and render faster overall when compared to Python and the BGE’s rendering system, it still isn’t “100%” to me.
Now, I would recommend using it over the BGE currently because it has more backing, potential, and progress. However, it’s useful to know the strengths and weaknesses of an engine before committing to learning and using it.
According to the wiki: “Godot has been in development and used in house by OKAM as early as 2001”.
but something tells me that in 7 years time there will be threads like this on the GODOT forums complaining that the engine is “broken” and prospective coders will be lured away to some other new project with the promise of getting it right next time.
Maybe.
I mean, ultimately, there’s only so far patches can take you, even if you have a really good core team that knows the code-base intimately. At some point, assumptions that were made in the early stages of development are no longer true, and the cost of writing something new is basically at level, or maybe even lower than the cost of updating what’s already there.
I think the trouble begins when:
A) The core developers leave, taking crucial system knowledge with them.
B) System complexity grows out of control, because there’s no focus.
To be honest, I don’t know if strong foresight architecture-wise was employed even back in the NaN days, it seems to me that the issue is that the BGE wasn’t really designed to grow into a true AAA quality engine, as it started as this small engine for artists to make simple to medium-complexity games with.
Now you look at Godot’s roadmap and they are indeed gunning for AAA features, so they may be planning out the architecture accordingly. Also, the original developer who led the project when it was still commercial is still the project lead and main developer, so it’s likely that he’ll have quality standards for patches.
Now if you want an engine that can be an example of real growing pains then look at how Epic is having to manage a tidal wave of volunteer development going into Unreal, the engine is getting developed at breakneck speed but it also means massive amounts of bugs being introduced as well (be very careful with beta builds)
We’ll still need perhaps a few dozen more of these in the near future and a moratorium on new features until some extensive cleanup and organization work is done, if those still wanting to support BGE development can pull that off, then I may well join those in saying that it’s not dead yet.
Wow, flipper has been broken for so long I almost forgot about it. I used to use it a lot, but I don’t know what I’d use it for now…
Anyway, always good to see fixes. Thanks to Moguri!
Thanks for the link, I am thinking to pay a shivaEngine license soon but I will test this. I miss videos and examples to see how I can animate 2d and 3d characters, add gui on game… When does started the develop of godot? Thanks
As I suggested before, waiting for two months to see a couple of fixes is far from what is required to save the BGE, we will need fixes on a weekly basis for starters as well as a lot of code cleanup and reorganization.
A good engine should allow for a complex game without having to employ workarounds, something the BGE seems to have lost in the days after 2.49b.
Got the little guy on his wheels using 6DOF constraints, the entire setup consisting of 5x2 objects (due to two materials on each) treated in editing as one unit thanks to scene instancing.
As far as I know, their generic constraints are not bugged like the BGE’s providing you have the object origins properly set (and the ‘custom integrator’ checkbox checked).
EDIT: noting more things about Godot that the BGE doesn’t have, like a special buffer you can send 3D objects to that will draw them in front of everything else regardless of depth and direct manipulation of orientations without having to go through Matrix/Euler conversion functions (it even allows you to use degrees if you want with the only requirement being to use the function to convert it to radians). You also do not have to start the game to see environmental shading, AA, and custom shader results.
Looks good, Ace Dragon! I dug more and after asking questions in the Godot forums (about equivalent functions like alignAxisToVect) it looks like Godot is shaping up well.
Looking at more tutorials, I could port over my projects quite easily once API documentation is sorted and there is a bank of examples (like Tutorials For Blender). I would still miss the immediacy though of Blender. Its just so…easy, despite its flaws. For me at least Blender does everything I need it to. Still, I’ll keep an eye on Godot. Give it a year or so it might become compelling, but time will tell. Until then, its BGE for me.
Hey guys,
I about finishing a Godot Export Manager. This one is uses reduz “Better Collada Exporter” in the background.
You can create export groups with objects assigned, define all export settings for that group. Set the destination folder and export name.
And Once set up you just have to save your blendfile.
Each time you save, the groups are exported as collada files into the destination folder.
So you won’t have to bother about exporting anymore! Once godot notices the collada files are updated they can be refreshed in godot right away.
Here’s a screen. I think some little polishing and it can be released. I will ask reduz to approve the addon. Maybe it can be added to godot repository.
In general, the whole engine works by instancing the contents of scenes inside larger scenes.
The most commonly used mesh node is Mesh Instance, but there’s also Multi Mesh Instance for large numbers of certain pieces of geometry (which may or may not have some differences).
