MVC (Model-View-Controller) Архітектура ігрового двигуна - так чи ні? [зачинено]

Я читаю одну чудову книгу « Кодування ігор завершено» , і ця книга настійно рекомендує використовувати підхід MVC (Model-View-Controller) з трьома ключовими шарами:

1. Шар додатків для ігор
2. Логіка гри
3. Перегляд гри

Мені такий підхід виглядає як надмірне значення для мобільної комп’ютерної гри.

Яка ваша думка, будь ласка? Чи варто реалізовувати цю архітектуру, навіть якщо вона додає додаткову комунікацію, необхідну між модулями? Чи може ця конструкція споживати стільки потужності процесора, що, врешті-решт, результат буде значно повільнішим, ніж якби він не був реалізований?

Я дещо підтримую використання структури MVC навіть для простої мобільної гри. Якщо нічого іншого, це допомагає з проблемою, яка набридає розробникам, які не вкусили її достатньо разів: відокремлюючи код відображення від логіки гри.

Я також скажу, що потрібно пам’ятати, що MVC, як і всі шаблони дизайну, існує, щоб полегшити ваше життя . Це означає, що якщо в будь-який момент часу перебування в якомусь наборі правил щодо того, що слід і чого не слід робити, коли користуватися MVC, ускладнює ваше життя, ігноруйте це . Відбудеться одна з двох речей: 1) вас покусають пізніше, і тоді ви зрозумієте, чому це робити по-іншому, в першу чергу, насправді полегшило б ваше життя в перспективі, або 2) жодних наслідків.

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

Конструкції часу компіляції не споживають процесорної потужності, якщо у вас є неймовірно безглуздий компілятор. Об'єктно-орієнтована мова або підхід не відрізняється за характеристиками виконання, ніж процедурна. Ви не користуватиметесь додатковими накладними витратами на використання MVC. Модульність існує в час компіляції, а не під час виконання, коли код вкладений та оптимізований, він взагалі не матиме ніякої різниці.

Багато сучасних ігор реально керують моделями та переглядами окремих розділів і отримують великі переваги від продуктивності на більшості платформ.

В кінцевому рахунку, MVC хороший дизайн , який отримує ви збільшили зміст і менше помилок і т.д. для безкоштовно . Немає причин не використовувати його. Це як запитати, чому ви повинні використовувати forцикл замість рукописних gotos. Якщо ви не маєте вищого дизайну на увазі, це, звичайно, краще, ніж нічого.

Редагувати: Конструкції часу компіляції не споживають енергії процесора. Очевидно, такі проекти, як виконання, як спадкування.

Майже завжди існує компроміс між чіткістю коду та технічними вимогами (швидкістю, пам'яттю тощо) програми. Об'єктно-орієнтовані мови мають накладні витрати порівняно з процедурними мовами, але, як було показано, вони мають багато переваг перед процедурними мовами, особливо при тривалому підтримці коду (помилки тощо), а також часто і швидкості розвитку.

Отже, маючи на увазі, я пропоную, що MVC варто реалізовувати заради вас як ігрового програміста . Ваш код буде краще дотримуватися об'єктно-орієнтованих принципів, особливо інкапсуляції , і ви, швидше за все, матимете набагато простіший час його збереження (виправлення помилок або додавання нових функцій).

З іншого боку, переконайтеся, що насправді закінчите гру і не витрачаєте стільки часу на роботу над «двигуном», щоб це ніколи не було зроблено.

Для отримання додаткової інформації, будь ласка, прочитайте питання "Чому MVC & TDD більше не використовуються в архітектурі ігор?" і моя справді довга відповідь.