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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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