I hadn't heard that CD Projekt Red managed to do such a thing, I'll have to look into it and maybe adjust my position.
The main part I think isn't actually the tools, it's the "framework" side of things. Writing all the really low-level stuff that the other features need to run on top of - thread-friendly containers, job systems, an abstraction layer for the renderer, etc - and giving them a good interface that you can really rely on to build the other low-level stuff, is big work.
You can speed things along by buying physics, audio, maths libraries as middleware, but if you're buying middleware (and I pray you're getting full source licenses for it), why not buy a bunch of it that you know will work together, i.e. an engine? As an example, integrating Scaleform into an engine can be time-consuming as they provide you with a set of example shaders, but you're expected to customise them to match your actual rendering pipeline. CryEngine comes with that work already done, as I expect most other Scaleform-supporting engines do. I think overall, the middleware-gluing approach gives you some benefits in being able to pick and choose what you get, and navigate around things that you think are bad news, but it comes at the cost of having to do the integration, and at the risk of not spotting that one piece of middleware really pushes you towards one paradigm, while another can only run efficiently if it's talked to in a totally different way.
Don't get me wrong though. I agree with you that CryEngine was the "optimal" choice at the time of kickstarter.
Both solutions carry a roughly equal risk I feel, I'd be biased towards the "new tech" choice as I had some limited experience building very rudimentary (but functional

) 3D networked game engine frameworks myself in second year.
As I believe you've mentioned, the main advantages of a custom engine would be:
a) Flexibility, a good framework can be super modular.
b) Once you're done building it, your engine team literally knows almost everything there is to know about your tech and tools.
An engine package is more rigid and opaque I feel, even with full source access. On the flip side, these qualities do make problems more predictable and therefore frequenty easier to solve, provided you have dev support on hotline.
It would be a pretty massive task, but I'm not sure if it'd have taken much more time and effort than the amount of work that's been put into modifying CryEngine.
For the project itself... it really is a "hindsight 20/20" scenario. I think a significant chunk of the hurdles you guys have to overcome (mostly physics/precision and networking) could've been somewhat mitigated going custom tech "from scratch".
At the same time, building a networking architecture from the ground up is equally daunting and carries a great amont of risk in and of itself. (Networking would personally be my main concern for this project, the framework is tricky but imo it's really all about planning it properly with the right levels of abstraction.)
In the end for Star Citizen, this is what you guys went with and I'll be interested to see how it pans out. I for one would love to read a full post-mortem review about this project without all the dramatisation

Until then, we can forever speculate how it would've been in alternate realities.
If you/anyone wants to see the CDPR lecture, I can send it in PM. (Doubt the mods will like to have it posted here since it's not really SC related)
DLewth said:
so whilst I'm not convinced Cryengine was the best choice, using something that already exists probably was.
Honestly, if you look at the timeframe I really do agree that CryEngine was as good as anything they could've gotten for this project.
Every other engine would've generated the same issues, while being far less mature at the time of kickstarter, and without the prospect of having ex-devs of said engine working on your team.
