MVC-подібна поділка в іграх? [зачинено]

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

Це дозволить мені швидко прообразувати щось з простим текстовим інтерфейсом, а потім перейти до цього. Це також дозволило б мені легше перенести гру в інші ЗМІ.

Чи поширений такий вид розділення в іграх? Чи варто спробувати все далі розбити? Чи можуть виникнути ускладнення, які мені можуть бути відсутні

Настільна гра - хороший приклад гри, яку можна зробити за допомогою MVC, оскільки логіка (модель) гри існує досить незалежно від візуальних засобів (виду). Однак якщо ви розглядаєте таку гру, як Gears of War, геометрія 3D-моделей невід'ємна у логіці гри, тому відокремлювати вигляд так, ніби воно було незмінним, стає безглуздим. Unity3D - чудовий приклад більш специфічного для гри способу організації коду. У вас є базовий клас сутностей, до якого ви додаєте функціональність з компонентами, де один компонент може обробляти малюнок сутності, одна логіка гри ручки тощо.

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

Моє взяти на це:

• У моделі лежить більшість даних і відбувається вся логіка.
  Він читає чергу вхідних подій і відповідно змінює ігровий стан.
  Потім обробляє такі речі, як фізика та інші основні компоненти, які також оновлюють ігровий стан.
  Петля. Це все.
  Мета полягає в тому, щоб зробити модель незалежною: вона не має ніякої залежності від вигляду або речей контролера: ви повинні мати можливість зробити програму, яка працює лише за моделлю.
• Вид просто читає гру стан моделі, оновлює свої власні компоненти , присвячені уявлення даних, а також відображати речі на екрані.
  Він ніколи нічого не пише на моделі, це лише процес читання, за винятком, можливо, реєстрації якогось обробника подій (наприклад, "Hey Mister Model, коли ви виявите зіткнення між цими двома об'єктами, будь ласка, зателефонуйте моєму обробнику подій, який відтворює звук!" ").
• Контролер ловить подія введення і передає їх в чергу введення моделі. Він читає подання (чи відбулося таке натискання кнопки на кнопці інтерфейсу користувача?).

Таким чином ви можете підключити підроблений контролер, який читає файл, який містить попередньо записані події введення.
Зробіть також простий перегляд, який просто записує речі у файл.
Дуже корисний для тестування та налагодження.

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

Такий тип компартменталізації - це розкол між двигуном та ігровим кодом, і є досить поширеним явищем. По дорозі є багато місця для абстракції.

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