I see it as an unnecessary feature. Firstly, because a game engine needs to be powerful and have a lot of features to be useful. This would require a huge amount of effort from the developers to maintain and can detract from the rest of the Blender project.
Second, with the way Blender is already highly customizable with the Python API, game developers shouldn’t have too much trouble adapting Blender to work for them. A group of developers could even make their own set of scripts/addons that turn Blender into a full game engine.
Finally, I’ve heard that there are licensing issues with it. That’s kind of a deal breaker for almost everyone.
I’ve never actually used it myself, nor have I used Unity, Unreal, or any other game engines that have an integrated editor. However, I’d imagine that Unity and Unreal are far superior to BGE.
In my opinion, the Blender developers should just scrap BGE, or split it as a separate project or addon.
The purpose is obvious - it’s an integrated game engine that allows one to model, animate, and code a simple game all in the same application/environment. Regardless of the issues it might have in terms of quality, required maintenance, and deployment licensing, that purpose really hasn’t changed. The question is whether this purpose is important enough to take developer time away from other parts of Blender (more later).
Lacking an actually dedicated engine, or large expansion to the Blender Python API if BGE was removed, I do not believe that Blender could be easily scripted to play a game. Far too many game-focused tweaks/hacks needed to the viewport, physics, input, sound playback, etc. Honestly, I don’t think we want Blender’s application API to do that either. Either a game engine is important enough to have in the application (in which case, keep/use/improve the BGE) or it is not part of the application’s purpose (in which case, remove the BGE).
There are, indeed, licensing issues for anyone wanting to release their games outside the GPL. This is generally an important consideration for those who dream of making a living (or even half of one) developing games and the GPL is pretty damned tricky to get around when one is using GPL licensed API’s (like the BGE exposes). That is not a rag on the GPL, it was designed to do that, simply pointing out that it is not something we’re going to find an obvious solution to in the near-term future as said “solution” would be going against the very spirit & intent of the license (& lawyers more clever than us have tried).
As to engine comparisons, Unity & Unreal are pretty objectively “better” than the BGE when you can & are willing to pay for them. Unity Free has limitations BGE doesn’t have and vice versa, making it a harder one to compare in such an objective fashion. Their integration with content creation is less complete than Blender is with BGE, however, as one can edit not only the environment but model, rig, and animate from scratch in Blender, link the character into the BGE, then “run” your game all without leaving the software. The value of this is up for debate, of course, but it is a benefit the other two engines you mention lack.
Now, onto the more interesting question of whether the BGE should stay or go as part of “the Blender core distribution”. Personally, I think it should go. Whilst I can see some value in an integrated environment where one can teach game development from first vertex through to deployment - I don’t think it is a primary goal of Blender (or at least, the Blender Foundation). The BF has only done the one game project and has expressed “reluctance” about future endeavours along those lines. When it comes to priorities, the Blender Foundation has both explicitly and implicitly (through their planned feature lists) expressed a preference for features that focus on film & animation. Finally, the BF is already receiving funds from Epic in order to fund work on making Blender work better with external engines using the FBX format.
With all that in mind, and bearing in mind my actual reluctance regarding forks, I think branching BGE into it’s own Blender distribution is actually a better thing for the future. At least, as far as meeting the goals of the Blender Foundation as they are currently acting on them (development of a tool for/through the creation of Open Films). There are a variety of other engines that, whilst not as integrated as the BGE, have better runtime characteristics and licensing options.
A game engine does not need lots of features to be useful. Powerful is subjective. Many of the game engine developers solely develop it, and would not necessarily switch to other modules if the engine didn’t exist.
The reason that full game engines exist is because they are specialised towards performance. Blender has zero potential for this field, most of its features are not designed with real time performance in mind.
You should be careful when starting an argument with ‘I don’t know anything about this’.
The reason that the BGE is so useful is because it is integrated into the editor. If we scrap it, we loose an engine that works… For no reason.
Agreed here, it’s not like the BGE is leeching away developers from other areas of Blender because it has its own ecosystem in terms of that.
Also, when it comes to Unity vs. Unreal 4, I would sooner use UE4 than Unity because it comes with a lot more stuff out of the box and the development with each new release looks to be of a higher quality (it’s actually the highest rated engine in the entire IndieDB database right now).
The BGE, like it or hate it, is one of the only decent options in the world of FOSS when you take into account the idea of everything you need in one unified application, people use it over other engines because of its unique place as a part of Blender which makes game development very fast in general. Take away the BGE and you pretty much make FOSS a dead-end when it comes to game development (I know there’s the Jmonkey engine, but they take years between releases and it’s not actually all in one app.).
It leaches some devs time, after all we need to keep it building, reply to bugs, test that it works for releases and generally make sure its not broken when we change code that the BGE uses. Not a huge drain, but there is some overhead in keeping these areas of Blender supported.
I agree with the majority of that post. Summed up nicely with this one line…,
100% agree. The prime utility in the BGE is it’s integration with Blender. However, that is about the full extent of it’s advantages over other options and this is where I think the “objective as possible” judgement of it’s inclusion should be focused.
This is where I disagree, because there are many good reasons to split the BGE into a project outside the Blender core distribution.
First & foremost, the BGE does take time & effort from developers not contributing to Blender purely for integrated game engine purposes. A simple review of issues that crop up before, during, and after releases will show that the BGE is not isolated from the development process and, as such, requires resources from others (remembering time is also a resource, even if just spent waiting on someone else). Freeing up developer resources is a good reason to do something in large projects like Blender if the benefits
Secondly, and I intend no offense by this (though acknowledge people will take it as such anyway), the BGE is pretty low on the totem pole when it comes to game engines and the features offered. Sure, it’s not right at the bottom of the barrel, but it’s sure not the first option developers think of when deciding on an engine for their product. It’s greatest draw card is simply that it is integrated with Blender - not performance, not flexibility, not commercial track record, etc. If one looks at the engine on it’s own merits (as opposed to leaning on the rest of Blender) - developer effort on the BGE is currently (& for the foreseeable future) in catch-up mode. It’s hard to attract new developers when they are constantly having to work simply to get closer to what is offered elsewhere.
Finally, and here is the kicker for me, integration with Blender is not the draw card I think some believe it to be. In the context of getting kids interested in programming, game art, etc - yeah, the BGE rocks my world. In the context of developing games for much of anything beyond that, being able to rig & model my characters/scenery in the same application as I can play them in doesn’t strike me as that useful. Epic has put $10K towards better FBX import/export. Unity spent money to ensure they could get content out of Blender into their engine. GameKit can even load content straight from the .blend file including physics & logic bricks. The focus is on using Blender to create the content and exporting it to engines better suited to play it. This just so happens to be what the game development industry in general does for everything from garage indie to AAA games for 99.9999% of games developed.
To me, the question when it comes to paid developer effort is (& should always be) focused around cost benefit analysis. What does the BGE bring (that other engines do not) and is it worth paying developers for their time? At this point in time, like it or not*, the Blender Foundation is focused on films & film making. With that in mind, working to keep a game engine in sync & compiling with large changes (as outlined in their To Do & priority lists) is a drag on that focus.
If, as people are claiming, the developers for the BGE are only focused on the BGE and not Blender as a whole, there should be no issues with splitting the BGE distribution out of the core Blender distro. If the developer effort to keep everything merged & working is as minimal as suggested, it is just as viable in it’s own Blender distro than inside the core one. If that is not the case, clearly there is a cost associated with keeping it in the core distro, and this cost should be balanced against the level of benefit it brings to Blender as a whole.
Crystal Space, Horde3D, OpenMorrowind, id Tech 1/2/3/4, WorldForge, Spring Engine, etc… and that’s only the GPL/LGPL licensed engines I can think of off the top of my head. More if you want to consider BSD/MIT in your definition of FOSS. Your comment is hyperbole at best, flat out dishonest if taken at face value.
I get that the suggestion of removing the BGE is a hot topic. I remember the vocal, if not populous, backlash when Ton first suggested it. However, stepping into the realms of fantasy isn’t going to make your arguments any more convincing. In fact, it simply lowers the credibility of the rest of your commentary. BGE is nowhere near the forefront or pioneer of FOSS game development. In my opinion, it’s longevity is due to the success the Blender project overall - not on it’s own merits.
I’m not sure what fantastical statement you are referring to. I wrote my comment concerning scrapping the engine with the interpretation of the op that they suggested to completely remove the engine. Forking is another issue entirely.
Indeed, the BGE does demand some development time. This is both a good thing, for protecting some game-friendly editor features, and a bad thing, for stalling release targets and development projects.
Fully agree with the comment about the draw of the engine. I’ve said similar things in my *reasons to look at panda 3d integration * posts.
The issue with export pipelines is;
They’re slower for iteration time.
They add an intermediate step to producing content which creates headaches with versioning and editing.
They require a sane exporter to ensure that things don’t break. (this is also true of the game engine at present, but it is more obvious when conversion errors occur, as it happens during one step).
There is a really benefit to editor integration that I do not believe can be undersold. The ability to debug in real time in unity is amazing, and makes the process a lot easier. That same editor proximity for general design iterations would also be useful (a high priority goal for panda integration)
Fbx IO like most suffers from standard issues. Worse still is collada. Most of these formats do not offer the scope needed for true export to other engines, with loosely defined specs or closed source entirely.
The game kit importer is… Touchy at best
These issues aside, if it walks and talks like the BGE, it doesn’t matter if it truly is the BGE under the hood
Teh “fantastical statement” was Ace Dragon’s in regards to removing the BGE leading to a dead-end in FOSS game development. As your ability to suggest other options demonstrates (Panda3D being one I forgotten), this is clearly bollocks. Either it’s hyperbole or dishonest, but either way it is easily dismissed by those informed about what is out there & taints any other arguments made with the same lakc of credibility.
I understand them and they have merit… but they are not really the drag on game development I think that would make them a key decider for using the BGE over other engines. If the BGE were up there with the other engines in terms of features, flexibility, etc - the ability to keep an entire iteration from vertex to video game in the engine would be a massive step up. However, the limitations of the BGE limit the benefits only to those willing to stay at what it can offer.
Awesome beyond imagination for fiddling around with concepts and teaching kids the pipeline of game development through hands-on classes. Not quite so awesome when, integrated or not, you cannot do what you want due to BGE limitations.
That would indeed be awesome… but it doesn’t need the BGE for it and the BGE doesn’t really give you that outside some very limited areas.
Collada is just straight out useless. Whilst the week I spent trying to get it to work with an artist I had hired was some years ago, recent experimentation has shown it’s not really improved. I also agree GameKit can indeed be touchy, but my point was the direction of development rather than the quality of each and every import/export option. The industry works around using the DCC software in a pipeline. As recent events have shown, investment in Blender is coming from those that want to get their stuff in & out of Blender, in & out of other elements in the pipeline.
The fact the BGE keeps everything in the same application is not much of a drawcard when it comes to people looking for tools to assist them in creating content for any kind of serious game development. Learning game development, sure thing. I’ll even go so far as game concept development. Outside that? As I said before, BGE is pretty far down the totem pole of options available.
Bringing me to the question “What does ‘walking & talking like the BGE’ mean to you?”. Serious question because, given the option of export/integration with Panda3D, I don’t think it means to you what it might mean to others.
Most of these are either just API’s without integrated world editing capabilities (you just load up an environment like Visual C and use that), modding engines (where you just take an existing game and change the rules), or dead projects (does anyone actually use Crystal Space these days?).
As for the Gamekit, that project is rarely mentioned here anymore, so I don’t know how much progress it made. Last I looked however, it wasn’t being developed at a rapid rate and someone actually decided to make a branch of it to use for a new commercial product rather than contribute code to the original.
To note, it might end up being a nice thing to have full fledged .fbx export to an engine like UE4, but then I think that someday, Autodesk is going to make big changes to it and pull the rug out from under Blender (going to suck for game developers if the BGE is no longer there). Also, the BGE is capable of more game types than you might think (especially with access to every module that comes with Python), your assessment seems to give the impression of, well, it can make a cube move towards a sphere and jump but not much more.
Also, another argument I hear a lot is that there’s a lack of developer interest in the BGE, this isn’t true and Moguri is not the only dev. by any means.
There’s currently a total of six BGE-related items in the code-review area of the developer website. The issue though is that none of the other developers have actual commit rights to the BGE code and I think it is Campbell that grants them (though he’s not active in that area). The thing is that we might indeed get a bit more developer interest in the BGE if only people would be able to see their patches go in more quickly providing they have time to address concerns (same with more developer interest for Blender in general, as the lack of patch review resources is an issue endemic in the development scene).
With all due respect, the BGE is no more than an editor & physics engine from which you must build the logic of an entire game also. Unless, of course, you use other people’s game templates… which makes it no better or worse than the other engines that focus on a given game type. The id Tech GPL line alone is enough to debunk your theory of BGE’s absence bringing about the end of FOSS game development.
Which is exactly what Erwin intended people to be able to do. It’s licensed precisely so people can modify it for their commercial projects.
Clearly it is powerful enough for people to decide it’s a worthwhile foundation for their project and successful in enabling people to license their end product commercially without GPL issues.
GameKit has it’s issues (as does the BGE) but pointing out that someone took their branch commercial isn’t a flaw. It’s a design feature of choosing the license Erwin did. You’ll notice GameKit code didn’t disappear from the Internet and someone who wasn’t willing to contribute back to GameKit is not going to contribute to BGE. There is no “loss” from the action.
It would also pull the rug out from every other game & film project out there using the format given they’d have to re-export / re-import all of their assets. It’s a possibility, just like Ton as chairman deciding to focus all Blender Foundation funds into compositor development alone is possible. Neither possibility is very likely or probable given that the FBXio code will be available as a replacement should Autodesk decide on said suicide scenario.
A good majority of the “releases” I’m seeing are not much more functional than that. The vast majority of the games released/finished are variations on the FPS genre (either first or third person camera), perhaps with alternate GLSL shading options, and the occasional “action” button click. This can be done easily, with better performance, using the id Tech line of engines.
Feel free to show a game done by the BGE that you don’t believe can be done by other free & active engines out there. More than happy to meet that challenge. Or, perhaps, you can simply concede that the BGE no longer being part of the core Blender distribution won’t being an end to FOSS game development and we can focus discussion on whether the advantages BGE has (which I have admitted exist) are worth the development effort of keeping it in the core distribution.
We could waste time showing how the BGE isn’t a unique snowflake that’ll end FOSS game development as we know it if not in core… or we could have a productive discussion that relies on facts over hyperbole. I’m cool either way.
A lot of it is from lack of skill really, case in point, you can go to the Google Play store or Kongregate and see massive numbers of badly done Unity games, but an experienced user would tell you that you shouldn’t look at those free offerings and conclude that Unity simply cannot make a very complex game. Also, the IndieDB database shows that there are a set number of game types that are extremely numerous in the indie scene made with the entire gamut of available engines, FPS games being one of them (no doubt we’ll see a lot of FPS games (with or without zombies), made with UE4 as well, it’s just one of those ‘it’ genres that shows you can make a game.
With all due respect, the BGE is no more than an editor & physics engine from which you must build the logic of an entire game also. Unless, of course, you use other people’s game templates… which makes it no better or worse than the other engines that focus on a given game type.
You still have everything there though when you take into account that the BGE was initially designed to exist with Blender itself.
It would also pull the rug out from every other game & film project out there using the format given they’d have to re-export / re-import all of their assets
Actually, Campbell mentioned before that Autodesk can communicate the changes with all of their partners so they wouldn’t be left out of the loop, with Blender meanwhile being the one application that would not see a benefit, but possibly more of a hindrance.
Which is exactly what Erwin intended people to be able to do. It’s licensed precisely so people can modify it for their commercial projects.
You decide to use a permissive license, you acknowledge that you take such a risk, but it can also means that you might only have a few FOSS aficionados who will choose to stick with you and make a project that can be used by everyone (all of the people who have the big ideas will rather want to work on their own product, so in a way you have human nature working against you as well).
Which means precisely nothing other than the fact you skip the “export content” step other engines have. That the BGE was designed to exist with Blender is simply stating that the BGE relies on Blender, not the other way around. Remember, the OP & discussion is about whether Blender needs to include the BGE, not whether the BGE needs Blender to be stay relevant.
He also stated that the possibility had a very low risk of actually eventuating for the very reasons I stated. Don’t forget I read the forums too.
It wasn’t a “risk”. It was a deliberate decision he made choosing the license he did. Erwin has stated it that multiple times. GameKit’s license was deliberately chosen to allow people to take their branches & products using it commercial. The GPL is not for everyone and Erwin has been using truly permissive licenses for some time now in code he has released.
For the record, are you able to concede that FOSS game development isn’t going to reach a dead-end if the BGE is not in the main Blender distribution or will that claim be raising it’s head later in the conversation? I’d really like to settle that one now so as to not waste time with such twaddle later.
Eeeh, Am being quoted a bit out of context here - The point with FBX SDK is that Autodesk doesn’t need to communicate changes with partners.
As long as the SDK can load/save files smoothly, they can change format internals which only impacts people NOT using the SDK (Blender)
That said - we could use Autodesks SDK if supporting the format becomes a hassle long term.
Yes, you are missing that there are people using the BGE, and they wouldn’t be happy about what you suggested.
Seriously, what is it with all those suggestions to drop parts of Blender’s code lately?
“The VSE should be dropped because Sony Vegas is superior!”
“Blender Internal should be dropped because I prefer Cycles!”
“Scrap the NLA editor! I don’t do animations!”
To answer the question in the title: The purpose of the BGE is to be useful for those who use it. It is useful as an educational tool. It is available to those who can’t use Unity and Unreal (e.g. because their SDKs are not available for Linux).
Please keep in mind that Blender isn’t just about you.
Is there any part of blender, that is important?
There are better renderers. I find luxrenderer superior.
Do you need a modeler? You have python and can build your geometry more directly.
Do you need pyhon? There are other languages like lua or you go hardcore c/c++.
I think blender is more about beeing a collection of intresting parts, that find meaning and give new meaning to other parts.
Now you have a full usuable package for many things.
Isn’t OSL a more gamish feature which allows realtime rendering?
Cycles in comparision, there you can have realtime rendering, but with fireflies.
The walk-mode for architectual rendering is also nice new feature.