Чому MVC & TDD більше не використовуються в ігровій архітектурі? [зачинено]

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

Але, намагаючись застосувати практику кодування «корпоративних підприємств» у веб-додатках, дивлячись на вихідний код гри серйозно болить мені голова: «Яка ця логіка перегляду працює з бізнес-логікою? Для цього потрібен рефакторинг ... так це робить, рефактор, рефакторр "

Це хвилює мене, коли я збираюся розпочати ігровий проект, і я не впевнений, чи намагатиметься mvc / tdd процес розробки перешкодити нам чи допомогти нам, оскільки я не бачу багатьох ігрових прикладів, які використовують це або сильно підштовхують до кращих архітектурних практик у громаді.

Далі наводиться витяг із чудової статті про прототипування ігор , хоча мені здалося, саме таке ставлення, як здається, використовують багато розробників ігор при написанні виробничого коду гри:

Помилка №4: Створення системи, а не гри

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

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

... Просто виведіть речі на екран якомога швидше.

І ніколи, ніколи, не використовуйте аргумент «якщо ми займемо трохи зайвого часу і зробимо це правильно, ми можемо використовувати його повторно в грі». ВСЕ.

це тому, що ігри (в основному) зорово орієнтовані, тому є сенс, що код буде значно зважений у поле зору, тому будь-які переваги від переміщення матеріалів на моделі / контролери досить мінімальні, так навіщо турбуватися?

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

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

Можливо, я просто дивлюся на неправильний вихідний код, але чому ми не бачимо більше таких практик «підприємств», що застосовуються в ігровому дизайні? Чи справді ігри настільки різні за своїми вимогами, чи це питання людей / культури (тобто розробники ігор походять з іншого походження та, отже, мають різні звички кодування)?

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

Прототипи та ітерація, як правило, працюють набагато краще. Зрештою, з нього може вийти чудовий дизайн, але частіше з нього виходить щось більш просте і вишукане. KISS та YAGNI приходять до тями.

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

Справа в точці: Peggle , від PopCap Games. Основним механіком гри є фізика м'яча. Вони вдосконалили його! Я впевнений, що вони витратили досить багато часу, переконавшись, що це абсолютно ідеально, адже саме це робить гру. Але в той же час я можу повністю уявити собі ранній прототип їхньої гри, який, можливо, просто тягне спрайт на екран і робить якийсь тип примітивнішого виявлення зіткнень та підстрибувань, просто щоб побачити, чи ідея гри втіха. Потім, коли вони дізналися, що стріляти по м'ячу і спостерігати за його відскоком насправді може бути цікавим, вони вдосконалили підстрибування м'яча. _{(це, звичайно, лише міркування)}

Це також залежить від ваших технічних вимог, які ви повинні збити на початку (не ваш ігровий дизайн, а лише технічні вимоги). Платформа, на якій працює ваша гра, не повинна змінюватися, або якщо їй слід дозволити змінюватись, вам потрібно точно знати, наскільки ви плануєте дозволити їй змінюватися, не більше і не менше. Дизайн на цьому. Якщо ви розробляєте гру для OpenGL, і вам не байдуже DirectX, то насправді це не хвилює. Це означає, що якщо вам зручніше, щоб кожна організація малювала себе і не турбувалася про Фабрики та інші подібні шаблони дизайну, тоді робіть це. Це добре, тому що відповідає вимогам. Вам не доведеться змінювати це пізніше, незважаючи на те, що ви самі собі говорите. І справді, найгірший сценарій? Рефактор пізніше., отримуючи робочу гру на одній платформі, навіть якщо це означає, що вона не може одночасно і автоматично працювати на тостері.

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

Я думаю, що це також просто загальна відсутність знань та практики. Я не думаю, що TDD є поширеним і в інших областях, але, як і спритний розвиток, я думаю, що він поширюється. Ви можете сказати, що це випереджає свій час (а може і ні, як це може бути через роки). Більш важливим, ніж TDD, є "RDD" - розробка вимог. _{Я щойно це придумав.}Яка ваша мета? Щоб зробити гру. Все інше - друге. Якщо ви можете довести, що TDD збільшує продуктивність і допомагає командам досягати термінів, то чи не вважаєте ви, що всі будуть використовувати це? І, можливо, саме так. Але зараз наша галузь є більш конкурентоспроможною, ніж будь-коли, існують важчі та швидші терміни, і над цим просто потрібно працювати. Будівельні робітники спочатку не будують будівельні ліси; вони закладають фундамент, потім піднімають кілька стін і підлоги, і тільки потім будують вибіркові шматочки будівельних лісів, щоб виконувати конкретні завдання, які ліси роблять зручнішими. Я думаю, те саме стосується розробки програмного забезпечення.

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

І ей, роби те, що, на вашу думку, спрацює. Ви завжди можете його змінити або забруднити і почати спочатку. Це класна річ про будь-яку форму техніки; якщо спочатку вам не вдасться, спробуйте щось інше. (або щось подібне :-P) Ви не заливаєте бетон; програмне забезпечення ковче.

До речі, я задаю цей же питання і досліджую ці типи принципів дизайну вже деякий час. Ось деякі питання, як тут, так і в «Переповнення стека», які можуть вам бути релевантними:

• "Як можна організувати код для гри, щоб відповідати шаблону MVC?"
• "Як розробити програмне забезпечення гри таким чином, щоб його було легко провести?
• "Дизайн ігрового двигуна на основі компонентів"
• "Будь-які хороші навчальні посібники чи ресурси для того, щоб навчитися проектувати масштабований та" компонентний "ігровий" рамки "?"
• "Відокремлення ігрової та рендеринга логіки"
• "Чи життєздатне тестування модулів в ігровому програмуванні?"
• "Чи використовується модель дизайну MVC у комерційних комп'ютерних іграх"
• "Чи розробка тестових моделей є нормальним підходом до розробки ігор?"
• "Хтось із вас використовує Scrum для розробки ігор?"
• "Архітектура для гри - парувати чи не парити?"
• "Питання дизайну OO ігор"

Ось моя оригінальна відповідь на подібне запитання щодо SO з деякого часу назад, принаймні щодо частини MVC вашого запитання:

Він рідко використовується в іграх. Мені знадобилось певний час, щоб зрозуміти, чому, але ось мої думки:

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

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

У грі ці два світи набагато ближче один до одного. Ігровий світ (модель) - це як правило сукупність сутностей, розміщених у якомусь віртуальному просторі. Перегляд гри - це також сукупність сутностей, розміщених у якомусь віртуальному просторі. Обмежуючі обсяги, анімація, положення тощо, всі речі, які ви вважали б частиною «виду», також безпосередньо використовуються «моделлю»: анімація може впливати на фізику та ШІ тощо.

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

Натомість ігри, як правило, відокремлюють речі вздовж меж домену: AI, фізика, аудіо, візуалізація тощо зберігатимуться максимально окремо.

Тому що MVC не вписується в архітектуру гри. Потік даних для гри зовсім інший, ніж у застосунку enterprice, тому що це не так, як спричинено подією, і часто існує (дуже) жорсткий мільйсекундний бюджет, на який можна виконувати ці операції. Є багато речей, які повинні відбутися за 16,6 мілісекунд, тому вигідніше мати «фіксований» і жорсткий конвеєр даних, який обробляє потрібні вам дані на екрані саме в цей час.

Також поділ є; більшість часу це просто не підключено так, як MVC. Є двигун рендерінгу (View), керування введеннями користувачів (Controller) та інші, такі як логіка геймплея, ai та фізика (модель). Подумай над цим; якщо ви отримуєте введення користувача, запускаєте ai та надаєте зображення 60 разів на секунду, то навіщо вам потрібен спостерігач між моделлю та поданням, щоб повідомити, що змінилося? Не інтерпретуйте це так, як я кажу, що вам не потрібен шаблон спостерігача в іграх, але в цьому випадку ви насправді цього не робите. Ви робите всю цю роботу, кожен кадр, все одно.

Хоча TDD майже не використовується в студіях розробки, ми використовуємо Agile практики для розробки програмного забезпечення, і SCRUM, здається, є популярним вибором принаймні тут, у Європі. Причина проста, зміни відбуваються звідусіль. Художники можуть захотіти більше текстурного бюджету, більше світів, більше дерев, тоді як дизайнери хочуть багатшої історії (більше вмісту на диску), потокового світу, а видавці хочуть, щоб ви закінчили вчасно, і про бюджет, і так робить відділ маркетингу. І крім цього, "сучасний стан" постійно змінюється.

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

Також пам’ятайте, що в світі консолей це все ще відрізняється, оскільки ви програмуєте більше для обладнання, ніж для чого-небудь іншого. Це загалом (PS2 / PS3) означає, що потік даних є набагато важливішим, ніж потік коду майже у кожному випадку; через міркування щодо продуктивності. Що зводить нанівець використання TDD як архітектурного інструменту в більшості випадків. Хороший код OOP, як правило, має поганий потік даних, що ускладнює векторизацію та паралелізацію.

Чому MVC & TDD більше не використовуються в ігровій архітектурі?

Попередження: думка попереду.

MVC не використовується (багато), оскільки:

1. MVC - це порівняно новий підхід, і ігри, як правило, будуються на старому коді. Більшість людей, що роблять програми MVC, будують їх із нічого з кожного разу. (Я знаю, що сам MVC насправді складає десятиліття; нове - це широкий інтерес до нього, який, по суті, з'являється з веб-додатків, таких як RoR). У бізнес-програмному забезпеченні, над яким я працював, базувався на застарілому коді, і MVC там не використовувався. Це культура, але це не специфічно для гри.
2. MVC - це, по суті, модель GUI для програм, керованих подіями. Ігри не переважають ні на графічному інтерфейсі, ні на подіях, отже, застосовність не така велика, як для веб-додатків або інших форм-додатків. MVC - це, як правило, модель спостерігача з деякими відомими ролями, і в іграх часто немає розкоші чекати, щоб спостерігати щось цікаве - вони повинні оновлювати все, кожен кадр (або якийсь варіант на цьому), незалежно від того, чи хтось щось натиснув чи ні. .

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

TDD не використовується (багато), оскільки:

1. Дійсно незручно використовувати в іграх. Знову ж таки, це добре для програм, керованих подіями, де надходять входи та виходи, і ви можете порівняти побачене з тим, що очікували, і позначте його як правильне. Для моделювання з великою кількістю загального стану це значно незручніше.
2. Немає жодних незаперечних доказів того, що це взагалі щось допомагає. Просто багато претензій, а деякі цифри часто базуються на самозвіті та зверненнях до влади. Можливо, це допомагає бідним програмістам стати посередними, але стримує хороших програмістів. Можливо, час, витрачений на написання тестів, може бути краще витрачений на вивчення принципів SOLID або спочатку на розробку правильного інтерфейсу. Можливо, це дає помилкове відчуття безпеки, щоб мати тести, які проходять без реальних доказів того, що у вас є достатньо тестів, щоб переконатися, що ваш об’єкт робить правильно.

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

Однак, як ви, напевно, можете здогадатися, я значною мірою упереджений "практиці кодування підприємства", оскільки підприємства добре відомі тим, що перевищують часові шкали та бюджети. "Так роблять розробники ігор!" Я чую, як ви говорите - ну так. Я не думаю, що хтось насправді знає найкращий спосіб розробити програмне забезпечення зараз, і я не переконаний, що прийняття режиму роботи в основному програмному забезпеченні - це взагалі крок від більш вільної практики розважального програмного забезпечення. Насправді я підозрюю, що це в першу чергу користь для тих, хто покладається на товарних Java-програмістів, де ці підходи - це не сходи, щоб піднятися на більшу висоту, а захисна сітка, щоб зупинити їх падіння занадто низько.

Як зазначає Kylotan, "У іграх ви не можете розглядати презентаційний аспект як знімну та замінну концепцію, як HTML і CSS - це веб-програми". Побудувавши пару ігор за допомогою простого шаблону MVC (не величезна рамка) Я знайшов головну проблему в тому, що ваша модель повинна знати про ваш погляд. З великою ймовірністю вам знадобиться використовувати дані спрайтових растрових зображень, дані хіт-боксу або дані 3D-геометрії зі своїх художніх активів, щоб допомогти розпізнати зіткнення (або інше подібне завдання). Це означає, що кожна модель потребує посилання на свій погляд, що порушує класичний MVC-зразок - наприклад, ви більше не можете створювати новий вид на існуючу модель тощо.

Компонентна модель, яку ви бачите, наприклад, Unity3D - це найкращий спосіб організації ігрового коду.

MVC, на деяких рівнях, вже використовується в розробці ігор. На це вимушена ОС, яка має різні інтерфейси для введення та графіки. У більшості ігор також є ще кілька екземплярів MVC в них, наприклад, розділення фізики та відображення та введення потоків. Це прекрасно працює. Сучасна ідея MVC виглядає так, що його слід повторювати, фрактально, поки ніхто вже не може зрозуміти код. Ігри цього не роблять, на щастя.

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

Ігрові системи повільно переходять до кращих практик. Такі структури, як XNA, дають уявлення про те, щоб зробити код більш узагальненим / чистим, не додаючи занадто багато накладних витрат на час проектування чи виконання. Але в цілому я б сказав, що ігрові системи - це оптимізація складності та швидкості виконання, все залишаючись за жорстким графіком розробки та залишаючись мотивованим. Застосування інженерних концепцій програмного забезпечення та дизайну системи просто не є пріоритетом №1 в таких умовах.

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

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

Я не маю особливої ​​думки щодо MVC поза тим, що погляд часто відокремлюється від логіки простим фактом, що цикл візуалізації пакує купу матеріалів для обробки певного обладнання, і це не місце, де ви хочете "гра логіка »відбувається одночасно. "Контролер" також розділений апаратним забезпеченням, але, на жаль, багато, якщо не більшість розробників ігор роблять "цікаву" роботу в контролері контролера. (Обробник контролера IMO повинен читати кнопки та палички та створювати "презентацію" для гри для перегляду, але моя мильниця не така сильна.)

З іншого боку, TDD - це те, про що я маю дуже сильну думку. Це просто змінює розвиток таким чином, щоб отримати програмне забезпечення, яке легше будувати. Це важче зробити, в цьому немає сумнівів. Звичайно, оскільки це важче зробити, це не робиться. Деякі люди плачуть про TDD (або загалом тестування одиниць), яке не має значення, оскільки "гра - це тест", але факт полягає в тому, що в TDD тестування майже не має значення. Сенс TDD - це розробка та архітектура програмного забезпечення, що виходить із процесу.

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

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

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