Правильное использование шаблона стратегия.

[incvizitor]

Допусти мы делаем игру пакман.

Есть следущие типы элементов.

1) BlankElement - пустая клетка.
2) WallElement - стенка.
3) Packman - наш персонаж.
4) Enemy - наш враг.
5) SuperEnemy - враг, который, допустим, может ходить через стены.
6) Food - пища для пакмана.

ну и т.д.

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

Так вот, я хочу что бы в контроллере ето красиво обрабатывалось при помощи паттерна стратегия (если есть варианты лучше - you are welcome). Различия могут быть типа: враг не может есть пищу, супервраг может проходить через стены. Возможные решения:

1 - создать кучу классов PackmanToWall, PackmanToFood, PackmanToBlank, PackmanToEnemy... То же самое для врагов и для суперврагов.

Но сами понимаете что во первых это убийственное множество классов. Во вторых если я добавлю, например, элементы bomb, bonus - то надо будет добавлять еще как минимум 6 классов.

2 - создать для каждого двигоющегося объекта свои стратегии PackmanMotion, EnemyMotion, SuperEnemyMotion. Но тогда при добавлении нового элемента прийдется изменять ВСЕ существующие классы. Это не на столько печально - но все равно не шик.

Так как лучше всего разрешить данную ситуацию, что бы код был гибким, стабилным и расширяемым?

[Wolsh]

Ну хорошо, наверно надо начать то с представления, как именно Вы бы хотели видеть расширяемость? Если Вы не хотите создавать в будущем (и сейчас) кучу классов для каждого возможного варианта, то Стратегия не совсем то, что нужно, ибо абстрагирует действия. Просто Интерфейса, описывающего toWall(), toFood(), toBlank(), toEnemy() было бы достаточно наверное, но опять же в случае добавления нового персонажа придется добавлять взаимодействие с ним в Интерфейс и потом реализовывать во всех классах персонажей. А с другой стороны – разве условие задачи допускает каким-то образом НЕ ДЕЛАТЬ этого? Где-то, как-то, но всеравно придется описывать нового перса/дроп и его взаимодействие со всеми остальными участниками. Стратегия тут хвастается тем, что из 250 классов Вам надо будет изменить 15 и создать 15 новых. Не "ВСЕ")) Ну а так Вам придется написать класс, скажем Exploit, изменить Интерфейс и добавить в 15 классов метод toExploit().

[incvizitor]

Wolsh, так я и не говорю, что притендую на то, что бы вообще ничего не менять =) Просто, желательно, что бы я мог делать это меньшими силами. Дело в том, что конечно некоторые классы как bomb или bonus можно было бы наследовать от FoodElement и делать так что бы Enemy и SuperEnemy игнорили её, а Pakman думал что с ней делать. Получается что нужно в зависимости от движущегося элемента делать стратегию, которая в свою очередь выбирает стратегию поведения, в зависимости от элемента с которым мы столкнулись. То есть какае то стратегия стратегий.

Не думаю, что вбивать в интерфейс отношение к каждому элементу - хорошее решение.

ПС: вообще в идеале, я бы хотел, что бы модули с различным поведением можно было бы подключать из вне (как плагин).

[Wolsh]

Отлично) Но как описать отношение одного плагина к другому плагину? Видимо, надо абстрагировать набор свойств, которыми обладает каждый Элемент, и этот набор должен быть постоянен, а каждый Элемент должен полностью характеризоваться значениями этих свойств. Это позволит описывать и добавлять новые Элементы. Ну то есть к примеру:
Я собираю бонусы : true / false
Я даю бонусы к скорости Врага: 0...100
Я даю бонусы к здоровью Героя: 0...100
Я двигаюсь со скоростью : 0...100
Я наношу урон от взрыва Герою: 0...100
Я наношу урон от взрыва Врагу: 0...100
Я имею резист к урону от взрыва : 0...100
Я имею резист к урону от зубов : 0...100

Ну и так далее. И при встрече таких.. плагинов сопоставлять все их скиллы. Но вот если Вы придумаете потом новый параметр, новый скилл, какой-нибудь Урон Холодом, сладко не будет.

Добавлено через 13 минут
Но, в общем то, на такой системе построены сотни "больших" игр, особенно RPG. Все, что нужно, это хорошенько продумать набор возможных скиллов, модификаторов и тд. Можно оптимизировать многие, например не делать отдельно bonus и damage, а сделать просто "модификатор здоровья Героя : -100..0..100". И прочие модификаторы (bonus/damage) к набору базовых характеристик - здоровье, скорость, стамина(запас сил), ловкость(инерция), скрытность, резист к физической атаке, резист к психологической атаке, резист к атаке стихиями, резист к яду, резист к магии.

[incvizitor]

Ну вообще я расматривал фичи типа телепорта и т.д. Но вот для реализации фичи "+1 жизнь" надо уже модельку уровня передавать. То есть надо еще как то понять, какие именно параметры предать стратегии. Пихать всё параметрами в один метод - как то вообще не по феншую.

Может быть тогда для персонажа использовать шаблон декоратор? На пример при "ударе холодом" мы обвертываем его свойства в оболочку которая замедляет его и добавляет в фильтры въюшки ColorMatrixFilter которым делает его синеватым на время эфекта.

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

[Wolsh]

Но вот для реализации фичи "+1 жизнь" надо уже модельку уровня передавать.

Есть такая штука как проценты) Ну и наконец просто умножение динамического уровня на статический модификатор от Элемента с каким-то коэфициентом. И, по сути, герой-то в игре один, все остальные – враги или друзья, не является концепцией, а только значениями модификаторов. Герой принципиально другой "конструкции", в частности у него нет списка "отношений к Герою", а у всех Элементов – по два списка, модификаторы для Героя и модификаторы для Элементов.
Фичи типа телепорта, разновидностей стен, инвертированной гравитации, пси-поле инвертирующее управление – в отличие от разновидностей сред в помещениях (вода, кислота, темнота, пожар, морозильник) не относятся к Элементам, так как воздействуют не на характеристики Героя и врагов, а на геймплей и свойства карты(позиционирования). То есть для них нужна другая, своя система. Хотя, про телепорт как раз не уверен... такой модификатор Элемента как "перемещаю на 5 позиций вверх" может пригодиться не только для телепорта, но и для ловушек и для "подбрасывающих врагов".

[expl]

Стратегия в контроллере ничего не даст - это точно.

Что делать?
Ни на что не претендую, но раз в _центральном_ контроллере возникает сумасшедший код - может _децентрализовать_ систему?
Т.е. позволить объектам самим решать, что делать. Тогда при добавлении нового элемента его поведение можно будет описывать прямо в нем.

А когда заканчивается время - переключать у всех объектов поведение в режим "паника" с помощью вашей любимой стратегии, например, но здесь это не суть.

Здравый смысл подсказывает, что если каждый элемент будет _особым_ образом взаимодействовать с каждым - получим комбинаторный взрыв (и не важно будем ли мы городить свитчи в контроллере или свитчи в объекте)
Т.е. надо универсализировать отношения с объектами.
Т.е., например у стены, пустой клетки, реки, кольев - сделать 3 характеристики: проходимость, прочность, наносимый вред.
Берем пакмана, у него слабая пробивная сила - значит он не пройдет через стену с проходимостью 1,
но пройдет через объект с проходимостью 2
Возьмем противника - он тоже не пройдет через препятствие (все! нам не надо знать стена это или еще что-то) с проходимостью больше 1
Возьмем суперпротивника - у него хорошая проходимость и он пройдет и через препятствие с проходимостью 1
Т.е. общие свойства у групп объектов выделить и работать с ними, абстрагироваться от конкретных объектов.

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

[Wolsh]

Вот и я о том же. Если Вы реально хотите (и я с Вами абсолютно солидарен), чтобы была возможность в будущем придумывать новых персонажей, новые ловушки/бонусы, новые среды на карте – Вам надо абстрагировать свойства элементов и обеспечить механизм взаимодействия именно свойств. Логика самой игры не должна вообще решать, что происходит с элементами при взаимодействии. Чтобы не дублировать код взаимодействия во всех элементах, и иметь возможность централизованно корректировать формулы/коэфициенты (например при изменении уровня), нужно создать в логике игры метод, который возьмет карту свойств одного элемента/героя и другого элемента в момент столкновения, и рассчитает результат взаимодействия для обоих, после чего вернет им карты полученных бонусов/повреждений, которые уже эти элементы обработают сами(!) по своим инкапсулированным законам, отобразят своей характерной анимацией (тот же урон Холодом). Этим Вы развяжете себе руки сделать каждый Элемент действительно уникальным и при этом совершенно свободно вписывать в реалии мира совершенно новые элементы, с одним набором, но разными значениями свойств.
Есть и другой способ организации этого дела.
Все возможные actions для элементов могут храниться списком. Каждому действию соответствует id, скажем 24-битный uint. Тогда каждому классу Элемента не нужно нести на борту пустую информацию, полную нулей. Он может содержать тупо массив айдишников тех действий, которые он оказывает. Ну может конечно и параметры к этим действиям, но во всяком случае не будет нести ничего лишнего. Что мы выигрываем, кроме веса классов))? Возможность придумывать и добавлять не только новых персонажей/элементы, но и новые действия малой кровью. То есть – придумали Вы совершенно новую фичу, врага с каким-то оружием, которого раньше вообще не было предусмотрено. Вам не нужно добавлять новый параметр (айдишник действия) во ВСЕ классы элементов. Вы добавляете его только тем, кто эту фичу использует или наоборот, может от нее пострадать. И в логике игры описываете, естественно, работу этой фичи. Возможно, в таком варианте визуальной обработкой может заниматься логика игры, а не сам элемент. На примере изморози при уроне Холодом думаю понятно, о чем речь и в чем красота такого решения.

[incvizitor]

Wolsh, expl, спасибо огромное за советы!

[dimarik]

Я вот тоже присоединяюсь к expl. И графы не забудьте! Ребра между клеток отражают скорость перемещения на этих участках для конкретного персонажа. Помните же, когда пакман или монстрики подаются вправо или влево по средней линии в край, они немного притормаживают. A-звезда, Дейкста будет рулить в данном механизме.