OK, so we can break this down into a couple of different questions/answers.
Why did you stop using CryEngine?
That is actually explained in my video here:
The TL;DW is that CE was constantly breaking their engine and IDE and it was becoming entirely too cumbersome to even try and develop on that platform.
Why don't you use Engine X instead of Unity? Engine X is clearly better/faster/shinier/easier/cheaper?
No. Engine X is not better. Specifically, everyone ALWAYS tells us to use Unreal Engine. Unreal is fantastic at small levels, FPS, and games designed around limited areas. When we started evaluating engines, Unity was already being used in several large world games and was being expanded by UT to handle even larger ones. UE was not, and had nothing noted on their roadmap to do so and since HoO revolves around a large world it was a clearly better choice. Since then, UE has started supporting larger worlds, but it still has several drawbacks and memory limitations. Unreal is still very limited in terms of the community. One of our criteria for choosing an engine was community support so we went to every game engine forum and asked similar questions. Essentially the UE forums were a response of 'pfshhh, you are dumb / we are smart /read the manual / go away'. It hasn't gotten a whole lot better since then. The next item we did was contacted the development teams for each engine directly. We sent emails to both UE and UT with the same types of questions and within hours we got a response from the team at UT with an answer and some helpful tips. We are still waiting for that UE email to get responded to.
Would Unreal work great for other projects? Sure. It is a stellar engine. Just not the right engine for HoO. We need flexible options to stream levels, stream assets, connect to multiple clients/servers over multiple methods. We also need a much faster development cycle engine and C++ is just not a fast code base to work with. C# in Unity has been a very fast and flexible language to use and has shortened the development cycle considerably over any of the C++ based engines.
Assets and examples are the last part that pushed Unity over the top in our selection process. We found free assets to make nearly every base component of the game from, and for small amounts of money we could purchase other components that fulfilled the other parts we needed. Purchasing assets makes for a much faster development cycle again, and that is always a good thing.
So, in short, UT fit the bill for the project and was the better fit.
- Graphics/lighting
- UT - PBR/PBL, easily good enough for what we want. Some limitations in static lighting, but can be worked around. Has quickly caught up with UE levels of detail.
- UE - PBR/PBL, extremely nice appearance, though has issues with dynamic lighting and large meshes
- Source code access
- UT - no, but we don't need it 99.999999% of the time. Any bugs are reported to Unity that releases a patch about 2-3 times a month that addresses them.
- UE - yes, but we don't want to constantly run our own source code as that branches us further from the core code and slows development time and makes for more bugs.
- Free and low cost assets
- UT - Tons of great tutorials and free assets. Lots of low cost assets on the store.
- UE - Not a lot of low cost assets. Store is still pretty barren.
- Community of other developers
- UT - Very helpful, lots of interaction between indie devs. Projects are more commonly scaled for indies so everyone helps each other.
- UE - Almost like a minefield. Can either be very helpful or nearly toxic. Projects tend to scale toward tightly knit teams rather than indies (slowly coming around though).
Anyhow, probably more than was asked for, but that is the basic process we went through. Mind you, we agonized for several weeks over the decision but it was sealed with the above factors taken into account and that we did two simultaneous projects with the same goals in mind with the Unity project being done in a matter of hours and the UE one about 1/3 of the way done in the same timeframe. Just the development cycle speed alone made it a better choice for an indie volunteer project.