It's more difficult to regret something that doesn't exist. Have you regretted running out of time to implement all the features you would have liked to get in? I understand why it's improved in a general sense, to support multiple objects. My contention is, to use an analogy - you don't use gold plated terminals, when copper terminals will do.
Perhaps it's easiest to put it this way: I have never regretted having written a class in such a way that it could have more than one instance; on the other hand, I regularly suffer from classes that were [incorrectly] designed to only have one instance.
Care to elaborate, with a bit of context?
had a bit of a laugh seeing all the globals and #defines in there
Yes, there's nothing wrong with globals or defines. They're preferred way of representing certain data.
That's not why "globals are bad".
You think improved OO design would have helped achieve this?Maybe they could make a game that wouldn't be forgettable 2 minutes after launch.
would cryengine be a better product had it been developed using software design best practices
But making a game with a game engine was never their priority, it's just a tech demo and it wins in that category.
That's really my point, it's about priorities. The code was effective as assessed against the dominant metric.
Yes, though you will need to provide some quotes to illustrate what you mean by that, because I don't believe believe anyone has posted anything (even remotely) to this effect.
why everything has to be a black and white/all or nothing proposition.
Such as why there can't anything be possibly wrong with global references?
I've never seen any large scale pure C projects, though I imagine there's quite a bit of global data passed about (I could be totally wrong, somewhat liberal assumption on my part). Where I'm heading with this though, is do you consider all pure C projects to be rubbish, on the basis they don't follow modern OO principles?