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).

At work we have been making a C++ 3D engine which favours portability above all else. The technology used varies per platform (The only common part is OpenGL).

Some of the tech used for desktop platforms is Xlib/glx, libpng, openal, libogg/libvorbis.

The consumer platforms (Android / iOS) use the underlying platform's stuff but wrapped with C APIs similar to the desktop counterparts to minimize #ifdefs and other changes to the core games.

All the model loading, animation and physics is bespoke and written in C (with C++ wrappers) so is perfectly portable to everything.

To get it up to a usable state ready for games it took two of us a couple of months. It is unlikely to be as advanced as Hodgman's but as an "indie" studio, we currently need to battle with tablet / phone support and all the gimmicky short lived technology that it brings.

@flyingsatin: The gpl license (...). If you are making everything from scratch, i'll like to know about it because i might make some things from scratch for the engine.
With the features (not the libraries) i plan on putting in the engine(s), it is unlikely the source code will be available or it'll be free but they'll be inexpensive (big dreams) and no royalties (don't like'em).

Just fyi, if any part of a codebase uses GPL, the entire codebase must be licensed under GPL or equivalent. This means, if you use GPL code in a library, game, or engine, you don't have a choice of whether it's opensource or not: It is legally required to be opensource by the license.

Also note: LGPL is different than GPL, and is more lax in some ways, permitting LGPL in closed-source software, as long as the LGPL code is dynamically linked instead of statically compiled in (though there is some discussion about permitting static compiling also). Basically, the idea with LGPL is that any changes to the LGPL part of the project needs to be re-shared with the world, but any code that uses the LGPL libraries don't have to be shared. :)

There's other nuances there, but I just wanted to make sure you understood that GPL doesn't give you the option of saying, "it is unlikely the source code will be available or free" if you decide to use GPL code in your project. :mellow: