The problems of overly-complex object trees is inherent in OO languages of all flavors. There was a fairly famous book on the subject back in the 90s regarding C++, and I think that the problem has a name, though I currently forget what it is. VB6 has a different, but related, problem where global variables can tie disparate routines into a total spaghetti mess (except that spaghetti is easier to untangle). Both problems are a result of poor or misguided practices, though the practices are somewhat different.

I liked the wumpus-hunt reference. I have a link to an online version of the old Hunt the Wumpus game on my system at home. It's an oddly easy game. I don't remember it being so easy when I was young, but I may not have been quite as logical in my approach.

@FD: I'm not sure that is true. In the 90s, there was a fair amount of discussion as to how you had to use C over C++ for cutting edge games because the added cost of OO was too much to bear. Compiler developers focused on this issue for several years, and by the time the first ANSI standard was coming out, it was generally held that the operating cost of OO had been reduced to 0 or near enough to 0 that even the cycle counters didn't seem to care anymore. After all, functions don't get replicated with each instance of an object, they only exist in memory once, and they are generally all loaded somewhere when the app starts. That leaves only data members, and those may be nearly the same for procedural languages. There was a cost for OO, I'm just not sure that it exists anymore.