Разборы · Статья: · Видео: · 25 мин
Fable 5 в разработке игр: сильная полировка не равна магическому редизайну
Студия Игор тестирует Claude Fable 5 на трёх уже существующих играх: Godot-двор, браузерные караваны и 2D-космические рейнджеры. Получается не чудо, а важный урок про полировку, лимиты и постановку задачи.
Коротко
Fable 5 хорошо читает существующий проект, чинит детали, улучшает камеру и добавляет полировку, но в one-shot не обязательно радикально переделывает игру. Главный урок: если нужен большой редизайн, его надо явно требовать, дробить на этапы и проверять геймплей, а не ждать магии от одной фразы.
Объясни проще
Суть без жаргона
Простыми словами
Автор даёт Fable 5 один и тот же промпт на трёх старых игровых проектах: изучи код, улучши графику и ощущения, сделай игру менее похожей на прототип. Модель работает долго и местами умно, но чаще полирует и чинит, чем полностью переизобретает игру.
Как ребёнку
Роботу дали три уже собранные игры и попросили сделать их лучше. Он подкрутил свет, камеру и кнопки, но не превратил старые игрушки в совсем новые — для этого ему надо было дать более точное и большое задание.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Свежий практический тест Fable 5 на фоне ограниченного доступа к модели и большого интереса к agentic-разработке игр.
Три разных проекта, живой запуск результата и честное обсуждение лимитов дают хороший материал, хотя без строгих сравнений.
Формат теста знакомый, но полезен именно акцентом на доработку существующего кода, а не генерацию с нуля.
Очень полезно для тех, кто хочет отдавать агенту реальные проекты: видно, где промпт надо уточнять, а где модель сама осторожничает.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 На существующем коде модель становится осторожнее
Fable 5 не рвётся переписать всё с нуля. Он чаще исправляет свет, камеру, интерфейс, производительность и мелкие игровые ощущения. Это может разочаровать, если ждать вау, но хорошо для реального проекта, где разрушительный редизайн опасен.
02 Screenshot harness — важный сигнал зрелости агента
В первом проекте модель сама планирует делать скриншоты до и после изменений. Это правильное направление: агент должен не просто править код, а иметь способ увидеть эффект правок.
03 Лимиты становятся частью архитектуры работы
Каждый крупный прогон съедает много времени, токенов и лимитов подписки. Поэтому «один большой промпт» быстро превращается в дорогой и неуправляемый процесс.
04 Game feel часто важнее количества новых объектов
Самые заметные улучшения — камера, тени, движение, отдача и ощущение управления. Новые ассеты и объекты не спасают игру, если боёвка стала хуже или FPS просел.
05 One-shot плохо подходит для больших игровых рефакторингов
Тест честно показывает: агент может улучшить проект, но для сильного результата нужен цикл: цель, диагностика, отдельный визуальный проход, отдельный геймплейный проход, playtest и фиксы.
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
Проси диагностику перед изменениями
Пусть агент сначала перечислит слабые места проекта: графика, камера, управление, производительность, геймплейный цикл, баги. Без диагностики он будет полировать наугад.
Разделяй визуал и геймплей
Отдельно проси улучшить свет/материалы/камеру, отдельно — боёвку, цели, баланс и управление. В одном промпте агент легко сделает косметику и сломает механику.
Включай screenshot/video harness
Попроси агента сделать до/после скриншоты или короткую проверку сцены. Для игр это лучше, чем читать отчёт о том, что «стало красивее».
Ставь лимит на масштаб правок
Если проект уже работает, укажи, что нельзя ломать управление, боёвку и существующие сценарии. Если нужен радикальный редизайн — скажи это явно.
Играй в результат минимум 5 минут
Пройди основной цикл, попробуй проиграть, выиграть, застрять, открыть меню, сменить режим. Игры ломаются не в отчёте агента, а в руках игрока.
Фиксируй расход лимитов
Для больших моделей записывай, сколько ушло времени и токенов на один проход. Это поможет решить, где агент оправдан, а где дешевле дать маленькую задачу.
Сценарии применения
Как разные люди применяют это на практике
Я как инди-разработчик
Проблема: есть прототип игры, но непонятно, как безопасно дать его ИИ на улучшение
Хочу: получить полировку без разрушения рабочих механик
Поможет: статья подсказывает дробить задачу и требовать диагностику, screenshot harness и playtest
Я как автор YouTube-канала про game dev
Проблема: хочется честно сравнивать модели, а не показывать только красивые моменты
Хочу: строить тесты, которые видят и успехи, и поломки
Поможет: разбор показывает, как фиксировать лимиты, время работы, состояние проекта до/после и реальный геймплей
Я как технический лидер
Проблема: агент может внести огромный diff и сломать продукт
Хочу: понять, как ставить ограниченные задачи на существующем коде
Поможет: пример Fable показывает пользу консервативной полировки, но и необходимость явных рамок
Я как геймдизайнер
Проблема: модель добавляет объекты, но игра не становится интереснее
Хочу: перевести задачу с «сделай красиво» на «улучши игровой цикл»
Поможет: статья помогает формулировать цели: мотивация игрока, обратная связь, камера, баланс, проигрыш и победа
Я как покупатель AI-инструментов
Проблема: frontier-модель выглядит мощно, но непонятно, окупается ли дорогой прогон
Хочу: оценить стоимость одного улучшения
Поможет: можно сравнить качество результата с расходом лимитов и временем ожидания
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка Автор выбирает три уже существующих игры
Это важнее генерации с нуля: модель должна читать чужой код, не ломать проект и улучшать то, что уже есть.
-
Аргумент Один общий промпт просит сделать игру круче
Формулировка широкая: изучить код, улучшить графику и ощущения, добавить цельность, но не плодить большие новые фичи.
-
Пример Godot-двор получает свет, тени, камеру и маленький геймплей
Это самый заметный визуальный прогресс, но не радикальный редизайн: стало лучше, однако не без косяков и просадок.
-
Пример Караваны показывают риск полировки
Модель улучшает интерфейс и внутренние детали, но частично ломает боёвку. Это типичный риск большого one-shot diff.
-
Пример Космическая игра меняется мягко
Есть улучшения фона, эффектов и ощущений, но автор не видит революции. Модель скорее полирует, чем переосмысляет.
-
Вывод Вывод: Fable 5 силён, но промпт должен управлять масштабом
Если нужно «починить и отполировать» — модель полезна. Если нужен новый дизайн — требуется явный запрос и итерационный план.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Это хороший противовес роликам, где модель создаёт впечатляющую игру с нуля. Здесь Fable 5 получает уже существующие проекты, а значит должен делать более взрослую работу: понять структуру, не сломать механики, улучшить визуал и добавить ощущение законченности.
Почему результат кажется спокойным
Fable 5 не превращает три проекта в новые игры. В Godot-дворе он улучшает свет, тени, камеру и добавляет простой сбор воспоминаний. В караванах делает полировку, но ломает боёвку. В космической игре добавляет эффекты и фон, однако без радикального скачка. Если ждать «модель перепридумала всё», ролик разочарует.
Но для реального кода это не обязательно плохо. Агент, который осторожно чинит и полирует существующий проект, может быть полезнее агента, который красиво сносит половину архитектуры. Проблема в другом: авторский промпт просил «сделать круче», но не задавал точного масштаба редизайна и критериев успеха.
Что забрать в практику
Для игр важно разделять задачи. Сначала baseline и диагностика, потом один узкий проход: камера, свет, управление, геймплейный цикл или производительность. После этого playtest и следующий проход. Большой one-shot выглядит заманчиво, но на существующих проектах он слишком легко превращается в дорогую лотерею.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 5
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. Почему результат Fable 5 в ролике нельзя назвать однозначным провалом?
-
2. Что такое screenshot harness в контексте ролика?
-
3. Какой риск показала игра про караваны?
-
4. Почему один широкий промпт плохо подходит для большого игрового рефакторинга?
-
5. Что лучше сделать перед тем, как дать агенту существующую игру?
Словарь терминов
Понять незнакомое простым языком
Показать 6 терминов Свернуть словарь
- Fable 5
- Модель Anthropic, которую автор тестирует в Claude Code на задачах разработки игр.
- Godot
- Игровой движок, подходящий для 2D и 3D проектов. В ролике на нём сделан постсоветский двор.
- Game feel
- Ощущение игры в руках: камера, отклик, скорость, звук, отдача, плавность и понятность действий.
- Playtest
- Проверка игры через реальную игру, а не через чтение кода или отчёта модели.
- One-shot
- Один большой запрос без серии уточнений и ручной итерации.
- Diff
- Набор изменений в коде. Большой diff сложнее проверить и он чаще ломает существующее поведение.
Похожие разборы
Fable 5 против Codex 5.5: почему самопроверка важнее красивого демо
Видео показывает не «кто умнее вообще», а где coding-агент проваливает последнюю милю: физику, коллизии, мобильное управление, реальные данные и самоисправление. Fable 5 чаще выглядит как агент, который дольше проверяет себя и доводит идею до playable-состояния, а Codex 5.5 часто даёт красивый, но менее надёжный первый проход.
Читать → РазборGLM-5.2: открытая coding-модель сильна, когда ей дают исправляться
GLM-5.2 выглядит не как модель для одного идеального скриншота, а как сильный открытый агент, который умеет планировать, проверять код и чинить заметные поломки. Главный вывод ролика: для coding-моделей важнее цикл «сделал → запустил → исправил», чем первая красивая генерация.
Читать → РазборВайбкодинг против реальности: как инженер собрал микро-бизнес на ИИ и почему «навык» теперь легко подделать
Внешне простая задача «кропнуть фотку» под капотом оборачивается десятком нейронок, ручным контролем рефандов и войной за токены, а сам сервис может в одночасье потерять выручку из-за апдейта Google. Главный вывод: ИИ обесценил внешние атрибуты навыка — код, тесты, красивые PR теперь генерируются за минуту, а ценным остаётся понимание, которое нельзя сымитировать.
Читать → РазборUnreal Engine 6 и ИИ в геймдеве: что меняется на самом деле, а что — хайп
Epic показала в Unreal Engine 6 генерацию 3D-локаций, целых городов и блюпринтов по тексту — и это правда сдвинет геймдев, но нейросеть лишь собирает готовые модели, а не заменяет 3D-художника. Главный подвох спрятан в цифрах-токенах: за «игры по кнопке» платит сам разработчик, а без идеи и диздока выйдет очередной «нейрослоп».
Читать →