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

Я предвосхищу это, говоря, что я не искал огромное количество игровых исходников и не создавал много игр.

Но из-за того, что я пытаюсь использовать «корпоративную» практику кодирования в веб-приложениях, просмотр исходного кода игры серьезно ранит мою голову: «Что эта логика представления делает с бизнес-логикой? Это требует рефакторинга ... так же как и это, рефакторинг, рефакторрр» "

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

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

Ошибка № 4: Создание системы, а не игры

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

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

... Просто выведите материал на экран как можно быстрее.

И никогда, никогда не используйте аргумент «если мы потратим дополнительное время и сделаем это правильно, мы сможем использовать его в игре». КОГДА-ЛИБО.

это потому, что игры (в основном) визуально ориентированы, поэтому имеет смысл, что код будет сильно взвешен в представлении, поэтому любые выгоды от переноса материала на модели / контроллеры довольно минимальны, так зачем беспокоиться?

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

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

Возможно, я просто смотрю на неправильный исходный код, но почему мы не видим больше этих «корпоративных» практик, используемых в игровом дизайне? Действительно ли игры настолько различны в своих требованиях, или это проблема людей / культуры (т.е. разработчики игр происходят из другого фона и, следовательно, имеют разные привычки кодирования)?

Как говорится в цитате, многие программисты делают ошибку (пытаясь) построить систему, а не игру. Обычно эта система выходит из-под контроля, пока не станет настолько сложной, что теоретически она сможет справиться с чем угодно, но на практике все, что у вас есть, - это большой набор кода. Или чаще, прежде чем вы даже приступите к работе, вы настолько запутались в коде, который не запускается, что вы теряете фокус (если у вас было что-то для начала) и мотивацию (поскольку на самом деле ничего не работает).

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

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

Показательный пример: Peggle , от PopCap Games. Основная механика игры - физика мяча. Они усовершенствовали это! Я уверен, что они потратили довольно много времени, чтобы убедиться, что это было абсолютно идеально, потому что это то, что делает игру. Но в то же время я могу полностью представить себе ранний прототип их игры, который, возможно, просто рисует спрайты на экране и делает более примитивное обнаружение столкновений и подпрыгивание, просто чтобы увидеть, является ли идея игры забавной. Затем, как только они узнали, что стрелять по мячу и наблюдать за его отскоком на самом деле может быть весело, они улучшили отскок мяча. _{(это все только предположения, конечно)}

Это также зависит от ваших технических требований, которые вы должны заблаговременно (не от игрового дизайна, а от технических требований). Платформа, на которой работает ваша игра, не должна меняться, или, если это нужно изменить, вам нужно точно знать, в какой степени вы планируете ее изменять, не больше и не меньше. Дизайн на это. Если вы разрабатываете игру для OpenGL, и вы не заботитесь о DirectX, то на самом деле, вам все равно. Это означает, что если вам удобнее рисовать каждую сущность и не беспокоиться о фабриках и других подобных шаблонах, то сделайте это. Это нормально, потому что соответствует требованиям. Вам не нужно менять это позже, несмотря на то, что вы говорите себе. И действительно, в худшем случае? Рефакторинг позже.получить рабочую игру на одной платформе, даже если это означает, что она не может одновременно и автоматически запускаться на тостере.

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

Я думаю, что это также просто общий недостаток знаний и практики. Я не думаю, что TDD распространен и в других областях, но, как и в Agile разработке, я думаю, что он распространяется. Вы можете сказать, что он опередил свое время (или, может быть, нет, так как в этом случае могут быть годы). Более важным, чем TDD, является «RDD» - разработка на основе требований. _{Я только что сделал это.}Какова твоя цель? Чтобы сделать игру. Все остальное идет вторым. Если вы можете доказать, что TDD повышает производительность и помогает командам уложиться в сроки, то не думаете ли вы, что все будут его использовать? И, возможно, это так. Но сейчас наша отрасль более конкурентоспособна, чем когда-либо, есть более жесткие и более короткие сроки, и материал просто должен работать. Строительные рабочие не строят леса в первую очередь; они закладывают фундамент, затем они поднимают некоторые стены и полы, и только тогда они строят отдельные части лесов, чтобы выполнять конкретные задачи, которые леса делают более удобными. Я думаю, что то же самое относится и к разработке программного обеспечения.

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

И эй, делай то, что, как ты думаешь, сработает. Вы всегда можете изменить его или отказаться от него и начать все сначала. Это крутая вещь в любой форме инженерии; если сначала вам не удастся, попробуйте что-то другое. (или что-то в этом роде :-P) Вы не заливаете бетон; ПО податливое.

Кстати, я задавал этот же тип вопросов и изучал эти типы принципов проектирования в течение некоторого времени. Вот некоторые вопросы, как здесь, так и в переполнении стека, которые вы можете найти актуальными:

• "Как вы можете организовать код для игры, чтобы соответствовать шаблону MVC?"
• «Как спроектировать игровое программное обеспечение так, чтобы его можно было легко тестировать?»
• «Компонентный дизайн игрового движка»
• "Какие-нибудь хорошие учебные пособия или ресурсы для изучения того, как разработать масштабируемую и основанную на" компонентах "игровую" среду "?"
• «Разделение логики игры и рендеринга»
• "Является ли юнит-тестирование жизнеспособным в программировании игр?"
• «Используется ли шаблон проектирования MVC в коммерческих компьютерных играх»
• «Является ли разработка на основе тестов нормальным подходом в разработке игр?»
• "Кто-нибудь из вас использует Scrum для разработки игр?"
• "Архитектура для игры - пара или нет?"
• "ОО вопрос дизайна игры"

Вот мой оригинальный ответ на аналогичный вопрос по SO, который был, по крайней мере, в части MVC вашего вопроса:

Это редко используется в играх. Мне понадобилось время, чтобы понять, почему, но вот мои мысли:

MVC существует, чтобы провести различие между двумя представлениями. Модель - это абстрактное представление ваших данных. Это то, как машина просматривает состояние вашего приложения. Представление (и контроллеры) представляют более конкретную видимую реализацию этой системы таким образом, который имеет смысл для людей.

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

В игре эти два мира намного ближе друг к другу. Игровой мир (модель) обычно представляет собой набор сущностей, расположенных в некотором виртуальном пространстве. Представление игры также представляет собой набор объектов, расположенных в некотором виртуальном пространстве. Ограничивающие объемы, анимацию, положение и т. Д., Все, что вы считаете частью «вида», также непосредственно используется «моделью»: анимация может влиять на физику, ИИ и т. Д.

Конечным результатом является то, что грань между моделью и представлением в игре будет произвольной и бесполезной: в конечном итоге вы дублируете много состояний между ними.

Вместо этого игры имеют тенденцию разъединять вещи вдоль границ домена: ИИ, физика, аудио, рендеринг и т. Д. Будут храниться как можно более раздельно.

Потому что MVC не вписывается в архитектуру игры. Поток данных для игры полностью отличается от потока данных для корпоративного приложения, потому что он не является управляемым событиями и часто имеет (очень) ограниченный миллисекундный бюджет для выполнения этих операций. Есть много вещей, которые должны произойти за 16,6 миллисекунды, поэтому более выгодно иметь «фиксированный» и жесткий конвейер данных, который обрабатывает необходимые данные на экране именно в это время.

Кроме того, разделение есть; Большую часть времени он просто не подключен так же, как шаблон MVC. Есть движок рендеринга (View), пользовательский ввод (Controller) и другие, такие как логика геймплея, ai и физика (Model). Думаю об этом; если вы выбираете пользовательский ввод, запускаете ai и отрисовываете изображение 60 раз в секунду, то зачем вам нужен Observer между моделью и представлением, чтобы сообщить вам, что изменилось? Не интерпретируйте это как то, что я говорю, что вам не нужен паттерн Observer в играх, но в этом случае вы действительно не нуждаетесь. Вы делаете всю эту работу, каждый кадр, в любом случае.

Хотя TDD практически никогда не используется в студиях разработки, мы используем Agile-методы для разработки программного обеспечения, и SCRUM, кажется, является популярным выбором, по крайней мере, здесь, в Европе. Причина проста, изменения происходят отовсюду. Художникам может потребоваться больший бюджет текстур, большие миры, больше деревьев, в то время как дизайнеры хотят более насыщенную историю (больше контента на диске), потоковый мир, а издатели хотят, чтобы вы закончили работу вовремя, в рамках бюджета, как и отдел маркетинга. И, кроме того, «состояние техники» быстро меняется.

Это не означает, что мы также не проводим тестирование, большинство студий имеют большие отделы вопросов и ответов, проводят множество регрессионных тестов и регулярно проводят модульные тесты. Однако вряд ли имеет смысл проводить модульные тесты заранее, потому что большая часть ошибок связана с искусством / графикой (дыры в сетках столкновений, неправильные текстуры и т. Д., Сбой в глубине полевого шейдера), которые не могут покрыть модульные тесты. И помимо рабочего кода, самый важный фактор любой игры - это то, что это весело, и нет никакого юнит-тестирования.

Также помните, что в консольном мире это все еще отличается, потому что вы программируете больше для аппаратного обеспечения, чем для чего-то еще. Обычно это (PS2 / PS3) означает, что поток данных гораздо важнее, чем поток кода почти в каждом случае; из соображений производительности. Что сводит на нет использование TDD в качестве архитектурного инструмента в большинстве случаев. Хороший ООП-код обычно имеет плохой поток данных, что затрудняет его векторизацию и распараллеливание.

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

Предупреждение: мнение впереди.

MVC не используется (много), потому что:

1. MVC - это относительно новый подход, и игры, как правило, построены на старом коде. Большинство людей, создающих приложения MVC, каждый раз создают их из ничего. (Я знаю, что самому MVC на самом деле уже несколько десятилетий; новшеством является широко распространенный интерес к нему, который по сути исходит от веб-приложений, таких как RoR). В программном обеспечении для бизнеса, над которым я работал, оно основывалось на унаследованном коде, там также не было никакой пользы для MVC. Это культурная вещь, но она не зависит от игры.
2. MVC - это по сути графический интерфейс для программ, управляемых событиями. В играх не доминируют GUI и не управляют событиями, поэтому применимость не так велика, как для веб-приложений или других приложений на основе форм. MVC - это, как правило, паттерн Observer с известными ролями, и играм не хватает роскоши ждать, чтобы увидеть что-то интересное - они должны обновлять все в каждом кадре (или в некоторой вариации) независимо от того, щелкнул кто-нибудь или нет. ,

Это не значит, что игры не могут многому научиться у MVC. Я всегда стараюсь отделить модель от вида в играх, которые делаю. Традиционная идея о том, что представление и контроллер являются двумя частями одного и того же (виджета) объекта, на самом деле не работает, поэтому вам нужно быть немного более абстрактным в этом. Я согласен с вами, что производительность вряд ли будет настоящей проблемой здесь. Во всяком случае, производительность может выиграть от разделения визуальных и логических элементов, так как это лучше поддается кэшированию, параллелизму и т. Д.

TDD не используется (много), потому что:

1. Это действительно неудобно для использования в играх. Опять же, это хорошо для программного обеспечения, управляемого событиями, где вводятся и выводятся выходы, и вы можете сравнить то, что вы увидели, с тем, что вы ожидали, и отметить это как правильное. Для моделирования с большим количеством общего состояния это значительно более неудобно.
2. Нет никаких неоспоримых доказательств того, что это вообще помогает. Просто много претензий, а некоторые цифры часто основаны на самоотчетах и ​​обращениях к власти. Возможно, это помогает бедным программистам стать посредственными, но сдерживает хороших программистов. Возможно, время, потраченное на написание тестов, лучше потратить на изучение принципов SOLID или, прежде всего, на разработку правильного интерфейса. Возможно, это дает ложное чувство безопасности, когда тесты проходят без какого-либо реального доказательства того, что у вас достаточно тестов, чтобы убедиться, что ваш объект работает правильно.

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

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

Как отмечает Килотан: «В играх вы не можете рассматривать аспект представления как отделяемое и заменяемое понятие, такое как HTML и CSS для веб-приложений». Создав пару игр с использованием простого шаблона MVC (не огромного фреймворка), я обнаружил, что основная проблема заключается в том, что ваша модель должна знать о вашем представлении. Весьма вероятно, что вам понадобится использовать данные спрайтового изображения, данные хитбоксов или данные трехмерной геометрии из ваших художественных ресурсов, чтобы помочь в обнаружении столкновений (или другой аналогичной задаче). Это означает, что каждая модель нуждается в ссылке на свое представление, которое нарушает классический шаблон MVC - например, вы больше не можете создавать новое представление для существующей модели и т. Д.

Модель компонентов, которую вы видите, например, в Unity3D, - лучший способ упорядочить игровой код.

MVC, на некоторых уровнях, уже используется в разработке игр. Это вызвано ОС, которая имеет различные интерфейсы для ввода и графики. В большинстве игр также есть несколько экземпляров MVC, например, разделяющих физику и потоки рендеринга и ввода. Это отлично работает. Современная идея MVC заключается в том, что его следует повторять фрактально до тех пор, пока никто не сможет больше понять код. Игры не делают этого, к счастью.

TDD не используется, потому что редко известно, что игра "должна делать", прежде чем вы будете многократно повторять прототип. Практики TDD, такие как непрерывное тестирование или интеграционное тестирование, часто используются при разработке игр.

Игровые системы постепенно переходят на лучшие практики. Такие фреймворки, как XNA, дают представление о том, как сделать код более обобщенным / чистым, не добавляя слишком много времени на разработку или выполнение. Но в целом я бы сказал, что игровые системы - это оптимизация сложности по сравнению с быстродействием, все в то же время, если у вас плотный график разработки и мотивация. Применение концепций разработки программного обеспечения и системного дизайна просто не является приоритетом № 1 в такой среде.

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

Также, как правило, к тому времени, как вы закончите свою игру, у вас будет как минимум 1000 идей о том, как улучшить базовую механику, основные системы и т. Д. Таким образом, чтобы очень мало этого «повторно используемого» кода действительно пригодный для использования. Днем я работаю на обычной работе SE, и хотя системы, над которыми мы работаем, могут быть огромными, честно говоря, я думаю, что они бледнеют по сравнению со сложностью в играх.

У меня нет особого мнения о MVC, за исключением того факта, что представление часто отделено от логики простым фактом, что цикл рендеринга упаковывает кучу вещей для обработки некоторого оборудования, и это не то место, где вы хотите ». логика "происходит одновременно. «Контроллер» также разделен аппаратно, но, к сожалению, многие, если не большинство разработчиков игр, делают «интересную» работу в обработчике контроллера. (IMO обработчик контроллера должен читать кнопки и флешки и создавать «презентацию» для просмотра игры, но моя мыльница не настолько сильна.)

С другой стороны, TDD - это то, о чем у меня очень сильные мнения. Это просто меняет разработку таким образом, чтобы создавать программное обеспечение, на которое проще опираться. Это сложнее, без сомнения. Конечно, так как это труднее сделать, это не сделано. Некоторые люди жалуются на то, что TDD (или, в более общем смысле, модульное тестирование) не имеют значения, потому что «игра - это тест», но факт в том, что в TDD тестирование практически не имеет значения. Суть TDD - это дизайн программного обеспечения и архитектура, которая выходит из процесса.

Использование TDD действительно меняет подход к программированию. У меня были некоторые чувства по поводу того, что было правильно и что было не так, прежде чем я начал идти по пути TDD, но как только я вскочил обеими ногами, я действительно понял, что то, что я делал, помогало или мешало будущему развитию. , Действительно, это своего рода точка позади поста кодовой комнаты, TDD без t .

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

Я убежден, что люди, которые отказываются принимать TDD, просто не хотят быть лучшими программистами. Они уже думают, что они «превосходны» в программировании, дизайне или архитектуре, хотя на самом деле их код говорит что-то совершенно другое.