Насколько умным (активным) должен быть объект в игре?

[kukareku]

Вот, например, есть "герой". Пусть, для простоты, у него есть свойства "защищен"(тру-фолс), "состояние"(идет-корчится-умер) и методы "изменить состояние" и "изменить анимацию". Он идет. Ну, и его может укусить враг (тогда он корчится). Он может найти "волшебство", и тогда на какое-то время он "защищен", укус врага на него не действует. Если он укушен три раза, он умирает.

Вариант1: все управление героем идет из объекта "игра". Игра отслеживает, когда героя укусит враг, смотрит его свойство "защищен, и если он не "защищен", вызывает его методы "изменить состояние" и "изменить анимацию", чтобы он корчился, сама отслеживает когда анимация корчения завершается, и опять же вызывает его методы "изменить состояние" и "изменить анимацию" чтобы он шел. Игра же отслеживает, когда он находит "волшебство", изменяет его свойство на "защищен", отслеживает, когда "волшебство" заканчивается, и изменяет свойство героя "защищен" на фолс. Считает, сколько раз он укушен, и если три раза, то опять меняет его свойства и анимацию на "умер".

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

Вариант3. Некий промежуточный. Часть делает герой, часть - игра.

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

Ну, или, скажем так: как предпочитаете делать Вы, и почему?

(Ну, аналогично вопрос можно распространить на все другие объекты игры)

И если есть ссылки на почитать про это, тоже буду рада.

[maxkar]

У вас здесь точно не один объект и не один класс.

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

UI героя. Отдельный класс. Слушает модель героя. Изменяет анимацию. При необходимости через модель героя уведомляет о событиях анимации. Взаимодействует только с моделью героя!

Управлением занимается "игра". Она соответствующим образом меняет модель (не UI!). Возможно, прослушивает уведомления от UI через ту же модель. При этом в игре может быть выделен и HeroController, который занимается обслуживанием модели. Важно при этом то, что HeroController является не частью героя, а частью игры, получившейся в процессе ее (игры) декомпозиции. Контроллер героя взаимодействует с игрой (остальной частью, другими контроллерами) и моделью игрока. Обычно к "моделям" других объектов контроллер героя не обращается (иначе сложно найти, кто и что меняет).

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

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

[Srednas]

У Антона Карлова есть неплохая статья, правда про искусственный интеллект, но, возможно, что-то для себя найдете =)

[elder_Nosferatu]

Вариант 1 - вынос мозгов даже на маленьком прожекте.
Вариант 3 - не самая лучшая идея, лучше пусть мухи будут отдельно и котлеты отдельно

Поищите в гугле или здесь на форуме темы:
- MVC = Model-View-Controller = Модель-Вид-Контроллер
- FSM = Finite State Machine = Конечные Автоматы

Еще почитайте этих ребят:
- coolisee.com
- xitri.com
- ant-karlov.ru

[kukareku]

Большое спасибо всем ответившим на этот момент.

"Этих ребят" читала, из прочитанного ясный вывод для себя в этом плане сделать не смогла. Антон Карлов, как мне показалось, вообще событиями не пользуется принципиально (ну, или я что-то пропустила)

Чистый, весь такой правильный из себя MVC городить че-то не хочется, мало времени.

maxkar, а это - теоретически, или Вы именно так игры делаете?
Хотелось бы из опыта.

[ChuwY]

Если не будете достаточно отделять модель от представления, времени потратите куда больше и нервов.

[maxkar]

maxkar, а это - теоретически, или Вы именно так игры делаете?
Хотелось бы из опыта.

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

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

public interface Property {
  public function getValue() : *;
  public function addChangeListener(listener : Function) : void;
  public function removeChangeListener(listener : Function) : void;
}
 
public class HeroStats {
  public var hitpoints : Property /* int */;
  public var mana : Property /* int */;
  public var score : Property /* int */;
  public var level : Property /* int */;
}
 
// где-то в инициализации:
var mainHeroStats : HeroStats;
mainHeroStat.hitpoints = new PropertyVariable();
mainHeroStat.mana = new PropertyVariable();
mainHeroStat.score = new PropertyVariable();
mainHeroStat.level = Properties.lift(calculateLevel, score);
Properties.onPropertyChange(notifyLevelChanged, mainHeroStat.level);

Properties - это немного черной магии по работе с подобными гранулярными свойствами. Позволяет не писать новых классов с ручной подпиской, обновлением и т.п. В примере level всегда будет равен значению функции calculateLevel(score.getValue()) и будет автоматически изменять уведомления. notifyLevelChanged будет вызываться при изменении mainHeroStat.level и т.п. В некоторых местах могут быть "полновесные" объекты модели для подписок. Например, такие полновесные объекты обычно используются для управления анимациями и групповыми взаимодействиями.

Ну и бонусами вроде независимого изменеия я уже несколько раз пользовался. Это позволяет независимо переделывать различные аспекты. Например, взаимодействие объектов в видимой части сцены не зависит от начисления очков, переноса уровней и т.п.

[kukareku]

ChuwY, ну так это вот и вопрос, что считать "достаточным"

maxkar, спасибо, буду думать!