Наковальня Пустоты

Те, кто играл (кто не играл оч рекомендую) в Dragon Age: Origins и достаточно долго шатался по гномьим подземельям, наверняка помнят Наковальню Пустоты.

Каридин создал ее для производства големов.

Инструмент получился настолько эффективным, что довольно быстро возник классический технологический вопрос:

«Если мы можем это делать - означает ли это, что мы должны это делать?»

Сначала в големов превращали добровольцев. Потом добровольцев стало не хватать. Дальше история ожидаемо пошла куда-то не туда...

Каридин попытался остановить конвейер и в итоге сам превратился в голема.

А спустя много лет уже перед игроком появляется выбор: уничтожить Наковальню или сохранить инструмент, способный дать гномам огромное преимущество (но какой ценой?).

Я тогда Наковальню оставил. Инструмент слишком полезный. Проблема ведь не в молотке. Проблема начинается, когда молотку дают должность главного архитектора, геймдизайнера, программиста, художника и продюсера одновременно.

С AI у меня примерно такое же отношение. Я не считаю, что нужно уничтожать Наковальню. Наоборот.

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

Вообще не стоит кидаться в крайности типа:

"AI - зло. Настоящий разработчик должен всё писать руками".

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

Но есть и другая крайность:

"Зачем вообще что-то знать? Написал промт — получил игру".

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

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

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

По Интеграции SDK у меня к примеру отдельная ветка. Спецом для этого сделал навыки для агентов, шаблоны. Процессы постоянно обновляются.

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

То есть я не говорю агенту: "Сделай мне такую игруху, чтобы все просто охренели и были в восторге! Чтобы я ее загрузил потом на Яндекс Игры и сразу начал грести деньги лопатой."

Задача выглядит скорее так:

вот этот модуль отвечает за сохранения;

вот контракт данных;

здесь должен быть платформенный адаптер;

игровая логика не должна напрямую обращаться к SDK;

вот сюда добавь конкретное поведение;

вот "это" не трогай, совсем... даже если будет "так" или "вот так" - не трогай!

Сначала я стараюсь прокрутить решение у себя в голове. Представить блоки. Представить как я стою в чистом поле, а вокруг мощный цветовой контраст, ветер... Связи. Где состояние. Кто кого вызывает. Что произойдёт после рекламы (Игрок закроет игру и никогда ее не откроет). Что будет, если SDK не загрузится. Что произойдёт при потере фокуса окна. И только потом отправляю конкретную работу в нашу цифровую кузницу.
По мне, это наиболее здоровый вариант использования AI агентов.

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

Например, игра Astro.

Первую играбельную версию я буквально навайбкодил за пару часов.

Я специально решил сделать игру максимально AI-first: концепцию прорабатывать через GPT, реализацию отдать Codex, работать через VS Code, а графику по возможности вообще не рисовать традиционным способом.

Хотелось проверить несколько довольно простых вопросов.

Что получится?

Можно ли в это будет играть?

«Способна ли такая игра зарабатывать?

Сколько времени я реально потрачу?

Каким окажется качество?

И главное:

«Что произойдёт, если я постараюсь прикладывать к непосредственному производству как можно меньше ручного труда?»

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

В этом и был смысл эксперимента.

Я хорошо знаю, как работают игры такого типа, поэтому мог довольно точно понимать, где ИИ делает нормально, где делает ерунду, а где делает работающую ерунду.

Последнее, кстати, отдельная категория.

За основу взял старую классику в духе «Galaxian» — fixed shooter (аркадный шутер с ограниченной зоной движения), один из ранних представителей жанра shoot 'e
m up.

Это одна из тех игрушек, с которыми я познакомился ещё во времена NES, в далеком детстве. Насколько помню одна из первых игр в которые я играл на денди.

Сама идея намеренно простая. Мне хотелось проверять не мою способность придумать невероятную концепцию, а способность GPT и Codex построить полноценную игру на хорошо понятном фундаменте.

Просто клонировать Galaxian мне было неинтересно.

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

Например, убрал необходимость постоянно нажимать кнопку выстрела. Стрельба стала автоматической. Добавил простую прогрессию. Валюту. Разные корабли. Разные типы оружия. Паттерны поведения противников. Боссов.

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

Мне хотелось, чтобы у игры был конец. Лично меня в старых бесконечных аркадах всегда немного раздражало отсутствие финальной точки. Поэтому после 100 уровней в Astro появляется финальный очень жирный босс.

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

Часть идей для его поведения я вообще достал из каких-то своих старых наработок. Уже даже не вспомню, какой давности. Было интересно посмотреть, как ИИ реализует знакомые мне игровые паттерны. И реализовал он их именно так как и планировалось.

Я сделаю игру с одного промта!

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

Да, можно написать:

Сделай Galaxian, только современный.

Через некоторое время на экране действительно что-то полетит.

Но между:

«что-то полетело» и «в это можно нормально играть» находится небольшая такая пропасть. И вот там начинается работа.

У меня уже был собственный HTML5-шаблон, который когда-то делался руками. Адаптация под разные экраны, базовые подходы к интеграции SDK и некоторые другие решения не рождались в Astro с нуля.

Было понимание платформы. Ну и самое главное - я знал, как подобная игра должна работать.

Поэтому весь эксперимент нельзя честно описать как: написал предложение - получил коммерческую игру. Так пока не работает.

Скорее: «поставил ИИ практически на все производственные позиции под тщательным наблюдением.»

Самая большая проблема оказалась вообще не в коде

Баланс. ИИ его не чувствует.

Он прекрасно может написать:

damage = 4;

fireRate = 1.2;

enemyHp = 15

Но почему здесь должно быть `4`, а не `2.7`?

Почему скорострельность должна расти именно так?

Когда игрок начнёт чувствовать усиление?

Когда прокачка сломает сложность?

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

Вот здесь магия внезапно заканчивается.

Приходилось самому задавать:

характеристики кораблей;

порядок их силы;

прирост урона;

скорострельность;

стоимость;

количество рикошетов;

количество траекторий;

здоровье;

частоту атак;

ограничения на одновременно атакующих врагов;

поведение босса;

интервалы между атаками;

награды;

темп прогрессии.

Причем быстрее было бы просто открыть игровой движок и передвинуть три значения руками. Серьезно. Я дольше объяснять и описывать это буду...

Пока сформулируешь промт. Пока объяснишь контекст. Пока агент изменит. Пока проверишь. Потом выясняется, что "немного увеличить скорострельность" он понял несколько иначе, чем ты. Пишешь еще один промт. Потом ещё один.

В какой-то момент сидишь и думаешь:

«я сейчас автоматизирую работу или очень медленно редактирую переменную через посредника?»

Но кое-где ИИ оказался чертовски хорош

Я специально открыл финальную сборку Astro и посмотрел на неё не как автор игры, а как программист.

Некоторые решения там хорошие. Прям действительно хорошие. Например, интеграция Яндекс SDK вынесена в отдельный адаптер. Игровая логика не разбросана прямыми вызовами `YaGames` по всему проекту. Есть отдельный слой `yandex-sdk-adapter.js`, который занимается авторизацией, рекламой, облачными сохранениями, таблицами лидеров и событиями платформы. Это правильное решение. Хранилище тоже сделано довольно аккуратно.

Есть нормализация данных, локальные сохранения, объединение локального и облачного прогресса, версия настроек, обработка старых сохранений.

Для браузерной игры такого уровня - вполне здраво.

Есть отдельные модули:

`config.js`;

`storage.js`;

`audio.js`;

`i18n.js`;

`yandex-sdk-adapter.js`;

`ui.js`;

`game.js`;

`main.js`.

Без npm. Без фреймворка. Без игрового движка. HTML5/JS/Canvas. В целом эта "портянка" оказалась вполне читаемой.

На оптимизацию тоже пришлось потратить время. Я наивно полагал, что ИИ сам учтёт этот момент. Увы. Когда в игре стало много объектов, появились просадки производительности. И пришлось уже напрямую ставить конкретные задачи.

Например, пришлось указывать чтобы он сделал:

Object Pooling — объекты пуль и частиц не создаются заново каждый раз, а переиспользуются.

Это снижает давление на Garbage Collector (сборщик мусора).

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

Закешировать Canvas-спрайты.

То, что раньше перерисовывалось сложными Canvas-path каждый кадр, в ряде мест предварительно собирается в offscreen canvas (скрытый холст), а затем используется повторно.

Закешировать: противники; снаряды; некоторые эффекты; полосы HP; бонусы и т.д.

Появились короткие simulation substeps (подшаги симуляции), чтобы при просадке FPS быстрые снаряды не начинали пролетать сквозь цели.

Обновления HUD ограничить по частоте, чтобы выполнялись только при изменении значений.

Удалить части временных объектов без "дорогого" сдвига массивов. до этого он его двигал.

Уменьшить количество ненужных `atan2`, Canvas transforms и пересозданий объектов.

То есть если поставить перед ИИ конкретную задачу:

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

Найди способы уменьшить allocation и количество операций на кадр. То ИИ работает очень достойно. И вот это для меня один из главных выводов всего эксперимента.

**Чем точнее я сам понимал проблему, тем полезнее становился ИИ. **Как-то подозрительно.

А теперь посмотрим внутрь голема

Есть и другая сторона. Основной `game.js` в текущей версии - примерно «2200 строк».

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

Работает?

Да.

Хотел бы я добровольно построить архитектуру нового проекта именно так? Хотел бы я далее работать с этим проектом? Нет, нет, нет.

В коде хватает hardcode (жёстко прописанных значений).
Есть некоторые формулы, которые фактически продублированы между игровой логикой и UI.
Например, визуальное описание усиления оружия рассчитывается отдельно от самой механики оружия.
Это потенциальная точка рассинхронизации.
Проект использует общий глобальный namespace `window.GameTemplate`.

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

Также нет нормального автоматизированного набора unit-тестов.
Зато есть большой `QUALITY_GATE.md`, чек-листы и проверки синтаксиса - это полезно. Но чек-лист не заменяет тесты. Тесты есть тесты.
Есть довольно агрессивное восстановление после runtime-ошибок непосредственно в игровом цикле.

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

Ну и главное.

Архитектура появилась «эволюционно».

Не: «сначала определили систему, затем реализовали».

А: «сделали - добавили - починили - расширили - оптимизировали - еще добавили - теперь это трогать нельзя, оно держит потолок».

Знакомо?
Мне тоже…

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

С графикой Наковальня экономит огромное количество времени

В игре практически нет традиционного набора игровых изображений.

Корабли, враги, боссы, снаряды, эффекты и значительная часть визуала рисуются непосредственно через Canvas. То есть ассет фактически является кодом.

Для эксперимента как по мне - отличный вариант.

Мне не пришлось:

• рисовать десятки спрайтов;

• экспортировать их;

• собирать атласы;

• постоянно перекидывать новые версии;

• следить за разрешениями каждого изображения.

Поменял параметры - получил другой силуэт. Попросил переработать визуальный язык - изменился весь набор. По скорости проверки гипотез это очень мощно.

Что касается уникальности... тут без чудес, получите очередной конвейерный ИИ продукт.
То же самое со звуком: часть звукового оформления генерируется через WebAudio.

Для прототипирования и небольших HTML5-проектов ИИ здесь действительно может резко сократить производственный цикл.
Хотя есть обратная сторона.
Когда все генерируется одним инструментом и примерно одним способом... Начинаешь это видеть.

Итог

В игру можно играть. Более того, в целом она получилась примерно такой, какой я ее и представлял. Можно считать что ИИ справился.

Но все равно, сколько я ни пытался потом добавить ей характера...

Нет авторской мелочи, странности, неправильности, решения из серии "я художник я так вижу".

Слишком "правильно" собиралось вокруг требований. Я могу это почувствовать, потому что делал игры другими забытыми способоми.

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

Получится конвейерный очередной голем.

Сэкономил ли я время?

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

И да и нет.

Огромное количество времени сэкономлено на:

• первичной реализации;

• рутинном коде;

• Canvas-графике;

• локализации;

• документации;

• поиске очевидных ошибок;

• рефакторинге отдельных участков;

• оптимизации;

• создании однотипных систем;

• проверке технических гипотез.

Но когда дело доходило до:

• баланса;

• feel (ощущения управления);

• сложности;

• игровой экономики;

• поведения врагов;

• темпа прогрессии;

• архитектурных решений;

• требований платформы;

экономия становилась гораздо менее очевидной.

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

«Чем меньше я знаю о задаче - тем волшебнее выглядит ИИ.»

«Чем лучше я знаю задачу - тем отчетливее вижу, где он действительно экономит время, а где просто переносит работу из кода в промты»

И второй вариант мне нравится гораздо больше. Потому что тогда ИИ перестает быть магией. Он становится инструментом.

Что дальше будет делать Darles Games

Наковальню мы уничтожать не будем. Слишком полезная.

ИИ уже хорошо работает как:

• ускоритель прототипирования;

• дополнительный программист;

• инструмент анализа;

• генератор технических вариантов;

• помощник при оптимизации;

• средство автоматизации рутины;

• быстрый способ проверить идею;

• помощник при работе с незнакомым API.

И дальше его роль будет только увеличиваться. Но все же многие задачи и решения я оставлю за собой.

Особо важным считаю умение отсекать и выбрасывать предложенные решения ИИ. Потому что человек, который уже не способен сказать агенту: "Нет. Это плохое решение. Переделывай вот так." - не управляет Наковальней.

И в какой-то момент его самого может ждать судьба Каридина.

Может ли ИИ сделать коммерческий продукт?

Результатом эксперимента стала Astro - браузерная аркада на Яндекс Играх.

Это не попытка показать: "Смотрите, ИИ уже заменил разработчиков".

Наоборот…

Мне было интересно проверить предел инструмента, который все плотнее становится частью нашей профессии.

Способен ли ИИ помочь создать готовый коммерческий продукт?
Да.
Но за качество, идею, исполнение, баланс и конечный игровой опыт по-прежнему отвечаете вы.

Я довольно давно использую ИИ, и сделал определенные выводы. За это время:

Где-то ИИ меня удивил.
Где-то не оправдал ожиданий.
Где-то сэкономил часы.
Где-то заставил потратить час на то, что руками заняло бы десять минут.

Прогресс ИИ определенно напоминает снежный ком. Куда он в итоге врежется и какие будут последствия - тема для отдельного разговора...

---

Наковальня вайбкодинга продолжит работать.

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

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

Ну и живых дварфов, пожалуй, будем использовать пореже. Хотя бы до следующего обновления...

Не кукольный дом, а живая система

Обычно в симуляторе жизни игрок выбирает персонажа и говорит ему:

Проснуться
→ сходить в туалет
→ приготовить завтрак
→ поесть
→ помыть посуду
→ пойти на работу

То есть персонаж остаётся куклой, а игрок становится его внешней волей.

Мне хотелось сделать наоборот.

Члены семьи должны сами:

• замечать собственные потребности;

• оценивать обстановку;

• помнить об обязанностях;

• учитывать отношения;

• выбирать доступное действие;

• жить с последствиями своего выбора.

Игрок не управляет человеком напрямую. Он управляет условиями его жизни.

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

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

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

Минимально достаточный человек

Игра не пытается честно смоделировать человеческое сознание. Для этого не хватит ни компьютера, ни моей жизни.

Вместо этого используется минимальная модель субъектности.

У каждого персонажа есть несколько внутренних состояний:

• энергия;

• голод;

• стресс;

• близость;

• автономия;

• здоровье.

А также более устойчивые черты:

• ответственность;

• общительность;

• любовь к порядку;

• потребность в независимости.

При выборе действия персонаж примерно оценивает:

Насколько мне это сейчас нужно?
+ Привык ли я это делать?
+ Обещал ли я это сделать?
+ Поможет ли это близкому человеку?
+ Считаю ли я это своей обязанностью?
− Сколько потребуется сил?
− Насколько мне это неприятно?
− Что я не успею сделать вместо этого?

После этого он выбирает действие самостоятельно.

Это не настоящий разум. Но если причинно-следственная связь достаточно понятна, игрок начинает видеть не набор коэффициентов, а характер.

Игрок управляет не людьми, а укладом

В этой игре игрок — не один из родителей и не всемогущий бог.

Скорее, он представляет собой волю домашнего хозяйства.

Его инструменты:

• планировка квартиры;

• покупка предметов;

• семейный бюджет;

• распорядок дня;

• общие приоритеты;

• распределение ответственности;

• крупные жизненные решения.

Например, нельзя приказать:

«Мира, немедленно приготовь ужин».

Но можно договориться, что готовка — её ответственность.

И даже после этого Мира может отказаться. Если она истощена, перегружена или считает договорённость несправедливой, формальное назначение не превращает её в робота.

Тогда игроку придётся менять систему:

• передать готовку Павлу;

• снизить другие обязанности Миры;

• купить готовую еду;

• приобрести бытовую технику;

• пожертвовать частью дохода ради свободного времени;

• временно согласиться на менее чистый дом.

Здесь нет идеального решения. Есть только разные последствия.

Дом одновременно является миром и интерфейсом

Графически игра вдохновлена компактными менеджмент-стратегиями с изображением здания в разрезе.

Весь дом виден сразу:

Каждая комната — не просто декорация, а функциональный блок системы.

Кухня преобразует продукты, время и энергию в готовую еду. Спальня преобразует время и покой в восстановление. Рабочее место превращает силы человека в деньги и стресс. Гостиная может создавать близость — или конфликт.

Игрок смотрит на дом как на живую кибернетическую схему.

Люди в ней не фишки. Они сами перемещаются между помещениями и используют доступные возможности.

Главный ресурс семьи — не деньги

Деньги важны, но настоящий дефицит — время и внимание.

У каждого человека только один день.

Если Павел берёт дополнительные смены:

Доход растёт
→ Павел сильнее устаёт
→ меньше участвует в быту
→ нагрузка переходит на Миру
→ у Миры исчезает личное время
→ растёт раздражение
→ ухудшается атмосфера дома
→ Лена получает меньше спокойного внимания

Дополнительная работа была рациональным решением. Семье действительно нужны деньги.

Но локально правильное решение может сделать всю систему менее устойчивой.

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

Даже еда — это цепочка

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

Полная цепочка выглядит так:

Работа
→ деньги
Деньги + время
→ покупка продуктов
Продукты + время + энергия
→ готовые порции + грязная посуда
Готовая порция
→ снижение голода
Грязная посуда + время + энергия
→ чистота

Если никто не купил продукты, готовить не из чего.

Если продукты есть, но никто не приготовил еду, ребёнок всё равно останется голодным.

Если еда приготовлена, но вся кухня завалена посудой, бытовая нагрузка никуда не исчезает — она просто перенесена в будущее.

Так из нескольких простых преобразований появляется домашняя экономика.

Что такое семейный климат

Кроме индивидуальных состояний, у дома есть общий эмоциональный климат.

Это не ресурс, который можно потратить, как деньги. Скорее, это температура семейной среды.

На неё влияют:

• средний стресс;

• близость;

• совместное время;

• неравномерность бытовой нагрузки;

• накопившиеся конфликты;

• забота;

• выполненные и нарушенные обещания.

Климат меняется медленно.

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

Стресс людей
→ ухудшение климата
→ дома труднее отдыхать
→ стресс растёт ещё сильнее

Получается опасная петля обратной связи.

Но возможен и обратный процесс:

Помощь
→ снижение нагрузки
→ меньше раздражения
→ больше возможностей для общения
→ восстановление близости
→ улучшение климата

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

Семья как единый организм

В какой-то момент субъектом становится не только отдельный человек.

Вся семья начинает вести себя как организм:

При этом внешне благополучная семья может быть внутренне хрупкой.

Дом чист. Деньги есть. Ребёнок накормлен.

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

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

Что считается победой?

Я не хочу делать единственную шкалу «идеальной семьи».

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

Вместо этого семья постепенно формирует собственные ценности:

• близость;

• безопасность;

• свобода;

• порядок;

• образование;

• карьера;

• взаимопомощь;

• личное пространство.

Нельзя максимизировать всё.

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

Вопрос игры не в том, насколько семья совершенна.

Вопрос в другом:

Какой она стала — и какой ценой?

Что уже есть в прототипе

Сейчас собран браузерный MVP:

• PHP;

• JavaScript;

• MySQL;

• запуск на обычном хостинге;

• автономная симуляция в браузере;

• автоматические сохранения;

• комнаты, действия и предметы, описанные в базе данных;

• самостоятельный выбор действий персонажами;

• приоритеты и распределение обязанностей;

• бытовые ресурсы;

• нагрузка;

• семейный климат;

• хроника событий.

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

Например, объект «посудомоечная машина» не просто повышает абстрактное счастье. Он изменяет конкретные процессы:

меньше времени на уборку
→ ниже бытовая нагрузка
→ больше времени на отдых
→ меньше стресс
→ выше вероятность общения

То есть предмет становится не бонусом, а вмешательством в систему обратных связей.

Самый важный тест

У проекта есть простой критерий качества:

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

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

• родился ребёнок;

• кто-то заболел;

• изменилась работа;

• закончились деньги;

• приехал пожилой родственник;

• семья переехала;

• старый распорядок перестал работать.

Прежнее равновесие разрушается, и приходится создавать новое.

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

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

И теперь мне интересно:

• Хотели бы вы играть в симулятор, где персонажи могут отказаться выполнять ваши планы?

• Что должно сильнее всего влиять на атмосферу семьи?

• Нужны ли прямые приказы хотя бы в экстренных ситуациях?

• Какие жизненные события стоило бы добавить первыми?

• Где проходит граница между интересной автономией и раздражающим поведением ИИ?

Потому что создать послушную куклу относительно просто.

Гораздо интереснее создать кого-то, с кем придётся договариваться.

6. Делает автоматическую проверку раз в 24 часа, пока Браузер может выполнять фоновые задачи.

7. При запуске браузера дополнительно проверяет, не прошло ли 24 часа с последней проверки.

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

Работает в данных браузерах - Chrome / Yandex Browser / Edge / Brave / Opera / Vivaldi

Как установить:

1. Если у вас один из этих браузеров в строке где сайт вводим
   Яндекс.Браузер: browser://extensions

   Google Chrome: chrome://extensions

   Microsoft Edge: edge://extensions

   Brave: brave://extensions

   Vivaldi: vivaldi://extensions

   Opera / Opera GX: opera://extensions

2. Распаковываем Архив, папку ложите в удобное для вас место, главное не удаляйте иначе не будет работать

3. Включаете режим "разработчика", выбираете папку куда скинули

4. Добавляете, заходите и проверяете

ВИРУСОВ НЕТ! ПРУФЫ НИЖЕ!
VT:
manifest -https://www.virustotal.com/gui/file/7a31f15e7baf8d0c22177b67...
background - https://www.virustotal.com/gui/file/e593c65f0dfe040c3baec477...
popup
https://www.virustotal.com/gui/file/c616f6d1b32d03143d5bc9b7...

https://www.virustotal.com/gui/file/c9d78b4d063e4944b90f283c...

https://www.virustotal.com/gui/file/0a7e7d99292b68559df04f02...

Скачать

Телеграмм канал - https://t.me/skuf_v_pive/298
Яндекс Диск - https://disk.yandex.ru/d/Wb3_B-hAdXPdSw
Яндекс Диск - https://disk.yandex.ru/d/thdZH0DKFgNzJA : UPD - 15.08.2026

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

Также напоминаю, что все внутри генерируется кодом, модели, музыка, окружение и т.д. Без полноценного игрового движка, в роли графического ядра - THREEJS.

Мое видение игры это нечто другое, непохожее на Megabonk или Vampire Survivors. Я не люблю хрючево из частиц на экране (без негатива к играм), поэтому кучи эффектов или горы врагов в моей игре не будет. Также я решил отказаться от лишних цифр, может и урон также уберу. Чтобы игрок не задумывался и не пытался составлять какие-либо системы прокачек, а просто получал удовольствие от геймплея здесь и сейчас, погружался в атмосферу. То есть данный жанр это просто как тарелка для основного блюда.

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

https://www.youtube.com/watch?v=aRJz7s2Bejg

Основные измененения не опять, а снова касаются визуала - могу себе позволить.

Переделал цветовую палитру, добавил bloom эффект, улучшил шейдеры тумана, немного осветлил палитру, было темновато, разнообразил деревья и добавил вариативности окружения:

Особо мне понравился динамический эффект пастозной техники импасто (разводы текстур), тут кстати еще можно посмотреть как персонаж ведет себя при бездействии если не видели, это было сделано еще давно, но все же:

Что немаловажно переделал HUD и UI, теперь это выглядит немного более консистентно как игровой интерфейс, а не веб как было до.

Что немаловажно сильно переделал систему движения персонажа, анимации и прочее (locomotion). Это не стало идеально, но это стало гораздо лучше. Вообще это мой девиз по ходу разработки, если что-то стало немного лучше это уже неплохо. Тут теперь компенсация движения, больше инерции и импульса, больше плавности в переходах, в зависимости от направления движения разная скорость и техника. На самом деле locomotion это самая сложная механика в игре на данный момент.

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

Куда же без экрана смерти с рэгдолом. Радоваться такому приходится по причине отсутствия движка и готовых механик, с THREEJS реализовывать такое приходится без помощи движка:

Некоторые другие изменения:

• Разбросал больше случайных объектов по арене вроде веточек, листьев, мертвых растений и прочего

• Переделал анимацию всплеска персонажа (Splash)

• Улучшил траекторию движения врагов, теперь они меньше застревают и не входят внутрь модели персонажа и двигаются нелинейно

• Немного поменял траву

• Могильные плиты решил генерировать хотя-бы частично по сетке, чтобы они не росли как сорняки где попало

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