# 📱 UI и мобильный UX

Всего постов в архиве: 19

## Выпуск 17 мая 2026

### Альтернативы AI Dungeon в 2026 году для интерактивной прозы

*12 мая 2026 · autogpt.net*

Статья сравнивает современные альтернативы AI Dungeon для интерактивной fiction и roleplay. Автор выделяет восемь платформ, среди них NovelAI, DreamGen, Character.AI, KoboldAI + SillyTavern, Friends & Fables, RPGGO, Meridian Realms AI и EndlessVN. Главный вывод: часть конкурентов уже обошла AI Dungeon по качеству прозы, памяти и творческой свободе. NovelAI описан как сильнейший вариант по качеству письма благодаря Kayra-XL, 128K context window и Lorebook для персонажей, локаций, правил и связей. Важная UX-деталь: NovelAI больше похож на co-writing studio, чем на простую игру с командным вводом, поэтому требует настройки и дисциплины. Для проекта особенно полезны идеи Lorebook и явного разделения между быстрым игровым вводом и более сложной настройкой мира.

- NovelAI выигрывает за счёт длинного контекста и Lorebook, который подмешивает релевантные факты по мере сцены.
- Лучшие AI-text платформы конкурируют не только моделью, но и UX памяти, мира и персонажей.
- Простой режим «введи команду и смотри результат» остаётся важным, потому что сложные writing tools повышают порог входа.
- Для long-form roleplay критична не только генерация текста, но и сохранение backstory через десятки ходов.

> 💡 **Действие:** Добавь в Gradio UI компактную мобильную панель «Память сцены»: 3-5 активных фактов из state/lore рядом с текущим нарративом, без ручной настройки игроком. Это даст эффект NovelAI Lorebook, но сохранит быстрый игровой ввод с телефона.

Теги: `ai-dungeon` `novelai` `lorebook` `interactive-fiction` `mobile-ux`

[Источник](https://autogpt.net/the-best-ai-dungeon-alternatives/)

---

### GemMaster: LLM-RPG как кадры игры вместо обычного чата

*11 мая 2026 · dev.to*

GemMaster описывает локальный движок текстовой RPG на Gemma 4-E4B, где каждый ответ модели трактуется как игровой кадр, а не как сообщение в чате. Автор делает упор на жёсткий протокол тегов: модель пишет нарратив и вызывает механики через маркеры вроде [[CHECK]], [[SKILL: QTE]] и [[SKILL: VISION]]. Игровая логика выносится из LLM во фронтенд: проверки, QTE и случайность обрабатываются детерминированно, чтобы модель не тратила внимание на расчёты. Для борьбы с drift используются скрытые напоминания в каждом пользовательском ходе, session-lock и Markdown-журнал для долгой непрерывности. В UI применяются динамические визуальные состояния: фон меняется по тону сцены, а Web Speech API озвучивает внутренние режиссёрские сигналы. Важное ограничение: сложный multi-tag protocol может ломаться на маленьких моделях в длинных сессиях, поэтому протокол требует строгого парсинга и контроля формата.

- Ответ LLM оформляется как Game Frame с нарративом, тегами механик и состоянием сцены.
- Механики вызываются структурными тегами, а не свободным текстом модели.
- Детерминированные проверки и seeded randomness вынесены из модели в движок.
- Скрытые reminders и журнал сессии используются против language и model drift.
- UI усиливает reading flow через тональные фоны, речь и отдельные интерактивные режимы.

> 💡 **Действие:** Для RE2×Jade стоит добавить в prompt_builder строгий мини-протокол тегов только для UI-событий, например [[UI:THINKING]], [[UI:CHECK]], [[UI:WOUND_ALERT]], а обработку оставить в Python/Gradio. Начать с одного безопасного тега для отображения проверки или ранения рядом с текстом, чтобы не раздувать формат ответа и не ломать лимит 30 секунд.

Теги: `gemma` `llm-rpg` `structured-output` `mobile-ux` `game-state`

[Источник](https://dev.to/quentin_merle/gemmaster-immersive-core-rpg-orchestrating-narrative-absurdity-with-gemma-4-4372)

---

### AI в мобильном UI должен заменять сломанный шаг, а не добавлять чат

*12 мая 2026 · aijourn.com*

Статья критикует поверхностную интеграцию AI в мобильные приложения: отдельная чат-кнопка, спрятанный voice mode или рекомендации без реальной пользы редко улучшают retention. Главная мысль — на телефоне AI должен быть встроен в конкретную пользовательскую задачу: ввод, поиск, принятие решения, автоматизацию или персонализацию экрана. Мобильный UX особенно требователен из-за маленького экрана, нестабильной сети, батареи и короткого внимания пользователя. Автор предлагает начинать не с модели, а с проблемного шага в пользовательском пути, где AI реально сокращает трение. Для production важны гибридная архитектура, fallback при сбоях модели или сети и измеримые метрики вроде time-to-result, task completion или day-30 retention. Для игрового Gradio-интерфейса это полезно как напоминание: AI-нарратив не должен превращаться в тяжёлый desktop-chat на маленьком экране.

- AI-фича должна заменять плохой шаг в UX, а не добавлять новый слой интерфейса.
- На телефоне свободный чат быстро становится нагрузкой, если каждое действие требует длинного ввода.
- Нужны fallback-сценарии на случай задержки LLM, обрыва сети или пустого ответа.
- Эффект AI стоит мерить конкретно: скорость хода, завершение сцены, возврат к игре, удержание.
- Персонализация полезна, если интерфейс сам поднимает вероятные следующие действия.

> 💡 **Действие:** В Gradio UI игры стоит добавить рядом с полем ввода 3-5 контекстных кнопок вероятных действий из текущего state: осмотреть, идти, атаковать, лечиться, открыть инвентарь. Это снизит трение на телефоне, но свободный ввод оставить как основной режим для нестандартных действий.

Теги: `mobile-ux` `ai-ui` `chat-ui` `fallback` `retention` `gradio`

[Источник](https://aijourn.com/ai-integration-in-mobile-apps-how-to-build-a-competitive-edge-in-a-crowded-market/)

---

### On-device AI в мобильных KMP-приложениях

*10 мая 2026 · techdynasty.medium.com*

Статья описывает архитектуру для запуска AI-функций прямо на устройстве в Kotlin Multiplatform: Gemini Nano на Android и Core ML на iOS. Общая логика выносится в commonMain: сборка prompt, парсинг ответа, кеширование, feature flags и доменные модели. Платформенные части реализуют только inference через нативные SDK каждой ОС. Пример функции — smart replies в мессенджере, где модель читает последние сообщения и предлагает несколько коротких ответов. Главные преимущества подхода: приватность, офлайн-работа, отсутствие API-расходов и задержка порядка 50–200 мс вместо сетевых 300 мс–2 с. Для текущего проекта статья не предлагает готовый UX-паттерн для Gradio/chat-UI, но полезна как ориентир по разделению orchestration logic и model backend.

- On-device inference снижает задержку и убирает зависимость от сети.
- Prompt engineering и response parsing можно держать отдельно от конкретного AI-бэкенда.
- Платформенные AI SDK лучше прятать за единым интерфейсом доступности и генерации.
- Кеширование коротких AI-ответов снижает повторные вычисления.
- Материал ближе к мобильной архитектуре, чем к UX AI-driven fiction.

> 💡 **Действие:** Не переносить проект на KMP/on-device AI: текущая игра завязана на GPT-5.5 через Codex backend. Забрать только паттерн интерфейса: в Gradio добавить явный слой статуса модели «доступна / думает / ошибка / повторить» и кешировать безопасные UI-подсказки, не игровые ходы.

Теги: `on-device-ai` `kmp` `gemini-nano` `core-ml` `mobile-ux`

[Источник](https://techdynasty.medium.com/on-device-ai-in-your-kmp-app-using-gemini-nano-on-android-and-core-ml-on-ios-from-shared-code-4044d2f259b5)

---

### Prompt-to-game агент Boo и этап согласования GDD

*10 мая 2026 · newsswift.co.uk*

Статья описывает AI game agent как систему, которая превращает текстовое описание игры в playable prototype через несколько этапов. Важная мысль — агент не просто парсит команды, а пытается понять намерение: жанр, настроение, целевое ощущение, core loop и стиль. Перед генерацией Boo задаёт 2-3 уточняющих вопроса по развилкам вроде визуального стиля, сложности и механик, чтобы не уйти в неверную сторону. Затем агент формирует Game Design Document, где фиксируются механики, структура уровней, роли персонажей и условия победы/поражения. Пользователь может редактировать GDD обычным языком, и статья подчёркивает, что этот этап важнее поздней итерации. После утверждения агент автоматически генерирует ассеты, логику и playable prototype, а дальнейшие правки делаются через natural language feedback.

- Самый ценный UX-паттерн — короткая pre-communication стадия перед генерацией.
- GDD используется как контракт между пользователем и агентом до начала тяжёлой автоматической работы.
- Агент должен спрашивать только о неоднозначных местах, а не превращать старт в длинную анкету.
- Natural language iteration удобна после прототипа, но первичное согласование экономит больше времени.

> 💡 **Действие:** Добавь в Gradio перед первым ходом короткий экран «настройка партии» из 2-3 вопросов: тон хоррора, желаемая жёсткость survival-систем и уровень свободы действий. После ответов показывай русское резюме контракта партии и сохраняй его в JSON state, чтобы GPT-5.5 каждый ход держал единый UX/GDD-контекст.

Теги: `ai-agent` `gdd` `prompt-to-game` `ux-flow` `game-design`

[Источник](https://newsswift.co.uk/ai-game-agent-explained-from-text-prompt-to-finished-playable-game/)

---

### Daily loop и persistent state из social games

*11 мая 2026 · viblo.asia*

Статья предлагает playbook для социальных игр в духе Stardew Valley, FarmVille, Minecraft и cozy/farming/sim-жанра. Главная идея: удержание строится на коротких ритмичных сессиях, ежедневном возвращении и persistent state, который меняется между заходами игрока. Автор выделяет важность daily loop, прогрессии, pacing, экономики, live ops, социальных механик и этичной монетизации. Для текущего проекта статья не про LLM-driven interactive fiction и не про мобильный chat-UI, поэтому применимость ограничена. Полезная часть — модель возвращения игрока через видимые незавершённые процессы: восстановление энергии, изменение мира, готовность событий, накопление последствий. Это можно адаптировать не как social game, а как UX-паттерн для текстовой survival horror игры с сохранённым JSON-state.

- Короткие повторяемые сессии удерживают лучше, чем редкие длинные заходы.
- Persistent state должен visibly меняться между сессиями, чтобы игрок чувствовал живой мир.
- Daily loop строится вокруг понятного цикла: триггер, действие, награда, новый повод вернуться.
- Для проекта нерелевантны social, Web3, монетизация и multiplayer-части.
- Полезен принцип мягкого прогресса без полной потери нескольких часов игры.

> 💡 **Действие:** Добавь в Gradio UI компактный блок «Что изменилось с прошлого хода/сессии»: 2-3 строки про инфекцию, усталость, раны, шум, NPC или события окружения из JSON-state. Это даст игроку mobile-friendly ощущение persistent world без копирования social-game механик.

Теги: `retention` `daily-loop` `persistent-state` `mobile-ux` `game-design`

[Источник](https://viblo.asia/p/the-social-games-playbook-part-1-oKLnqeYNJQO)

---

### Потоковый chat-UI для мобильного LLM без подвисаний

*11 мая 2026 · dev.to*

Статья разбирает мобильный chat-UI для on-device LLM на Gemini Nano, AICore, Jetpack Compose и Kotlin Coroutines. Главная UX-проблема описана как token stream: модель генерирует ответ по токенам, поэтому ожидание полного ответа создает долгий пустой спиннер. UI должен быть реактивным приемником потока и обновлять сообщение в реальном времени, чтобы игрок видел, что AI уже отвечает. AICore представлен как системный слой Android, который держит модель общей для приложений, обновляет ее через Google Play и управляет CPU/GPU/NPU с учетом памяти, скорости токенов и нагрева. Для проекта важна не Android-часть, а паттерн: отделить тяжелую генерацию от UI, показывать постепенный вывод и явно управлять состоянием ожидания. Данных по реализации после раздела про загрузку модели мало, поэтому конкретные детали Compose-кода в статье не раскрыты.

- Для GenAI-чата критичен поток токенов, а не вывод готового текста целиком.
- Долгий спиннер на 5-10 секунд воспринимается как зависание интерфейса.
- UI должен обновлять текущий ответ инкрементально и не блокировать ввод/экран.
- Тяжелая загрузка модели или backend-процесса должна иметь отдельное состояние готовности.
- Аппаратные детали AICore к Gradio не применимы напрямую, но UX-паттерн применим.

> 💡 **Действие:** В Gradio UI для RE2×Jade стоит заменить простой статус ожидания на потоковый вывод ответа Narrator: сразу показывать строку «Ведущий думает...» и затем дописывать текст по мере прихода чанков от subprocess. Отдельно добавить состояние «движок загружается» для первого хода, чтобы игрок на телефоне понимал разницу между холодным стартом и обычной генерацией.

Теги: `gemini-nano` `chat-ui` `streaming` `mobile-ux` `aicore`

[Источник](https://dev.to/programmingcentral/mastering-gemini-nano-building-a-high-performance-on-device-ai-chat-ui-with-jetpack-compose-16h2)

---

### Function Calling как слой маршрутизации в мобильных AI-приложениях

*12 мая 2026 · gemilab.net*

Статья описывает переход от обычной схемы «prompt → text response» к архитектуре, где модель выбирает нужные функции сама. Автор подчёркивает, что Function Calling меняет не отдельную фичу, а распределение ответственности: модель принимает решение о маршрутизации, а код выполняет конкретные действия. Для мобильных приложений это важно, потому что новые backend-функции можно добавлять без обновления клиента через App Store или Google Play. Пользовательский запрос на естественном языке вроде «покажи что-то спокойное, но не как обычно» лучше обрабатывается через набор объявленных возможностей, чем через заранее закодированные фильтры. В статье заявлено, что Gemini 3.2 Pro надёжнее предыдущих версий при цепочках из нескольких function calls. Прямой фокус статьи — iOS/Android-приложения, но паттерн применим к Gradio UI с LLM-ведущим и состоянием игры.

- Function Calling переносит выбор действия с клиента на модель, но выполнение оставляет в коде.
- Новые возможности можно добавлять на backend без обновления мобильного клиента.
- Естественный язык лучше подходит для выбора намерения, чем жёсткие UI-фильтры.
- Цепочки из нескольких вызовов функций требуют проверки надёжности и лимитов времени.

> 💡 **Действие:** Для RE2×Jade стоит рассмотреть не прямое управление state через свободный JSON от Narrator, а слой объявленных game-функций: move, inspect, use_item, attack, wait, talk. В мобильном Gradio UI это можно совместить с кнопками быстрых действий, чтобы LLM выбирала допустимую функцию, а game_engine валидировал и применял её к JSON-state.

Теги: `function-calling` `mobile-ux` `llm-routing` `game-state` `gradio`

[Источник](https://gemilab.net/en/articles/gemini-api/gemini-32-pro-function-calling-mobile-apps-indie-dev-guide)

---

## Выпуск 11 мая 2026

### Quilltap переработал UX экипировки вокруг готовых наборов

*7 мая 2026 · github.com*

В коммите Quilltap полностью переработан интерфейс wardrobe для AI-чата с персонажами. Главная идея — показывать составные образы как отдельные bundle-карточки с действиями Take off и Break apart, а не дублировать предметы по каждому слоту. Редактор получил явное переключение Single garment / Outfit bundle и сценарий Save-as-outfit, который собирает outfit из уже выбранных слотов. В правой колонке появились вкладки Live outfit и Outfit Builder, а выбор outfit при старте чата заменил плоский список чекбоксов на встроенный composer. В Aurora view/edit добавили вкладку Wardrobe, открывающую общий диалог, а sidebar-иконка теперь выбирает последнего активного персонажа в чате. Для проекта важен не сам гардероб, а UX-паттерн: группировать связанные элементы состояния в понятные карточки действий вместо длинных списков слотов.

- Составные наборы показываются одной карточкой, а не повторяются в каждом слоте
- Пользователь может переключаться между одиночным предметом и bundle-сборкой
- Плоский список чекбоксов заменён встроенным builder-компонентом
- Контекстный запуск из sidebar выбирает последнего активного персонажа
- Удалены старые карточки и списки, потому что workflow стал другим

> 💡 **Действие:** Для мобильного Gradio UI сделай аналогичный слой группировки инвентаря: показывай экипированные/надетые связки одной компактной карточкой рядом с HP, ранами и инфекцией, с действиями вроде «снять», «разобрать», «использовать». Это лучше, чем длинный список предметов по слотам, потому что на телефоне игрок быстрее понимает текущее состояние перед вводом следующего хода.

Теги: `quilltap` `wardrobe` `mobile-ux` `inventory-ui` `chat-ui`

[Источник](https://github.com/foundry-9/quilltap-server/commit/36c278e01fc4238298a770865b27edea1876f154)

---

### On-device LLM как безопасный слой действий в мобильном приложении

*7 мая 2026 · medium.com*

Статья показывает, как Apple FoundationModels используется не как отдельный чат, а как AI-слой внутри реального приложения с локальным состоянием. Пример построен вокруг библиотечного приложения на SwiftData: список книг, экран детали и ассистент, который может перечислять книги, открывать карточку и менять статус книги. Ключевой паттерн — перед запуском AI проверять доступность модели, потому что Apple Intelligence зависит от устройства, настроек и готовности модели. Автор подчёркивает ограничения on-device LLM: приватность, офлайн-работа и отсутствие серверной стоимости полезны, но большие промпты и глубокие рассуждения не являются сильной стороной. Для действий в приложении предлагается использовать короткие прямые промпты и role-specific instructions. Самая применимая идея — guided generation со структурированным выводом, чтобы модель не просто отвечала текстом, а возвращала понятное намерение для UI и бизнес-логики.

- AI полезнее в приложении, когда управляет конкретными действиями, а не только ведёт чат.
- Перед AI-ходом нужен явный статус доступности: модель готова, недоступна, скачивается или отключена.
- Короткие инструкции и ограниченный набор действий снижают риск расплывания поведения модели.
- Structured output превращает свободную фразу пользователя в проверяемую команду приложения.

> 💡 **Действие:** Для Gradio UI добавь рядом с полем ввода компактный русский индикатор состояния хода: «Ведущий думает», «обновляю состояние», «ход применён», «ошибка ответа». В parser/action layer стоит держать whitelist намерений игрока и показывать подтверждение только для рискованных действий вроде лечения, траты патронов или смены локации.

Теги: `on-device-ai` `structured-output` `mobile-ux` `app-actions` `chat-ui`

[Источник](https://medium.com/@navinkumar7582/foundation-models-building-a-real-library-app-with-apples-on-device-ai-a65d739b3aa5)

---

### LoreKeeper: EPUB-библиотека с экспортом текста для AI

*7 мая 2026 · dev.to*

Автор описывает LoreKeeper, open-source менеджер EPUB с 3D-интерфейсом на Three.js и локальным запуском через Docker. Главная идея проекта — не просто показать книги как объекты на полках, а подготовить их содержимое для работы с AI. Изначально автор пробовал local RAG с локальными LLM, но отказался от этого из-за нагрузки на железо при одновременной работе 3D-движка и модели. Вместо этого LoreKeeper делает AI-Bridge: извлекает, очищает и форматирует текст EPUB в структурированный .txt для ChatGPT, Claude или Gemini. Для проекта с телефонным Gradio UI статья почти не применима как пример 3D-интерфейса, но полезна как аргумент в пользу легкого UI и вынесения тяжелой AI-работы на backend. Также интересна идея «чистого экспорта контекста» как отдельного слоя между сырыми данными и LLM.

- 3D-интерфейс выглядит эффектно, но автор сам упирается в нагрузку на пользовательское железо.
- Практичный pivot — заменить local RAG на AI-Bridge с подготовкой чистого текстового контекста.
- Для LLM-продукта важен слой очистки и структурирования данных перед передачей в модель.
- Docker используется как способ упростить локальный self-hosting без ручной настройки Node.js.
- RSVP speed reading в roadmap можно рассматривать как идею ускорения чтения длинного текста.

> 💡 **Действие:** Не переносить 3D-подход в игру: для мобильного Gradio это лишняя нагрузка и слабая применимость. Вместо этого стоит сделать «AI-Bridge» внутри интерфейса: отдельную кнопку/экран экспорта текущего state, инвентаря, ран и последних сцен в компактный текст для отладки промпта и ручного анализа.

Теги: `threejs` `epub` `ai-bridge` `rag` `mobile-ux`

[Источник](https://dev.to/gabriele_trovato_e7184eb0/building-lorekeeper-an-immersive-3d-library-to-bridge-epubs-and-ai-14go)

---

### GenFM превращает текст в диалоговый AI-подкаст

*9 мая 2026 · elevenlabsmagazine.com*

ElevenLabs GenFM — функция внутри мобильного приложения ElevenReader, которая превращает PDF, статьи, ebook, YouTube-ссылки и вставленный текст в AI-подкаст с двумя ведущими. В отличие от обычного text-to-speech, система не просто зачитывает материал, а пересобирает его в диалог: ведущие задают вопросы, реагируют друг на друга, переформулируют и контекстуализируют источник. Генерация обычно занимает несколько минут, после чего выпуск сохраняется в библиотеке ElevenReader. Поддерживаются iOS и Android, выбор языка вывода, несколько голосов и настройка стиля обсуждения. В статье GenFM сравнивается с Google NotebookLM Audio Overview: у ElevenLabs сильнее качество голосов, у Google лучше интеграция с источниками через экосистему Drive. Для текущей UI-секции материал полезен не как игровая механика, а как пример мобильного UX для ожидания AI-генерации и превращения длинного текста в более легкий формат потребления.

- GenFM делает не TTS-чтение, а двухголосый диалог по исходному материалу
- Мобильный UX строится вокруг быстрого импорта контента, ожидания 2-5 минут и сохранения результата в библиотеке
- Натуральность достигается паузами, реакциями, вопросами, легкими несогласиями и вариативной интонацией
- Главный паттерн для игры — AI-ответ можно подавать как живую сцену с ритмом, а не как монолитный блок текста

> 💡 **Действие:** В Gradio UI для телефона попробуй разбивать длинный ответ Narrator на короткие реплики с визуальным ритмом: сцена, реакция NPC, системное состояние, варианты действий. Для ожидания GPT-5.5 добавь явный статус на русском вроде «Ведущий обдумывает сцену...» и прогресс-ощущение без фейкового процента.

Теги: `elevenlabs` `genfm` `mobile-ux` `ai-audio` `chat-ui`

[Источник](https://elevenlabsmagazine.com/elevenlabs-genfm-guide-2026/)

---

### Edge AI в мобильных приложениях: стриминг, история и fallback

*6 мая 2026 · rorklab.net*

Материал описывает production-архитектуру для локальных LLM в Rork/React Native приложениях через Ollama. Главные элементы: HTTP-стриминг токенов для плавного chat-UX, хранение истории диалога в SQLite, маршрутизация задач между локальными моделями и fallback на облачные API. Автор делает акцент на экономике indie-приложений: локальная модель на VPS даёт фиксированную стоимость вместо роста расходов за токены. Для UX важен именно streaming: пользователь видит, что модель отвечает постепенно, а не ждёт пустой экран. Также предлагается выбирать модель по типу задачи и длине контекста, чтобы избегать OOM и держать задержку под контролем. Статья не про interactive fiction напрямую, но её паттерны применимы к мобильному Gradio UI с LLM-ведущим.

- Стриминг ответа снижает ощущение задержки в chat-UI.
- История диалога должна храниться отдельно от модели и управляться явно.
- Fallback на облачную модель полезен как аварийный маршрут, а не как основной путь.
- Маршрутизация модели по типу задачи помогает балансировать скорость и качество.
- Для indie-проектов локальный LLM даёт предсказуемую стоимость, но требует контроля latency.

> 💡 **Действие:** Для RE2×Jade стоит добавить в Gradio UI видимый режим «ведущий отвечает» со стримингом текста или хотя бы покадровым выводом ответа, чтобы на телефоне не было ощущения зависания. Отдельно проверь, можно ли показывать короткий индикатор этапа: «обработка хода», «обновление состояния», «сцена готова» без раскрытия технических деталей.

Теги: `ollama` `streaming` `chat-ui` `edge-ai` `mobile-ux`

[Источник](https://rorklab.net/en/articles/rork-dev/rork-offline-ai-app-complete-implementation-premium)

---

### Память и ветвление как главные критерии AI text games

*6 мая 2026 · storynight.io*

StoryNight сравнивает AI text-based games по практическим критериям: качество диалогов, память между сессиями, связность маршрутов и устойчивость длинных сюжетных арок. Для теста платформы гоняли по одному сценарию с несколькими персонажами, локациями и незакрытым subplot, проверяя, когда AI забывает имена, ломает голос персонажа или теряет последствия ранних выборов. Главный вывод статьи: память важнее всего, потому что большинство AI text platforms быстро забывают базовые факты о протагонисте и сюжете. Второй критерий — voice consistency, чтобы NPC не сливались в один тон через несколько сцен. Третий критерий — route coherence: ранние решения должны реально влиять на поздние сцены, как в нормальной branching narrative. Статья отдельно отмечает, что гибридная структура с авторскими ветками и AI-диалогом работает стабильнее, чем полностью свободная генерация.

- Память между сессиями названа главным отличием хороших AI text games от слабых.
- Длинные сюжетные арки тестировались через повторяющихся персонажей, локации и незакрытый subplot.
- Voice consistency важна почти так же, как память: персонажи должны сохранять разные голоса.
- Hybrid approach с авторской структурой и AI-диалогом лучше удерживает route coherence.
- Полностью свободная импровизация чаще ломает последствия ранних выборов.

> 💡 **Действие:** Добавь в мобильный UI отдельный компактный блок «Память сцены»: 3-5 фактов, которые GPT-5.5 обязан учитывать в текущем ходе, например активный subplot, раны, отношения NPC и последнее обещание игрока. Это поможет игроку видеть, что state реально сохранён, и быстрее замечать drift без чтения JSON.

Теги: `ai-text-games` `memory` `branching` `mobile-ux` `interactive-fiction`

[Источник](https://www.storynight.io/blog/best-ai-text-based-games)

---

### LLM-NPC как замена деревьям диалогов и их UX-риски

*5 мая 2026 · pinkcrow.net*

Статья разбирает переход от заранее написанных деревьев диалогов к NPC, которые отвечают через LLM на свободный ввод игрока. Главная идея — LLM меняют контракт между игроком и игрой: вместо выбора из реплик игрок получает открытое семантическое пространство. На примерах Sony, Inworld AI, Vaudeville и Suck Up! автор показывает, что prompt-driven взаимодействие уже может становиться не украшением, а основной игровой механикой. При этом ключевые ограничения остаются прежними: hallucinations, latency и потеря авторского контроля над сюжетом. Для нарративных игр это означает, что ошибки LLM нужно проектировать как ограничения системы, а не считать обычными багами. Писатели и дизайнеры не исчезают, но их роль смещается от написания линейных реплик к проектированию архитектуры поведения, границ персонажей и правил мира.

- Свободный ввод дает игроку больше agency, но резко увеличивает число неожиданных состояний.
- Hallucinations в LLM-нарративе становятся UX-проблемой: игрок видит их как поломку мира или персонажа.
- Latency облачной LLM критична для ощущения живого диалога, особенно если ход должен восприниматься как быстрый ответ.
- Prompt-driven механики могут заменить часть классических игровых правил, если UI ясно показывает границы возможного.
- Нарративному дизайнеру нужно проектировать не реплики, а рамки поведения NPC и допустимые изменения state.

> 💡 **Действие:** В RE2×Jade не делать NPC полностью свободными: добавь рядом с полем ввода 3-5 контекстных кнопок намерений вроде «спросить», «угрожать», «обмануть», «осмотреть», а свободный текст оставь для деталей. Это снизит narrative drift и поможет GPT-5.5 привязывать реплики к state, не превращая игру в бесконтрольный чат.

Теги: `llm-npc` `interactive-fiction` `chat-ui` `narrative-agency` `latency` `game-ux`

[Источник](https://pinkcrow.net/ai/ai-npcs/)

---

### Браузерные текстовые игры выигрывают за счет низкого входа

*6 мая 2026 · storynight.io*

Статья объясняет, почему в 2026 году браузерные текстовые игры стали удобным форматом для interactive fiction: они запускаются без установки, работают на телефоне и десктопе, часто имеют бесплатный вход. Отдельно выделяется рост AI-driven текстовых игр, которые теперь чаще выходят сразу как browser-native опыт, а не как отдельные приложения. Важный UX-фактор — сохранения: старую проблему потери прогресса при закрытии вкладки современные проекты решают локальными и облачными сейвами через аккаунт. Для мобильной игры статья прямо указывает на проблему parser-based ввода: набор команд с телефона создает трение, поэтому choice-based и touch-friendly интерфейсы работают лучше. В примерах перечислены StoryNight, Fallen London, ChoiceScript, Twine на itch.io и The Dreamhold как разные варианты браузерной interactive fiction. Для проекта полезнее всего вывод про мгновенный старт, mobile-optimized layout, persistent saves и снижение доли ручного набора на телефоне.

- Browser-native формат снижает трение: без установки, без приложения, сразу в мобильном браузере.
- Cloud/local saves стали обязательной частью UX для длинных текстовых игр.
- Parser-команды хуже подходят для телефона из-за трения при наборе текста.
- Choice-based и visual-novel-style интерфейсы лучше переносятся на мобильный экран.
- Twine и ChoiceScript показывают ценность коротких touch-friendly решений для branching narrative.

> 💡 **Действие:** В Gradio UI добавь рядом со свободным вводом набор контекстных кнопок действий для частых команд: осмотреться, инвентарь, осторожно идти, атаковать, спрятаться, использовать предмет. Для мобильного UX также сделай явный индикатор автосохранения после каждого хода: «Сохранено: ход N», чтобы игрок не боялся закрыть вкладку.

Теги: `browser-games` `mobile-ux` `interactive-fiction` `cloud-saves` `choice-ui`

[Источник](https://www.storynight.io/blog/best-text-based-browser-games)

---

### Четыре слоя, которые удерживают AI-roleplay от распада

*8 мая 2026 · anione.me*

Статья разбирает AI-roleplay как turn-based collaborative fiction, где LLM держит персонажа, сеттинг и цель на протяжении длинной сцены. Главная проблема таких сессий — drift: персонаж теряет голос, забывает события и превращается в bland narrator после нескольких десятков сообщений. Автор выделяет четыре ключевых слоя: базовую LLM, persona prompt, memory window и output layer. Persona prompt должен работать как character sheet: фиксировать мотивации, речь, реакции под стрессом, ограничения и состояние мира. Memory layer нужен не как полный лог, а как механизм извлечения важных фактов, суммаризации старых событий и повторной подстановки их в каждый ход. Output layer включает изображения, голос, видео и mood tags, но для текстовой игры важнее вывод о том, что дополнительные сигналы состояния помогают удерживать контекст и атмосферу.

- AI-roleplay держится на связке LLM, persona prompt, memory layer и слоя вывода.
- Длинные арки ломаются без памяти, даже если базовая модель сильная.
- Persona prompt должен описывать поведение под давлением, а не только внешность.
- Память должна сжимать старые события в ключевые факты и возвращать их в каждый ход.
- Дополнительные mood/state signals могут усиливать нарратив, если не перегружают интерфейс.

> 💡 **Действие:** Добавь в мобильный Gradio UI компактный блок «Память сцены» рядом с нарративом: 3-5 коротких фактов из текущего state, которые реально попадают в prompt_builder на следующий ход. Это поможет игроку видеть, что Game Master помнит важное, и быстрее замечать drift или неверно сохранённые факты.

Теги: `ai-roleplay` `memory` `persona-prompt` `llm-narrative` `mobile-ux`

[Источник](https://www.anione.me/en/blog/ai-roleplay-guide-2026)

---

### Микросессии для мобильной текстовой игры

*4 мая 2026 · bestgaming.space*

Статья разбирает mobile game loop для коротких сессий на 1–5 минут: игрок должен быстро понять цель, выполнить действие, получить обратную связь и почувствовать прогресс. Главная мысль — короткая сессия не равна просто малому времени игры; она требует низкой когнитивной нагрузки и мгновенного возвращения после паузы. Плохой UX возникает, когда перед самой игрой игрок тратит время на меню, инвентарь, награды или повторную ориентацию в ситуации. Хорошая микросессия дает понятный атомарный шаг: выжить, защититься, собрать, улучшить, решить, выбрать маршрут. Для retention важна не только сложность, а ощущение, что игра уважает время игрока и не наказывает за короткий заход. Хотя статья не про LLM-narrative напрямую, принципы хорошо переносятся на мобильную Gradio-игру с текстовым ходом и долгим ожиданием ответа модели.

- Цель текущего хода должна быть понятна за несколько секунд после открытия игры
- Каждая сессия должна завершаться ощутимым изменением state или ясным следующим шагом
- Меню, инвентарь и статусные панели не должны отнимать время до основного действия
- Игрок должен безопасно прерваться и вернуться без повторного чтения длинного контекста

> 💡 **Действие:** Добавь в мобильный UI компактный блок «Сейчас важно» рядом с нарративом: текущая угроза, ближайшая цель, 2–4 допустимых быстрых действия и состояние HP/инфекции/инвентаря. После каждого хода показывай короткую строку «Итог хода» и «Следующий риск», чтобы владелец мог играть микросессиями без перечитывания всей сцены.

Теги: `mobile-ux` `micro-sessions` `retention` `game-loop` `chat-ui`

[Источник](https://bestgaming.space/designing-for-short-sessions-crafting-mobile-game-loops-that)

---

### Практическая модель применения AI в разработке игр

*10 мая 2026 · dev.to*

Материал описывает AI как ускоритель разработки, а не замену игрового дизайна. Автор делит применение AI на три слоя: dev-time для ускорения производства, ship-time для функций внутри игры и ops-time для эксплуатации после релиза. Основной фокус статьи — социальные игры вроде Stardew Valley, FarmVille и Township, поэтому большая часть контекста не совпадает с текстовой LLM-horror игрой. Полезная идея для проекта — не пускать AI бесконтрольно в ядро игрового опыта без проверок, потому что игроки быстро замечают «AI slop», галлюцинации и слабую связность систем. В статье также подчёркнуты риски live LLM NPC, юридические ограничения, стоимость AI-стека и необходимость human-in-the-loop пайплайна. Для RE2×Jade это применимо скорее как принцип организации: отделять AI для разработки, AI в игровом ходе и AI для анализа логов/ретеншна.

- AI усиливает уже правильный дизайн, но не придумывает его вместо разработчика.
- Полезно разделять AI-задачи на dev-time, ship-time и ops-time слои.
- Live LLM NPC и генеративный контент требуют ограничений, проверок и human-in-the-loop.
- Главные риски: галлюцинированные системы, AI slop, стоимость и юридические ограничения.

> 💡 **Действие:** Раздели AI-функции проекта на три списка: разработка, игровой ход, анализ после сессий. Для игрового хода оставь GPT-5.5 только как Narrator/Game Master, а проверку state, инвентаря, ран и инфекции держи в deterministic Python-слое, чтобы не получить галлюцинированные механики.

Теги: `ai-games` `llm-narrative` `game-design` `liveops` `ux`

[Источник](https://dev.to/truongpx396/building-social-games-with-ai-the-practitioners-guide-o98)

---