|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
|
Пара вопросов по архитектуре
Делаю игру (пошаговая стратегия, по типу этой), по возможности пытаюсь применить новые знания в области ООП и паттернов, когда это помогает решить задачу наиболее просто и эффективно. Но так как я не так давно обратил внимание на программирование на уровне интерфейсов, принципы абстракции и полиморфизма, и это, по сути, моя проба пера, возникает довольно много проблем, которые я решить не могу. Помучавшись над ними, я решил спросить здесь. Возможно, будет немного скомканно, но это как раз из-за того, что я запутался.
1. Есть группа объектов. Она обширная (насчитывает более 200 элементов в планах и будет дополняться новыми). Каждый объект имеет одинаковый набор однотипных методов, отличающихся только реализацией. Стоит ли засорять приложение сотнями классов: по одному на каждый подобный объект или можно решить задачу более мирным путем? Речь идет про способности героев. Они представлены классом Ability, имеют свойства типа перезарядки (и в этом не отличаются), а также должны каким бы то ни было способом вызываться (т. е. применяться в игре). Проблема в том, что способность может делать кучу ништяков - от банального нанесения урона до наложения и диспелла баффов. Разные спсобности - разные наборы действий. И вот что меня до конца вводит в ступор - так это то, что многие значения, играющие роль в использовании способности, должны еще и обрабатываться. Например, если способность наносит урон, то для него надо будет еще посчитать крит и добавить бонус к урону от надетых предметов на урон (они могут быть не на урон или даже отсутствовать). И при этом, мы не знаем подробности внутренней реализации применения способности! Собственно, идея про сотни классов была вызвана книгой про паттерны, где во многих примерах в аналогичных ситуациях создавали по классу на объект, например, в главе про Фабричный метод на каждое сочетание типа пиццы и ее стиля было создано по классу. По мне так, это решение не очень, но идея была и я ее изложил. Проблему засоренности можно в крайнем случае решить переносом всех классов способностей в отдельный подпакет, но что начнется, когда в очередном патче надо будет изменить урон и длительность эффекта в, скажем, 10 способностях, образовывавших имбалансное комбо! Рыться во всех 10 классах? 2. Каждого персонажа (npc и игрока, они ведь сходны) представлял класс Unit. Согласно принципу одной обязанности я даже поделил Unit на BattleUnit и RoamingUnit - персонаж в бою (с такими показателями как хп и мана, способный получать урон, тратить ману,..., с постоянными характеристиками) и персонаж после боя (можно менять экипировку, качать характеристики и прочее). Второй класс доступен только для игрового персонажа, на основе его собирается соответствующий BattleUnit. NPC'шные же BattleUnit'ы имеют набор характеристик и способностей и логику, соответствующий их уникальному id. Имеет ли смысл использовать паттерн Строитель для этой задачи, чтобы собирать npc "по частям"? Как тогда сосредоточить декларацию всех свойств всех юнитов в одном месте? Нужно легко добавлять новых юнитов по ходу разработки. Стоит ли также применить Строитель для сборки игрового персонажа - ведь на нее влияют характеристики, например, количество здоровья зависит от очков живучести? 3. В режиме просмотра инвентаря и характеристик отображается внешний вид игрока, его инвентарь, экипировка, атрибуты. В нем же их и надо менять. Хорошо ли здесь зайдет паттерн MVC? Модель - RoamingUnit, представление, соответственно, экран, ну и контроллер прикрутить для слабой связности. Если да, то как хранить в контроллере ссылку на объект RoamingUnit, а не сам объект? Пока что все. Вопросов, конечно, больше, но их я буду задавать как-нибудь позже. Простите что так много написал, сложно структурировать информацию, в которой сам не до конца разбираешься.
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe |
|
|||||
Регистрация: Dec 2014
Сообщений: 312
|
Лучше от отдельному топику для каждого вопроса.
По третьему вопросу: какие цели ты преследуешь, пытаясь использовать MVC в данном случае? |
|
|||||
Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
|
Цитата:
Если изменятся логические правила, то я всего лишь лезу в контроллер и ищу соответствующий обработчик. Если изменится интерфейс класса Unit (например, новые возможности, которые надо учесть), то же самое. Без MVC, как мне кажется, код запутается между gui и Unit'ом и сильно свяжет эти два элемента друг с другом, в то время как MVC предоставит элегантную и интуитивно понятную схему Просто 1 и 2 у меня плотно связвались. То, что станет понятно для Ability, скорее всего, пригодится и для Unit. Впрочем, постараюсь в следующий раз так не делать
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe |
|
|||||
Регистрация: Dec 2014
Сообщений: 312
|
MVC применяется, в первую очередь, чтобы одна и та же модель могла отображаться в разных вьюшках. В твоем случае всего одна вьюшка. Получается MVC здесь не подходит.
|
|
|||||
Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
|
Спасибо. А что насчет 1 и 2?
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe |
|
|||||
Регистрация: Dec 2014
Сообщений: 312
|
1 вопрос. Не знаю ответа.
2 вопрос. Не понимаю паттерн Строитель. |
|
|||||
Не делай по классу на каждую способность или тип способности.
Сперва полностью продумай структуру всех данных. Способности: Название, кд, стоимость, необходимый лвл, эффект. Эффекты способностей: Тип действия (урон, лечение, воскрешение), значениеА, значениеБ, значениеС ... (Используются под конкретный тип действия. Например, у лечения только значениеА, у урона по местности А и Б, у урона по местности с конкретной шкалой магий 3 значения - дамаг, радиус, шкала) Далее создаёшь способности простым добавлением новых записей в таблицу. В игре будет всего по одному классу: Ability, AbilityEffect и ещё список, где будет храниться кулдавн по каждой способности у игрока.
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
|
Цитата:
И в какую таблицу и что я буду добавлять, когда захочу создать способность?
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Я тоже думаю, что неясные значения не нужны. Пусть в шаблоне Способность все возможные значения будут представлены явно. Если какие-то свойства бессмысленны для данного конкретного экземпляра, пусть хранят ноль и всё. Допустим, свойство СпособВоздействия — на себя, касанием, на цель, цепная реакция на группу целей, на область. Соответственно, свойство ДальностьВоздействия не имеет смысла для первых двух Способов, а для двух последних нужен еще параметр РадиусВоздействия. Однако сами эти параметры, Дальность и Радиус, вполне могут быть у всех способов воздействия, просто равны нулю там, где не играют никакой роли.
Добавлено через 5 минут Классическим паттерном для снаряжения персонажа и юнитов считается Декоратор. Добавлено через 16 минут Мне это кажется слишком категоричным. MVC допускает использование нескольких вью, как и нескольких контроллеров, но вовсе не ставит это целью.
__________________
Reality.getBounds(this); |
|
|||||
Цитата:
Сперва продумываешь структуру всех данных, что вообще есть в игре и как оно друг с другом связанно. (По примеру со способностями и их эффектами) А потом заполняешь её там, где эта структура у тебя будет храниться. (Бд, конфиг файл или прямо так - захардкодить)
__________________
Дети не должны знать о своих родителях |
Часовой пояс GMT +4, время: 22:56. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|