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

[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 файле? И добавлять и удалять проще, и выглядит структура такого файла аккуратнее, + можно без каких-либо скриптов открыть файл вручную и посмотреть что там внутри. Да и заморочек с базой данных не будет

[markII]

В принципе мне все стало намного яснее.Спасибо большое за ответы всем.C одной стороны конечно неплохо все запихнуть в один xml файл вручную.В этом есть много плюсов.Например такой xml файл может заполнять кто угодно, например, администратор игры.можно добавлять новые квесты не влезая в БД.Но есть и минус.Если квестов будет больше 100 , то объем такого файла будет почти мегабайт.И каждый раз при загрузке приложения он будет его скачивать.
С Базой данных тоже не все так просто.Во первых за каждый пройденный квест он будет записывать в БД и ждать ответа от сервера.Во вторых нужно сразу заполнять БД для того чтобы потом в нее не лазеть.Но есть плюсы - это экономия времени при загрузке приложения и гарантия того что этот файл никто не посмотрит.
Т.е. получается затык только в том , что квесты нужно передавать в разных форматах.Но эту проблемму решает JSON.Как написал Dukobpa3 можно хранить данные в базе в виде JSONа и парсить его в зависимости от заголовка которые будет в ответе от сервера.
В общем с одной стороны с xml все просто но не продуктивно .С другой стороны с БД все сложно но быстрее и безопаснее.Может быть надо выбрать тот способ которые гибче остальных?Вдруг что то придется добавлять или изменять

[Dukobpa3]

"Лучше потому что лучше" - имхо, не аргумент. С таким же успехом можно джейсон файлики на диске складировать и результат будет тем же.

[goodguy]

Я не говорил "Лучше потому что лучше", а подробно сказал почему лучше.
Джейсон описание уровня - каша-мала. Хуже читается - значит и сам подход хуже.

[Dukobpa3]

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

[-De-]

Квесты будут секретные только если их никому не будут выдавать)
Писать в базу каждый пройденный квест придётся в любом случае.
Вам нужно как можно быстрее узнавать, в каком состоянии квест. Быстрее всего - программа-сервер, постоянно висящяя в памяти, которая знает всё о квестах и игроках онлайн. Быстрее всего, т.к. всё о чем надо знает и делает только то, что надо, заточена конкретно под ваши квесты. Только её написать тяжело, не советую вообще.
Потом идёт БД. Потому что по сути у вас в любом случае будет БД, только в случае текстовых форматов вам надо будет предварительно её ещё и распарсить. Ну и информацию об игроке в любом случае из БД доставать, а так есть шанс, что на вопрос "что там у такого-то игрока с квестами" можно будет ответить одним запросом. Утилитку для редактирования квестов написать не сложно.
БД не должна быть для вас сложной, это базовая вещь вообще, не бойтесь её. Индексов главное налепить побольше =))

[Psycho Tiger]

У меня не так. Парсер лишний, только если хотите спихнуть работу на какого-нибудь другого человека )
У меня квесты выглядат так:
item = new TutorialItem();
item.position = new Point(100, 100);
item.header = "Купи себе значок!";
item.text = "Пионер без значка - как икра без кабачка!\nСкорее отправляйся в МАГАЗИН.";
item.unblockedSquares.push(new Rectangle(686, 80, 90, 80));
item.awaitingClickOnName = RightMenu.SHOP_BUTTON_NAME;
item.callbackWhenTrigger = tutorial1_waitingShopClickTrigger;
item.arrowAt = [665, 115, -90];
super.push(item);

Как видно, здесь можно задать, куда указывает стрелка, от какого элемента ожидается клик и т.д.
Если ожидается не клик, а ответ от сервера - я делаю диспатч баббл эвента, с номером туториала и номером шага. Если туториал сидит на этой точке - то считается, что пункт пройден. Ну, и много всякой ерунды ещё. Блокирую экран Sprite`ом, в котором режу дырки )
callbackWhenTrigger позволяет выполнить код, когда доходит до этого шага - там предоставляется необходимый функционал, вроде viewport.addOnTop у меня подсвечивает объект над областями затемнения. Так же там имеется доступ к главному контроллеру и я в принципе могу приказать что угодно кому угодно.

[Dukobpa3]

item.callbackWhenTrigger = tutorial1_waitingShopClickTrigger;
А что вот эта штука делает?

[Psycho Tiger]

Когда юзер доходит до этого TutorialItem (50 шагов - 50 TutorialItem`ов) - вызывается этот метод, если он указан.
В нём, например, можно сделать запрос на сервер, или приказать какому-нибудь окошку закрыться.

[Dukobpa3]

А где сами ссылки на коллбеки хранятся?

В итеме понятно. А до вот этой строчки: item.callbackWhenTrigger = tutorial1_waitingShopClickTrigger;
Откуда берется значение "tutorial1_waitingShopClickTrigger"?
Какая-то хитрая схема с формированием имени колбека и в таком духе? или хардкод, или где-то в каком-то списке хранится?

[markII]

item = new TutorialItem();
item.position = new Point(100, 100);
item.header = "Купи себе значок!";
item.text = "Пионер без значка - как икра без кабачка!\nСкорее отправляйся в МАГАЗИН.";
item.unblockedSquares.push(new Rectangle(686, 80, 90, 80));
item.awaitingClickOnName = RightMenu.SHOP_BUTTON_NAME;
item.callbackWhenTrigger = tutorial1_waitingShopClickTrigger;
item.arrowAt = [665, 115, -90];
super.push(item);
Скорее всего это квест забивается вручную, потому что нужен только для тьюториала на сколько я понял.А как быть если item.callbackWhenTrigger = tutorial1_waitingShopClickTrigger; задавать динамически?

[Psycho Tiger]

Да, хардкод, конечно.
Например такой триггер:
private function tutorial2_onInvite():void {
//invite panel
Odnoklassniki.showInvite("Вступай со мной в пионерский отряд, будем играть вместе!", null);
super.nextStep();
}
И в коде соответственно
item.callbackWhenTrigger = tutorial2_onInvite;

@markII, а зачем туториалу что-то менять динамически?

[markII]

а зачем туториалу что-то менять динамически?Psycho Tiger нет мне не для туториала нужно.Я пытаюсь сделать архитектуру для квест менеджера.Поэтому все квесты должны загружаться динамически(я же не буду забивать около 100 квестов вручную).С туториалом немного полегче.Я делал его немного по другому.У меня был мувклип с порезанными масками и стрелочками.я написал класс который слушает события по определенному сценарию.На каждом шаге я вешал листерны хардкорно в зависимости от шага туториала и все нормально работало.С квестами все намного сложнее если они не в туториале

[Dukobpa3]

Ну вообще эта реализация натолкнула меня на мысли с иньекциями.

Делается некий класс со списком ссылок на функции внутри.

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

Далее в том месте где инстансы квестов инициализируются можно брать эти функции из этого списка и присваивать в переменную класса.

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

У меня так сделана обработка данных с сервера. Но там так Классы инжектятся, насчет коллбеков так не пробовал но можно попробовать.

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

[markII]

Т.е. я так понял ты имеешь ввиду следущее :
1 - сделать массив с айдишниками квестов.
2 - В каждую ячейку массива положить строковые имена событий(их может быть несколько а может быть только одно)
3 - повесить слушатели на эти события.Как только эти события выполнятся, то проверять эти события с теми данными которые я указал в квесте.Например у меня там указано собрать 3 огурца.Тогда когда я собрал 3 или больше огурцов(положил их в модель или еще куда то),то поднимается событие СucumberUpdateEvent(UPDATE,numCucumber:Number) , где numCucumber - это количество огурцов которых собрали.И по идее функция обработчик считает что огурцов 3 , удаляет этот слушатель, и отправляет результат на сервер с текущим id квеста, сервер отвечает, повышается уровень ну и вся вытекающая муть .В общем приходит новый айдишник квеста, вешаются новые слушатели ну и так далее.
Получается затык только в функции обработчике, которая ловит эти слушатели .Так как события все разные то и функции должны обрабатывать все события по разному.Как быть тогда с этой функцией-обработчиком, чтобы она обрабатывала разные события?

[Dukobpa3]

// В родительском классе подписываемся
cucumberQuest.addEventListener(QuestEvent.QUEST_DONE, onCucumerQuestDone);
cucumberQuest.someParam = "блаблабла"

//*********************************
// в квесте диспатчим
dispatchEvent(new QuestEvent(QuestEvent.QUEST_DONE, someParam))

//*********************************
//обработчик в родительском
private function onCucumerQuestDone(event:QuestEvent):void
{
if(event.currentTarget.data == "блаблабла"){}
}

[markII]

//*********************************
// в квесте диспатчим
dispatchEvent(new QuestEvent(QuestEvent.QUEST_DONE, someParam))
Мы берем инстанс этого класса из массива по айдишнику текущего квеста.Вешаем на него слушателя. Все стало ясно, но я не понимаю как этот класс должен получать откуда то данные которые ему нужны для того чтобы продиспачить это событие?
//*********************************
//обработчик в родительском
private function onCucumerQuestDone(event:QuestEvent):void
{
if(event.currentTarget.data == "блаблабла"){}
}
так как этот обработчик в родительском классе то это значит что мне надо под каждый класс квеста написать свой обработчик этого события
//*********************************
// в квесте диспатчим
dispatchEvent(new QuestEvent(QuestEvent.QUEST_DONE, someParam))
тогда получается что мне нужно диспачить разные события для каждого квест класса?Например

dispatchEvent(new СucumberQuestEvent(СucumberQuestEvent.QUEST_DONE, someParam))
Так?

[Dukobpa3]

Да нет же.

1. Данные можно брать из некоего класса-списка констант или бд или хмл, вобщем какое-то хранилище данных с описаниями квестов.
2. ну вообще необязательно. В идеале один обработчик со свичем по какому-о параметру в самом событии. И да, событие придется написать кастомное, чтобы в нем было несколько параметров. Например один из параметров может быть тип квеста, а остальные - это те данные которые нужны в этом типе квеста.
3. Диспатчится одно событие, но внутри него есть пачка с данными которые могут отличаться в зависимости от типа квеста.

Кастомный параметр может быть и один всего, но с типом обжект, а в этот обжект уже пихаем всё что нужно.

[terbooter]

масочки с дырочками :)
Как-то кустарно очень.

[markII]

Данные можно брать из некоего класса-списка констант или бд или хмл, вобщем какое-то хранилище данных с описаниями квестов.
я имел ввиду данные которые должен отследить квест.Т.е. если я собрал 3 огурца, то квест менеджер должен поймать это события, что 3 огурца собрано.Откуда он будет знать что 3 огурца собрано, чтобы продиспачить событие dispatchEvent(new QuestEvent(QuestEvent.QUEST_DONE, someParam)) ?

[Dukobpa3]

масочки с дырочками
Как-то кустарно очень.

Так полет фантазии же:))

[markII]

масочки с дырочками
Как-то кустарно очень.
Сроки были маленькие поэтому за один день это первое что пришло на ум )))

[Dukobpa3]

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

[markII]

У меня появилась идея как это сделать.Т.к. будут отдельные классы квестов для каждого типа квеста(По идее их не должно быть более 10-15 типов), то в этих квестах будут уже прописанны слушатели на определенные события.Допустим если при самом првом квесте мне надо собрать 3 огурца то я просто активирую слушатели для класса cucumberQuest.Например так cucumberQuest.activateListeners(params) и передаю туда нужные параметры для каждого квеста cucumberQuest.activateListeners(3) - собрать 3 огурца.
Тогда этот квест будет слушать , допустим, изменение состояния модели (когда пополниться урожай на 3 огурца).После этого квест диспачит событие dispatchEvent(new СucumberQuestEvent(СucumberQuestEvent.QUEST_DONE, someParam)).
После этого обработчик ловит это событие и проверяет соответствует ли значение собранных огурцов указанному в квесте.Если да то квест выполнен и отсылается событие на сервер.После этого я деактивиую квест и он больше не будет ловить это событие.Мне кажется что у этой схемы есть плюс в том что можно делать комбинированные квесты.(Т.е. объединять 2 квест класса в один путем наследования просто и все).Но есть минусы в том что нужно много кода писать (Каждый тип квеста + обработчик к нему).Как такая схема?

[Psycho Tiger]

масочки с дырочками :)
Как-то кустарно очень.
А ещё я экран блокирую большим прозрачным спрайтом для мышки. Табы отключены.

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

А вообще, чисто архитектура... много раз я делал "крутую штуку", которая любила обрастать костылями в конце своего пути, в силу того, чтобы до жути инкапсулированная система из независимых модулей интересно так между собой общалась. Сейчас я работаю по принципу: код должен быть реюзабелен до той степени, до которой нет и намека на неудобство со стороны хай-левел-кодинга. Да, когда я реиспользую свои классы. Но всё больше понимаю, что нетронуто должен быть совсем ядро этих библиотек/фреймворков, некий энвоирмент вокруг них процентов на 20-30 переписывается. Да, не очень круто. Но очень круто потом, когда программа не является налепленным друг на друга костылями, чтобы "сцепить" эти либы.

Я это к чему: Вам настолько нужен очень-очень крутой туториал-менеджер?

[markII]

Я это к чему: Вам настолько нужен очень-очень крутой туториал-менеджер?
Нет.Тема называется квест менеджер.Я конечно понимаю, что квест может быть частью туториала,но пока мне нужно только сделать механизм запуска, обработки и результат очереди квестов - тобиш квест менеджер

[Dukobpa3]

В таком случае достаточно будет двух-трех основных классов.

Собственно сам квест который сможет либо коллбеками либо событиями что-то куда-то передавать и маячить о текущем состоянии.

Ну и манагер который будет в себе содержать список квестов и понимать каждый отдельный квест и уметь принимать некие решения в зависимости от результатов того или иного этапа каждого конкретного квеста. Всё.

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

Добавлено через 4 минуты
Кстати про масочки с дырочками:))
Тоже считаю это костылем, но в одном нашем проекте именно так реализована обучалка)) и ниче, вродь пока работает. Правда на будущее себе прикинул более гломурную систему. Хотя тут двояко. У меня не раз бывало когда погрязнув в AbstractioFreek's раздумьях и реализациях закапывался в такую *опу что потом всё это нафиг удалялось и переписывалось за пару часов на первый взгляд костыльно, но тем не менее рабоче:) Не всегда очень красивая на первый взгляд архитектура и реализация является такой в действительности:) Как и на первый взгляд костыль не всегда таковым является:)

Добавлено через 5 минут
Постепенно прихожу к мысли что нужно писать в первую очередь рабочий код, а уж потом красивый. Правда мой перфекционизм этому мешает.

[Astraport]

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

[Dukobpa3]

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

[Psycho Tiger]

А, тьфу, прошу прощения. Упорно думал что речь идёт о туториал-менеджере.

У Вас казуалка? Если нет - все квесты должны проходится на сервере, клиент получает только результат.

[markII]

У меня социалка.Что то вроде ёвиля на фэйсбуке

[terbooter]

Все команды вываливать сразу на сервер слишком тяжко для сервера.
Обычно есть эмулятор сервера на клиенте, который дулирует часть серверной логики.

Не понимаю почему проблема именно с квест менеджером? Остальные данные приложения вы же как-то получаете обрабатываете и храните.
Данные квестов ничем не отличаются от других игровых данных.
Есть конфиг, в котором прописаны параметры квестов. Конфиг общий для сервера и клиента.
Юзер что-то делает на клиенте. Если условие квеста выполнено, то даем награду. Сервер пишет в БД,
что квест такой-то пройден.
Только писать сохраняшки в отдельные ХМЛ файлы это еще круче чем дырочки в туториале =)
Если не нравятся реляционные СУБД, попробуйте, например, MongoDB.

Сознаюсь, дырочки в туториале я однажды тоже делал.
Такие же отговорки, что надо быстро и просто.
Но мне это очень не понравилось и больше я так не делаю.
Считаю, что если пришлось делать дырочки, то есть явные проблемы с архитектурой.
Напрмер, у визуальных эментов должны наличествовать enable() и disable() методы, которые не только на 100% заменят дырочки,
но много где и как могут быть использованы.

[markII]

Не понимаю почему проблема именно с квест менеджером? Остальные данные приложения вы же как-то получаете обрабатываете и храните.
Данные квестов ничем не отличаются от других игровых данных.
Дело в том что мне нужно сделать квест менеджер расширенный и большой.Большой - это значит в нем должно быть примерно 200 квестов, а расширенный это значит квесты в нем примерно 15 типов и примерно половина из них комбинированная.Т.е. в одном квесте может быть например 3 разнотипных квеста.Поэтому мне нужно палить изменение состояния модели на разные события
Я решил сделать квест менеджер двумя способами(Благо запас почти месяц)
Первый, который я начал сейчас реализовывать состоит в следующем.
Все квесты прописнны в xml файле.Например так:

<quests>
<quest id = "1" type = "bulding" award = 20>
<results>
<result buldID = "17"/>
<result buldID = "18"/>
</results>
</quest>
<quest id = "2" type = "bulding" award = 25>
<results>
<result buldID = "25"/>
</results>
</quest>
</quests>

Это примерный код xml файла , в котором будут прописаны квесты.Обращаю внимание что xml просто пока для примера он не рабочий и не продуман до конца(что то типа прототипа).В первом квесте нужно построить здание с айдишником 17 и 18 во втором квесте здание с айдишником 25.
После того как с сервера мне пришел айди текущего квеста, я в квест менеджере через здоровенный свитч либо через вектор беру инстанс квеста по его типу (в данном случае это type = "bulding").
В этом квесте есть слушатели на модель или еще на что то где храняться состояние аппликации.Я 2 слушателя на изменение модели построек.После того как модель пополнилась двумя айдишниками, то я диспачу событие QuestCompleteEvent(COMPLETE,award:Number).Контроллер слушает это событие и отправляет его значение на сервер, после этого приходит другой айдишник квеста.И так далее

Второй способ схожий с первым.Исключение лишь составлет то что все квесты будут храниться в БД и отсылаться будут в виде JSON или OBJECT.А дальше принцип такой же.