Спадщина проти складу

Я заробляю гроші на C # Взагалі на цій мові я люблю розв’язувати все на високі небеса за допомогою інтерфейсів. Це добре допомагає мені в коді підприємства, але в написанні ігор на C # я вважаю, що прагну до спадкування через те, що я можу визначити деяку поведінку за замовчуванням для базових класів. Я відчуваю себе брудно, роблячи це, як ніби я не підкорююся якомусь архітектурному богу, який одного разу сказав "прихильник композиції над спадщиною". Я знаю, що це не чорно-біле, але я також відчуваю, що я можу використовувати інтерфейси трохи більше роботи і досягти приблизно того ж.

Що роблять інші люди? Чи є успадкування правильним підходом до ігор чи я повинен переробляти деякі інтерфейси?

Наслідування в іграх - це насправді одна з найгірших речей, яку ти можеш зробити - зокрема, стосовно юридичних осіб. Прочитайте це для чого. Склад над спадщиною переносить вас довгий шлях з іграми. Що стосується інших областей вашого двигуна, це насправді не має значення. Скажімо, наприклад, ви здійснюєте виклик у якусь послугу зовнішньої мережі, тоді ви можете успадкувати один загальний тип сервісу, наприклад. HTTPService і SocketService - дуже багато, як у корпоративних додатках, до яких ви звикли.

Якщо ваша гра не дуже просто, ви будете хотіти використовувати суті (CBE) архітектуру на основі компонентів. Загальна думка полягає в тому, що в сутностях причина, чому вони так складені, а не успадковується, тому що ви не можете до часу виконання часу знати, які можливості даної сутності матимуть. Наприклад, візьміть корабель гравця в космічному шутрі. Ви не знаєте до певного моменту ігрового процесу, яку зброю, броню, системи (тобто компоненти), який гравець збирає забрати, придбати, продати, програти, знищити і т. Д. Тож єдиний реалістичний спосіб моделювати це через об’єктну композицію. Плюсом цього сценарію є те, що у вас також можуть бути повністю настроювані вороги, побудовані однаково, а не вороги, які завжди однакові щоразу, коли ви бачите цього типу ворога. Так що з CBE, ви можете побачити марсіанський вантажник і подумати: "А, у нього є лише крихітні лазери, я зніму його", і зазвичай це було б правдою, але коли раптом потрапляєш у діапазон, то розумієш, що у нього є велика дупа червоточний пістолет. Сюрприз сюрприз!

Компонентизація - це усунення неявного зв’язку логіки, і це добре.

Для тих, хто говорить німецькою мовою, цікава книга: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Детальніше про те, коли і навіщо використовувати архітектуру, можна знайти тут: /programming/1901251/component-based-game-engine-design

Для себе я вирішую свою архітектуру залежно від розміру проекту та можливості розширення чи повторного використання коду. Навіщо вкладати години та години в архітектуру мікропроекту, коли немає шансу знову використовувати код? У той же час ви можете закінчити проект.

Композиція проти компонентів Компоненти - це чудові фантазії, але в більшості проектів / архітектур композиція також виконуватиме роботу (без накладних витрат на основі компонентів). Це залежить від того, що ваша компонентна система може забезпечити, що композиція не може.

Наприклад, візьміть корабель гравця в космічному шутрі. Ви не знаєте до певного моменту ігрового процесу, яку зброю, броню, системи (тобто компоненти), який гравець збирає забрати, придбати, продати, програти, знищити і т. Д. Тож єдиний реалістичний спосіб моделювати це через об’єктну композицію.

все, що було можливо без компонентів і давно