[Bf-committers] Call for GameEngine developers
Tue, 23 Sep 2003 11:18:17 +0200
> 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
- 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=
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.
> If Saluk and one or two other developers are committed, I think we can =
> ketsji work.
> With the python interface proposal implemented, separating Ketsji out =20=
> 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. ;)
> On Wednesday 17 September 2003 21:24, Ton Roosendaal wrote:
>> Still no news from the Solid frontier...
>> It might be a little too early to start a dedicated mailing list now =20=
>> 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
>> 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 =
>> be like the Tuhopoo tree, to enable experiments with the code without
>> being bothered with all requirements an official release has. Of =20
>> 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 =
>> 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 =
>> 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 =
>> fully integrated with Blender code and Blender features.
>> I know this strategy has potential dangers in it; especially in how =20=
>> 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 =
>> 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
>> 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
>> On Tuesday, Sep 16, 2003, at 13:20 Europe/Amsterdam, Kester Maddock
>>> Hi Martin,
>>> I've also been poking the game engine recently - with Hos's help =
>>> the ODE physics support in tuhopuu2.
>>> I'm also thinking of trying to break into the OpenGL side of things =
>>> look at Cg & nVidia's pixel shaders.
>>> On Sunday 14 September 2003 22:53, Martin wrote:
>>>> Although a relative newbie to Blender, my reasons for wanting to =
>>>> 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
>>>> the game engine - count me in! (to the limit of my abilities).
>>>> What I want is a game engine which is small, easily downloadable =
>>>> installable, capable of network connection for control of gameplay =20=
>>>> loading additional geometry while running. This means decent =
>>>> support in the game engine!
>>>> ----- Original Message -----
>>>> From: "maci_ray" <email@example.com>
>>>> To: <firstname.lastname@example.org>; <email@example.com>;
>>>> 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
>>>> | firstname.lastname@example.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
>>>> | Bfemail@example.com
>>>> | http://www.blender.org/mailman/listinfo/bf-committers
>>>> Bf-committers mailing list
>>> Bf-committers mailing list
>> Ton Roosendaal Blender Foundation firstname.lastname@example.org
>> Bf-committers mailing list
> Bf-committers mailing list
Ton Roosendaal Blender Foundation email@example.com =20