Проектирование архитектуры системы достижений(achievements)

Question

[p4s8x]

Встал вопрос проектирования архитектуры системы достижений(achievements).
Речь идет конечноже о разработке логики серверной части приложения.

Игра — фирмум для социальных сетей.

Достижения совершенно разные:
1) зашел N дней подряд
2) пригласил N друзей
3) прошел N уровней
4) набрал N конкретных достижений(грубо говоря это позволяет организовать квест)
5) собрал N денег
и т.д.
количество таких достижений может быть измеряться сотнями.

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

«Достижения» встречаются в огромном количестве игр, есть конечно собственные соображения, множество путей решения, хотелось бы поинтересоваться у сообщества — какую архитектуру системы выбрали Вы?
Особенно интересует — стоит ли связываться с поиском универсального решения, или разбить достижения на группы и реализовать свою систему под каждую группу? Какие грабли?
Схемы БД и прочие диаграмки в ответах приветствуются.

Answer 1

[Вячеслав Слинько]

Мой путь был бы таким:
— key-value db;
— каждое действие генерирует событие;
— для каждого достижения есть свой подписчик который случает необходимые ему собития;
— при срабатывании подписчик читает поле в базе с ключем __;
— сравнивает с лимитом;
— увеличивает его или генерирует событие добавления нового достижения.

Comments

[Вячеслав Слинько]

с ключем user_achievement_counter, где:
user — id пользователя;
achievement — id достижения;
counter — название счетчика.

Например:
VasyaPupkin_SecretQuestAchievement_SIgnupAchievementCount = 1
VasyaPupkin_SecretQuestAchievement_FirstKillAchievementCount = 0

Answer 2

[startsevdenis]

Не претендую на решение, но идея такова:
Большая часть достижений это количество каких то действий, то есть нужно что то сделать несколько раз. Для этих целей создается таблица, с полями id пользователя, достижение 1, достижение 2,… достижение N. Соответственно при выполнении нужного действия нужно достижение в таблице наращивается.
Далее можно создать таблицу с уже полученными достижениями, чтобы можно уже было учитывать те достижения для получения которых нужно выполнить несколько конкретных.
Само присвоение достижений думаю проще будет вести триггерами которые будут проверять достигнуто ли достижение когда обновляется запись.
Такой вариант позволит вам в любой момент добавлять достижения, обычным добавлением поля в таблицу, и триггера на более сложные достижения

Comments

[Евгений Лещенко]

Поддержу. Абсолютно так же и поступил когда на одном портале нужно было написать похожей механизм.

Answer 3

[gleb_kudr]

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

Поэтому:
1. Делаем архитектуру подписки на события. В зависимости от платформы, может понадобится отдельный диспетчер событий.
2. Инкапсулируем логику достижения как то, что зависит от цепочки пришедших в него событий.
3. Вызываем проверку по триггерам (например, у нас есть 90 достижений, обновляем статус по ним в конце каждой миссии, при условии, что в достижение пришло какое-либо событие).
4. Храним состояние в базе каким угодно образом.