Don’t think theres a real conclusion, that can be made by reasoning it out.
You’re opinion here will hinge on weather you believe the BGE is generally useful and the perceived impact of the trade-off we make by keeping & maintaining it (which we can’t really quantify - but its not zero).
If you use the BGE and ran into some bugs/limitations which prevented you from making a game… that will influence opinions too.
Also if you tried to work on improving the BGE and ran into really bad-code or bugs which were hard to fix that seem like they should have been easy… it will influence your opinion.
We’ve been discussing this (in #blendercoders IRC)
The likely outcome here is - Blender game engine stays in maintenance-mode (just keep it running). And some developers will investigating supporting an external engine (Using similar API hooks we use for external render engines), then if this integration can be made to work about as well as the BGE, we can deprecate and eventually remove the BGE. But this is a way off, and just something to investigate, no firm decisions made yet. Its also possible someone works towards big improvements, But so far this didn’t happen much.
We should drop Cycles, because exist Vray and Octane.
We should drop SculpMode Because exist ZBrush
We should drop Texture Paint Mode because exist Mari
We should drop Blender because exist Maya.
That’s simply not true. GPL has nothing to do with how good a software is or how it is developed. It’s simply a super restrictive license. There are fine examples of open AND closed source projects that are free or donation based, but not GPL.
I’m going to ask you one more time: Do you have any information about donations being diverted into projects that don’t benefit the donors?
A simple yes or no will do.
Also, if you don’t think Ton has plans to remove the burden BGE puts on Blender development, you haven’t been paying attention to the idea of it becoming an “interactive mode” only. Look it up. We’ll wait.
You misunderstood Ton’s proposal. What he did announce is that the BGE should be more closely tied to the rest of Blender, which means: removing redundant code and making BGE functionality available outside “Blender Game” mode. This makes perfect sense. For example, although the 3D viewport has a GLSL shading mode, only the BGE can load custom GLSL scripts. On the other hand, using the BGE as an advanced OpenGL renderer requires external screen capturing software. There’s currently no way to render a BGE scene to disk, frame by frame. The BGE’s logic editor would be useful to define the rules for procedural animation not just in games (think large animated battle scenes in movies). Removing the separation means that the BGE’s focus will be broadened beyond mere games. Hence the proposed name change to Blender Interaction Mode. However, it will still be possible to make games in that mode.
There’s nothing in that proposal saying “Let’s drop the BGE”. It’s all about broadening the BGE’s focus, so that more people get something out of it and realize its value.
After using BGE and comparing it to Unity and UDK, I noticed the lack of a lot of features (not to mention bugs).
Now to fix bugs and add features is obviously going to require time from developers. Which I think slows down other parts of Blender development.
I’d rather choose Unity for small/casual games or even simulations and UDK for larger, graphically intense games.
But I’d surely use Blender for modelling, animation, sculpting and texture painting.
@BluePrintRandom
You can achieve that in other game engines too fairly easily.
If you don’t want bugfixes and feature requests to slow down other parts of Blender development, just stop reporting bugs and requesting new features. It’s that simple.
Developers are the reason how good a software is. Most if not all Blender devs, volunteer and paid alike, chose to work on it because it is Free Software. If the Blender devs shared your loathing of the GPL, it would simply not have evolved to where it is today. Surely you must understand that?
I think the BGE’s situation is a little more than just ‘being in maintenance mode’ when you take into account new features that work in it like LOD, enhanced actuators, collision layers, the light data node, multi-threaded animation, anti-aliased shadows, ect…
There’s also around three developers other than Moguri who have created code cleanup and organization patches that are either currently in review or in a separate branch (Lordloki, Brita_, and HG1). In all, the current development is actually more than what a few other areas are seeing (VSE and BI to list the two major ones).
You have to make up your mind: Do you want those bugs fixed and those features added? Then report/request them. Are you concerned about occupying developers? Then don’t!
The bottom line is, people file bug reports if a tool they need doesn’t work properly. The fact that BGE bugs get reported means there are people using the BGE. As long as people use the BGE, it’s ok to make developers work on it. It’s probably not ok to drop a tool just to avoid the bug reports. However, that is exactly what some people here are suggesting: Kill the BGE because it occupies developers that could work on UDK/Unity integration instead. Kill the internal renderer because it keeps developers from working on Cycles. Kill the VSE… Well, you’re getting the point.
Yes. It’s in the Gooseberry thread. I’m not going over it again. You want to raise that argument - go read up on the details and start it yourself. The reaction to it was bad enough that forum rules were changed and applied to that thread. I’m not going to be the one to do that again. If you want to start a flame-war, do you’re own legwork.
Not according to recent comments from actual Blender core devs. If you want to take it up with them, feel free. I’m not going to quibble with someone clearly more interested in starting a fight.
Indeed. It’s about transforming the “game engine” into something less than a “game engine”. I would consider that dropping the feature in exchange for a less powerful, though more integrated one. You can consider it anyway you like. The important thing here is the people that have been actually using the BGE, rather than just fighting about it on the forum, seem to agree with the view I’m presenting and dislike the idea.
I would like to see academics develop the BGE to use as an immersive teaching tool, and code teaching tool, as well as to allow people to develop and sell games.
there are many schools and professors and students that won’t like you very much…
instead why don’t we bring in more? This is the true beauty of GPL.
Universities, Private academies, online schools…
The BGE can be OVER handled by the community,
and have a spill off of devs to the Blender /animation/stills/map baking side of things.
(it seems like if you can handle developing/coding the BGE, you can handle ANYTHING as it’s a mix of many styles, and is not “clean” (but will be better soon!) )
Thank you Hg1 and LordLoki? https://developer.blender.org/D625
Ps-
My poor wording - I didn’t mean the BGE is currently in maintenance mode, just that its possible it stays in Blender, but is (mostly) in maintenance mode, Similar to OpenCollada or Blender-Internal-Renderer.
This is hard/impossible to prove, I know GPL is important to some devs, but others don’t have a strong opinion either way and would probably be just as happy to work on an Apache licensed code-base (Permissively licensed rather than Copyleft).
You can argue Blender (as an application, ignoring the BGE aspect) would do better/worse with Apache - but its all conjecture.
@Krice, You know there are permissively licensed alternatives to Blender, which devs are free to work on.
I would support the inclusion of the half-lambert shading patch in BI yet, the game engine people would also like it because it comes with a matching GLSL shader that the BGE can use.
I personally think BI could still take a useful path in being more like a truly comprehensive scanline/legacy-based solution rather than trying to turn it into a pathtracer like Cycles (the ill-fated render25 branch comes to mind).
