[Bf-committers] restore Game Engine project

[Ton Roosendaal]

Hi,

I think you've got a misunderstanding in what the original concepts =20
behind Blender's engine was... not to blame you, it's an idea I find =20
myself pretty lonely in!

Anyhow, the target group for Blender's engine feature was never =20
intended at game studios or game programmers. It's solely meant as an =20=

extra tool to for 3d artists, to extend their creative possiblities =20
with interactive/realtime 3d.
Understanding and fully grasping this topic was something we failed in =20=

during the NaN period... especially in creating the technology (tools) =20=

and marketing it. This doesn't really change my opinion however, I =20
still find it a challenge to bridge this gap... having realtime both as =20=

'linear' 3d tools in your hands.

The notes you make below can be put in that context as well. So we =20
should separate two topics:

- import/export and cooperation/integration
this to enable artists to use Blender in their (professional) =20
environments, whether that's support for a renderer or a game project. =20=

Efforts to integrate with Yafray can be classified of the same type as =20=

doing that for game artists.
- tools to create and playback interactive 3d content
probably we should redefine (clarify) what this exactly means... it =20
could be limited in functionality, like the old engine, and/or based at =20=

prototyping/testing and assisting creative processes (pre-viz).

In fact you already mention it, with this sentence:

> Actually I believe that dropping the current game engine and focussing =
=20
> on game
> engine *support* - meaning making blender a tool for game developers - =
=20
> would
> be better than developing yet another open source game engine.

With added note, that is is of course not the sole focus of Blender, =20
but something that should *also* work well. :)

-Ton-



On Sunday, Aug 10, 2003, at 21:33 Europe/Amsterdam, Gregor M=FCckl =
wrote:

> Am Sonntag, 10. August 2003 03:31 schrieb Patrick:
>>   I think I see the advantage of seperating it out now.  I'm looking
>> into open scene graph as an alternative rasterizer, as it already has
>> culling, is fairly up to date with special effects and opengl
>> extensions, and seems less bloated than the current favorite Crystal
>> Space.  If we seperate out the engine it will have more flexibility =
in
>> plugging these kinds of things in.  We need to get together and make =
a
>> major combing through of the source documenting/figuring out how it =20=

>> all
>> fits together.
>>
>
> You got me all wrong here. It never was my intention to use Crystal =20=

> Space as a
> replacement for blender's current game engine. My goal is making =20
> Blender
> useable for modelling real-time contents for external game engines.
>
> Therefore my emphasis was on the following possibilities:
>
> 1. easy integration and testing of game models/levels into an external =
=20
> game
> without the need of a programmer to do the integration work
> 2. ability to add game- or engine-related metadata
> 3. best possible preview, which would ideally rely on the game =
engine's
> renderer.
>
> This affects different parts of blender. Some of the work is already =20=

> under
> way. But the third and (to me) least important point would need a lot =20=

> of
> extra interfaces in blender.
>
> Most of the features above are interesting for all external game =20
> engines as
> well as blender's own game engine. So seperating it and defining
> well-abstracted interface between blender and game engine plugins =20
> would help
> the community a lot.
>
> Actually I believe that dropping the current game engine and focussing =
=20
> on game
> engine *support* - meaning making blender a tool for game developers - =
=20
> would
> be better than developing yet another open source game engine.
>
> I recently noticed that game engines that are deeply integrated into =20=

> game
> authoring tools are generally frowned upon and actually do not wind up
> generating good games.
>
> Furthermore, good state of the art game engines are a lot more work =20=

> than you
> possibly expect. Needless to say that many game engines are very =20
> specialized
> to the game's environment for a reason. True general purpose engines =20=

> have to
> be slower and are harder to develop.
>
> I'm not saying this in favor of CS alone. Actually I am currently not =20=

> really
> supporting any specific game engine.
>
>>     And to the fellow who says kill the game engine, I can see you're
>> point of view, as I hardly ever use the rendering functions, or =
nurbs,
>> or metaballs etc.  I pretty much exclusively use the game engine.  It
>> might be a good idea in the future to restructure blender in such a =20=

>> way
>> that the user can decide what things they want in their blender.  =20
>> Like,
>> I would have the game engine, but I would take out the render module,
>> and metaballs, and paths, etc.  And you could not put in the game
>> engine.  But there are too many people using the game engine right =
now
>> to just can it.  And there are a lot of really good games so far, you
>> must have missed them:)  There are less good games than there should =20=

>> be
>> however because there are 4 or 5 major bugs that slow development =
down
>> trying to find workarounds.
>>
>
> When you were given the chance to choose from a variety of =20
> specialized, highly
> developed and sometimes even modular stand-alone game engine for which =
=20
> you
> can create models using blender, would you still choose blender's own =20=

> engine?
>
>>     The modular approach would be desirable I think, and we can start =
=20
>> by
>> seperating the game engine out.  The rest of blender would be much
>> harder to do that with :/
>>
>
> Seperating the game engine is a good idea. Making a new type of binary =
=20
> plugins
> for external engines (including blender's engine) is an even better =20=

> idea in
> my eyes. Note that many good game engines do not have python bindings =20=

> and
> therefore it will be hard to impossible to tie these engines to =20
> blender using
> python.
>
>> Anyway, I am optomistic about the future of the engine.  I think with
>> some work it could become the premier game engine for hobbyist game
>> designers and proffesional RGD (rapid game development), although I
>> really do hope some more programmers can help us out:)
>>
>
> No. Blender would also need to satisfy the needs of the game =20
> programmers who
> need a good script editor at least. And this is yet another hell of a =20=

> task.
>
> Regards,
> Gregor
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------=20=

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