Hacker News new | past | comments | ask | show | jobs | submit login

In addition to the other fine replies: As a game gets bigger and more complicated, you'll often find that the direct mutable OO approach becomes an antipattern at scale.

Do you have anything that you want to do, but discover halfway through for some reason it's not legal? Good luck undoing what was half done. Of course you might think the simple answer is "don't do that", but as the game gets bigger and responsibilities get spread out between all the objects it becomes increasingly easy for some action to become possible that requires a lot of checking, and if things are just willy-nilly mutating themselves the odds of you encountering this sort of problem skyrocket. And that's just one example... games by their nature resist the sort of decomposition that most "real" software can have done on it, because as soon as you tell a designer that X can't talk to Y, by golly they'll start thinking about how awesome it would be if X was talking to Y. You don't get a pretty tree of relationships with occasional crosstalk, you get a nasty snarl of communication patterns, irreducibly.

Many games end up functional under the hood anyhow, with a clearly-defined loop:

    1. Ask all the objects in the world what they "want" to do.
    2. Validate and resolve conflicts.
    3. Render the new world state.
One of OO's big problems in general is lack of control over the profound, often-overpowerful effects of mutation, and used in an undisciplined manner, games often turn into a worst-case-scenario for OO. And most of using them in a "disciplined" manner turns out to be using "FP" techniques to keep the complexity under control.

Of course nothing stops you from doing that in OO, with discipline and care unenforced by the compiler. But what it does mean is that suddenly the "mismatch" that you're referring to disappears, and one starts wondering whether perhaps FP is the better match for games and OO the accident of history.




I might also point out that OO and FP are not strictly at odds. You can use object libraries in FP languages to encapsulate the state and logic but avoid the mutation of the state.

So if the two issues are orthogonal then you're both right. :-)


Good point. So if I use OO while maintaining immutability then am I doing functional programming, OO or both?


At the risk of going really philosophical, in the end words are just words, and your program is what it is. Given the vast, vast, vast space of possible programs it should come as no surprise that little tiny English words are hardly up to the task of completely rigidly classifying them. Especially programs, which are quite literally the most perverse mathematical constructs known to man, courtesy of the Church-Turing thesis.


> You can use object libraries in FP languages to encapsulate the state and logic but avoid the mutation of the state.

Where is the OO in that approach? The encapsulation?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: