I am on the verge of finishing university and I haven't really made any projects even though I am programming almost every day.

3 moths ago I decided to start a project that I will actually finish. It will be a coop game. I started in Ue4 and I think it is a really great engine but my project is starting to get bigger and bigger and my iteration times are decreasing rapidly. I have around 140 files and my compile times are getting worse every day. A simple change in my Character.h will result in a 100 sec build time. I am already managing all my header files by myself and I decided not to use the unity build feature but it is still not great.

To be fair this is the worst scenario because my Character.h has 27 dependencies but it is also the file where I am currently spending the most time. All files are on an SSD. I really don't enjoy working on the project anymore.

I think I really want to move away from C++. I know that there is Mono for Ue4 but it doesn't seem to be a very active project. I think if I want something like C# or D in Ue4 I would have to maintain the bindings by myself and I am not sure if that is what I want to work on right now.

So I am thinking of switching to Unity. But Unity comes with its own problems. The built in networking seems to be very bad and Unity is actually working on a new networking implementation called "UNET" which is already available in the 5.1 beta. But the beta access is limited to pro users which cost $1500 or 12 month * $75 which is too heavy for a student just to get beta access. Then there is something called boltengine which seems pretty neat but it is maintained by one person and it is still in beta and costs $80. Overall Unity feels pretty bare bones compared to Ue4 but programming is actually pretty fun, everything compiles instantly and errors don't crash the editor (at least not yet).

I am not sure what I should do. Am I crazy for wanting to switch from Ue4 to Unity?

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

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.

However, as Radikalizm (cool name!) said: 2 minutes is nothing. You are blessed. ;)

Unity's build time is deceptive since you're not really compiling to machine code at all. Not a .NET wizard, but it gets compiled at least once more at runtime.

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

Just to be clear, we are talking about incremental builds right? I usually program with some sort of REPL where I hit the compile button several times are minute. I probably have to lose that habit when I code in C++.

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.

However, as Radikalizm (cool name!) said: 2 minutes is nothing. You are blessed. ;)

Unity's build time is deceptive since you're not really compiling to machine code at all. Not a .NET wizard, but it gets compiled at least once more at runtime.

But it's jit'ed so you won't notice the "second" compile time. And if you do a release build I think Unity converts the the IL code to C++. I think they call it IL2CPP not sure if it is already live though.

But it's jit'ed so you won't notice the "second" compile time.

Yeah, I know. Initially, it was noticeably slower by quite a bit, but not nowadays.

And if you do a release build I think Unity converts the the IL code to C++. I think they call it IL2CPP not sure if it is already live though.

That would be really cool if they did. Wonder how that compares to code written for C++ in the first place?

I think the deciding factor really should be what language/environment that you feel most at ease with.
2 minutes of compile-time is really not an issue when working with such a complex C++ beast as Unreal. Be glad that you are not working on larger projects..

Sounds like you need to learn how to architect C++ code to manage dependencies better. The bible for this is:
http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

I second Hodgman -- at least until it gets modules, 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, first and foremost by reducing dependencies between code modules. Be mindful that in C and c++ headers are included by text substitution -- that header is not processed once and then referenced by files that include it, when you make a change, dependent files are recompiled with all their headers pasted inline, and then--since they've changed now--any of their dependents are also recompiled with all their headers pasted inline; and so on and so forth until the cascade ceases.

Taking a WAG (Wild-Ass Guess) based solely on the filename, it sounds like maybe your character.h has a common base-class for a character heirarchy, which is probably inherited by subsequent many other classes in layers of said hierarchy. In Java or C# that is a normalized pattern, but in C++ it would be an anti-pattern. Or, perhaps you're just putting too much new stuff in what should be a pretty stable file by now, if its got 27 dependencies.

Hodgman -- That book is nearly 20 years old. Has nothing better, or at least as good but newer, been written in the interim? I'm all for golden oldies, but has the state of affairs really not changed in so long? Probably at least the firewall-patterns like pImpl would be made better by modern novelties like unique_ptr, and there must be more to be made better.

So, to answer my own question, it appears that John Lakos himself has started to address the interim dearth of books on C++ design at scale, with the first of a three-part series -- unfortunately, it won't be until July of 2016 before its out. I got excited when his own reading list suggested that it had already been slated for 2014 but there must have been a delay.

Amazon link for the patient: http://www.amazon.com/Large-Scale-Volume-Architecture-Addison-Wesley-Professional/dp/0201717069

Just a minor point, but UE's quick iteration 'thing' is Blueprints - while prototyping and playing with ideas they are pretty much the right way to go. If you need to later when things are nailed down you can transition them to C++.

Well I am following Ue4 guidelines. I started with the ShooterGame example which already had around 70 header files.

They create a file called something like MyGameClasses.h which contains every header file from your project. Then they put this header file in MyGame.h and MyGame.h needs to be in every file that you create.

Note that MyGameClasses.h is auto generated from their build tools. Then they use something called a unity build where they put everything in one file and then hit compile.

I ripped everything apart and I am managing my headers now manually with proper forwarding etc and I turned the unity build off. Also they have a tool that parses every header file to generate the necessary reflection code which also needs some time to run. I have also put most header files in the .cpp files so that I can avoid an additional header parse.

Now I am pretty sure I can optimize the build times a bit more because it took me 3 hours to go over every file and fix the dependencies and I probably have done a few mistakes but I don't think that there are any low hanging fruits.

For the architecture I don't think I have too much freedom If I want to use unreals gameplay framework. But I still don't know why it has 27 dependencies, at least I can not find that much. I think it has something to do with their build tool and the way they generate the reflection code. I should investigate further.

I also do not want to use blueprint, I am not a big fan of visual scripting, also the blueprint system comes with its own problems.

I am thinking about integrating D or C# but I am not sure how much work that would require and I really have no experience with this kind of stuff.