Development diary #3

Long time no see...

Well, the engine is moving steadily. Most of the ongoing features are complete or stable enough now to comfortably keep expanding.

Those features include the modular graphic framework, wrapped around SFML/OpenGL which can handle Sprites, Text, as well as custom "visuals" (e.g. the main planet has its own type). Although the framework act as a wrapper, it also abstracts the data, allowing the user to easily add new visuals to the scene, move the viewport around, without having to worry about optmization : culling, occlusion, depth, and so on.

The object manager I talked about in the previous diary is almost fully working, and supports two types of objects : objects and visible objects.
The idea behind that system, is that users can easily create new types of objects, which can either act as a game object (e.g a character, with a sprite and AI), or a more abstract component (a radar ) which would run in the background. Once the object has been written ( for now only in C++ ), the user just needs to insert it whenever he/she wants during the game, without having to worry about calling the appropriate update function (which is being handled by the object manager).
Some examples of the system being used are the console GUI, and the planets.

Talking about planets, I have rewritten the main planet code from scratch, in order to correspond with the current engine's structure. Initially in the prototype version, which wasn't very much optimized, the landscape was generated using RMD ( random midpoint displacement : http://www.gameprogrammer.com/fractal.html), and used a very primitive LOD ( level of detail ) system which would skip a certain amount of points based on the zoom factor and the screen position. All of this has been rewritten aswell, using a binary tree structure, and proper viewport culling, which in the end increased the performances by 10, if not more. This not only improves performance, it also means the level of complexity can be increased even further with no issues, as well as allowing easy geometry alteration.

This particular point will be the next one on my list : terraforming will be a key element in Biosphere. The terrain will be altered by your settlers when building infrastructures, meteorites colliding with the planet, and possibly volcanos and errosion.

To give you an idea, I am running the whole application at a stable 300FPS on a laptop with an Intel dual core 2.1GHz CPU, 2048MB of RAM and a Geforce 8600M GS.

Finally, an interesting (in my opinion) feature I recently implemented, which I had not planned initially : the inclusion of the Python scripting language, more precisely stackless Python : http://www.stackless.com/ ( other games such as Eve Online use it ). The idea of using the scripting language is to abstract and encapsulate the game engine, as well as making it alot faster and easier to define and alter the game code. Although it is not fully linked with the engine's component yet, it should allow the user to easily extend the game, by deriving base objects into his/her own custom objects, make menus and interfaces without requiring any knowledge of C++.
The other benefit of the scripting layer, is that it simplifies the memory management process : python has a garbage collector, and once plugged into the engine, it facilitates the whole allocation/deallocation process, making it a safe engine to use. Although some people might argue over the fact that scripting languages are slow, the interpreter is run in parallel of the C++ code, at a controlled speed, meaning no slow downs, or stalls.

In the end, I have still decided to keep the python script optional, as I found it added an extra dependency to the application ( users are required to install stackless Python in order to run the game ). So basically, users should be allowed to choose between C++, Python or even both, seemlessly, and include it or not with their application.

What's new ?

Voilà !! That's all for now, so let's have a look at what I have done so far :

• Working modular graphic framework, with a stable pipeline, and which now handles viewports (singular for now) and custom types (e.g. the planet renderer).
• Working object manager, with easy implementation of custom components.
• Implementation of the stackless Python interpreter, allowing the game to be coded both in C++ and Python.
• Main planet landscape with working dynamic LOD.

Plans for the future ?

I have quite a lot ahead of me, but here is what I'm aiming to achieve soon :

• Fully linked Python interpreter with the ability to fully script the game mechanics.
• Terraformable terrain.
• And of course the other core components, such as input and sound (already supported, but not embedded in the engine).

I have a couple of weeks work-free, so hopefully, I should be able to post some more update soon. In the meantime, here are some snap shots of the LOD system in action :