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


18

Я читаю одну замечательную книгу, Game Coding Complete , и эта книга настоятельно рекомендует использовать подход MVC (Model-View-Controller) с тремя ключевыми слоями:

  1. Уровень игровых приложений
  2. Игровая логика
  3. Просмотр игры

Для меня такой подход выглядит излишним для мобильной компьютерной игры.

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


5
-1 и проголосуй за закрытие. Все, что стоит сказать о MVC в играх, было сказано по адресу gamedev.stackexchange.com/questions/3426/… , и пока все, что у нас есть, это мусор.

@Joe Wreschnig, это довольно резко, но я думаю, правда ...
Spooks

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

2
@Joe: О, хорошо, спасибо. :) Аргумент, что ООП является бесплатной, несколько поражает воображение. Я предполагаю, что по некоторому стандарту нам не нужны пункты, подобные повторенным моим, но новички случаются, и поэтому с дублированием возникают вопросы. Это также служит для того, чтобы позволить опоздавшим на сайт, подобным мне, скрести крошечное количество повторений, несмотря на массовую активность. :) Я имею в виду, чёрт, у меня 40K повтор на SO, но здесь я даже не могу редактировать тэг вики.
хаос

Ответы:


30

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

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

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


Дорогой Хаос, мне больше всего нравится твой ответ, поэтому я отмечаю его как ответ на мой вопрос. Подход MVC добавляет абстракцию в дизайн кода. Абстракция обычно добавляет дополнительные шаги кода, которых можно избежать с помощью более простого дизайна. Как я правильно понял, мне не нужно беспокоиться о стоимости, вносимой абстракцией, добавленной в результате проектирования MVC.
Bunkai.Satori

1
Хороший ответ, +1 за это .. Теория все хорошо и хорошо, но это может привести к тому, что игры не будут доставлены, если вы просто не сделаете это.
Джеймс

@ Bunkai.Satori: Это добавляет абстракцию, и IMO это полезная абстракция, которая окупается. Я согласен с последним утверждением, с тем уточнением , что там есть стоимость, и что я не думаю , что вам нужно беспокоиться об этом.
хаос

4

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

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

В конечном счете, MVC - это хороший дизайн, который позволяет вам повысить уровень обслуживания и уменьшить количество ошибок и т. Д. Бесплатно . Там нет причин, чтобы не использовать его. Это все равно что спросить, почему вы должны использовать forцикл вместо рукописных gotos. Если вы не задумываетесь о превосходном дизайне, он, несомненно, лучше, чем ничего.

Редактировать: проекты во время компиляции не потребляют мощность процессора. Проекты времени выполнения, такие как наследование, очевидно, делают.


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

Спасибо DeadMG за ваш ответ. По сути, я имею в виду, что с каждым уровнем абстракции код становится все медленнее, так как добавляется все больше и больше промежуточных шагов. MVC является более абстрактным дизайном, который, скорее всего, приведет к большему количеству шагов для достижения той же задачи. Это имело бы влияние на скорость, IMO.
Bunkai.Satori

4

Почти всегда существует компромисс между ясностью кода и техническими требованиями (скорость, память и т. Д.) Программы. Объектно-ориентированные языки имеют дополнительные издержки по сравнению с процедурными языками, но было показано, что они имеют много преимуществ по сравнению с процедурными языками, особенно в долгосрочном обслуживании кода (ошибок и т. Д.), А также часто в скорости разработки.

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

С другой стороны, убедитесь, что вы действительно закончили игру и не тратите так много времени на работу над «движком», что это никогда не будет сделано.

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


1
ОО языки вообще не медленнее процедурных. Если вы напишете некоторый код на C ++, который выполняет сдвиг битов, он не будет медленнее, чем на C. Язык или программа не медленнее, чем процедурные, только потому, что они объектно-ориентированы. Программы показывают только ухудшение производительности, потому что они плохо написаны . В результате я чувствую необходимость понизить ваш ответ.
DeadMG

Привет Рикет, спасибо за объяснение. Это звучит очень логично. DeadMG, ну, с одной стороны, вы правы, с другой стороны, я думаю, что ОО-подход добавляет больше битов информации в скомпилированный код, чем процедурный язык. Эти дополнительные биты кода, связанного с ОО, делают полученный код медленнее. Вы согласны?
Bunkai.Satori

3
Ух ты ... Конечно, простая строка в C ++ a++будет точно такой же, как и a++в C (где aтип примитива и т. Д. И т. Д.). Но рассмотрим простой класс C ++ с виртуальной функцией, которая что-то делает, эта виртуальная функция несет большие издержки по сравнению с простой функцией C, даже если внутренний код идентичен. Объектно-ориентированные языки имеют накладные расходы . Извините за явное высказывание "скорость". Если дополнительное выделение памяти и тому подобное не приводят к более медленной программе, то вы абсолютно правы.
Рикет

2
Если функция виртуальная, это означает, что программе необходимо выбирать между 2 разными версиями одной и той же функции во время выполнения. (В противном случае вы не сделаете его виртуальным.) В этом случае у вас все равно есть дополнительный условный уровень или уровень косвенности, который вам придется реализовать на процедурном языке (например, с помощью указателя на функцию или оператора switch). , Это не накладные расходы - это неотъемлемая часть проблемы.
Kylotan
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.