As someone who works in games, I should point out that the industry has rejected the hierarchical OO model in new engines because it doesn't remain maintainable

As someone who works in games, I should point out that the industry has rejected the hierarchical OO model in new engines because it doesn't remain maintainable at scale. The influence that is driving the new stuff - component systems and composable entities - can be seen as derivative of the actor model. Actor models go beyond what is present in most game engines, which tend to stay well on the imperative side of the line. It takes a heavy dose of purity to grok actors in full, but it dovetails well with functional style as an alternative view of computation. (I also recommend the Tim Sweeney POPL06 "Next Mainstream Language" talk to see exactly what problems are motivating the changes) First, aim to never store values on objects - prefer instead listeners that return values independent of the objects themselves. Suddenly you start to enjoy "code=data" just as in Lisp, because the semantics of getting data and processing data are identical and interchangeable - you can take a getter on one object and copy it to a different one, and they'll return the same data, even if their other methods are completely unrelated! Decoupling occurs naturally in such a system - instances can be as similar or different as desired. The usage of classes shackles these abilities into monolithic, heavily-coupled data structures again, which is the core point of difference from "OO" as we know it in industry. If you also stay purely asynchronous at all times, there is no longer a difference between "now" and "later" to the callee, so order-dependent operations can naturally transition from one-to-one mappings into arbitrary ordering and queuing. Pure asynchronicity was lost when actor-style systems first tried to enter industry(e.g. Smalltalk-80 opted for a synchonous system - a concession to single-threaded performance), but it's come back into vogue in this heavily-parallelized era. Fortuitously, it's straightforward to achieve these properties in languages that support closures and reflection. And you don't have to write entirely in this style; raw data structures can be written imperatively, and then tied together using actors. The listeners can access a common database to look up values. You can mix and match. State-of-the-art game entity systems aim to cut down this level of power into a palette of performance/power options for composition, but if you can live with high overhead, taking all the power is pretty simple to do. I wrote a prototype for it yesterday - 169 lines of Haxe.