[Bf-committers] Blender roadmap article on code blog

[Ton Roosendaal]

Hi Daniel,

(The long version)

The proposal I wrote for the GE future is not really news for me, it's always been my dream to have a 3d tool that seamlessly merges 3D creation for realtime interaction and traditional film/animation making. That's why I started Blender's GE in 1996. I'm still totally proud of having this integration, and think it's one of the unique things that makes Blender so cool.

Nothing happens in open source without devoted developers though. The fact I have dreams or plans for Blender mean nothing without a team supporting it. But also the fact users like to make commercially marketable games in Blender doesn't mean it happens either.

After 11 years of Blender progress with this open source dynamics, I think it's quite fair to witness that the GE itself is falling behind compared to rest of Blender, in support level and in feature expectations.

In my blog proposal I try to address this by solving the two most crucial aspects for a good online open source project:

1) Focus

What is our "game engine" precisely, who do we make it for, what's the use case references we aim for?

In all aspects for Blender's animation/film pipeline, we have a quite ambitious focus, based on providing production-ready tools and rendering for artists or small teams who can use it for living. Animation and film content created in Blender is very close (if not equal) in quality to what the high-end programs do.

We're even competing with commercial programs here at 'industry level', although we would be realistically ranked more "mid tier" (in the regions of C4D and LW). That's a huge achievement already.

However, where 3d tools are common to to deliver a full finished short film, there's no comparable product that does it for games. Game delivery is still a market (and method) dominated by specialized engines, optimized for platforms and for highly specialized constructed content to play. Even mid-tier engines like Unity3D focus on that delivery aspect (and not offer it as creation tool).

You can find a lot of vocal Blender GE users who _do_ consider that delivery is the focus for our GE in Blender. It's the people who want Blender's GPL dropped for example, so they can "sell" games. I think that's the focus we shouldn't pursue, and that's the remark in the blog to "drop the idea to have an embedded “true” game engine". 

Realistically we cannot expect to be able to realize ever anything that is even close to the gaming experience and appearance we know from mid or high-end games studios. Simply because they also don't use a tool like Blender to do it. The entire process is too specialized still, with a lot of middleware and tools, and teams with plenty of full time coders working on achieving the results.

So - we have to be more clear in communicating to everyone and ourselves what we want from a game engine (or interactive 3d) precisely. Positively worded that is:

- Focus on designing and making games, especially on tools
  (which can lead to playable prototypes)
- Focus on fast access to create interactive 3D in general
  (walkthroughs, character tests, simulations)
- Focus on good support of Blender to fit in game creation pipelines
  (for unity3d, or browser javascript engines, but also for PS4)

2) Support and feature expectation

By dropping the articificial separation in code (and usability) between the "GE" and the "rest of Blender" I think we can get a lot of benefits on both support level (stability, new development) as on feature expectation (amazing tools and possibilities to turn things interactive).

That benefit would even work for both sides. I can think of plenty of features the GE has currently, which would be very useful in the viewport as well. LOD for example, advanced shader effects, fog, light caches, name it.

To answer to your three conditions

> 1. We don't lose existing BGE features

I don't know which features you'd be afraid to lose, but we do have to take a step forward to redesign parts from scratch. The archaic logic editor for example, or the separated Python api, the lack of support for animation, lack of particles. I'd like to see real state-based animation possible, behaviour control, massive sims.

Further I believe much more in artists (give them tools) than in features. A tool-based focus for a game engine would be incredible feature-rich!

> 2. We don't lose the ability to publish BGE games

Would work just as usual. We can even check on a smaller 'player' build for it.

> 3. We don't lose a focus on performance for BGE games

Performance for Blender is relevant in any area and in any editor. It just wouldn't be a separated "games" focus anymore, but a target to achieve in generic ways that would benefit every user. Everyone complains about our slow 3d viewport. Now, let's just tackle that :)

All the best,

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 17 Jun, 2013, at 8:00, Daniel Stokes wrote:

> I would like to know more about what Ton means by the line "What should
> then be dropped is the idea to make Blender have an embedded “true” game
> engine" from the blog post.
> 
> What exactly is proposed to be dropped here? It looks to me all that is
> proposed to be dropped is an idea, changing the focus of the game engine to
> make it better at what it can do rather than making it a clone of other
> game engine/game editors. Are we actually talking about removing features
> and/or the ability to publish a game? The blog post mentions creating "3D
> interaction for walkthroughs, for scientific sims, or game prototypes".
> This can still make use of existing code/features as well as the ability to
> publish and distribute these creations.
> 
> As a BGE developer I have often considered a closer integration of the BGE
> and the rest of Blender for their mutual benefit. At its simplest, closer
> integration means better viewport visualization, and more maintained code
> for the BGE. Stronger integration yields even more interesting ideas as Ton
> outlines in the blog post. As I said in my original response, this sounds
> like a great idea as long as those three conditions (mostly we aren't
> losing a lot of functionality for current BGE users) are met.
> 
> As to the idea of me changing GSoC projects, I am not entirely against it,
> but I would like to better understand both Ton's proposal and the potential
> new project before jumping ship to a vague/undefined project.
> 
> Regards,
> Daniel Stokes
> 
> 
> On Sun, Jun 16, 2013 at 10:46 PM, Benjamin Tolputt <
> btolputt at internode.on.net> wrote:
> 
>> On 17/06/2013, at 3:23 PM, Campbell Barton wrote:
>> 
>>> Then it may be a good argument for Daniel to make a start on
>>> interactive-animation tools,
>> 
>> If he is amenable to the switch, then that would make a decent compromise
>> to offer surely?
>> 
>>> While this is a valid point, (as far as I know) none of these devs
>>> have stepped up to really supporting the BGE and helping become a
>>> maintainer.
>>> They mostly submit one feature they need for their game, then become
>>> inactive with BGE dev.
>> 
>> I wasn't pointing it out as a reason against Ton's move, I was using it to
>> support the *earlier* point that there is a lack developer effort/focus
>> toward the BGE. The patches/submissions to Blender aren't being accepted, a
>> good-sized proportion of BGE advocates are recommending that one use a
>> build that applies most of them, and yet they admit is almost a fork due to
>> the variance between "official BGE" and "HG1 build BGE".
>> 
>> Perhaps it will be a benefit to both BGE and Blender if they become
>> separate projects? Blender can focus on asset creation (with the data
>> structures and code compromises that make that efficient) whilst the BGE
>> can start optimising the code/structures it uses to make it better for
>> running a game.
>> 
>>> ... you could argue this is catch22 - if we accepted their patches
>>> they would become more active and submit more fixes.... but I still
>>> think if someone really wanted to become active and take the BGE
>>> forward they could - despite some slow patch review.
>> 
>> Whilst you could argue the catch-22 aspect, I'd have to disagree that slow
>> patch review isn't a big issue in it's own right. Watching a patch wither
>> on the vine is a very demotivating experience, especially if it fixes
>> something and the bug is left in the main project despite you having put
>> the effort into solving it so the core development team didn't have to.
>> That's something being bandied about the Blender-verse lately as well.
>> 
>> Sure, if you want to be active enough, you'll walk over shards of broken
>> glass to keep submitting your patches but that doesn't mean we should
>> expect them to. Again, not an argument against the BGE
>> removal/simplification as I support/defend Ton's decision in this regard.
>> Just pointing out that the argument (like the "it's not as good as the
>> competition" one) is pretty poor on it's own.
>> 
>> --
>> Benjamin Tolputt
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers