Some images of a game/engine I've been working on for about two years now. The idea is to create some sort of multiplayer skirmish featuring basic stuff like deathmatches, CTF and so on. But as I lost my creativity at the age of 14, the game has taken a direction of being a more like a template for those who have the actual ideas.

I designed the engine to be highly moddable: every mod will be provided as zip or 7-zip archives that can patch each other when loading the game. With xml and scripting users can implement new types of enemies, vehicle and player classes, game modes and visual effects.


Current features summer 2012:
Hardcoded features:
-DirectX 11 HDR rendering
-Cascaded variance shadow maps (not fully finished though, too much peter-panning when the scene gets bigger)
-Dual-paraboloid variance shadow maps
-Dynamic impostors (works somehow, the update logic still needs a proper implementation, also some issues with depth and ambient occlusion)
-Particle rendering
-Skeletal animation, linear+additive blending (animation layers) - integration with physics (ragdoll -> animation transitions) is still WIP
-CCD IK (bugs badly atm, needs investigation)
-Fork and join multithreading using Intel's TBB (includes rendering, physics and update logic)
-SSE2 +optionally SSE4.2 instructions
-PhysX 3.2
-APEX destruction (rendering code not finished yet, some issues with the existing pipeline)
-Angelscript (indirectly controls everything and makes the actual game, event-based system)
-Component based actors (all objects in the images are actors, including sky, triggers, snow particle system and light sources)
-XML defined actors, materials (forward shading, post-processing and physics) and entities
-Terrains - about 10% completed... Ready enough to put it in the list . I wanted it mainly for the ocean, but not a priority for now.
-Decals, not that great support either, but I'm working on that
-Asynchronous data loading from zip and 7z archives
-Basic font rendering, console interface (also with user implemented scripted commands)

Datadriven features (some examples of have been done):
-Tonemapping
-HBAO
-SMAA
-Ragdolls
-Wide variety of lighting models
-Translucency approximations
-DXT5 compressed normal maps
-Detail/Phong tessellation (Palm leafs were too jaggy, phong tessellation fixed the problem)

Some comments about the images:
1. Overview of the test scene I've been using. It's a bit dumb with all the hovering buildings and layers, I still lack a proper level editor.
2. Same scene at night
3. Basic flight simulation. Forces and torques are applied by script, the physics engine handles the rest. It'd probably be more interesting if there was something to fly above instead of a runway and a boring skybox. I'm thinking about the ocean here. With current features it's possible to implement a smoke trail, but I'm too lazy for that.
4. Playable animated character standing on a playable aircraft! I should find some clothes for this dude. But the gilded rifle is already there!

Most of the models visible were bought from dexsoft sales.

Edit: added the new images

Click here to view the iotd

Nice, what are you using in terms of scenemanagement and visibility determination?

For rendering there are simple linear render queues for opaque and transparent objects (all passes), particles and such. These queues and built from a list containing actors which have any kind of "renderable" component. A standard render component defines a set of tranformations and other properties (materials, flags, special cases, ...) for a referred model. Most of these parameters are handled by other systems before the graphics engine gets to do anything (state interpolation is done by graphics engine though). So basically no trees, graphs or anything, just plain lists of pointers .

The visibility determination is about just as simple. When a queue is ready to be rendered, it's first sorted depending on the situation. After that the queue is shared among rendering threads. Before anything is written to a command list, the mesh or whatever is culled using basic frustum - oriented bounding box intersection test (triangle casts and spheres are also used for cases like shadows).

Thanks for commenting, I hope I answered something...

I polished the aircraft a bit. Although it looks better now IMO, it doesn't change the fact that it's still programmer art... And I'm still experimenting with different shaders. I also armed the vehicle with four AIM-120 AMRAAMs, and thanks to engine design they can be set to track any actor in the scene 8). For testing purposes they're currently all preset to track the player itself once launched. It's really entertaining to try to evade one's own missiles!

Don't pay much attention to clouds, they aren't sorted properly due to their size and particle system overlapping.