[qalmakka]

UE looks cool, it's full of features, but it's also full of warts (especially when you realize how poorly designed and implemented certain parts are, and the huge mess they made with their C++). My major issue with blueprints is that they are always abused and turn into an unmaintainable mess in the blink of an eye.

The company I work at has a massive UE-base codebase and we've been working hard for months to purge as much blueprint logic from our it as we can because it's simply impossible to maintain them. Epic is pushing them hard but I just can't see them as more than a way for amateurs to mock up stuff.

[abraxas]

Yeah, after my initial honeymoon I'm souring on blueprints fast. Working with them on a team using version control must be a bit of a nightmare. Not having a way to export them into a human usable formal (say a good quality Lua style DSL) means excluding all kinds of tooling that could be built by other parties for handling text based code.

[qalmakka]

What UE sorely lacks is a good scripting language. It's clear to me that Tim Sweeney wanted to offer a C#-like experience, but using C++ - IMHO UE failed in any possible way to accomplish that - Epic made a sawed-off shotgun in place of a precision weapon. There are just a gazillion ways to introduce concurrency and memory issues in UE, but most of the time it's "fine" because for a videogame some aspects (like proper memory management, safety, ...) are less important than CPU cycles. A game often behaves as if it's the only application running on a machine, and if it gobbles too much RAM the usual answer the developer gives its users is, "buy more". Thankfully this has been changing in the last few years due to mobile gaming and freemium, which forces companies to target not top-notch machines but cheap laptops.