[Bf-committers] Blender roadmap article on code blog

[Benjamin Tolputt]

On 17/06/2013, at 2:41 PM, Campbell Barton wrote:

> Not being as good as competition is a stupid argument (on its own),
> quite a few of blenders features aren't as good as other software.

Agreed. On it's own, it's a terrible argument. After all, there are *dedicated* game engines out there that are worse than their competition ;)

Some of the reasons *why* is isn't as good as the competition are worthy arguments though, but I don't think Ton is making them directly. Possibly to sidestep the argument that would entail (I've made the mistake before of "punching that there tar-baby" *eek* ).

> The problem IMHO is more that the BGE is not getting much developer
> attention and not likely to pick up any time soon.

This I think is the kicker. Where development effort is spent is a frequent subject in the Blender-verse these days and for good reasons. Only the features that have developer focus get maintained and improved. Features that are not maintained in a larger body of work can have a detrimental affect on other areas (e.g. "This module relies on feature X using function Y - we can't change function Y without altering the module... and we don't really maintain that module anymore").

> The timing here is unfortunate too.
> It's not nice for Daniel Stokes to find out the BGE will be
> discontinued the day he starts working on GSOC. (BGE Level of Detail
> and Bug Fixing/Polishing)
> Bug-fixing a system that gets removed in a year isn't such good use of
> resources.

I was unaware of this and have to agree, the timing sucks. That said, I'm not sure if it's a great argument for keeping the BGE as it is and integrated as it is. The whole "sunk cost fallacy" comes to mind and, while I don't want to be callous to Daniel Stokes, I can't see that his GSOC project will really change the underlying motivations that prompted this move.

There are folks on BlenderArtists talking about the large number of patches contributed for BGE that never made trunk and would almost constitute a fork themselves if applied (they're calling it the "HG1 build". This is a symptom of the developer effort allocation problem mentioned earlier and would apply as much to a GSOC project as any other large patch correct?

--
Benjamin Tolputt