Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 03.02.2017, 14:39
Wormhole вне форума Посмотреть профиль Отправить личное сообщение для Wormhole Найти все сообщения от Wormhole
  № 1  
Ответить с цитированием
Wormhole
 
Аватар для Wormhole

Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
Attention Пара вопросов по архитектуре

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

1. Есть группа объектов. Она обширная (насчитывает более 200 элементов в планах и будет дополняться новыми). Каждый объект имеет одинаковый набор однотипных методов, отличающихся только реализацией. Стоит ли засорять приложение сотнями классов: по одному на каждый подобный объект или можно решить задачу более мирным путем?
Речь идет про способности героев. Они представлены классом Ability, имеют свойства типа перезарядки (и в этом не отличаются), а также должны каким бы то ни было способом вызываться (т. е. применяться в игре). Проблема в том, что способность может делать кучу ништяков - от банального нанесения урона до наложения и диспелла баффов. Разные спсобности - разные наборы действий.
И вот что меня до конца вводит в ступор - так это то, что многие значения, играющие роль в использовании способности, должны еще и обрабатываться. Например, если способность наносит урон, то для него надо будет еще посчитать крит и добавить бонус к урону от надетых предметов на урон (они могут быть не на урон или даже отсутствовать). И при этом, мы не знаем подробности внутренней реализации применения способности!

Собственно, идея про сотни классов была вызвана книгой про паттерны, где во многих примерах в аналогичных ситуациях создавали по классу на объект, например, в главе про Фабричный метод на каждое сочетание типа пиццы и ее стиля было создано по классу. По мне так, это решение не очень, но идея была и я ее изложил. Проблему засоренности можно в крайнем случае решить переносом всех классов способностей в отдельный подпакет, но что начнется, когда в очередном патче надо будет изменить урон и длительность эффекта в, скажем, 10 способностях, образовывавших имбалансное комбо! Рыться во всех 10 классах?

2. Каждого персонажа (npc и игрока, они ведь сходны) представлял класс Unit. Согласно принципу одной обязанности я даже поделил Unit на BattleUnit и RoamingUnit - персонаж в бою (с такими показателями как хп и мана, способный получать урон, тратить ману,..., с постоянными характеристиками) и персонаж после боя (можно менять экипировку, качать характеристики и прочее). Второй класс доступен только для игрового персонажа, на основе его собирается соответствующий BattleUnit. NPC'шные же BattleUnit'ы имеют набор характеристик и способностей и логику, соответствующий их уникальному id.

Имеет ли смысл использовать паттерн Строитель для этой задачи, чтобы собирать npc "по частям"? Как тогда сосредоточить декларацию всех свойств всех юнитов в одном месте? Нужно легко добавлять новых юнитов по ходу разработки.
Стоит ли также применить Строитель для сборки игрового персонажа - ведь на нее влияют характеристики, например, количество здоровья зависит от очков живучести?

3. В режиме просмотра инвентаря и характеристик отображается внешний вид игрока, его инвентарь, экипировка, атрибуты. В нем же их и надо менять. Хорошо ли здесь зайдет паттерн MVC? Модель - RoamingUnit, представление, соответственно, экран, ну и контроллер прикрутить для слабой связности. Если да, то как хранить в контроллере ссылку на объект RoamingUnit, а не сам объект?

Пока что все. Вопросов, конечно, больше, но их я буду задавать как-нибудь позже. Простите что так много написал, сложно структурировать информацию, в которой сам не до конца разбираешься.
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe

Старый 03.02.2017, 15:05
callme вне форума Посмотреть профиль Отправить личное сообщение для callme Найти все сообщения от callme
  № 2  
Ответить с цитированием
callme
 
Аватар для callme

Регистрация: Dec 2014
Сообщений: 312
Лучше от отдельному топику для каждого вопроса.

По третьему вопросу: какие цели ты преследуешь, пытаясь использовать MVC в данном случае?

Старый 03.02.2017, 15:23
Wormhole вне форума Посмотреть профиль Отправить личное сообщение для Wormhole Найти все сообщения от Wormhole
  № 3  
Ответить с цитированием
Wormhole
 
Аватар для Wormhole

Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
Цитата:
Сообщение от callme Посмотреть сообщение
По третьему вопросу: какие цели ты преследуешь, пытаясь использовать MVC в данном случае?
Если я правильно себя помню (пишу по собственным запискам), то возможность централизовать комбинированные действия и логику. Например, когда пользователь кликает по иконке способности, то формируется соответствующий запрос, т. е. просто вызывается метод контроллера. В контроллере обрабатываются проверки на достаточность очков способностей, на изученность необходимых предыдущих способностей, выясняется, на какой лвл качать, в соответствии с этим контроллер отдает несколько запросов Unit'у: апнуть лвл способности, затем убрать одно очко способности и прочее. Внесенные изменения сразу отражаются в пользовательском интерфейсе.
Если изменятся логические правила, то я всего лишь лезу в контроллер и ищу соответствующий обработчик. Если изменится интерфейс класса Unit (например, новые возможности, которые надо учесть), то же самое. Без MVC, как мне кажется, код запутается между gui и Unit'ом и сильно свяжет эти два элемента друг с другом, в то время как MVC предоставит элегантную и интуитивно понятную схему

Цитата:
Сообщение от callme Посмотреть сообщение
Лучше от отдельному топику для каждого вопроса.
Просто 1 и 2 у меня плотно связвались. То, что станет понятно для Ability, скорее всего, пригодится и для Unit. Впрочем, постараюсь в следующий раз так не делать
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe

Старый 03.02.2017, 16:03
callme вне форума Посмотреть профиль Отправить личное сообщение для callme Найти все сообщения от callme
  № 4  
Ответить с цитированием
callme
 
Аватар для callme

Регистрация: Dec 2014
Сообщений: 312
MVC применяется, в первую очередь, чтобы одна и та же модель могла отображаться в разных вьюшках. В твоем случае всего одна вьюшка. Получается MVC здесь не подходит.

Старый 03.02.2017, 16:48
Wormhole вне форума Посмотреть профиль Отправить личное сообщение для Wormhole Найти все сообщения от Wormhole
  № 5  
Ответить с цитированием
Wormhole
 
Аватар для Wormhole

Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
Цитата:
Сообщение от callme Посмотреть сообщение
MVC применяется, в первую очередь, чтобы одна и та же модель могла отображаться в разных вьюшках. В твоем случае всего одна вьюшка. Получается MVC здесь не подходит.
Спасибо. А что насчет 1 и 2?
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe

Старый 03.02.2017, 17:19
callme вне форума Посмотреть профиль Отправить личное сообщение для callme Найти все сообщения от callme
  № 6  
Ответить с цитированием
callme
 
Аватар для callme

Регистрация: Dec 2014
Сообщений: 312
Цитата:
Сообщение от Wormhole Посмотреть сообщение
Спасибо. А что насчет 1 и 2?
1 вопрос. Не знаю ответа.
2 вопрос. Не понимаю паттерн Строитель.

Старый 03.02.2017, 17:48
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 7  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Не делай по классу на каждую способность или тип способности.
Сперва полностью продумай структуру всех данных.

Способности:
Название, кд, стоимость, необходимый лвл, эффект.

Эффекты способностей:
Тип действия (урон, лечение, воскрешение), значениеА, значениеБ, значениеС ... (Используются под конкретный тип действия. Например, у лечения только значениеА, у урона по местности А и Б, у урона по местности с конкретной шкалой магий 3 значения - дамаг, радиус, шкала)

Далее создаёшь способности простым добавлением новых записей в таблицу. В игре будет всего по одному классу: Ability, AbilityEffect и ещё список, где будет храниться кулдавн по каждой способности у игрока.
__________________
Дети не должны знать о своих родителях

Старый 03.02.2017, 18:33
Wormhole вне форума Посмотреть профиль Отправить личное сообщение для Wormhole Найти все сообщения от Wormhole
  № 8  
Ответить с цитированием
Wormhole
 
Аватар для Wormhole

Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
Цитата:
Сообщение от Tails Посмотреть сообщение
Не делай по классу на каждую способность или тип способности.
Сперва полностью продумай структуру всех данных.

Способности:
Название, кд, стоимость, необходимый лвл, эффект.

Эффекты способностей:
Тип действия (урон, лечение, воскрешение), значениеА, значениеБ, значениеС ... (Используются под конкретный тип действия. Например, у лечения только значениеА, у урона по местности А и Б, у урона по местности с конкретной шкалой магий 3 значения - дамаг, радиус, шкала)

Далее создаёшь способности простым добавлением новых записей в таблицу. В игре будет всего по одному классу: Ability, AbilityEffect и ещё список, где будет храниться кулдавн по каждой способности у игрока.
Но тогда получается неясность значений - нигде напрямую не сказано, что у урона по области значение А используется именно для количества урона, а значение Б - для радиуса области действия
И в какую таблицу и что я буду добавлять, когда захочу создать способность?
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe

Старый 03.02.2017, 19:00
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 9  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Я тоже думаю, что неясные значения не нужны. Пусть в шаблоне Способность все возможные значения будут представлены явно. Если какие-то свойства бессмысленны для данного конкретного экземпляра, пусть хранят ноль и всё. Допустим, свойство СпособВоздействия — на себя, касанием, на цель, цепная реакция на группу целей, на область. Соответственно, свойство ДальностьВоздействия не имеет смысла для первых двух Способов, а для двух последних нужен еще параметр РадиусВоздействия. Однако сами эти параметры, Дальность и Радиус, вполне могут быть у всех способов воздействия, просто равны нулю там, где не играют никакой роли.

Добавлено через 5 минут
Классическим паттерном для снаряжения персонажа и юнитов считается Декоратор.

Добавлено через 16 минут
Цитата:
Сообщение от callme Посмотреть сообщение
MVC применяется, в первую очередь, чтобы одна и та же модель могла отображаться в разных вьюшках. В твоем случае всего одна вьюшка. Получается MVC здесь не подходит.
Мне это кажется слишком категоричным. MVC допускает использование нескольких вью, как и нескольких контроллеров, но вовсе не ставит это целью.
__________________
Reality.getBounds(this);

Старый 03.02.2017, 19:39
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 10  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
Сообщение от Wormhole Посмотреть сообщение
Но тогда получается неясность значений - нигде напрямую не сказано, что у урона по области значение А используется именно для количества урона, а значение Б - для радиуса области действия
И в какую таблицу и что я буду добавлять, когда захочу создать способность?
Wolsh предложил отличный вариант, используй его.

Сперва продумываешь структуру всех данных, что вообще есть в игре и как оно друг с другом связанно. (По примеру со способностями и их эффектами) А потом заполняешь её там, где эта структура у тебя будет храниться. (Бд, конфиг файл или прямо так - захардкодить)
__________________
Дети не должны знать о своих родителях

Создать новую тему Ответ Часовой пояс GMT +4, время: 22:56.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 22:56.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.