Как сделать квест менеджер

[markII]

Здравствуйте!Столкнулся с проблемой создания квестов для игры(типа как любимой ферме собрать 5 огурцов, убрать 10 деревьев и .т.д.).Подскажите пожалуйста с чего можно начать; вообще как правильно организовать такую архитектуру.Может быть кто то уже с этим сталкивался и знает все подводные камни.Я не прошу делать это за меня.Просто хотя бы подскажите в какую сторону копать(Главное чтобы эта сторона была верным направлением).Заранее благодарен.

[Dukobpa3]

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

Начать следует с описания самой сущности квеста, что это и с чем едят, требования для выполнения(в какой момент становится активным), результаты выполнения(что получим по завершении), процесс выполнения(клики, таймер, позвать друга, прочая муть).

Ну а потом уж как карта ляжет.

[markII]

требования для выполнения(в какой момент становится активным)

каждый квест должен срабатывать после того как он будет выполнен предыдущий.

процесс выполнения(клики, таймер, позвать друга, прочая муть).

Т.к. Квесты обычно не однообразные(допусти это может быть пополнение ресурсов таких как картошка, овощи ,фрукты, инвентарь, строения и.т.д.),потом результат квеста может быть таким, как ,например, подружиться с кем то или поговорить, может быть результат покупки товара в магазине, приглашение друзей и т.д.В общем ход выполнения может быть совершенно любой а результат один - за выполнение квеста должны начислять очки и через несколько квестов уровень игрока должен увеличиваться.Может быть надо как то типизировать эти квесты или еще что то в этом роде

[Dukobpa3]

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

Ну собственно удачи в начинаниях)) И лучше все-таки конкретные вопросы.

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

Возможно у вас там будут какие-то группы квестов,возможно будут какие-то периодические квесты и сюжетные. Это опять же нужно как-то представить на бумаге для себя чтоб понимать о чем речь.

[markII]

Ясно.Спасибо большое.У меня вот появилась идея сделать QuestController дабы разграничить квесты по типу назначения.Скорее всего сгруппирую их по типам.Дело в том что непонятно как инициализировать нужный квест.Т.е. я должен где то хранить текущий questID и относительно его давать следующий по порядку.Сначала я хотел описать все квесты в xml файлы но потом понял что это ни к чему не приведет, так как уж больно разнотипные квесты.В общем главное для меня осталось не ясно в каком виде их хранить и как их инициализировать.То ли их БД ,то ли в xml загружать.Так что интересен вопрос в каком виде принимать квесты и как мне их описать(т.е. в каком виде представить)

[goodguy]

в XML удобнее хранить такие вещи, есть смысл так же делать хотя бы примитивное шифрование XML файлов, чтобы любой дилетант не мог посмотреть решение

[Dukobpa3]

Ну тут щас набегут советчики.

Я предпочитаю джейсон ибо есть куча инструментов для конвертации джейсона в стандартные обжекты ас3.
Много кто любит хмл, так как при работе с хмл можно никакие обжекты и не юзать а просто брать данные из того самого хмл посредством своего языка запросов (е4х кажись, поправьте если ошибаюсь, не используюпотому не вкурсе).

Опять же и джейсон и хмл могут быть как просто файликами на диске, так и строковой записью в какой-то бд.

Если БД носкуль - то там скорее всего нативный формат джейсон в который можно будет из этой самой базы выгрузить нужные данные.

Короче опять же, вариантов море, а посему мой совет не заморачиваться и работать с тем с чем лучше всего умеете)

[goodguy]

Я предпочитаю джейсон ибо есть куча инструментов для конвертации джейсона в стандартные обжекты ас3.

Есть вещи, в которых XML на две головы выше джейсона.
Это как раз тот случай. Описание уровня с помощью джейсона будет выглядеть как каша. Я даже не уверен, что джейсон вообще справится со всеми задачами, с которыми справляется XML.
Джейсон хорош как язык передачи данных, но для хранения уровней XML все-таки лучше

[Dukobpa3]

Меня ни в чем убеждать не надо)) Свое имхо высказал.

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

Добавлено через 1 минуту
И примеры можно где хмл будет лучше? Я с ним действительно мало работал и не вкурсе. На будущее учту обязательно.

[goodguy]

И примеры можно где хмл будет лучше?

Я же уже написал где он лучше. Зачем вообще хранить уровень в базе, когда можно хранить его в xml файле? И добавлять и удалять проще, и выглядит структура такого файла аккуратнее, + можно без каких-либо скриптов открыть файл вручную и посмотреть что там внутри. Да и заморочек с базой данных не будет