Добро пожаловать в «Сказку»!¶

«Сказка» — браузерная многопользовательская текстовая ролевая песочница с действующими самостоятельно героями.

Сайт игры:	https://the-tale.org
Огранизациия:	https://github.com/the-tale
Репозиторий:	https://github.com/the-tale/the-tale
Форум:	https://the-tale.org/forum/subcategories/28
Разработчики:	контакты

Введение¶

Что такое «Сказка»¶

На текущий момент «Сказка» — это два тесно переплетённых и дополняющих друг друга проекта:

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

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

«Сказка» развивается с 2011 года.

Игра¶

Начинаясь как чистая Zero Player Game игра постепенно обрастала элементами песочницы и на текущий момент кратко определить её жанр сложно. Неизменным остаётся нетребовательность геймплея ко времени игроков.

Можно выделить несколько ключевых особенностей игры:

непрямое управление героями — они действуют самостоятельно, в большинстве случаев игроки могут влиять на их поступки только косвенно;
состояние мира игры полностью зависит от действий игроков и их героев;
всё что происходит в игре описываются художественным текстом, вид которого зависит от множества параметров;

В «Сказку» можно играть как в тамагочи (выращивая своего героя) или как в «политическую песочницу» (кооперируясь с другими игроками для получения нужного эффекта на мир).

Вселенная¶

Вселенная появилась в процессе разработки игры, но уже давно вышла за её пределы. Далеко не всё из лора реализовано в игре.

Есть несколько ключевых отличий сказочной вселенной от множества других:

инженерный подход к использованию магии;
Пандора — мир, в котором происходит действие, — является гигантским магическим механизмом;
бессмертие (включая воскрешение и вечную молодость) является «рядовым» явлением, хотя и редким.

Наработано большое количество хужожественных описаний существ и артефактов существующих в Пандоре.

Кроме этого мы работаем над каноничным описанием мира.

Мы заинтересованы в выходе новых игр (или других произведений) по нашей вселенной и готовы к сотрудничеству.

Цели проекта¶

На протяжении жизни игры цели её разработки меняли свой приоритет, но их список остаётся неизменным. На текущий момент по приоритету он выглядит так:

Создать игру, мир которой будет восприниматься игроками как живой.
Дать каждому игроку его уникальное бесконечное приключение — собственную сказку.
Создать оригинальную вселенную, которая станет отдельным культурным явлением.
Получить площадку для экспериментов в области разработки ПО и геймдизайна.
Создать площадку для тематического творчества игроков.
Заработать денег, если игра станет достаточно популярной.

Технологии¶

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

Основные ЯП:	Python3 (backend) и JavaScript (frontend)
Фреймворки:	Django для сайта, aiohttp для (новых) фоновых сервисов
База данных:	PostgreSQL
Кеш:	Redis
Очереди:	RabbitMQ

Разработка ведётся с помощью виртуальной машины, поднимаемой с помощью Vagrant.

Краткая история¶

2011 год — Елецкий Алексей (Tiendil) начал разработку игры (по вечерам).
2012 год — Tiendil уволился и начал работать над игрой полный рабочий день.
2012 год — Первые игровые концепции сформированы в сотрудничестве с Александром Титовым (Gizoom).
2012 год — К разработке примкнули геймдизайнеры Саша и Лена Дедковы (спасибо Gizom-у).
2015 год — у Tiendil-а кончились деньги :-D он устроился на работу и продолжает заниматься игрой по вечерам.
… — разработка продолжается.

Команда¶

Елецкий Алексей (Tiendil)¶

Занятие:	программирование, но занимается всем.
Блог:	https://tiendil.org
Skype:	Tiendil
E-mail:	a.eletsky@gmail.com

Саша и Лена Дедковы¶

Занятие:	геймдизайн и разработка вселенной.

Планы¶

На этой странице представлены примерные стратегические планы развития игры. Планы примерные и порядок реализации «фич» периодически существенно пересматривается. Здесь представлены ключевые, наиболее существенные моменты игры — небольшие изменения и дополнения могут происходить спонтанно и в любой момент.

Будет реализовано¶

версии 0.4.*¶

Доработка и развитие гильдейских эмиссаров.
Гильдии NPC с особыми механиками (некроманты, демонопоклонники, Серый Плащи, etc.).
Чат (Discord).
Вики вместо путеводителя.
Вики вместо технической документации.
Вики вместо фольклора (как расширение функциональности текущего фольклора).
Замена форума на сторонний движок.
Галерея (как расширение функциональности фольклора).
Общение с героем (ответы «молитвы»), модифицирующее его характер.
Переработка характера героя (предпочтений и черт) в пользу общения с героем.
Отказ от кнопки «помочь» в пользу использования карт судьбы и общения с героем.
Переработка системы прокачки и способностей героев (в сторону EVE online).
Временные эффекты на героях (проклятья, благословения, травмы).

далёкое будущее¶

Встречи героев.
Подробное описание внешности героя (зависящее от его одежды, характера, достижений);
Появление воды на карте (реки, озёра и прочее);
Подземелья.
Развитие системы заданий.
Группы связанных фраз в лингвистике.
Деревни: постройка, развитие, жители, задания связанные с ними — отдельные поселения, которые могут развивать как отдельные игроки, так и гильдии или группы друзей.
События на карте: логова опасных монстров, ярмарки, нашествия некромантов, погодные катаклизмы, подземелья.
Создание гильдиями легендарных артефактов.
Групповые задания.
Характер героя — особенности — уникальные черты героев, делающие их «особенными» (параметры не влияющие на силу героев: специальные задания, особые фразочки; примеры: кладоискатель, филателист, романтик, дипломат);

Уже реализовано¶

версии 0.3.*¶

[сделано] гильдии - базовый механизм для объединения игроков, закрытый гильдейский форум;
[сделано] достижения и рассказы-награды за них;
[сделано] усложнение системы артефактов - поломка/починка, покупка с учётом полезности, градация качества, особые эффекты;
[сделано] карты судьбы - универсальный способ влиять на мир игры и героев;
[сделано] спутники героев;
[сделано] рынок - внутриигровая торговля картами судьбы;
[сделано] характер для персонажей в городах, влияющий на мастерство, получение влияния городами и персонажами, выдаваемые ими задания и на все остальные моменты игры. Каждый персонаж станет действительно уникальным, получит друзей и врагов среди таких же персонажей;
[сделано] улучшение интерфейса рынка;
[сделано] специальные правила объединения карт;
[сделано] автоматическое вознаграждение авторов лингвистики;
[сделано] редактирование дорог игроками, улучшенный поиск пути героями;
[сделано] совершенствование управления гильдиями;
[сделано] эмиссары гильдий;

Разработка¶

Все обсуждения, связанные с разработкой, можно вести на форуме игры.

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

Установка и запуск¶

Окружение игры организуется с помощью Docker.

В рамках этого документа предполагается, что вы знакомы с базовыми концепциями Docker.

Инструкция проверялась под Ubuntu, должна работать для любого популярного linux дистрибутива.

Инструкция должна работать для Windows под WSL — Windows Subsystem for Linux, но не проверялась.

Мы с радостью примем pull requests с уточнениями как документации, так и кода.

Термины и соглашения¶

Далее будут встречаться некоторые понятия, которые лучше пояснить отдельно.

старые сервисы — сервисы игры, разработанные на оригинальном движке. Используют Django, общаются через очереди, реализованы в коде сайта. Отвечают за логику игры.
новые сервисы — часть игры, переписанная на микросервисную архитектуру. Использует aiohttp, общается по http, реализованы отдельными модулями.

Установка (для разработки)¶

Установите Docker и Docker Compose.

git clone https://github.com/Tiendil/the-tale.git

git clone git@github.com:the-tale/the-tale.git

сd ./the-tale

# Все следующие команды необходимо выполнять из корня проекта.

# При необходимости переключаем репозитории в ветке develop.
# git checkout develop

# При необходимости определяем переменную окружения, отвечающую за тип создаваемого окружения.
# Про типы окружений будет рассказано подробнее.
# Значение по умолчанию: stage
# export TT_ENV=stage

# Обратите внимание на использование обёртки над docker-compose.
# Все операции необходимо выполнять через них.

# Собираем все контейнеры.
./bin/docker_compose_build_all.sh

####################################################
# Производим первоначальную настройку состояния игры
####################################################

# Создаём файл с кастомными настройками игры.
# Запомните его, он будет полезен в процессе разработки.
# В данном случае мы явно включаем в игре режим отладки.
# Файл settings_local.py добавлен в .gitignore и не сохраняется в репозиторий.
echo "DEBUG = True" > ./docker/the_tale/settings_local.py

# подготовливаем игру к запуску
./bin/before_first_start.sh

# В том числе команда создаём суперпользователя с параметрами по-умолчанию.
# ПОМЕНЯЙТЕ ИХ, если планируете давать доступ к игре другим людям.
# - ник: superuser
# - почта: superuser@example.com
# - пароль: 111111

Запуск игры¶

./bin/tt_game_start

# Теперь игра должна быть доступна по адресу "localhost".

# Остановить игру можно командой
# ./bin/tt_game_stop

# После остановки игры, можно остановить инфраструктуру
# ./bin/docker_compose.sh down

Типы окружений¶

Игра может запускаться в нескольких режимах, управляемых переменной окружения TT_ENV:

prod — окружение для запуска проекта в боевом режиме.
stage — окружение для запуска на тестовых серверах или на машине разработчика.
tests — окружение, оптимизированное для прогона тестов.

В большинстве случаев вам будет хватать stage.

Окружение test использует оптимизированную конфигурацию контейнеров для ускорения прогонки тестов:

PostgreSQL запускается на tmpfs то есть держит абсолютно все данные в памяти. Убедитесь, что у вас достаточно RAM.

Docker Compose¶

Вся конфигурация контейнеров находится в директории ./docker.

Базовую конфигурацию можно найти в файлах :

./docker/docker-compose.build.yml — параметры сборки контейнеров.
./docker/docker-compose.temlates.yml — общие параметры сервисов. В этот конфиги используется шаблонизация yaml.
./docker/docker-compose.base.yml — персонализированные параметры сервисов, общие для всех окружений.
./docker/docker-compose.$TT_ENV.yml — конфиги конкретных окружений.

Итоговое окружение получается с помощью переопределения нескольких конфигов. Это делается в обёртках над docker compose (см. ./bin/docker_compose.sh и прочие скрипты).

Сервисы разбиты на несколько профилей:

core — ключевые сервисы инфраструктуры: база, кэш, веб-сервер, etc.
services — все новые сервисы. От их доступности зависит работоспособность сайта.
workers — все старые сервисы. От их доступности зависят некоторая функциональность сайта. Например, регистрация.
site — сервис сайта.
utils — вспомогательные контейнеры для запуска утилит.
tasks-managers — сервис менеджера периодических задач (а-ля cron).
tasks — сервисы периодических задач, по сервису на задачу, управляются tasks manager-ом.

Сервисы без указанных профилей — сервисы инфраструктуры. В большинстве случаев все они должны быть запущены.

Опциональные репозитории¶

Часть проектов, родившихся в рамках разработки, доросли до стабильной версии и хостятся на pypi.org.

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

Репозитории:

генератор имён персонажей: https://github.com/Tiendil/pynames
продвинутые перечисления: https://github.com/Tiendil/rels
генератор текста: https://github.com/Tiendil/utg
умные импорты для Python: https://github.com/Tiendil/smart-imports
генератор карты: https://github.com/the-tale/deworld
генератор заданий: https://github.com/the-tale/questgen

Нюансы¶

Настройка форума проводится через админку Django.

Права пользователей также настраиваются через админку Django.

Админка Django доступна по адресу https://localhost/admin

После настройки, в базе игры не будет фраз для лингвистики, вместо них будут отображаться заглушки, описывающие тип фразы и её параметры. Фразы необходимо добавлять руками. Вы можете написать нам и мы вышлем дамп таблиц лингвистики для личного пользования.

В окружении разработчика используется самоподписанный сертификат, поэтому браузеры будут сообщать о «небезопасном соединении». Это нормально (для окружения разработчика). Если вы хотите избавиться от этого предупреждения, импортируйте сертификат к себе в систему или поправьте конфиги nginx.

Разработка¶

Процесс разработки с помощью Docker ещё не устоялся и может поменяться. На текущий момент:

Код из репозитория монтируется в соответствующие контейнеры.
Изменения в коде будут появляться в контейнерах, но запущенные сервисы не будут перезапускаться.
Если вы ведёте активную разработку одного из сервисов, рекомендуем запустить bash в соответствующем контейнере и запускать тесты и сервис вручную оттуда.

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

Пример:

# обратите внимание на параметры
# --name — должен быть установлен в имя сервиса в docker-compose.base.yml, иначе другие сервисы не найдут его в сети.
# --entrypoint — указываем контейнеру запустить bash вместо команды по-умолчанию.
./bin/docker_compose.sh run utils-site bash

# запускаем какие-то команды

# стартуем сайт в обычном режиме
# tt_site -b 0.0.0.0:80 -w 4

# стартуем сайт в режиме разработчика
# tt_django runserver 0.0.0.0:80

# запускаем тесты
# tt_django test the_tale.portal

Запуск тестов¶

Тесты сервисов:

./bin/docker_compose.sh run tt-diary tt_run_tests

Главные тесты игры:

# Выключаем всё
./bin/tt_infrastructure_stop

# Запускаем только необходимые для тестов сервисы.
./bin/tt_infrastructure_start
./bin/docker_compose.sh --profile services up -d

./bin/docker_compose.sh run utils-site tt_django utils_run_tests

Предупреждение

Тесты игры идут очень долго. На моей машине около часа.

Небольшая часть тестов может сообщить об ошибках (обычно до 5) — это «нормально» — следствие большой вариативности логики игры. Стабилизация таких тестов — хорошая задача для нового разработчика.

Бэкапы¶

Контейнер utils-postgresql предоставляет экспериментальную функциональность по созданию бэкапов, загрузке их на amazon s3, выгрузке и восстановлению.

Как присоединиться?¶

Спасибо что интересуетесь нашим проектом! Мы (в особенности Tiendil) обещаем всеми силами помогать вам.

Присоединиться в разработке можно разными способами, все они привычны для open source проектов:

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

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

Кроме этого вы можете помочь игре как политик, автор лингвистики или фольклора.

Прежде чем браться за какую-либо задачу:

Научитесь запускать локальную версию игры.
Напишите Tiendil-у (сделать это можно на сайте игры или по любому из контактов на tiendil.org). Он подробно расскажет про все нюансы выбранной задачи.
Прочтите про организацию процесса разработки.

Процесс разработки¶

Общий подход¶

Разработка игры идёт в духе «инкреметального прототипирования», что предполагает прохождение каждой «фичи» через последовательность прототипов, совершенствующих её реализацию. Не делается попыток с первого раза написать самый правильный и самый крутой код. Как следствие:

новая «фича» реализуется самым простым и понятным образом, без переусложнений и оптимизаций;
по мере развития игры (и анализа её работы), логика «фичи» уточняется и совершенствуется;
если «фича» оказывается достаточно независимой, она выделяется в отдельную библиотеку.

Следствием такого подхода является постоянный рефакторинг проекта.

В случае крупных инфраструктурных изменений их допустимо не применять сразу ко всему проекту, а только к тем частям, над которыми идёт работа в настоящий момент. Старый код вычищается тогда, когда появляется необходимость изменения компонента, в котором он находится.

Тесты¶

Весь важный код покрывается тестами.

Весь не важный код покрывается тестами по возможности.

Миграции¶

Миграции схемы базы создаются на основе Django ORM (даже если сам Django больше нигде в сервисе не используется).

Работа с версиями¶

Разработу ведём по git-flow:

Master ветка всегда содержит в себе текущую рабочую версию проекта (ту, которая сейчас запущена на сайте).

Работа над новой версией ведётся в ветке develop. По завершении работы, делается тег и изменения подливаются в master.

Всю работу надо делать в ветке develop или её ветке. Изменения применять к ней же.

Требования к изменениям¶

Предлагаемые вами изменения в обязательном порядке должны:

быть в виде одного патча (pull request должен содержать 1 коммит);
быть покрыты тестами;
не использовать устаревшую функциональность;
применяться к ветке develop (не master!), как и положено по git-flow.

Желательно, чтобы они сопровождались документацией.

Описание импортов в исходниках на Python¶

В проекте используется smart_imports. Это упрощает редактирование и анализ кода, плюс, упорядочивает имена сущностей.

Документацию по smart_imports можно найти на странице проекта.

Конфигурация библиотеки (правила импорта) находится в файлах smart_imports.json Например, для основного сайта игры — the_tale — конфигурацию можно найти в файле ./src/the_tale/the_tale/smart_imports.json

В целом, правила импорта можно описать следующими эвристиками (по приоритету):

Если имя переменной является стандартным (сторонним) пакетом, оно импортируется напрямую.
Если имя переменной находится в списке предопределённых значений, оно импортируется по собственному правилу. Правила определены в smart_imports.json.
Если имя переменной совпадает с именем локального модуля (из той же директории), то импортируется модуль.
Если имя переменной начинается с имени одного из базовых модулей (например, places_logic, где places — стандартный модуль), то импортируется его подмодуль, определённый после префикса (например, places_logic is the_tale.game.places.logic). Префиксы определены в smart_imports.json.
если имя переменной является модулем верхнего уровня стандартной библиотеки, то он импортируется.

Дочерние проекты¶

Из игры, по мере готовности, выделяются небольшие проекты, которые можно использовать отдельно от неё.

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

smart_imports — умные импорты для Python¶

Smart imports, анализируя код на Python, определяют что куда и под каким именем необходимо импортировать (и импортируют). Позволяют избавиться от длинных списков импортов и навести порядок в именах.

pypi:	https://pypi.org/project/smart_imports/
github:	https://github.com/Tiendil/smart-imports

pynames — генератор имён¶

Генератор имён персонажей. Может создавать имена на русском и английском. На русском выдаёт все формы имени.

pypi:	https://pypi.org/project/Pynames/
github:	https://github.com/the-tale/pynames

utg — генератор русского текста¶

Шаблонный генератор русского текста с учётом зависимостей слов и их форм. Используется для генерации всего текста в игре.

pypi:	https://pypi.org/project/UTG/
github:	https://github.com/the-tale/utg

deworld — генератор карты для игры¶

Библиотека моделирует изменения ландшафта в игре. Учитываются:

высота
температура у земли
температура воздуха
влажность почвы
влажность воздуха
качество почвы
направление ветра
растительность

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

Игровые объекты могут влиять на изменение параметров, устанавливая «точки влияния», которые изменяют параметры слоя в заданной области.

За счёт подобного подхода удаётся получить «реалистичное» изменение ланшафта не сходящееся к стабильному состоянию (так как влияние игровых объектов постоянно меняется, мешая сходимости).

github:	https://github.com/the-tale/deworld

questgen — генератор квестов¶

Генератор цепочек квестов в игре с учётом контекста (какой NPC с каким дружит или враждует, etc). Принцип работы описан на хабре.

habrahabr:	https://habrahabr.ru/post/201680/
github:	https://github.com/the-tale/questgen

Направления разработки¶

Планов по развитию «Сказки» у нас больше, чем свободных рук, поэтому всегда есть крупные задачи, ожидающие своей реализации.

Эта страница посвящена как раз таким задачам и будет интересна опытным разработчикам с большим количеством свободного времени.

Если вы хотите активно участвовать в разработке игры — эти задачи для вас. Подробно про каждую из них может рассказать Tiendil.

Наиболее важной задаче сейчас является рефакторинг проекта с монолитного на набор микросервисов.

Планируемая архитектура описана на отдельной странице.

Рефакторинг¶

Как сказано в описании процесса разработки, игра находится в состоянии непрерывного рефакторинга. У нас всегда найдётся место, в котором нужно навести порядок :-)

Оптимизация тестов — в проекте более 4000 автоматических тестов, работу которых можно ускорить и упростить.
Эксперименты с организацией кода привели к неудобной системе обёрток над Django view, которую надо заменить на более удобную.
Те же эксперименты переусложнили работу с объектами игры.
Бразуерный интерфейс игры реализован на старых технологиях, необходимо его актуализировать (или переписать полностью).

Отдельно хочется отметить идущий рефакторинг проекта с монолитного на набор микросервисов. У этой активности две цели:

уменьшение связанности логики игры (чтобы упростить внесение изменений);
получение независимых от логики игры переиспользуемых сервисов.

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

Существующая функциональность¶

Часть фунциональности игры реализована в минимально необходимом виде, поэтому её можно (и нужно) развивать.

Форум (нужны система модерации, доработка статистики, исправление ошибок, приведение кода в порядок).
Гильдии (нужны звания, взаимодействие с форумом, продвинутые настройки, статистика, развитие геймплея).
Игровая статистика (увеличение собираемых параметров, их анализ).
Лингвистика (упрощение интерфейса и логики работы).
На сайте игры необходимо внедрить семантическую разметку.
Необходимо развивать функциональность генерации и отображения карты (нужны библиотеки GUI для разных платформ, улучшение интерфейса и расширение функциональности).

Новая функциональность¶

Новая функцональность реализуется в виде отдельных сервисов.

Список текущих задач по новым сервисам.

Кроме этого, мы привествуем прототипирование новых фич веб-интерфейса.

Проекты-спутники¶

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

По историческим причинам «Сказка» — монолитный проект с сильной связанностью, это начало усложнять реализацию новых фич. Поэтому сейчас он переписывается на микросервисы. Пока идёт активная фаза рефакторинга, сервисы выделяются логически, но не выносятся из основного репозитория (ложаться в соседние каталоги). Когда крупные изменения закончатся, сервисы будут разнесены в разные репозитории.

На этой странице описана архитектура игры, какой она должна стать.

Базовая структура ¶

Стрелками указано использование сервисами друг друга.¶

Все сервисы игры можно разделить на две группы:

frontend — сервисы, с которыми так или иначе взаимодействуют пользователи.
backend — сервисы, не доступные напрямую для пользователей.

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

Backend сервисы недоступны извне, доверяют всем клиентам и не реализуют GUI (предоставляют только API).

Коммуникация сервисов происходит через передачу сообщений в формате Protocol Buffers 3 по протоколу HTTP.

Существующие сервисы ¶

Текущий список сервисов.

the_tale — сайт игры (сейчас содержит и основную логику);
tt_diary — хранилище сообщений в дневнике героя;
tt_market — рынок;
tt_personal_messages — личные сообщения;
tt_storage — хранилище предметов игрока (в рамках Сказки, карты судьбы).
tt_bank — хранилище игровой валюты с поддержкой транзакций.
tt_timers — управление таймерами (например, на получение карты), по истечении таймера делает заданные http запрос.
tt_impacts — учёт численных «воздействий» одних сущностей на другие. Например, влияние героев на Мастеров.
tt_events_log — хранилище истории игровых событий с привязкой к «тегам» и фильтром по ним.
tt_effects — хранилище эффектов, действующих на объекты игры.
tt_matchmaker — простой сервис поиска соперника для pvp и отслеживания активных боёв.
tt_properties — хранилище свойств объектов, нужных в частных случаях логики (например, флаг «разрешить приглашать игрока в клан»).
tt_uniquer — сервис выделения уникальных целочисленных идентификаторов для строк.

the_tale ¶

Вся функциональность игры: как логика, так и инфраструктура (форум, регистрация, лингквистика, etc).

По мере рефакторинга в этом компоненте останется только сам сайт.