Игра-толкователь: веб-игра про этимологию и общие корни слов

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

Идея автора и задача

Суть игры проста для описания и глубока по содержанию. Игроку показывают цепочку слов из разных языков, которые на первый взгляд не имеют друг к другу отношения. Задача — доказать, что у них общий корень. Доказательство ведётся не на глаз, а по правилам: есть система соответствий между буквами и звуками, и, применяя её, игрок раскрывает, как одно слово связано с другим, а где связь ложная.

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

Ключ-алфавит УХО

В основе игры лежит ключ — алфавит соответствий, по которому игрок кодирует и сравнивает звуки. Это русский алфавит, дополненный тремя бурятскими буквами: Ү (читается как У), Һ (читается как Х) и Ө (читается как О). Автор неслучайно собрала их в мнемоническое слово «УХО»: игра — про слух, про звучание слова, а не про его написание в конкретном алфавите. Именно звук, а не буква, тянется сквозь века и языки, и именно на звук опирается вся механика.

Эти три дополнительные буквы дают инструмент для аккуратной работы с оттенками произношения, которые в стандартной кириллице или латинице сливаются или теряются. Для игрока ключ — это его рабочий инструмент: он смотрит на слово, переводит его в звуки по ключу и сравнивает с другим словом, приведённым к тем же звукам. Технически ключ — это часть данных игры, а не логики, и это важно для архитектуры, о которой ниже.

Лингвистическая гипотеза

Центральная идея, которую предлагает игра, — авторская гипотеза о судьбе греческой буквы ипсилон. По этой гипотезе, ипсилон, которая в ранних передачах записывалась как сочетание вроде «Yu», при переходе в латиницу разделилась на две разные буквы: Y, закрепившую звук «и», и U, закрепившую звук «ю»/«у». Это разделение, по мысли автора, как ножницами разрезало этимологические связи: слова, которые звучали и родственно, и узнаваемо, разошлись по написанию и со временем перестали опознаваться как родня.

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

Смешанная механика проверки

Механику мы сделали «смешанной» — и это ответ на желание автора активировать мышление игрока, а не кормить его готовым. С одной стороны, игроку доступны подсказки и разбор: по клику он может раскрыть, как звук в одном слове соответствует звуку в другом, увидеть промежуточные формы, получить наводку. С другой стороны, финальный вердикт выносит сам игрок: он решает, родственные ли перед ним слова или это «ложные родственники» — внешне похожие, но этимологически чужие.

Эта развилка — ядро вовлечения. Пассивное чтение статьи об этимологии забывается через минуту. Активная проверка гипотезы, когда ты сам берёшь на себя ответственность за вывод «да, родственные» или «нет, ложный след», заставляет думать и запоминается. Подсказки при этом не превращают игру в чтение с подглядыванием: они помогают дойти до решения, но не выносят его за игрока. Технически это означало аккуратно развести в интерфейсе две сущности — вспомогательный материал, который можно раскрывать, и собственно решение игрока, которое фиксируется и потом сверяется с авторским разбором.

Пример уровня: корень ТУР

Чтобы было предметно, разберём устройство одного уровня — с корнем ТУР. Цепочка начинается со слова ТУРИСТ и ведёт через ряд форм, включая тюркские. Здесь важна деталь, которую задаёт автор: форма TURIST в цепочке стоит раньше тюркской формы, потому что сохраняет чистый звук «у» — тот самый исходный звук, который по гипотезе тянется от ипсилона. Порядок в цепочке несёт смысл: он показывает, где звук ближе к предполагаемому истоку, а где уже видоизменился.

В том же уровне есть ловушки — ложные родственники. Некоторые греческие слова (например, обозначающие сыр или шину) внешне будто просятся в ту же семью, но на самом деле не родня: их греческие транскрипции идут через звук «и», а не через «ю»/«у», и по ключу это сразу видно. Задача игрока — не попасться: применить ключ, услышать, что звук не тот, и вынести вердикт «ложные родственники». Так один уровень одновременно и обучает правилу, и проверяет, усвоил ли игрок его на слух, а не на глаз.

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

Движок как трафарет

Вот главное инженерное решение проекта, и оно определило всю архитектуру. Мы построили игру по принципу трафарета: логика игры — движок — зафиксирована раз и навсегда, а уровни задаются отдельными данными. Движок умеет одно и то же для любого уровня: показать цепочку слов, дать применить ключ, раскрыть подсказки по клику, принять вердикт игрока, сверить его с эталонным разбором и показать результат. Что именно за слова, какая цепочка, какие ложные родственники, какой разбор — движок не знает и знать не должен. Он берёт это из конфигурации уровня.

Такой data-driven подход означает, что добавить новый уровень — значит добавить новый блок данных, а не написать новый код. Автор может придумывать десятки новых цепочек — про любой корень, с любыми языками и ловушками, — и каждая станет полноценным уровнем без переписывания движка, без рисков что-то сломать в уже работающих уровнях, без релиза новой версии логики. Конфиг уровней живёт отдельно от движка, и это разделение — не косметика, а стратегическое решение, которое определяет стоимость роста игры на годы вперёд.

Почему это важно именно здесь? Потому что ценность игры — в объёме и разнообразии материала. Если бы каждый уровень требовал программирования, игра застряла бы на первых нескольких заданиях: любое пополнение упиралось бы в разработчика. Сделав движок трафаретом, мы передали автору контроль над содержанием: техника перестала быть узким горлышком. Мы один раз построили механизм, а дальше он штампует уровни из данных, как трафарет — одинаковый контур по любому листу.

Для нас это ещё и вопрос надёжности. Когда логика не меняется от уровня к уровню, её достаточно один раз выверить — и все уровни автоматически ведут себя предсказуемо. Ошибка в данных одного уровня не роняет остальные, а исправляется правкой этого блока данных. Чем строже граница между движком и данными, тем спокойнее жизнь проекта.

Честная позиция по контенту

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

Наша роль в проекте была технической: мы отвечали за то, чтобы игра работала, была удобной, честно передавала авторскую механику и легко росла. За научную валидацию концепции мы не отвечали и не выдаём себя за арбитров в этом вопросе. Мы считаем правильным сказать это открыто — и по отношению к игроку, которому честно предлагается авторская перспектива, а не «доказанная истина», и по отношению к автору, чью идею мы уважаем как творческую оптику и способ увлечь людей словами и языками. Игра ценна как инструмент любопытства и активного мышления; воспринимать её как учебник по сравнительно-историческому языкознанию не следует, и мы этого не скрываем.

Частые вопросы

Игра учит настоящей этимологии? Игра построена на авторской концепции, которая не является общепризнанной наукой. Она отлично развивает внимание к звучанию слов и активное мышление, но подаётся как авторская перспектива, а не как строгий научный курс. Мы честно обозначаем это и игроку, и в описании проекта.

Что значит «движок-трафарет» и зачем он нужен? Это архитектура, где логика игры зафиксирована, а уровни — это данные. Благодаря ей новый уровень добавляется как блок конфигурации, без написания нового кода. Автор может наращивать число заданий сколько угодно, не привлекая разработчика к каждому добавлению.

Кто отвечал за содержание, а кто за технику? Идея, лингвистическая концепция и наполнение — авторские. Мы выступали техническим исполнителем: спроектировали движок, интерфейс, механику подсказок и проверки, систему уровней. Границу ответственности мы проговорили сразу.

Можно ли так сделать любую обучающую игру? Да. Data-driven движок-трафарет подходит везде, где механика повторяется, а меняется наполнение: языковые тренажёры, викторины, карточные и логические игры. Один раз строим механизм — дальше он масштабируется данными.

Коротко о главном

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

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