I've found programs (games) powered by Unreal to be much more responsive and less buggy than comparable games made with Unity.
I could be wrong - just a feeling.

This could be because *a lot* of hobby developers use unity. There are some really nice and/or complex games done in unity. Cities: Skylines, Crossy road, the quest keeper, besiege, the forest, stranded deep, rust, etc...

A simple change in my Character.h will result in a 100 sec build time.

Honestly, 100 seconds is nothing to complain about. Actually 100 seconds for a build is blazing fast compared to the stuff I have to deal with daily. You can barely get up, walk to the kitchen and pour yourself a cup of coffee in that time!

If you want to get stuff done stick with the tech you're familiar with. Switching your entire technology base just because you don't like to wait two minutes for a build is just insane.

EDIT:

Fun fact, while typing this post originally I was actually waiting for a build to complete. I can guarantee you it took longer than 100 seconds ;)

It is something to complain about, it's a matter of perspective, it's very fast as far as a C++ project is concerned but when you're used to instant build on C# (rebuilding whole mid size project rarely takes more than 1 or 2 seconds, instant if you're just building instead of rebuilding).

Changes the way you work pretty much hitting build every few lines because "it's free".

UE4 tends to take longer to compile than an ideal C++ setup would allow.

Their custom build tool is slow, and in general, the code is over coupled and skews toward the broken Java model of inheritance

It is possible to have very fast iteration in C++, but it requires a lot of stupid work that smarter languages do for you.

If you are just working on a hobby game, you might be better off doing most of it in Blueprints, or as you said, using a different engine.

What exactly are you changing so many times that the recompilation time (which is many magnitudes shorter for me) becomes a problem? If you're changing gameplay variables, these should be in blueprint and exposed to the editor to cut down on iteration time.

You could always try exporting some of the functionality into a library file (ie. a DLL file on Windows). That way you only have to recompile things that change in the main project.

C++ compile times are necessarily longer than they ought to be (longer than comparably complex code in more modern languages by orders of magnitude). This is unfortunate, but there are steps you can take to reduce compile times

Much of those costs are also the source of the strengths. I don't think it is "longer than they ought to be". Yes, it takes more time, but that is a cost paid for an actual benefit.

The performance killers are well documented. Opening up every #include is time consuming, and features like template expansion cause compilation time to grow rapidly. However, the benefits from those compilation costs can be amazing.

One of the strongest features of the language is that the compiler digs deeply into every function and searches for things to elide and eliminate, nested calls to inline, code to relocate and merge, and evaluate an enormous number of potential substitutions in order to save a few nanoseconds at runtime. Trying to do the same thing with more modern languages, the deeply-nested call trees that ultimately resolve to a single data read, the logic that in some builds vanishes completely, these are opposite of the modern language functionality. It is possible to get some of that benefit with JIT compilation and hotspot analysis done at run time, but that moves the cost to a different time that is often unacceptable in games. Sure it is fine if one of the load-balanced business servers in a server rack slows down for a moment for a hotspot optimization, not so much if the game stutters.

The compilation model used by C and C++ and several other older languages include features that are completely at odds with features in more modern languages. You cannot perform the heavy optimizations, the heavy stripping of dead code, extracting logic from common classes or from deeply-inlined calls, the complete removal of unused logic and functions, while at the same pulling in features like complete reflection of classes.

So yes, the compilation times can be much faster in modern languages. For fast iteration that is a good thing. But since games are still pushing computers to their limits, there are many times when those extra compile times provide major benefits that cannot be recouped in modern languages.

It is a tradeoff. Use the right tools.

The same for switching from ue4 to unity. They are similar tools, but they have differences. If one is a better fit for the project at hand, use that one.

Are you already using multi-CPU compilation? Incremental builds? Pre-compiled headers?

Your project is very small so that sounds a long time for a build on a modern PC to me.

You'll also achieve more by better planning of your code, that way you won't have to be changing your core headers all the time :)

C++ compile times are necessarily longer than they ought to be (longer than comparably complex code in more modern languages by orders of magnitude). This is unfortunate, but there are steps you can take to reduce compile times

Much of those costs are also the source of the strengths. I don't think it is "longer than they ought to be". Yes, it takes more time, but that is a cost paid for an actual benefit.

The performance killers are well documented. Opening up every #include is time consuming, and features like template expansion cause compilation time to grow rapidly. However, the benefits from those compilation costs can be amazing.

One of the strongest features of the language is that the compiler digs deeply into every function and searches for things to elide and eliminate, nested calls to inline, code to relocate and merge, and evaluate an enormous number of potential substitutions in order to save a few nanoseconds at runtime. Trying to do the same thing with more modern languages, the deeply-nested call trees that ultimately resolve to a single data read, the logic that in some builds vanishes completely, these are opposite of the modern language functionality. It is possible to get some of that benefit with JIT compilation and hotspot analysis done at run time, but that moves the cost to a different time that is often unacceptable in games. Sure it is fine if one of the load-balanced business servers in a server rack slows down for a moment for a hotspot optimization, not so much if the game stutters.

The compilation model used by C and C++ and several other older languages include features that are completely at odds with features in more modern languages. You cannot perform the heavy optimizations, the heavy stripping of dead code, extracting logic from common classes or from deeply-inlined calls, the complete removal of unused logic and functions, while at the same pulling in features like complete reflection of classes.

So yes, the compilation times can be much faster in modern languages. For fast iteration that is a good thing. But since games are still pushing computers to their limits, there are many times when those extra compile times provide major benefits that cannot be recouped in modern languages.

It is a tradeoff. Use the right tools.

The same for switching from ue4 to unity. They are similar tools, but they have differences. If one is a better fit for the project at hand, use that one.

This might interest you http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/