Here are four shots from a small engine i'm developing these days. The engine is called Alithia Engine (alithia means "truth" in greek although the pronounciation is slightly different). It is a complete rewrite of an engine with the same name i wrote three years ago which i started at November last year (although from about 13-Nov to a 26-June i did nothing ).

The engine is inspired by Cube 1's simplicity and like that engine it features an in-engine editor and a 2D grid based world format. The rendering methods however are different (although there might be some similarities - i haven't read Cube's code but from what i've seen when i fly high in the edit mode it seems to cast rays like my engine), but Alithia Engine is written with newer hardware in mind (in that it tries to keep calls low instead of having tight occlusion). Still it doesn't use anything more complex than OpenGL 1.x calls, which allows it to have playable performance even in my Aspire One .

Rendering works by casting rays (via ray marching) from the camera's position to 360 degrees around it in the 2D grid. Rays march in the grid cells until an occluder is found, where they stop. The grid is divided in clusters which contain the actual geometry in mesh-only display lists (one or more display lists per cluster - the geometry is sorted by texture) and they are marked as "visible" as each cell is visited. Then when all rays are cast, the visible clusters are checked for frustum inclusion using the axis-aligned bounding box of their geometry and if a cluster is inside the frustum, it is considered for rendering. Clusters contain a list with the entities in the cluster which are also considered for rendering (so occlusion works for both world and entities).

The "considered for rendering" part basically means that they are added in a geometry bucket system where each bucket has a texture reference and list of display lists (buckets contain both world and static entity geometry). They are rendered after the visible clusters have been found.

The world has a single big lightmap which covers the whole grid with one lumel per cell. The lightmap is always rendered with multitexturing for world and the lumel under each entity's center is chosen to tint the entity geometry by placing a light above the entity and using a dark ambient with the same color (this will be tweaked later to look better). Currently lights do not affect entities, but i might change that later. The same applies for shadows which are simple projected flat stencil shadows.

Currently the engine doesn't do much: you can walk around, edit world cells, put and move entities around, put and move lights, recalculate the lightmap, etc.

There is a scripting system which uses a Tcl-like scripting language of mine. It allows very dynamic scripting although the performance is a bit slow. However i don't mind that since most of the intensive tasks will be done via native code.

The scripting system is always active and there are both game and editing commands. The screenshot at the bottom left corner shows a small script i typed in the in-engine script evaluator which creates random lights inside the currently selected grid area.

This screenshot also shows the engine GUI system which supports floating resizeable windows, buttons, text editing fields and areas, popup menus and other controls. The texture browser, for example (shown at the right corner of the image) is a floating window with a custom control.

The image contents are: top-left shows a level design test i did in game mode. It took me about 20 minutes to do that (it has other areas outside that room but i only took one shot - i still can't save world files) top-right shows the ability to create arches, slopes, etc using vertex offsets in editor gui mode bottom-left shows the GUI in editor gui mode and the script evaluator with a script that registered two menu options bottom-right shows the object movement action in editor camera mode. When moving objects and lights (the little spheres - their radious is shown as another sphere when the mouse moves over them) around the editor draws guidelines to assist in placement

Generally the goal is to create a simple engine. I'm not placing must effort in optimizing - most of the time i just code whatever simplest method pops in my head and only optimize when things go slow. Also i only implement stuff "on demand" - for example i added "plane_t" etc structures only a few days ago. This makes Alithia Engine a very compact engine (currently it is about 10KLOC including empty lines and comments and about 2KLOC are from my scripting engine which is a separate project). An important aspect of the engine is that i want to have everything in my head .

Still it needs more work and the size will probably double once it is usable. But i thought i might share a few images here

added some physics. I have no idea about physics (except moving particles around in a totally simple pos += vec; vec *= 0.999; manner ), so i made whatever popped in my mind. It isn't very physically correct but i found it funny

Improved the collision system and made the player be an entity himself so he can push other entities around and stand on them . Now i need to optimize the code a bit (doing too many unnecessary checks and the objects still do not "rest" - ie they check for collisions, movement, etc all the time even when they simply sit around).