Как лучше поступить?
Вар.1: хранить большую БД, с тремя десятками полей для каждого задания (описания, требования для получения, награды, к чему открывает доступ и т.д.) и десятком для кв-итема.
Вар.2: по завершению каждого кв-итема вызывать ф-цию, в которой руками прописывать все необходимые действия.

Принятый ответ

Если умеешь в ООП, то можно сделать конструктор заданий, которые будут набираться из его деталей (структур).

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
16
6 лет назад
0
Clamp, подробней плз.
0
30
6 лет назад
Отредактирован Clamp
0
Представь квест в виде UML диаграммы.
0
16
6 лет назад
0
Clamp, как реализовать - я разберусь. Я не могу вкурить суть твоего конструктора.
На какие детали ты предлагаешь делить задания?
0
30
6 лет назад
0
А какие тебе нужны?
0
16
6 лет назад
0
Clamp, у меня на данный момент есть кучка модулей, каждый из которых вызывается в зависимости от данных в БД.
Каждый модуль отвечает за свой участок работ (визуализация заданий в журнале, отслеживание прогресса выполнения разных типов заданий, продвижение по этапам задания итд).
Но это же явно не то, что ты имел в виду, да?
6
28
6 лет назад
Отредактирован nvc123
6
avuremybe, каждый квест будет иметь 3 поля
событие при котором запускается квест
условие прохождения
и награда при прохождении
для каждого из 3 полей создай по 1 классу которые ничего не делают и только содержат необходимые методы
далее создай классы наследующие базовый и переопределяющие эти методы
советую чтобы среди этих классов были классы контейнеры способные хранить другие объекты своего типа
например класс GroupEvent наследует класс Event и содержит в себе список объектов класса Event
класс Event содержит метод check который возвращает true
класс GroupEvent переопределяет метод check который возвращает true лишь в том случае если все содержащиеся в нём объекты класса Event вернут true
с точки зрения использования система будет выглядеть следующим образом
Quest q=new Quest();
GroupEvent gr=new GroupEvent();
Event e0=new EventGoldMore(5000); // класс у которого check возвращает true если золота больше чем 5000
Event e1=new EventQuestDone(myQuest); //класс у которого check возвращает true если квест myQuest был завершён
gr.addEvent(e0);
gr.addEvent(e1);
q.setEvent(gr); // в результате квест q будет начат тогда когда у игрока более 5000 золота и он выполнил квест myQuest
0
30
6 лет назад
Отредактирован Clamp
0
avuremybe, ты не совсем меня понял (тут ты верно подметил С=). Возьми все свои квесты в куче и выдели абстрактные сущности, которые можно найти в каждом из них (пример: в каждом квесте наверняка есть награда, но даже если есть квесты без награды, в них всё равно можно её выделить, хоть и нулевую). Для каждой такой сущности создай общую обёртку (интерфейс), которая будет требоваться для создания любого квеста, и в наследуемых классах расширяй её.
Таким образом ты получишь состоящую из стандартных деталей универсальную конструкцию, на которой будет строиться любой квест, причём сами детали могут быть сколь угодно сложными. Наверняка окажется, что некоторые квесты будут иметь схожее строение той или иной детали, и ты сможешь выделить их в универсальную для этого типа квестов структуру, по сути переиспользуя её код.


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

Ещё небольшое замечание.
для каждого из 3 полей создай по 1 классу которые ничего не делают и только содержат необходимые методы
Лучше использовать не классы (структуры, если говорить о варкрафте), а интерфейсы.

А, и ещё. Стоит хранить в базовой структуре квеста не только условия прохождения, но и условия провала.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.