@lichtso: no windows for your game engine?

The engine has no Windows support so far, because MSVS doesn't even support c++11 and I'm already using c++14 features …
I tried some cross compilers, GCC and Clang for Windows but as long as you don't use MSVS you can't link against the system libraries, so it didn't work so far.

could you say whose of this features were bigger amount of work andwhich ones here were less work to run?

Sorted them ascending from simple/less amount of work to hard/took long to implement:

• Localization: Support for different languages is a nice feature and really simple to code.
• Material Mapping: Only one texture lookup in the shader, no problem
• Using C++ 11 features: At the time I started this project I had no idea of c++11 only programmed c++03 so far, but it was intuitive and I learned quickly how to use all the new features of the language.
• Port from Mac OS 10.8 to Ubuntu 12.04: There are people out there who think that porting modern c++ code is nearly impossible and yes it is true, when it comes to Windows. But as long as you only want unix support, there is absolutely no problem. I installed a Ubuntu on an extern hard drive and put LLVM 3.4 and GIT on it, cloned my GIT-repository, built the make file and it worked. I just had to fix some system unique things like the path to the safe games … well, of course I had the advantage of using only cross platform libraries, right from the beginning, so it went like It went like clockwork.
• Depth of Field / Fog and Edge Smooth / Antialiasing are all simple post processing shaders using the depth buffer.
• Texture Animation: A time uniform in each shader has to be in sync with the physics engines time.
• 
  Deformable Terrain: Needs vertex buffer objects and vertex array objects, OpenGL 3.2 "features" …
• 
  Logarithmic Depth Buffer: The math about it were the hardest part.
• 
  Bump/Normal Mapping and Glass Refraction: Calculating the tangent and bitangent needs a geometry shader and is the hardest part about it.
• 
  Particle Systems on GPU: Transformation feedback is also a OpenGL 3.2 feature and are hard to debug
• 
  GUI and Text: There is no text or GUI rendering in OpenGL. You have to use another library or do it your self. I used SDL_ttf for the text and did the GUI my self, not difficult but lots of work
• 
  Dynamic Shadows: Calculating and applying the shadow maps for all types of light sources took me (too) long
• 
  Dynamic Reflections (Mirrors and Water): The math behind all types of reflections and the frustum clipping of the mirrored world were the worst part about it, using frame buffers and texture projection was fairly simple
• 
  Skeletal Animation: Parsing a COLLADA, calculating the bone poses and implementing the shaders correctly is difficult
• 
  Parallax Occlusion Mapping: Raytracing, Whoo! Keeping the performance and nice visual results is nearly impossible, but I'm okay with that trade off now
• 
  Screen Space Ambient Occlusion: The same as above. Optimizing the performance while keeping the visual results is really difficult
• 
  Deferred Lighting: Well, using something advanced as deferred shading/lighting means inventing your own graphics pipeline and together with maintaining all other graphics features and transparency it is a real pain in the ass and therefore drove me crazy.

. . .11 is well supported so you should be learning it.

@ Nathan

Sorry, but if you don't know how to sort out Vectors yet building an engine is the worst possible thing you can do.. If you try to sort out matrices definitions for vectors, cross products, normalizing and Quaternion's without successful implementation you're going to suffer. I highly suggest you start with something like Unity, find out how a game is put together before you try and make an engine.

I can only agree. if you still not know how to use Vectors. you should forget to build an "engine" and first learn how you put componets together to build a game!!

As i started programming i aimed for the same idea but that is now 7 years ago and first now i can merely say that i am able to start thinking about. For example I started to create an "wrapper" around SDL2 to learn the new features. This is an good training to you learn how you use external library, learn your language features because you noticed how you cold organize something and so on....

but even for this work you still need to know how to use your language otherwise you will get lost in the middle of your progress

@ Lichtso Deferred lighting isn't that difficult (Don't get me wrong it's not that easy either).

http://ogldev.atspace.co.uk/www/tutorial35/tutorial35.html << Tutorial and source here.

Now POM isn't much of a killer, but you have brought up something very close to me... Trying to future proof an engine by getting that DAMN ray-tracing algorithm in so it doesn't cause the hardware (Even 2X R290x's) to come to a complete grinding halt.

DSSDO instead of SSAO, there tons of examples out there and a massive CryTek presentation on how it fits together. Great for a small mental hernia, but very much possible to implement, there is source code out there for it I'm sure you can reverse engineer it.

@ Nathan

Sorry, but if you don't know how to sort out Vectors yet building an engine is the worst possible thing you can do.. If you try to sort out matrices definitions for vectors, cross products, normalizing and Quaternion's without successful implementation you're going to suffer. I highly suggest you start with something like Unity, find out how a game is put together before you try and make an engine. Learn how to firstly manipulate the utter basics, follow the Unity Tutorial videos:

http://unity3d.com/learn/tutorials/modules/beginner/scripting

You still have to use and manipulate them, but all the hard math is abstracted from you. Vectors are the most simple portion of this whole thing.!

Why exactly do you feel the need to build your own engine? I have a reason, Unity doesn't do what I need it to..! To build a framework on top of it would take nearly as much time as just building an engine. CrySDK was too buggy and I didn't have a access to source to fix it and UDK I just didn't fancy .. (Unreal 4 looks like my cup of tea though).

I've been doing this a long time and I sure as hell don't really want to build an engine, it is last resort.. If all fails, then I'll build one and it's not because I want to.

The other side:

My engine I originally started on was in development for so long it's now defunct anyway and buggy as hell, so I started up a new basic implementation with OpenGL 4..! It's taken me two weeks just to get a basic engine with renderer together, for some people it takes months to get to the stage of having rotation, input, .OBJ loaders, a simple renderer put together as shown below:

Tip: For anyone attempting this, prototype it in a higher level language first.. There's no shame in doing so and use things like LWJGL, game engine design is ridiculously hard.

It will be extremely variable, because firstly there's a lot of variables (team size, full-time/part-time, experience, expectations, etc), and secondly there's no clear definition on what an engine is.
One might have a full editor for making every kind of content, another might have exporters for common 3rd party tools, another might have no tool support at all.
One might support a variety of scene/viewpoint types, such as overhead, planetary and indoor/corridor, others might support just one.
One might be extremely customizable, another might only work for a certain genre.
One might be mature enough to have had several games made with it, another might've never had a game made with it.

A while ago, I spent about 4 years (extremely part time) making a general purpose engine in C++, using Horde3D (a renderer built on OpenGL), Bullet, fmod, RakNet and some others. It was written in a very "modern C++" style, was aimed only at C++ programmers, and had a very poor toolchain. I made a few prototype games with it...

Recently, I've spent 1 year (full time) making a new general purpose engine in C++, using Direct3D, PhysX, fmod, LuaJIT and some others. It's written in a mixture of "modern C++" and "C with classes" styles, is aimed at good programmers, but also has an artist-friendly toolchain centred around Autodesk Softimage (XSI). It's being made specifically for one single game that's currently in development, but is flexible enough to be reused (some components are open-source, and other components are being licensed as stand-alone middleware).

I'm curious, why the move "back" from "modern C++" to C with classes?