3 ms·

I find point 3 (OOP Rules) an interesting conclusion. It seems like there is a greater push towards data driven game development and component based entity syst

I find point 3 (OOP Rules) an interesting conclusion. It seems like there is a greater push towards data driven game development and component based entity systems that have a more functional or procedural feel than OOP. It seems that people are moving towards a set up where the processing is handled by globally available managers and GameObjects are instead contained across multiple Component types. That's not to say you can't build an component based system in an OOP language of course.

chipsy 16y ago
OOP(in the hierarchical sense) is heavily blunted by the need for global mutable state in games. The game design often turns out to need to access anything, anywhere, at any time, so the natural move is towards a model more reminiscent of a relational database, with lots of indexing and denormalization. Subsequently the job of implementing game design is reduced to a lot of query statements; most of them are collision or "is-a" categorizations. At the same time, there's some pressure to serialize large parts of the game, if possible, for two reasons - save games, and editing tools. This further encourages a more formal relational-type system(leading to the entity/component distinction), since a setup based around unstructured pointers is harder to cleanly serialize.