I would add an anti-pattern in contrary to that: engine duct-taping.
There might be a specific solution in the engine for a problem, or in the underlying library/graphics API, which a developer could make use of/could unlock. But the level/game designers chose to build solutions on top of high-level engine features, which leads to poor performance, bugs, glitches and unwanted side effects.
Also any custom work to an engine where you still want to pull updates. I think on one project it would take one poor person two weeks to merge a new version of UE3.
UE4 has been around for almost 8 years at this point; There must be vanishingly small amounts of games still using UE3 in active development (cough _Rocket League_ cough). The upgrade path for UE4 releases is pretty straightforward these days - on my current project it's a half a day for one person to upgrade a major engine version and most of that is just syncing from empty to make sure everything works. We've gone from 4.25 to 4.26 to 4.27 with pretty much no pain points.
(disclaimer: I used to work for Epic as a developer, but my experience above is from my time since.)
These days for many projects it’s more about how much the underlying features you’re using have changed.
Either way if you’re using an engine and have extensively modified it upgrading is always going to be a pain. It’s just there is less call to now.
From Epic's side, UE at this stage is pretty customisable even without modifying engine source directly. You _can_ modify the source, but it's not a requirement to make a game in UE these days; much of what you needed to modify the engine for can be done with plugins or just straight up in game code.
> These days for many projects it’s more about how much the underlying features you’re using have changed.
Yeah, definitely this. Epic in particular have also become more mindful about not pulling the rug out from under you (although it does still occasionally happen)