[Bf-committers] Call for GameEngine developers

[Ton Roosendaal]

Hi,

> The "plug-in" term needs elaboration. If you mean that perhaps this  
> project
> could include window types that have full access to blender internals  
> including
> DNA so that Ketsji-specific data could be stored in regular blend  
> files, then
> there isn't much difference to the current setup.

That sounds hard to do... when it's a 'plugin', then I only thought of  
the blenderconvertor and 3d player. All editing then still is in  
Blender itself.

> Maybe with the planned script-UI
> integration features we could build "Ketsji guis" that bridge the  
> separate
> regimes. This reliance on python for robust access to Blender data  
> would
> hopefully strengthen the python API rather than tie up ketsji  
> development.

Yes, this is one of things I thought of. Python is *meant* for this  
type of extensions in Blender. Although it has some limitations, it  
should be able to cover most of the development that happens in ketsji.  
The proposal to extend Blender Properties system is one of the means  
for it.
For the logic brick system we'll have to evaluate it further though...

> Depending on these issues, the logic gui quality and integration with  
> Blender
> could suffer, and this is a big advantage the game engine has over  
> other
> products despite the minimal integration code-wise. I think totally  
> splitting
> Ketsji from Blender reduces its appeal, since although it doesn't  
> necessarily
> need blender to make it a "good" piece of software, it does need a  
> good gui.
> Otherwise it is just another game engine with tools that don't always  
> serve it
> well. How about forking Blender for a "Ketsji level editor" version  
> that
> supports Solid/fuzzics and potentially ODE? Could have:
>
> * more logic editing support such as finite state machines
> * remove some features not supported by game engines??

This also was discussed in NaN in the past... the 'fork' then basically  
can have a complete different UI as well; reading .blend files, and  
displaying only the tools needed for further editing of interactivity.

We can consider this a temporal situation. I didn't propose this  
splitting up because I think it's good to remove interactivity from  
Blender. In contrary, I still consider it one of its exciting & unique  
features.
My motivation comes from a managements perspective. I aim at getting  
all Blender aspects actively being maintained and improved. This is  
something we're still far from... but it's obvious that most interest  
of the current active developers is in in the 3d creation tool, not in  
the interactivity part.
Another aspect is that Blender itself is pretty mature compared to its  
interactivity part. Adding an engine to a 3d tool is still very  
innovative, something that needs real research to define how it can  
work best. I wouldn't mind supporting a team that has a lot of freedom  
to explore this, for example in the 'fork' you propose. Later on, we  
can join our roadmaps again in a Blender 3.0 design.

So, like another tuhopuu, but an 'i-Blender' or so?

> I know there won't be impetus for a complete fork unless there are  
> coders to do
> the work and maintenence, so a first step could be to implement Ton's  
> scheme.
> If there is interest at some point a full fork of Blender could be  
> made from
> tuhopuu.

Well, a cool experiment to gather all 'blender spaghetti haters'. :)
Here's your chance to rethink a 3d tool entirely from the engine  
perspective. There's already a C++ API around the 'blender convertor',  
choose to use GTK, everything in C++, and make all kinds of decisions  
you *never* can do in the bf-blender project!

-Ton-

------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org