MVC: Кто должен отвечать за спрайты?

Question

[Кирилл Баталин]

Решил сделать простую игру. У персонажа должна быть анимация передвижения. Как лучше это реализовать?
1. Модель хранит в себе спрайт. Представление запрашивает у модели картинку и выводит ее. В таком случае модель сама будет думать, какую именно картинку надо дать представлению, чтобы была анимация бега.
2. Представление хранит в себе картинку бега. Во время отрисовки представление запрашивает у модели "фазу" бега и выводит на экран необходимую часть картинки.
3. Представление само рассчитывает на основе данных из модели, какую часть картинки взять. В данном случае в представлении будет происходить немало вычислений, но зато все, что связано с отрисовкой будет именно в представлении.

UPD. В 3 варианте придется хранить прошлое состояние ("фазу") бега. Но за хранение состояний должна отвечать модель.

Answer 1

[Сергей Протько]

Решил сделать простую игру.

MVC для приложений, для игр оно не применимо так как у вас UI и предметная область слишком уж сильно связаны друг с другом, а MVC ставит перед собой цель именно "развязать" их. Конфликт идет уже в фразе:

Модель хранит в себе спрайт.

Модель должна хранить данные, то есть это симуляции каких-то процессов, ИИ, физика и т.д. Ну а спрайты - это по сути представление данных. И как вы могли заметить игра без графики - не игра и не имеет смысла. А вот сменить UI у приложения можно, на бизнес логику оно не влияет.

Короче для игрушек обычно применяют чуть другой паттерн, под названием ECS (Entity-Component-system), которы позволяет разделить обязанности чуть-чуть подругому.

p.s. но если вернуться к MVC - то третий вариант. А что до

Но за хранение состояний должна отвечать модель.

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

Comments

[ManWithBear]

Сергей Протько спасибо за ecs

Answer 2

[Владимир Хаттер]

А чем у Вас КОНТРОЛЛЕР занимается? @_@

Comments

[Кирилл Баталин]

Взаимодействие между контроллером и представлением хорошо описывается паттерном "Стратегия". Пользователь нажимает кнопки, представлением фиксирует нажатия, передает их контроллеру. Контроллер на основе нажатых кнопок вызывает какие-то методы у модели.

Answer 3

[Елизавета Борисова]

Не все паттерны полезны в разработке игр. В играх важна производительность, и если вы будете на один маленький спрайт навешивать model, view, controller, что будет с 200+ спрайтами ? (тест уже поставили?). Если хотите MVC, используйте его для всего (частичного) состояния игры.
Стандартную реализацию спрайтов можно найти в исходниках игровых движков.