other game engines (was: Re: [Bf-committers] restore Game Engine project)

[John K. Walton]

On Thu, 7 Aug 2003, Gregor [iso-8859-1] M=FCckl wrote:

> Am Donnerstag, 7. August 2003 13:11 schrieb Ton Roosendaal:
> > - separating also means allowing to think over support for more engines
>=20
> Support for other game engines has been mentioned a lot during the last m=
onth=20
> or two in several completely different threads. Currently this is just ta=
lk=20
> and no plan. This *is* an accusation. There are two way possible from her=
e:

three actually, dump the idea of a game engine entirely. i never cared
for it. it was complicated, created a lot of crossplatform
inconsistancies, and produced uninteresting games.
=20
> 1. Develop an C (better C++) interface that enables game engines to inter=
face=20
> directly with a running instance of blender. This means that blender's ow=
n=20
> game engine would be required to use this interface. I strongly propose a=
 C++=20
> interface as this is the only approach to hide away some of the more awkw=
ard=20
> internals of blender like the specialized memory management. And needless=
 to=20
> mention, that this would be the start of basing the entire blender on a s=
ound=20
> plugin-based architecture (if one C interface is there people will start =
to=20
> demand others... you know the tune ;-).
>=20
> 2. Don't heed other game engines, build a useable and - for a change -=20
> documented Python API and and force it down the throats of those programm=
ers=20
> that want to use other game engines with blender. Blender's own game engi=
ne=20
> would remain tightly integrated.
>=20
> Actually the first way will be the hardest one for everyone involved as g=
ame=20
> engines are anything but exchangeable. Each engine has different features=
,=20
> capabilities, limits and requirements, which are mostly embedded into its=
=20
> design. Therefore it is hard to design an interface on the "one size fits=
=20
> all" approach. Although a indirect coupling using python and a bunch of=
=20
> engine-specific tools increases turn around cycles a lot this will most=
=20
> likely be the better alternative.
>=20
> Regardless of which way this is done I'd wish a library of algorithms tha=
t=20
> will common to almost all exporters to come. The top of this list are=20
> conversion of per-face uv coordinates to per-vertex uv coordinates,=20
> conversion to left-handed coordinate systems (oh yes, even game engines u=
se=20
> these!) and triangulation of quads and higher-order polys.=20
>=20
> Adding these as modelling functions is pretty useless because this may me=
ss=20
> with models to a point that  renders them almost unalterable. And artists=
=20
> can't be bothered with most of these technical details, anyway. It's bett=
er=20
> to have the exporters/connectors do these things, so that artists don't h=
ave=20
> to care about this.
>=20
> Another part of this strategy is a way to place game/engine specific=20
> information in blender files. I have proposed the property system extensi=
ons=20
> as a solution to this.
>=20
> I believe that all of the above points (internal game engine development,=
=20
> helper library for exporters, storing of meta info in blender) should be=
=20
> bundled into a common "interactive 3D" strategy.
>=20
> Regards,
> Gregor
>=20
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>=20