Version History

Details at DevelopmentLog


When it all began - eVAC

In the Wintersemester 2003 we, along with a friend, decided to make a OpenGL? based game as software internship for the university: eVAC. We started our own engine from scratch, as our main goal was learning how 3D engines are made and what is one needs to know about them. Although most of us used Windows, we thought with a graphics API like OpenGL? we can try to make sure the engine will run on Linux, too, something we have always looked for.
We split the work up among the three of us and 4 months later we had the engine "eVAC" and the game basically finished. However since this was the first time we ever did something alike, alot things needed improvement, and we soon saw that we need to heavily overhaul the engine design. While the game ran fine, and was quite playable, although a bit hard ;) the engine was extremely messy and the interrelationships made it quite hard to add new things. We also did sorta mix between trying to be "open" for different games, ie not hardcode the gameproject, but have a bit of a abstraction layer, however exactly there our lack of experience made it quite hard to find good abstraction, hence the code was kinda chaotic at the end.
So for engine II our main goal was to find a nicer way to make the engine useable for other games easily, as well as enhancing the renderer.

eVAC II - judgement day

After a bit of a break, the work on eVAC II started in spring 2004. Mostly the codebase of eVAC I was used, but split up into "renderer", "fileio"... and then refined/recoded. The basic layout of the engine was made in that time, along with many small new features, like changing resolution and so on. I spent most time implementing a new "shader" script, which would work somewhat like q3a's shaderscript, allowing artists to easier combine textures and texture animation. This took quite a long time, and was sometimes due to faulty drivers quite a nightmare. After the materialscript was done something similar was made for particles, so we moved graphical effects as scripts outside the engine. The next big decision was to use a scripting language for the gamepart of the engine. Since our main goal of the engine was to make it scriptable totally outside of the engine itself. Eike experimented with LUA and had soon integrated it. He also added ODE into the engine, so we finally had proper physics and collision support. Combined with the external lua scripts, a few test applications were done in the winter 2004. There was also a very simple netcode so we could have a few box cars controlled by clients. Basically at that point we saw what kind of features were important to us, and how the engine should be organised. But again things were beginning to get a bit too complex, and it was time for another rewrite.


In January 2005 we started the rewrite of eVAC II, but we werent really happy with the name anymore. We wanted to have something with "light" in it. My sister came up with Latin for "nightingale" - "luscinia", bringing in "lux" (Latin for light), luxinia was born.
Main tasks were to find a good abstraction, between worldnodes and rendernodes, as well as having a easier way to publish internal functions to LUA. The FunctionPublishing? system was abstracted so that in theory one could use different languages for it, since we were always afraid of LUA not being fast enough, although for it's ease of use and openness its probably the fastest one can get. We also polished the tools for the engine a bit, with model convertors and mesh optimizers. The internal console is lua as well and one can directly interact wit the gamescripts from it. Also some more graphics effects, such as trails, partcile clouds and a system to alter the framebuffer by automatic texture fetching were added. Another experiment was a tile-based terrain engine, the tiles are put on a heightmap based terrain, like in classic 2D games, with automatic neighborhood handling the results were quite good. However finalising the terrain along with the reintroduction of ODE physics/collision is still due.
With the large feature set, we now focus on doing small games with the tools and gadgets with have, and add small things as we need them. This was somewhat our main problem over the whole development time, we have always thought about abstraction and making a big toolset, without actually using the already given tools. On the other hand the big toolset we have now begins to pay off, and one can do small games very quickly and easily.

The future

Well we will see what it will bring, mostly it is still bug fixing, tweaking a few implementations, trying to get the renderer faster... while keeping the open structure of the engine and keeping it entirely scriptable outside of the .exe. On the one hand so that other people can use the engine without having access to the actual source, on the other hand for us being able to focus on gamemaking and not engine hacking in C, which is something we dont want to load on our users.
For the future a built-in IDE and editors for the shader/material/particle systems are intended, as well as better/more exporters/fileformat convertors. Another hot topic is terrain rendering. In the future we also intend on releasing a linux version, and hopefully mac os x as well.

So much about a little trip through the history of luxinia. I hope people will have as much fun as we have with this project.

Christoph Kubisch - September 2005