We use our own custom engine. When we started out, Unity 3 and UDK (Unreal 3) were shitty (and UDK was expensive), and most other options were shitty and expensive... These days Unity is super cheap (cheaper than Unreal 4 if you do the maths), and Unity/Unreal are pretty great. Lumberyard and Stingray are trying to shuffle in but no one cares yet. Don't mention CryEngine...

We have a cross-platform rendering library that's like BGFX but with way better performance, way simpler, easier, etc... which we also license to other companies who are building their own engines. Then a bunch of open-source / middleware such as PhysX / Bullet (first is great, second is not great but no licensing headaches...), FMOD Studio, librocket, imgui, LuaJIT, yojimbo...

We stick with this because the sunken-cost fallacy is strong... plus we're actually doing "serious games" jobs, where "we have custom tech" is still seen as an asset and not a liability... and we're managing to actually see some returns on it now. Plus it means that our game runs at 300fps on mid-range hardware...

Leadwerks because:

- By far the easiest 3D engine to use

- C++ when I need it Lua when I don't

- No royaltys!

- Good and helpful community

I'm working on my own: GitHub

I've built a cross platform rendering library that (currently) supports OpenGL, DirectX and Vulkan. Recently it was modernized so it supports features like command lists, pipeline states, GPU queues (async compute, upload) and even explicit multi-GPU.

I worked with the guy at the XShaderCompiler project to bring a unified shading language into the engine. Now all the code is HLSL (even for OpenGL/Vulkan) and I wrote some extensions to the language so full material definitions can be specified, as well as some helpful constructs for combining and mixing and matching shaders.

All the rendering in the engine is multi-threaded (which seems to be rare or non-existent in other open source solutions). I think I have a pretty clean, mostly automated design when it comes to it, making sure its easy and safe to work with.

I've put a lot of focus on making the codebase clean and modular so it is easy to understand and modify. Codebases like UE4 (if you dig deep down into the engine core, where the interesting stuff lives) look like hell to modify, and I wanted something tinkerers & low-level developers like me can easily dig into and modify/experiment with. It's also written from scratch (aside from third party libs) in modern C++14 (I'll also be moving to C++17 modules as soon as compiler/IDE support is better). 

I used to work with Unity a lot (~5 years) but it ended up being a nightmare for anything that's a slightly bigger project or when we tried to do something out of the box. Primarily because of its closed source nature, as we had to hack around various restrictions and bottlenecks (instead of just changing them at the source). 

Frustrations with Unity were actually the primary reason why I went with my own engine. I really enjoyed its editor (ease of use, iteration time and extensibility were top notch) and C# scripting but wanted something that is more powerful under the hood, and can be easily modified.

I'm currently working on a physically based renderer (80% done), and will be adding Mac & Linux ports (hopefully) by the end of the year. Engine still isn't ready for production use but I strongly believe it offers a better foundation than anything else out there (that I've seen), and hopefully I can grow the feature-set to compete as well.

I wish I had jumped in earlier because pretty much everything I wanted to say has already been said.  I tend to write my own engines, like some of the other posters here, because I've found that I'm more interested in writing game engines than I am in actually writing games.

Mind you, I haven't written an engine I'm comfortable sharing with other people yet... :-D  But I get joy out of writing engines (I also get a fair share of frustration and second-guessing myself).

Every time I go to learn a new engine (e.g., Unity), I get halfway through some tutorial for making a game, and then I can't help but think, "I don't need Unity (or xyz engine) do this" or "I don't like this part.. I bet I could write it differently (or better)."  That's partly caused by hubris--I think I'm more capable than I actually am.  But then, as I try to write my own engine, I discover that the functions that are built into mature engines, like Unity, have been researched, implemented, tested, and optimized by teams of professionals, while I am just one person...

...But then..... Through all the struggle and frustration, I actually do learn bits that I was missing, and I improve across many facets of programming, algorithms, optimization, etc.

That's my personal take on it.

Thanks for sharing this. As always, participation is relevant and interesting.

Despite of the fact that there is only few answers, we can easily see that game devs are shared in two categories: the one who are using existing publicly available engines (due to various facts) and the other category will tend to create their own engines (due also to various facts, but mostly by own interest than for creating games).

From your answers it seems money is not as important. But this is certainly not relevant due to the number of answers.

I'm also happy to have had an answer of someone not using one of the top engines, even if leadwerks is quite known now.

21 hours ago, Hodgman said:

where "we have custom tech" is still seen as an asset and not a liability

Can you clarify this please ? Does it mean end customers prefer custom tech, so you as a studio, this custom tech can be shown in the front page of your website not taking into account that you'll have to manage the customer service (bugs, lack of documentation, having to had new stuff...) ?

If you're doing work for other people, you have to manage the customer service anyway.   If I develop a game for the client using Unreal and there's a bug discovered later, I can't tell the client "talk to Epic about it". All I can hope for is that it gets fixed more quickly with an engine that more people are using.

43 minutes ago, _Silence_ said:

Can you clarify this please ? Does it mean end customers prefer custom tech, so you as a studio, this custom tech can be shown in the front page of your website not taking into account that you'll have to manage the customer service (bugs, lack of documentation, having to had new stuff...) ?

Just when you talk to people, they're impressed that you own the entire stack and see it as adding value to your company. It also makes licensing discussions easier. This isn't really dealing with end users as customers, but other business who need a specific tool developed for them (to either use internally, or on-sell to end users).

Games execs on the other hand will see this as a massive unnecessary risk, and you'll have to thoroughly explain why you've taken that risk upon yourself and prove yourself repeatedly. 

Thank you. This is very appreciated.

On 6/29/2017 at 9:03 AM, BearishSun said:

I'm working on my own: GitHub

I've built a cross platform rendering library that (currently) supports OpenGL, DirectX and Vulkan. Recently it was modernized so it supports features like command lists, pipeline states, GPU queues (async compute, upload) and even explicit multi-GPU.

I worked with the guy at the XShaderCompiler project to bring a unified shading language into the engine. Now all the code is HLSL (even for OpenGL/Vulkan) and I wrote some extensions to the language so full material definitions can be specified, as well as some helpful constructs for combining and mixing and matching shaders.

All the rendering in the engine is multi-threaded (which seems to be rare or non-existent in other open source solutions). I think I have a pretty clean, mostly automated design when it comes to it, making sure its easy and safe to work with.

I've put a lot of focus on making the codebase clean and modular so it is easy to understand and modify. Codebases like UE4 (if you dig deep down into the engine core, where the interesting stuff lives) look like hell to modify, and I wanted something tinkerers & low-level developers like me can easily dig into and modify/experiment with. It's also written from scratch (aside from third party libs) in modern C++14 (I'll also be moving to C++17 modules as soon as compiler/IDE support is better). 

I used to work with Unity a lot (~5 years) but it ended up being a nightmare for anything that's a slightly bigger project or when we tried to do something out of the box. Primarily because of its closed source nature, as we had to hack around various restrictions and bottlenecks (instead of just changing them at the source). 

Frustrations with Unity were actually the primary reason why I went with my own engine. I really enjoyed its editor (ease of use, iteration time and extensibility were top notch) and C# scripting but wanted something that is more powerful under the hood, and can be easily modified.

I'm currently working on a physically based renderer (80% done), and will be adding Mac & Linux ports (hopefully) by the end of the year. Engine still isn't ready for production use but I strongly believe it offers a better foundation than anything else out there (that I've seen), and hopefully I can grow the feature-set to compete as well.

I'm looking to ditch Unity as well, but only in the future when my current game is either finished or abandoned.  I'll be checking out your engine later, thanks for sharing