Звучит так, как будто вы хорошо прочитали шаблон Model-View-Controller . Вам не нужно подчиняться этому рабски (например, в некоторых контекстах имеет смысл допускать некоторое перекрытие между Model и View), но хорошее понимание этого поможет вам построить любую программу, которая имеет много графических объектов. и логика, управляющая ими, и необходимость транслировать состояние или сохранять его на диске (сохранение игры) и т. д.
Вы также должны понимать, что cocos2d предоставляет хорошую систему для структурирования графического графического сценария и его эффективной визуализации, но не предоставляет полной инфраструктуры для программирования игр. В этом смысле это скорее графический движок, чем игровой движок. Если вы попытаетесь вписать архитектуру вашей игры в структуру cocos2d, у вас может не получиться наиболее приемлемого результата. Вместо этого вы должны рассматривать cocos2d как то, что он есть: отличный инструмент, чтобы позаботиться о ваших потребностях в отображении и анимации.
У вас определенно должен быть объект, отличный от сцен, которые поддерживают игровое состояние, потому что в противном случае куда пойдет все состояние при переключении между сценами? А в пределах сцен / уровней вы должны просто попытаться использовать хороший объектно-ориентированный дизайн, чтобы распределить состояние по объектам различных классов. Каждый объект персонажа запоминает свое собственное состояние и т. Д. Здесь вы можете увидеть, где MVC становится полезным: когда вы сохраняете игру на диск, вы хотите запомнить уровень здоровья каждого персонажа, но, вероятно, не какой именно индекс кадра показывал анимация спрайта. Таким образом, вы должны различать sprite и символ (модель). Тем не менее, как я уже упоминал ранее, для игровых объектов, к которым не привязана большая логика или которые не нужно сохранять, было бы хорошо просто объединить модель и представление в один класс ( в основном путем подкласса CCSprite).
Чтобы реализовать MVC в том виде, в каком он должен быть, вам также следует изучить основы Наблюдение значения ключа . (И вам лучше было бы использовать эту замену для интерфейса Apple.) В более интенсивных играх в реальном времени подобные методы могут быть слишком медленными, но, поскольку вы делаете RPG (хороший выбор для вначале) вы могли бы, вероятно, пожертвовать производительностью для более удобной в эксплуатации архитектуры.
Сцена игры (которая является еще одним спрайтом cocos2d) играет роль Контроллера, с точки зрения паттерна MVC. Он ничего не рисует сам, но говорит всему остальному рисовать себя на основе входных данных и состояния. Соблазнительно использовать всевозможную логику и функциональность на игровой сцене, но когда вы замечаете, что она набухает, вы должны спросить себя, как можно разделить эту функциональность на другие классы. Проанализируйте, какой тип функциональности вы реализуете. Это связано с данными и состоянием (модель)? Или это про анимацию и рендеринг (View)? Или речь идет о соединении логики с рендерингом (в этом случае вы должны попытаться заставить View непосредственно наблюдать за моделью)?
Сцена / Контроллер игры - это, по сути, диспетчерский центр, который принимает входные события (например, от пользователя или от спрайтов, сообщающих, что они что-то нажали) и решает, что с ними делать: он может сказать одному или нескольким объектов Model, чтобы обновить себя каким-либо образом, или это может просто вызвать анимацию в некоторых других спрайтах, например.
В игре в реальном времени у вас должен быть метод "тик" или "шаг" в сцене, который говорит всем объектам обновляться самостоятельно. Этот метод (игровой цикл) является сердцем программы и запускается каждый раз, когда рисуется новый кадр. (В современных игровых движках много многопоточности, но давайте не будем об этом думать.) Но в вашем случае вы можете создать модуль, который может «играть в игру» совершенно отдельно от игровой сцены. Представьте себе создание программы, которая может играть в шахматы через терминал, используя только ввод текста. Если вы создадите всю игровую систему таким образом, а затем подключите ее к графическому движку с помощью небольшого и чистого интерфейса, у вас будет действительно поддерживаемое приложение с большим количеством кода для повторного использования для будущих проектов!
Некоторые хорошие эмпирические правила: модель (данные) не должна знать ничего о спрайтах или состояниях отображения; представление (спрайты) не должно содержать никакой реальной логики игры (правил игры), а должно знать только, как делать простые вещи, такие как перемещение и подпрыгивание, и сообщение на сцену, если происходит что-то сложное. По возможности, представление должно реагировать на изменения в модели напрямую, без вмешательства контроллера.