Tobi, trepan, me and K-man (original author of most of the spring
pathfinding/unit AI) want to start a new spring
engine from the ground up with a new clean design.
The current spring engine has a lot of problems and some bad code
design. Instead of continuing to work on the current spring code and
cleaning it up, rewriting every thing seperate and adapting it to fit
the rest of the (messy) code, a full rewrite would result in better
features and design in the end.
The idea is to rely more on external libraries and implement scripting
in it from the start, for optimal modding capabilities. We can keep many
options open that would take lots and lots of rewriting in the current
spring. Think dynamic lighting, bridges, different kinds of world geometry,
dynamic lighting, maybe even seperated physics engines.
In short, we wish to use the Ogre3D graphics engine
( http://www.ogre3d.org), CEGUI and .NET/mono+SWIG for scripting.
Ogre3D has a clean design and many great features that help speed up
development for us. (full skeletal animation, shaders/material
systems, particle systems, editor plugins to name a few, a good
framework for implementing dynamic lighting). Check the ogre site to see
what ogre is capable of.
.NET/mono is ideal for scripting, it supports many different
languages, can compile scripts at runtime and can run the same
compiled dlls on both linux and windows. SWIG ( http://swig.sf.net) can
be used to generate a C++ → .NET binding. The SWIG on cvs has support
for implementing C++ virtual functions in C# classes.
One of the major drawbacks on the current code is that practically
everything assumes existance of the UnitDef structure, and everything
is written with a TA mod in mind. With a clean start, we can design
the core of the engine as a general rts with a single generalized unit
interface, and implement the unit code and related code in C# or other
.NET languages (even PHP ). You would get a TA module for TA-style mods,
and other modules for completely different types of rtses (a supcom
The C++ engine would provide functionality that require
high-performance code, such as pathfinding, rendering, target finding
and los calculation.
- Jelmer Cnossen