Зізнаюся, я зробив гріх надмірним зловживанням і навіть зловживанням спадщиною. Перший (текстовий) ігровий проект, який я зробив, коли я проходив курс OOP, йшов аж до «Замкнутих дверей» та «Відчинених дверей» від «Двері» та «Кімнати з одними дверима», «Кімнати з двома дверима» та так з "Кімнати".
З (графічною) грою, над якою я нещодавно працював, я думав, що засвоїв свій урок і поставив обмеження на використання спадщини. Однак я помітив проблеми, які незабаром починають з’являтися. Мій кореневий клас почав все більше розквітати, а мої листові класи були повні повторюваних кодів.
Я думав, що все ще роблю не так, і, переглянувши його в Інтернеті, я виявив, що я не єдиний із цією проблемою. Так я закінчив відкрити системи Entity після ретельного дослідження (читайте: googlefu)
Коли я почав читати це, я зміг зрозуміти, наскільки чітко він міг вирішити проблеми, що виникають у мене з традиційною ієрархією ООП з компонентами. Однак вони були в перших читаннях. Коли я натрапив на більш… “радикальні” підходи до ES, як, наприклад, на T-машині .
Я почав не погоджуватися з методами, якими вони користуються. Чиста складова система здавалася або непосильною, а точніше, неінтуїтивною, що, мабуть, є силою ООП. Автор іде так далеко, що стверджує, що система ЕС є протилежною OOP, і хоча вона може бути корисною для OOP, вона насправді не повинна. Я не кажу, що це неправильно, але я просто не відчував рішення, яке хотів би здійснити.
Тож для мене, і вирішити проблеми, які у мене виникли на початку посади, не суперечивши моїм інтуїціям, це все-таки використовувати ієрархію, однак це не буде монолітною ієрархією, як ті, що я використовував раніше, а швидше полілітичний (я не міг знайти слово, протилежне монолітному), який складається з декількох менших дерев.
Наступний приклад показує, що я маю на увазі (це натхнене прикладом, який я знайшов в «Ігровій архітектурі», глава 14).
Я мав би маленьке дерево для транспортних засобів. Кореневий клас транспортного засобу мав би компонент відтворення, компонент зіткнення, компонент позиції тощо.
Тоді танк, підклас транспортного засобу успадкував би ці компоненти від нього і отримав би його власний "гарматний" компонент.
Те саме стосується персонажів. У персонажа є його власні компоненти, тоді Клас гравця успадкував би його та отримав контролер Input, а інші класи ворога успадкують від класу Character та отримають контролер AI.
Я не бачу жодних проблем з цим дизайном. Незважаючи на те, що не використовується чиста система управління суттю Entity, проблема з ефектом пухирчастого ефекту, і великий клас коренів вирішується за допомогою ієрархії багатьох дерев, і проблема важкого дублювання листя коду відсутня, оскільки листя не мають будь-який код для початку, просто компоненти. Якщо потрібно змінити рівень аркуша, то це так само просто, як змінити один компонент, а не копіювати скріплення коду скрізь.
Звичайно, будучи таким же недосвідченим, як я не бачив жодних проблем, коли вперше почав використовувати єдину ієрархію, важку модель спадкування, тому, якщо є проблеми з моделлю, яку я зараз думаю реалізувати, я б не став вміти його бачити.
Ваша думка?
PS: Я використовую Java, тому використання декількох успадкувань для реалізації цього замість звичайних компонентів неможливо.
PPS: Інтеркомпонентні комунікації здійснюватимуться шляхом з'єднання залежних компонентів один з одним. Це призведе до з’єднання, але я думаю, що це нормально.