Архитектура игрового фреймворка - компоненты просмотра или MVC?

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

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

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

Я знаю, что этот вопрос может быть устаревшим, но мне нужно ответить на него. Собственно, я начал программировать игру на Lua (с LÖVE) и начал программировать для нее MVC - Framework. Во-первых, использование MVC действительно зависит от того, чего вы хотите. Я знаю свои проблемы с программированием игр, когда программа становится больше, и в большинстве случаев структура становится слишком сложной, чтобы ее можно было поддерживать. Следующее, что я знаю, я изменю всю графику, когда найду художника, который захочет над этим работать. Но до тех пор я буду использовать свою собственную фиктивную графику. Я хочу, чтобы художник мог свободно делать то, что он хочет, без каких-либо ограничений по разрешению или цвету. Значит, мне, возможно, придется изменить весь (!) Код презентации. Может быть, даже способ взаимодействия объектов (обнаружение столкновений, например). Логика игры отражена в моделях, поэтому я могу сосредоточиться на ней. И я считаю, что игровая логика - самая важная часть создания игры. Не так ли? Надеюсь, вы понимаете мою точку зрения.

Но если у вас есть все вместе: вся графика, звуки, все это; тогда вы можете писать код прямо вперед.

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

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