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

[Dukobpa3]

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

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

[markII]

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

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

[Dukobpa3]

я имел ввиду данные которые должен отследить квест.

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

[markII]

У меня появилась идея как это сделать.Т.к. будут отдельные классы квестов для каждого типа квеста(По идее их не должно быть более 10-15 типов), то в этих квестах будут уже прописанны слушатели на определенные события.Допустим если при самом првом квесте мне надо собрать 3 огурца то я просто активирую слушатели для класса cucumberQuest.Например так

cucumberQuest.activateListeners(params)

и передаю туда нужные параметры для каждого квеста cucumberQuest.activateListeners(3) - собрать 3 огурца.
Тогда этот квест будет слушать , допустим, изменение состояния модели (когда пополниться урожай на 3 огурца).После этого квест диспачит событие

dispatchEvent(new СucumberQuestEvent(СucumberQuestEvent.QUEST_DONE, someParam)).

После этого обработчик ловит это событие и проверяет соответствует ли значение собранных огурцов указанному в квесте.Если да то квест выполнен и отсылается событие на сервер.После этого я деактивиую квест и он больше не будет ловить это событие.Мне кажется что у этой схемы есть плюс в том что можно делать комбинированные квесты.(Т.е. объединять 2 квест класса в один путем наследования просто и все).Но есть минусы в том что нужно много кода писать (Каждый тип квеста + обработчик к нему).Как такая схема?

[markII]

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

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

[Dukobpa3]

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

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

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

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

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

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

[Astraport]

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

[Dukobpa3]

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

[Psycho Tiger]

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

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

[markII]

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