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

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

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

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

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

  

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

     

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

     

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

     

... Просто загрузите материал на экран, как   быстро, как вы можете.

     

И никогда не используйте аргумент   «Если мы возьмем дополнительное время и сделаем   это правильный путь, мы можем его повторно использовать в   игра. EVER.

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

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

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

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

152 голоса | спросил timoxley 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 04:47:19 +0400 2010, 04:47:19

8 ответов


133

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

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

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

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

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

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

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

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

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


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

ответил Ricket 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 05:08:29 +0400 2010, 05:08:29
32

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

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

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

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

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

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

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

ответил munificent 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 04 Sep 2010 00:39:58 +0400 2010, 00:39:58
18

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

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

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

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

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

ответил Jasper Bekkers 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 12:21:12 +0400 2010, 12:21:12
13
  

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

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

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

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

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

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

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

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

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

ответил Kylotan 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 18:24:35 +0400 2010, 18:24:35
9

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

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

ответил Iain 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 12:40:08 +0400 2010, 12:40:08
4

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

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

ответил 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 13:19:13 +0400 2010, 13:19:13
3

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

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

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

ответил Deleter 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 05:48:40 +0400 2010, 05:48:40
2

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

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

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

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

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

ответил dash-tom-bang 2 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 02 Sep 2010 03:08:28 +0400 2010, 03:08:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132