Ответ Джоша потрясающий, но я хотел бы добавить:
Одна из самых крутых функций Entity / Component - это управляемый данными способ создания и управления каждой «вещью» в вашей игре. Из того, что я видел, когда у вас есть хорошая библиотека типов компонентов и систем, вы можете создавать практически все с минимальными изменениями кода. (Примечание: минимальный! = 0 )
Определяя свою игру с точки зрения поведения и давая себе возможность изменять эти поведения на лету - во время выполнения, во время инициализации путем загрузки их из сценария или базы данных и т. Д. - вы открываете целый мир новых возможностей. Хотите понять, почему ваши тени не приземляются там, где вы ожидаете? Добавьте камеру / POV компонент к вашему свету.
Сущность / компонент позволяет создавать все, что вы хотите, если вы создали блоки.
Кроме того, множественное наследование вызывает ту же проблему, что и одиночное наследование. Когда вы добавляете атрибут или поведение в иерархию, он распространяется. Пока вы создаете глубокие иерархии, вы будете сталкиваться с ситуациями, когда вы несете ненужный вес, дублируете код или разрешаете конфликты. Большего из этого можно избежать, когда вы представляете свою игру как данные.
Я только начал играть с этим в последние несколько недель, но я впечатлен тем, как простые вещи стали. Это не серебряная пуля - я сталкивался с несколькими случаями, когда присоединение лямбды к компоненту было самым чистым и наиболее целесообразным способом решения проблемы - но это довольно хороший пример, если вы можете так его назвать.
Слегка примечательно: один из больших, скучных генераторов обслуживания в ориентированных на данные приложениях (веб-сайты и т. Д.) Отображает иерархические объекты в реляционные базы данных. У нас есть много изящных решений, но в конечном итоге все они предназначены для сглаживания иерархий. Вместо того чтобы строить свою модель так, чтобы она соответствовала цели приложения, вы попадаете на компромисс между эффективной иерархией и логическим реляционным представлением. Я возился с идеей перестроить довольно большую иерархию в одном из моих приложений как систему сущностей / компонентов - отказаться от иерархии и сделать базу данных золотым стандартом для остальной части реализации - и это многообещающе.
Когда вы интегрируете такие возможности, как динамическое генерирование кода / кэширование кода, которые могут решать проблемы с производительностью, вы получаете быструю, гибкую, логическую архитектуру, которая может просто реализовать цель многократного использования кода ООП намного, намного лучше.