As this sticky: http://www.gamedev.net/topic/539070-best-game-engine-for-indie-game/ is a few years old; and can't be commented on - I was curious to see what people are using these days for their indie, and hobby (to be indie) projects.
Browsing through the list in that thread I have to say that the Unreal engine looks really good with a reasonable entry price - But looking for others experiences and recommendations.
Yeah I would recommend UE4 or Unity to anyone looking to get started now. Unity is incredibly popular (and for good reason), and UE4 is incredibly cheap for a AAA engine with full C++ source code...
Unfortunately I'm one of those people who's stupid enough to make their own...
[edit] The Esenthel and C4 developers are members of this forum, so easy to get in touch with them if you have any questions on their products 
There was recent reddit about this topic.
http://www.reddit.com/r/gamedev/comments/1lhr2w/need_a_lightweight_3d_c_engine/
For me, I prefer to have SDL+some light weight libs which is free and gives me more flexibility & control than a complete 3d engine
using Unity here, pretty satisfied with it. You can do a lot until the engine becomes a bottleneck, and actually, you can very productive thanks to the good tools and documentation (which is not a given in some other engines).
I am pretty excited about trying out UE4 now that Epic is showing Indies some love with less-strings-attached (the 25% royalities in UDK kept me away). I will one day, I know that. But first things comes first, and that for me is to finally get the prototype I am working right now to a state I can show around... and as everything is started in Unity, is coming along nicely, AND I am also pretty excited about Unity 5, I will stick to Unity for now.
I used Esenthel for some time. Good renderer, advanced features at the time (DX11), and nicely integrated functions in some areas (creating graphics settings was extremly easy thanks to how the framewrok was laid out in the code). What was really amazing was the built in streaming terrain. It... just worked. Without anything but a small microlag when too much had to be loaded from disk. Still, pretty cool when you think that you could load a huge heightmap created in World Machine, divided in chunks, and have many miles of very detailed terrain. Also, the dev will listen to feature request.
Oh, and before I forget, the Importer is pretty good. Loaded my Meshes created in 3D Coat without any troubles whatsoever, when I need to tweak them everytime I import them into Unity (normalmaps are in the wrong format).
Negatives were terrible tools at the time (though the dev did something against it and released a new editor), some glitches (imported terrain heightmaps had small errors at places. Only in few places, still), performance woes of other people (I never got to stress the Engine to that extent), size of the built scene on disk (arguably huge in my case, 8x8 KM with 1x1m heightfields. Could have been my mistake for assuming the system was able to handle this. Still, multiple GBs for a single scene without much in it besides the terrain IS rather extreme), and the weird direction the dev of the engine took made me look elsewhere.
I am pretty sure that Esenthel will be a very good choice if its strengths are needed and the weaknesses are of no concern. If you are a good programmer (I don't know how good the new tools are, the old ones were just 'usable'... and a lot of stuff was much easier to do in code), you need a good terrain streaming system and huge scenes, you need a good DX9 Renderer (forget the DX11 specialities, they were quite broken when I tried them. Maybe they are fixed now, but anyway... who really cares about DX11?), and you are expirienced in how to setup your scene to prevent overloading the GPU or the CPU with draw calls, Esenthel will give you a very good Graphics with little intervention from your side.
Its certainly not for the inexpierienced, or non-programmers. There were issues with the implementation of the terrain streaming system back when I tried. And I would be quite wary about how Esenthel would be able to compete with next-gen engines like Unity 5 or UE4. From what I have seen, the dev of Esenthel is an extremly talented developer... but competing with companies like Unity or Epic as a single guy... Also, the community is rather small compared to Unity or Unreal. There are certainly people eager to help, but there are just not many of them around in the first place.
Yeah I would recommend UE4 or Unity to anyone looking to get started now. Unity is incredibly popular (and for good reason), and UE4 is incredibly cheap for a AAA engine with full C++ source code...
Unfortunately I'm one of those people who's stupid enough to make their own...
[edit] The Esenthel and C4 developers are members of this forum, so easy to get in touch with them if you have any questions on their products
Had a quick look at eight, why would you use C in core.cpp, malloc, printf ad a few other functions?
Note that there's not the full source for a game engine in that repo, just some common utilities such as memory-management, logging, debugging, threading, etc...
Some of those printf's should really put puts's 
It's just developer-only logging code that needs to deliver characters to stdout for debug purposes.
C++'s std::cout is unnecessarily complex for that case. I could dig inside the iostream to skip the localization crap and just print characters to it's raw buffer... but C's printf/puts are much cleaner at that point, so why not use them.
All that stuff is also wrapped up as a central logging output point. It could easily be changed to log to a file or a network socket instead.
Lots of parts of a game engine need to allocate large blocks of memory, but don't need to also invoke constructors at that time -- e.g. when streaming in a file from disc, you need to pre-allocate block of memory large enough to hold that file. malloc suits this purpose fine - there's no advantage to using new just because we're in C++.
eight::Malloc is just a wrapper around malloc for now. The purpose of that wrapper is so I can then choose to ban the use of malloc from the rest of the engine. If I want to change the engine so that it gets it's memory from HeapAlloc, VirtualAlloc, dlmalloc, new char[], etc, then there's one central point where I can make that change.
However, eight::Malloc is itself rarely used, because most of the engine uses scope-stack allocation and memory pools instead of heap allocation.
On that note, the new keyword is also banned within the engine code-base. New/malloc rely on global variables, and thus should be treated like any other global and only be used in select situations. Most of the engine is written to explicitly name a specific object to allocate memory from, instead of relying on a magical global allocator.
e.g. Instead of:
T* t = new T(args); // Create a T on the global heap
The engine uses:
T* t = eiNew(allocator, T)(args); // Create a T within the 'allocator' object
@Hodgman
Have you created an editor or how does that fit into the scheme of things, say you engine is x% done and you want to test some prototype, have you just create a bare bones editor or do you do that first?
