[Bf-committers] Call for GameEngine developers

Ton Roosendaal bf-committers@blender.org
Tue, 23 Sep 2003 11:18:17 +0200 

Hi,

> How does the enji engine compare featurewise to the ketsji engine?

Enji is more limited in:
- physics (no solid nor sumo)
- python (no scripting yet)
- drawing speed (no use of opengl vertex arrays)
- development at Enji stopped with 2.04, so quite some of the game =20
logic features have been tweaked for Ketjsi since then.
- internally it still has quirks, based at design limitations. I based =20=

Enji at the old NeoGeo engine which also had to run at PS1...
- it's not C++

Enji has advantages:
- it's plain C :)
- simple code (2 relative small .c files)
- hardly no data conversion takes place; it really starts in split =20
second
- re-use of standard Blender calls; adding blender features to Enji is =20=

a lot easier
- it has a simple but effective Sector system (spatial subdivision) =20
which enables making large environments
- collision detection is 'ray trace' based, so can run in low frequency =20=

fixed clock. (Solid runs time-step based, in a higher clock frequency, =20=

to prevent fast moving objects not colliding)

This basically describes the engines as well. As I mailed before, with =20=

accepting a completely different development focus for both engines, we =20=

might get the best from two worlds.
The simplicity of 'Enji' allows a quick redesign as well, aimed at:

- full blender integration
- only support for features that Blender has as well
- also enable other primitives, such as mball, curve, etc
- integrate with (a redesign of) of DispList system in Blender, for =20
more advanced drawing
- usage of *current* Python API for interactivity as well
- compatibility with basic OpenGL usage Blender has (=3D running at all =20=

platforms)

Ketsji then can have:

- more advanced OpenGL support
- physics/collision which doesn't have to work on Blender
- full conversion of data, to enable maximum freedom and speed
- its own dedicated Python API
- maybe even import from other data files...

When SOLID is back, we can also look at integrating it with Blender =20
itself, allowing physical based animation and modeling. Such tools then =20=

can be designed with interactivity in mind as well.

I know Phase has done quite some work at Enji recently, also to have it =20=

running nice for a commercial project he did with it. My proposal is to =20=

find two teams of developers (which can overlap of course), one for =20
each engine. Would be nice if we can make them 'module owner' of the =20
components, so that they can work in relative freedom.

-Ton-


>
> If Saluk and one or two other developers are committed, I think we can =
=20
> make
> ketsji work.
>
> With the python interface proposal implemented, separating Ketsji out =20=

> becomes
> a lot easier without changing it's user interface inside Blender.
>
> Apart from that, I agree with the proposed roadmap - do a Solid =20
> release and
> split it off as a module - I'd rather not fork the entire Blender =20
> tree. ;)
>
> Kester
>
> On Wednesday 17 September 2003 21:24, Ton Roosendaal wrote:
>> Hi,
>>
>> Still no news from the Solid frontier...
>>
>> It might be a little too early to start a dedicated mailing list now =20=

>> on
>> the game engine topic. I think there are about 3-4 people here
>> interested in actively supporting it. But if they prefer such a list,
>> you only have to say so!
>>
>> It might be interesting though to hear your opinion on the possible
>> roadmaps for creating games in Blender. For example; interesting
>> development like supporting OpenGL shaders are very important
>> decisions, that will affect it's usabality among the various =20
>> platforms.
>>
>> For game engine coders it's important to decide whether they want to
>> work on 'official' Blender releases, or want to work on more advanced
>> features in the engine, based at their own specific needs. I really
>> don't mind hosting at our projects site 'forks' for the engine. It =
can
>> be like the Tuhopoo tree, to enable experiments with the code without
>> being bothered with all requirements an official release has. Of =20
>> course
>> you can also participate in the Tuhopuu project itself. Their admins
>> are open for almost anything! :)
>>
>> I've posted remarks on future engine roadmaps before... as a =
reminder,
>> here's what I had in mind:
>>
>> 1- We make at least one release (2.30) which has full 2.25
>> compatibility. This means that improvements or changes in the engine
>> are not committed until 2.30 is out. The Tuhopuu tree is available =
for
>> most work on the engine now.
>> 2- We then separate the current game engine (nicked Ketsji) from the
>> bf-blender tree, turning it into a separately managed project, and as
>> an export extension or plug-in to Blender. This can be done quite
>> efficiently, because dependencies from the engine to Blender code are
>> minimal. How this will affect the 'game options' (logic editing) in
>> Blender has to be decideded on.
>> 3- We bring back the 2.04 engine (nicked Enji). Which is aimed to =
work
>> fully integrated with Blender code and Blender features.
>>
>> I know this strategy has potential dangers in it; especially in how =20=

>> the
>> two engines will compete, with Enji getting the advantage of being
>> integrated in the core bf-blender project.
>> However, Enji is *so much* more simple and basic. The focus for Enji
>> can be "reflecting what Blender can do", and not putting emphasis (at
>> all!) in adding features in Enji that are not in Blender itself.
>> For Ketsji it can be the opposite; by treating Blender as 'level
>> editor', and pushing engine performance & features as far as the =
group
>> members think is desirable.
>> Since the Ketsji architecture is completely different from Blender it
>> will attract different 'types' of developers as well.
>>
>> Lastly; we have the compatibility problem. Actually the Ketsji engine
>> was far from completed, with a maintenance backlog and long =20
>> buglisting.
>> The burden of keeping an engine 2.25 (or GameKit book) compatible is
>> not something I can not expect from anyone to be responsible for. We
>> have to be realistic here, how much pain it might cause for our users
>> even...
>>
>> -Ton-
>>
>>
>> On Tuesday, Sep 16, 2003, at 13:20 Europe/Amsterdam, Kester Maddock
>>
>> wrote:
>>> Hi Martin,
>>>
>>> I've also been poking the game engine recently - with Hos's help =
I've
>>> updated
>>> the ODE physics support in tuhopuu2.
>>>
>>> I'm also thinking of trying to break into the OpenGL side of things =
-
>>> maybe
>>> look at Cg & nVidia's pixel shaders.
>>>
>>> Kester
>>>
>>> On Sunday 14 September 2003 22:53, Martin wrote:
>>>> Although a relative newbie to Blender, my reasons for wanting to =
use
>>>> and
>>>> contribute to it are:
>>>>
>>>> 1)    Open source (a moral sort of thing)
>>>> 2)    The BlenderPlayer and browser plug in capabilities
>>>> 3)    The skeletal animation and vertex weighting features
>>>>
>>>> So I am really interested in anything which will keep alive or
>>>> resurrect
>>>> the game engine - count me in! (to the limit of my abilities).
>>>>
>>>> What I want is a game engine which is small, easily downloadable =
and
>>>> installable, capable of network connection for control of gameplay =20=

>>>> and
>>>> loading additional geometry while running.  This means decent =
Python
>>>> support in the game engine!
>>>>
>>>> Martin
>>>> ----- Original Message -----
>>>> From: "maci_ray" <maci_ray@yahoo.de>
>>>> To: <bf-committers@blender.org>; <bf-python@blender.org>;
>>>> <tuhopuu-devel@blender.org>
>>>> Sent: Saturday, September 13, 2003 12:41 PM
>>>> Subject: [Bf-committers] Call for GameEngine developers
>>>>
>>>> | Hi GameEngine developers!
>>>> |
>>>> | Don't you think we should bundle our efforts in
>>>> | improving the gameengine?
>>>> |
>>>> | If we are enogh people, maybe we can get our own
>>>> | list for more discussion. But this is future...
>>>> |
>>>> | For now I think it would be good to know from
>>>> | each other at which area everyone is working on.
>>>> |
>>>> | Maci_Ray.
>>>> |
>>>> | P.S. For clearness I propose to answer only on
>>>> | bf-committers@blender.org.
>>>> |
>>>> |
>>>> | =
__________________________________________________________________
>>>> |
>>>> | Gesendet von Yahoo! Mail - http://mail.yahoo.de
>>>> | Logos und Klingelt=F6ne f=FCrs Handy bei http://sms.yahoo.de
>>>> | _______________________________________________
>>>> | Bf-committers mailing list
>>>> | Bf-committers@blender.org
>>>> | http://www.blender.org/mailman/listinfo/bf-committers
>>>>
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers@blender.org
>>>> http://www.blender.org/mailman/listinfo/bf-committers
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://www.blender.org/mailman/listinfo/bf-committers
>>
>> =
----------------------------------------------------------------------=20=

>> --
>> --
>> Ton Roosendaal  Blender Foundation ton@blender.org
>> http://www.blender.org
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://www.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> 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