Выбор паттерна проектирования.

[бакуард]

Доброго времени суток.

Какой паттерн проектирования лучше использовать для следующей ситуации: есть игра 2D платформер. Имеется больше сотни видов различных платформ и 50 видов существ (эти цифры в дальнейшем могут сильно меняться, как в большую, так и в меньшую сторону). Каждый вид существ взаимодействует с некоторыми видами платформ специфическим только для них образом (в дальнейшем, виды платформ с которыми данный вид существ может взаимодействовать, могут поменяться на другие, как и способ взаимодействия с ними).

Какой паттерн лучше выбрать, чтобы все изменения с добавлением новых видов объектов или их изменением были централизованы в одном месте?

Кто сталкивался с подобной проблемой, подскажите пожалуйста как можно её решить.
Если можно скиньте ссылку.

[caseyryan]

Зачем тут какие-то паттерны? Это же простое наследование. ПростоПлатформа -> ПрыгющаяПлатформа -> ИсчезающаяПрыгающаяПлатформа -> ПлатформаЛовушкаДляДинозавровКотораяИсчезаетИПрыгает -> БлаБлаБлаПлатформа ....

[i.o.]

Предлагаю посмотреть в сторону паттерна Bridge и Decorator

[gloomyBrain]

Я бы каждый тип взаимодействия вынес в отдельный класс. А далее внутри платформы добавил бы Dictionary, в котором ключи - это классы существ, а значения - это экземпляры взаимодействий. Соответчтвенно у каждой платформы будет возможность применить (или не применять) взаимодействие для заданного класса существа. Чем-то напоминает паттерн "посетитель", если вам нужен именно паттерн ))

[PainKiller]

Про взаимодействия, только недавно читал, может пригодится http://gamedevelopment.tutsplus.com/tutorials/how-to-implement-and-use-a-message-queue-in-your-game--cms-25407

[callme]

Про взаимодействия, только недавно читал, может пригодится http://gamedevelopment.tutsplus.com/tutorials/how-to-implement-and-use-a-message-queue-in-your-game--cms-25407

Просто кладешь экземпляр класса EventDispatcher в глобальную переменную и все события через этот экземпляр кидаешь.

[i.o.]

глобальные переменные... мммм...

[callme]

глобальные переменные... мммм...

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

мууу :)

[GBee]

Просто кладешь экземпляр класса EventDispatcher в глобальную переменную и все события через этот экземпляр кидаешь.
Вы только картинки посмотрели? :о))

Автор, используй МВЦ, ахахаха

[callme]

GBee, конкретные претензии озвучьте.

[GBee]

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

[callme]

Когда забиваешь гвозди и топор подойдет, но лучше использовать молоток.

[dimarik]

Вопрос пока звучит так "посоветуйте как сделать свой falcon 9 применив хз знает что (паттерн? он подойдет?))".

[djyamato]

2 оси изменения (платформа и существо)
Бридж сложноват и очень легко ломается. Трудно читаем. Забудете что это был бридж, даже если напишете в комменте в коде это это бридж или назовете что-то Bridge-ем, например, класс или метод класса. Запутаетесь. Но мне приходит на ум именно он, хотя не рекомендую.
Бридж служит для объединения двух систем, которые изменяются как хотят - две ости изменений.
А рекомендую видеоуроки Сергея Демчинского по шаблонам.
Там Вы найдете ответы
https://www.youtube.com/results?search_query=%D1%81%D0%B5%D1%80%D0%B3%D0%B5%D0%B9+%D0%BD%D0%B5%D0%BC%D1%87%D0%B8%D0%BD%D1%81%D0%BA%D0%B8%D0%B9%20%D1%88%D0%B0%D0%B1%D0%BB%D0%B E%D0%BD%D1%8B
GoF1 итд, но посмотреть стоит все, там много хорошего
P.S. ТС, почитав вашу тему думаю что вы пытаетесь связать несвязаемое. Это даже не 2 оси изменения это 2 разных сабсистемы абсолютно не зависящие друг от друга. Одна строится по-своему, а другая по-своему. А вопрос, насколько я понял, состоит в том как описать layer (уж простите) в котором они будут взаимодейстовать друг с другом. Тут не паттер, а декомпозиция предметной области. Смотрите в сторону GRASP шаблонов (очень обобщенно), в сторону декомпозиции предметной области.
Что касаемо вашего вопроса, платформа не знает о существах, существа не знают о платформах (напрямую не дергают методы платформы, или ее переменные - инкапсуляция). Две абсолютно не знающие друг о друге системы, насколько я понял Вашу задачу. Делите их. Делите каждую из них на мелкие куски, независимые друг от друга. Повторяю, Немчинский великолепно читает

Добавлено через 24 минуты
Я думаю что порисовав UML диаграммы(это действительнро просто) Вы найдете решение средствами обычного ООП, а в каких-то конкретных местах будете использовать шаблоны

[i.o.]

Две абсолютно не знающие друг о друге системы, насколько я понял Вашу задачу. Делите их. Делите каждую из них на мелкие куски, независимые друг от друга.
Если поставить вопрос так, то падает выбор на Mediator)

[djyamato]

Я не до конца понимаю для чего тут вообще нужно применять шаблон на таком высоком уровне абстракции.
Хотя, медиатор действительно решает подобного рода задачи. Мне нравится пояснение медиатора на примере авиабазы http://cpp-reference.ru/patterns/behavioral-patterns/mediator/ Хотя, осмелюсь порекомендовать автору сначала попробовать решить архитектурные задачи средствами ООП, а затем уже: "Ага, где-то похожая задача решалась шаблоном. Елки, как же он зовется..."
P.S. Попробуйте решить задачу для начала обычным полиморфизмом