Thanks to the first Steam Workshop donation payment, we can now invest quality developer time for getting Blender work better in game creation pipelines. I’m happy to announce that Blender developers Dalai Felinto and Bastien Montagne have accepted a 6 month contract to work half-time on supporting game artists! Their contract will become effective this week.First thing Dalai and Bastien will do is investigate with artists out there (via Steam Workshop too) a nice priority list of topics to handle. This will be publicly reviewed in our many channels and become part of the weekly meetings in IRC too.
Valve expects that Steam Workshop is going to be earning us a sizeable share. We’ll learn more about this during the next months though. But if this continues, more projects for developers can be funded this way. Main focus will be on good tools for game artists though, including features that benefit everyone well too. This also opens up an opportunity to realize a bigger project related to our Game Engine. That’s something we’ll discuss with the current GE team first though.
Exciting times ahead! Many many thanks to Valve and to the Steam Workshop members who decided to support Blender Foundation this way!
-Ton-
Great news!
Awesome!! So happy to read this \o/
To be honest, probably not the good news if you want to publish games in blender. Much of that will be focused on the asset creation side. The valve funds are coming in from artist who sell game assets on the steam workshop and then get the option to have valve donate some of that revenue to a group of their choice. One of those groups is the Blender Foundation.
Logically, the more development is focused on developing better artist tool based around game art, the more revenue can be had for the BF.
I honestly dont think there is a future for the BGE, especially with the current licensing model. I do however think there will be more real time visualization and interaction elements added to Blender as a whole, this will probably be along side the asset creation side.
If the BGE developers can show that they are really serious about cleaning up and modernizing the BGE and its code (like Moguri seeking to clean up a bit of the old cruft), then there would be a stronger argument to leave the BGE as Blender’s built in game solution while the pipeline improvements to other engines are made.
I would also not forget the fact that Kupoman is in the midst of a large rewrite of the BGE’s rendering back-end that will likely be resumed when the GSoC period is over, this will allow for enhancements like inferred lighting and even this Summer he’s worked on shadow system enhancements and an LOD system that will soon make their way into Blender trunk (with the LOD system currently under review with the help of Brecht).
There is no “licensing model”: The BGE is free, Open Source software, which can be used to make and sell games. There is nothing in the GPL that hampers that.
Also, I don’t see how additional asset creation tools, and the financial resources derived from those, would be anything but good for our community: Asset creation tools will naturally extend into a “whole game creation” environment, as people learn more about blender (due to higher exposure).
As for the engine itself:
Ideally, someone who actually knows what they’re doing (like Eskil Steenberg) would lead the charge on a BGE rewrite (or maybe he could just integrate his code into Blender … Ton could pay him to do either). Or, if not that, Valve might help the Blender Foundation integrate some version of the Source SDK, with python bindings.
Trying to “patch” the existing code into something better is a lost cause, in my opinion, but I’m sure people will still try. 
In either case, this is all very good news.
The thing about the sentiment that there is absolutely no way for the BGE to move forward without a total rewrite is this…
If you’re going to remove all of the existing code and make everyone start their game logic over again from scratch anyway (down to basic object movement), then why not just plug in one of the more promising Open Source engines that support the same graphics feature like Urho 3D and give Blender a new engine right away rather than have an engine that sees no development for years while the rewrite is being done, as doing this pretty much defeats the defense that the BGE should be kept so people can continue to work on projects they’ve invested a lot of time in.
Of course in this scenario, one could perhaps code the plugin to interpret the BGE’s logic bricks as well as consider the entries in the properties panel as initialized variables to allow one to save a little time, one possible wet dream would be to somehow convert entire BGE Python scripts to another engine’s API, but you wouldn’t be able to resolve all cases.
Of course, I wouldn’t want to recode every piece of game-logic I have created for my projects so I would think just doing cleanups here and there as well as incremental rewrites will work well in allowing people to continue their projects smoothly while reaping the benefits, Blender in turn gets a better BGE while people can continue on and complete their projects (and believe me, some of my scripts for example are pretty complex and would require a lot of relearning to duplicate in another engine).
I never really tried Urho 3D, but if it’s a good engine, with a well-established team, and an active development community, then why not?
You can finish whatever game you’re currently working on in the BGE, and then you can start your new projects with a better engine … Or, in a plug-in architecture, you can pick which engine to use, and that would probably be best.
I heard they’re still working on expanding the Lua API, but I think Sinan has mentioned before that there is an addon that allows you to script your logic in Blender and then run the engine from a panel in the toolbar (the scene export being transparent and fast like with the BGE with the exception that you get a new window of Urho3D running rather than the viewport coming to life).
The main thing then would be that Urho would need to have equivalents of the more complex BGE functions like rayCast() and some mathutils/bge Vector functions, an orphographic camera, layered scene functionality, and the ability to create a virtual camera that matches the 3D view angle if you’re not in the camera view (for things like testing). One thing I like in particular with the BGE’s background scene functionality is that you can create a 2D game with a background that uses a perspective camera (creating an incredible parallax effect).
If I indeed was to start porting projects to a new engine that got plugged into Blender via an addon, it would need to allow me to do the new logic in Blender and have the functions needed to do it quickly (like raycasting).
The rayCast method simply wraps the relevant Bullet function. So, if Urho uses Bullet for physics, as stated on their features page, then it’s already there. Actually, all of the features you mentioned are present, or Urho carries viable alternatives.
Although, the documentation is a little sparse, and looking at the source code … Event systems, excessive template use, shared pointers … It seems convoluted.
If I indeed was to start porting projects to a new engine
Just to make it clear: I didn’t, nor would I recommend doing that. If you already have a good portion of your game working in the BGE, you should finish it in the BGE.
I agree with Goran about the role of the BGE.
What attracted to me to Blender is its potential as a universal editor. The open source community is littered with half-baked game editors and level editors. (And the structural biology community is littered with half-baked protein data editors). It is my dream that one day all 3D editors will be Blender plugins, allowing them to cooperate and share code.
I think that the Steam Workshop project is a huge step in that direction. The next huge step would be a Python VScript emulator on top of the BGE, so that you can actually test your mods live inside Blender. The final huge step would be Valve ditching Hammer: or, more precisely, convert Hammer into a Blender add-on with live testing. Imagine how much BGE love that would mean…
Considering Urho3D, I agree with AceDragon. I hope that Sinan goes for tight integration with Blender, including game logic. I imagine that would mean cycles of quick live tests running under the BGE, followed by the occasional slower export to Urho3D. That would require a logic system that runs under both engines. If Sinan decides to go for nodal logic, it can be emulated under the BGE with Hive. Adding Python support to Urho3D would be another possibility. I don’t see how raw AngelScript or Lua scripts could ever be executed inside the BGE.
In contrast, if Sinan decides for logic that would run only under Urho3D, I don’t see why this would be better than GameKit or Unity3D. Both of them have native support for Blender assets but not logic.
There is a licensing model, but it literally is tied to and limited by the GPL, which is a license.
That said, from my understanding, an open source game engine would be best if licensed as MIT. See: http://stackoverflow.com/questions/3902754/mit-vs-gpl-licence
Anyways, its just my opinion of course, but I think it would be far more realistic and usable for the BGE to dwindle out with its user base looking more at something like Torque 3D while promoting and building upon a tighter blender to torque pipeline/integration. This would be a win win situation for both camps. The torque crew seems to want tighter blender integration with their version 4 update anyhow and as this was previously a commercial entity, the studio behind it still actively develops it along with the user base.
http://www.garagegames.com/products/torque-3d
I do think that the work done with the BGE though, including logic bricks and all that, should find its way into blender as more of a simulation and visualization tool rather than a game publishing platform.
That also is a potential avenue for Blender. Naughty Dog for example (famous for a list of popular games on the playstation console) has their game engine built on top of Autodesk Maya. They are interlinked so that content can be made in maya and then executed to run in their game engine. Again though it probably has to pass the FSF filter and find out what kind of content can be used. I am not familiar with how MIT to GPL interactions work, rather where the lines are drawn in whats allowed.
I believe the MIT license is fully compatible with the GPL (look at the Bullet Physics engine for example).
Anyway, I guess the best road right now is to improve on the BGE itself, especially since it now doesn’t look like we’ll see a full seamless export of logic and assets for running in Urho3D in the near future, a good start would be Moguri’s plan to axe the Single-texture mode in favor of having a legacy and a modern graphics system (much like what Blender has now with BI and Cycles), this being followed by Kupoman’s shadow system work and BGE-Harmony phase 2 project (and if you don’t know, he actually is planning a phase 3 as well).
The BGE future seems to have two roads, one as a true game engine and the other as a visualization/interaction tool. However, IMHO, they are one and the same. The game logic bricks are often associated with the visualization aspect however they compliment the BGE as a true game engine. Advancing graphic capabilities tends to be the goal of game engines and they too compliment the BGE as a visualization tool (removing single-texture mode is a start ;)). The BGE is unique in this ability and worth maintaining. However, wWhatever happens, I think some form of the BGE will remain. The point I see people make often with the GPL licensing is related to distribution and securing the source code/assets. I thought this was sorted out (BPPlayer) since the player (engine) is separate from your assets, therefore the GPL licensing only applies to the player, if the assets are distributed separately from the engine. So you create a stub that loads all the assets which allows you to license the assets however you want. http://www.blender.org/education-help/faq/gpl-for-artists/#c2130
The Bullet physics engine is middle-ware, using a non-GPL license, and it was integrated into Blender with no legal problems.
Then you have distribution models and platforms, well those are key in reaching a wide audience if you are seriously developing games that you intend to be successful. I believe most of these are not compatible…
I believe you’re wrong.
Anyone can take the code and redistribute it…while you may be able to protect your assets, for code not so much.
If you take the time to read the post I linked to, you will understand why that is simply irrelevant.
but I think we need to be honest about limitations which can hamper expectations.
We are: There is nothing in the GPL that hampers the creation and sale of BGE games.
The fact that most people don’t really understand the practical implications of the GPL (or any other license) is a different issue.
Furthering this point, look at the majority of the games in the WIP/Finished section. They’re not finished because they’re not “good enough”. The majority of people who post finished games seem to have started learning modelling/texturing/scripting. We’re all (most of us) guilty of this, myself included (I started posting before I was ready). It’s a little like multiplayer “hack protection”. Most people who say they need it don’t, because those who understand it know that it is ineffective.
Well, actually the truth is as simple as this…as long as there is no commercial game on the market made with BGE there is no hope for this engine. BPPlayer should be official, and the BGE should go more commercial as it is known. Look what Unity have been doing.
As long as there is no pro developers here, there is no hope for this engine, no matter what engine developers are doing. 
Unfortunately, I think BGE is going down. What Ton is doing with it, is the wrong direction and Blender very soon will be known as only 3d developing tool. And I think, that is exactly what Ton wants and maybe he is right.
From what I’ve read, Ton has said before that he will talk things over with the BGE developers to help decide the direction it should go in, Moguri for example already has his own GIT branch to test ideas for tighter integration and code sharing and is seeking to clean out as much old cruft as he can so as to provide a better base to develop off of.
What I can say about my projects, what’s holding them up is not because of BGE limitations or bugs, but the fact I can only work on one at a time and the fact that I have had too many ideas to render out using Cycles. (I’d like to get back to the BGE sooner or later, but that’s when I get an idea for another Cycles image).
Is the source code really so bad that even after Kupoman finishes rewriting the rendering code, it’ll still be a lost cause? Because if it’s near-unworkable, then I’m all for working towards replacing/rewriting it in the future, even if it requires a massive API change. I mean, for my purposes, I’m fairly happy with the BGE as it is now, but there’s no sense in developing for an engine with a near-unworkable code base. The BGE devs’ efforts may be better spent elsewhere.
As long as Ton’s plan doesn’t involve removing any features, and still allows us to export our games as runtimes, then I don’t see what there is to worry about. On the other hand, if Ton actually wants to strip features out, then we ought to raise a storm over it.
BTW I agree with you, I think the BGE devs ought to take a few small steps towards making BGE more commercial-friendly (correct me if I’m wrong, but I think the GPL license is really hurting the BGE in this regard, because even though the GPL issue doesn’t apply to libloaded .blends, commercial devs probably just see ‘GPL’ and flee).