всем привет, делаю свою первую игру на юнити, 3D шутан с видом сбоку
Хочу сделать механику паркура.
В кратце
Игрок прыгает на стену захватывается за уступ и поднимается наверх или же спускается.
Я нашел анимации. Подставил их. Написал код(точнее Claude)
Все проверил, работает.
Однако работает криво.
Ибо я не понимаю как мне настроить коллизию и анимации так.
Чтобы игрок при отыгровке анимации не уходил сквозь текстуры и не застревал там. Гайдов в инете не нашел. ИИ хреново помогает. Может проблема в анимации либо в колизии самого персонажа. Либо в обоих случаях сразу.
В моей игре техника собирается из частей (корпус + башня), за исключением цельной типа вертолёта, джипа и пр.
малый корпус
малая пулеметная башня
Изначально танки были цельными и при покупке игрок выбирал из готовых, но по мере добавления новых типов, их становилось слишком много и я решил что система сборки танка будет и удобнее, и интереснее
часть меню сборки танка
Сложной частью было скорректировать характеристики собранных танков со старой моделью уже готовых, необходимо было подогнать башню и корпус чтобы при сборке "стандартных танков" их характеристики были точно такими же как и раньше.
Изначально вся техника могла моментально поворачивать свой корпус хоть на 180°, но буквально после первого теста в 2м, стало ясно что баланса с такой системой не добится, "мансить" можно было даже на огромном танке так же просто как на джипе и была введена скорость поворота корпуса и башни.
HP техники противника было решено не показывать игроку, после непродолжительных споров на этот счет во время тестов, вместо этого добавлены цифры нанесенного урона в момент попадания
разовый урон
Накопление многократно нанесенного урона суммируется пока урон наносится непрерывно
Решился на небольшой эксперимент, что сможет обычный 3Dэшник без программиста. Идея игры взята частично из Deepcall от Nican с геймджема (Discord канал xKoster'а), но решил сделать с небольшой графикой.
Это не реф, а готовые модели если что😅
Вкратце поднимаемся со дна Марианской впадины на поверхность, по пути будут попадаться различные препятствия в виде существ с картинки, а так же более мелких рыбёх, различной органики, ну и камушки.
Думаю это будет что-то в виде поезда событий, где игроку нужно прятаться, собирать различную органику вне "Батискафа", своеобразно сражаться с коллосами, чистить оставшиеся двигатели, в общем небольшой и незаёбный геймплей с небольшим сюжетом, с рыбками (от 10см до 2000м длиной).🦑
Подход думаю будет таковым: 1)Делаем модельки с ригами 2)Делаем эффекты с разрушениями 3)Качаем движок😂
Исправлены последние редкие ctd при очистке мусора (наконец-то)
Добавлена обработка клавиш в первом приближении.
Комментарий
Все еще до конца не перешел из состояния "втупляю" в состояние "поперло", но через полторы недели отпуск, там разгонюсь.
Система обработки клавиш на данный момент использует калбаки glfw с дополнительной оберткой в виде темплейтов биндов - для создания класса с привязкой к конфигу и системой делегатов для получения вызовов по по событию (на данный момент OnPress и OnRelease).
Выглядит это следующим образом:
Оглашается раскрытие темплейта и вызов его статичного метода для регистрации в системе обработки ввода.
Бинд привязывается к текстовой метке UserSettings конфига
клавиши пока в цифровом формате и без модификаторов
А дальше, где-нибудь в коде на один (или сразу на все) делегаты вешается нужный метод
в данном случае по нажатию Escape будет вызван метод OnEscape экземпляра актера testActor
При этом в лог будет записано страшное, ибо я не придумал ничего умнее, чем связать бинд с конфигом через систему Property (т.е. сейчас каждый бинд это полновесный метакласс фреймворка):
Глубоко прорабатывать систему пока не буду - нет необходимости. Добавлю обработку для мыши, чтобы все таки можно было камерой гулять, и продолжу со светом.
Konami намерена и дальше активно развивать свои известные игровые серии. Президент Konami Digital Entertainment Хидэки Хаякава заявил, что перезапуски Metal Gear, Silent Hill, Castlevania и Suikoden являются важной частью стратегии компании и одной из опор её бизнеса.
По словам Хаякавы, Konami одновременно хочет возвращать популярные франшизы и создавать новые проекты. При этом пока неясно, что именно компания подразумевает под «перезапусками»: речь может идти как о ремейках уже существующих игр, так и о новых проектах в рамках знакомых вселенных.
У Konami уже есть успешные примеры такого подхода. Silent Hill 2 получила полноценный ремейк, а серия продолжила развиваться благодаря новым играм. Компания также готовит Castlevania: Belmont's Curse, а мобильная Suikoden STAR LEAP уже открыла предварительную регистрацию.
Особый интерес вызывает Metal Gear: новая номерная часть пока не анонсирована, однако Konami продолжает развивать франшизу. В конце августа компания также выпускает Metal Gear Solid: Master Collection Vol. 2.
При этом Konami не собирается ограничиваться исключительно проверенными брендами. Руководство подчёркивает, что компания хочет создавать новые жанры и оригинальные проекты — в частности, среди таких разработок находится новая RPG Rev. NOiR.
Те, кто играл (кто не играл оч рекомендую) в Dragon Age: Origins и достаточно долго шатался по гномьим подземельям, наверняка помнят Наковальню Пустоты.
Каридин создал ее для производства големов.
Инструмент получился настолько эффективным, что довольно быстро возник классический технологический вопрос:
«Если мы можем это делать - означает ли это, что мы должны это делать?»
Сначала в големов превращали добровольцев. Потом добровольцев стало не хватать. Дальше история ожидаемо пошла куда-то не туда...
Каридин попытался остановить конвейер и в итоге сам превратился в голема.
Каридин (Dragon Age Origins)
А спустя много лет уже перед игроком появляется выбор: уничтожить Наковальню или сохранить инструмент, способный дать гномам огромное преимущество (но какой ценой?).
Я тогда Наковальню оставил. Инструмент слишком полезный. Проблема ведь не в молотке. Проблема начинается, когда молотку дают должность главного архитектора, геймдизайнера, программиста, художника и продюсера одновременно.
С AI у меня примерно такое же отношение. Я не считаю, что нужно уничтожать Наковальню. Наоборот.
Просто не стоит забывать, кто именно кого кует. Впрочем, эта тема для отдельного разговора.
Вообще не стоит кидаться в крайности типа:
"AI - зло. Настоящий разработчик должен всё писать руками".
Если инструмент позволяет за несколько минут сделать то, на что раньше уходил час, глупо специально от него отказываться.
Но есть и другая крайность:
"Зачем вообще что-то знать? Написал промт — получил игру".
С одной стороны именно так - получить «чет работающее» действительно становится все проще.
А вот получить хороший продукт по-прежнему требует усилий, опыта и понимания того, что ты вообще делаешь.
Для себя я решил, что все же многие вещи "пока?" оставляю за собой, например такие как: архитектура проекта, геймдизайн, баланс. игровой цикл, основные механики, то какой игровой опты должен получать человек и др.
По Интеграции SDK у меня к примеру отдельная ветка. Спецом для этого сделал навыки для агентов, шаблоны. Процессы постоянно обновляются.
Также привык собственноручно добавлять рекламу, сохранения, паузы, жизненный цикл игры и т.д.
То есть я не говорю агенту: "Сделай мне такую игруху, чтобы все просто охренели и были в восторге! Чтобы я ее загрузил потом на Яндекс Игры и сразу начал грести деньги лопатой."
Задача выглядит скорее так:
вот этот модуль отвечает за сохранения;
вот контракт данных;
здесь должен быть платформенный адаптер;
игровая логика не должна напрямую обращаться к SDK;
вот сюда добавь конкретное поведение;
вот "это" не трогай, совсем... даже если будет "так" или "вот так" - не трогай!
Сначала я стараюсь прокрутить решение у себя в голове. Представить блоки. Представить как я стою в чистом поле, а вокруг мощный цветовой контраст, ветер... Связи. Где состояние. Кто кого вызывает. Что произойдёт после рекламы (Игрок закроет игру и никогда ее не откроет). Что будет, если SDK не загрузится. Что произойдёт при потере фокуса окна. И только потом отправляю конкретную работу в нашу цифровую кузницу. По мне, это наиболее здоровый вариант использования AI агентов.
Периодически я провожу небольшие эксперименты, чтобы нащупать границы ии. Понять, на что действительно способен инструментарий. А что пока только очень убедительно делает вид.
Первую играбельную версию я буквально навайбкодил за пару часов.
Я специально решил сделать игру максимально AI-first: концепцию прорабатывать через GPT, реализацию отдать Codex, работать через VS Code, а графику по возможности вообще не рисовать традиционным способом.
Хотелось проверить несколько довольно простых вопросов.
Что получится?
Можно ли в это будет играть?
«Способна ли такая игра зарабатывать?
Сколько времени я реально потрачу?
Каким окажется качество?
И главное:
«Что произойдёт, если я постараюсь прикладывать к непосредственному производству как можно меньше ручного труда?»
Для эксперимента я выбрал хорошо знакомый мне жанр и механику. Намеренно простую. Тренды, популярность жанра и коммерческий потенциал я вообще не учитывал. Буквально взял первое, что пришло в голову и что было мне хорошо знакомо.
В этом и был смысл эксперимента.
Я хорошо знаю, как работают игры такого типа, поэтому мог довольно точно понимать, где ИИ делает нормально, где делает ерунду, а где делает работающую ерунду.
Последнее, кстати, отдельная категория.
За основу взял старую классику в духе «Galaxian» — fixed shooter (аркадный шутер с ограниченной зоной движения), один из ранних представителей жанра shoot 'e m up.
Galaxian
Это одна из тех игрушек, с которыми я познакомился ещё во времена 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 продолжит выпускать из нее новых големов.
Просто Астерон Кодосвет постарается сам не повторить судьбу Каридина и однажды не обнаружить, что кузнец тоже стал частью производственного процесса.
Ну и живых дварфов, пожалуй, будем использовать пореже. Хотя бы до следующего обновления...
День 3 съёмок нашего семейного блокбастера – в прошлый раз мы научили героя создавать магические печати, а сегодня проверяем, умеет ли он отправлять их точно в цель 🪄
На кухне осталась посуда. Ребёнку через сорок минут в школу. Один взрослый не выспался, второй уже опаздывает на работу. Еда в холодильнике есть, но завтрак никто не приготовил.
И тут персонаж решает не мыть тарелки.
Не потому, что сломался ИИ. Не потому, что игрок забыл поставить команду в очередь. А потому, что он устал, вчера уже убирался, считает распределение обязанностей несправедливым и обещал ребёнку помочь с уроками.
Я попробовал сделать игру, в которой подобное поведение — не ошибка, а основа симуляции.
Рабочее название проекта — «Домашний уклад».
Не кукольный дом, а живая система
Обычно в симуляторе жизни игрок выбирает персонажа и говорит ему:
Проснуться → сходить в туалет → приготовить завтрак → поесть → помыть посуду → пойти на работу
То есть персонаж остаётся куклой, а игрок становится его внешней волей.
Мне хотелось сделать наоборот.
Члены семьи должны сами:
замечать собственные потребности;
оценивать обстановку;
помнить об обязанностях;
учитывать отношения;
выбирать доступное действие;
жить с последствиями своего выбора.
Игрок не управляет человеком напрямую. Он управляет условиями его жизни.
Можно купить посудомоечную машину, изменить распорядок, перераспределить обязанности, выделить личное время или решить, что сейчас семье важнее деньги, а не идеальная чистота.
Но нельзя просто схватить Павла невидимой рукой и заставить мыть тарелки.
Павел — субъект. Пусть пока очень примитивный, но уже обладающий собственной логикой.
Минимально достаточный человек
Игра не пытается честно смоделировать человеческое сознание. Для этого не хватит ни компьютера, ни моей жизни.
Вместо этого используется минимальная модель субъектности.
У каждого персонажа есть несколько внутренних состояний:
энергия;
голод;
стресс;
близость;
автономия;
здоровье.
А также более устойчивые черты:
ответственность;
общительность;
любовь к порядку;
потребность в независимости.
При выборе действия персонаж примерно оценивает:
Насколько мне это сейчас нужно? + Привык ли я это делать? + Обещал ли я это сделать? + Поможет ли это близкому человеку? + Считаю ли я это своей обязанностью? − Сколько потребуется сил? − Насколько мне это неприятно? − Что я не успею сделать вместо этого?
После этого он выбирает действие самостоятельно.
Это не настоящий разум. Но если причинно-следственная связь достаточно понятна, игрок начинает видеть не набор коэффициентов, а характер.
Не кукольный дом, а живая система
Игрок управляет не людьми, а укладом
В этой игре игрок — не один из родителей и не всемогущий бог.
Скорее, он представляет собой волю домашнего хозяйства.
Его инструменты:
планировка квартиры;
покупка предметов;
семейный бюджет;
распорядок дня;
общие приоритеты;
распределение ответственности;
крупные жизненные решения.
Например, нельзя приказать:
«Мира, немедленно приготовь ужин».
Но можно договориться, что готовка — её ответственность.
И даже после этого Мира может отказаться. Если она истощена, перегружена или считает договорённость несправедливой, формальное назначение не превращает её в робота.
Тогда игроку придётся менять систему:
передать готовку Павлу;
снизить другие обязанности Миры;
купить готовую еду;
приобрести бытовую технику;
пожертвовать частью дохода ради свободного времени;
временно согласиться на менее чистый дом.
Здесь нет идеального решения. Есть только разные последствия.
Дом одновременно является миром и интерфейсом
Графически игра вдохновлена компактными менеджмент-стратегиями с изображением здания в разрезе.
Весь дом виден сразу:
Спальня | Гостиная
Ванная | Кухня
Рабочая зона | Детская
Каждая комната — не просто декорация, а функциональный блок системы.
Кухня преобразует продукты, время и энергию в готовую еду. Спальня преобразует время и покой в восстановление. Рабочее место превращает силы человека в деньги и стресс. Гостиная может создавать близость — или конфликт.
Игрок смотрит на дом как на живую кибернетическую схему.
Люди в ней не фишки. Они сами перемещаются между помещениями и используют доступные возможности.
Игрок управляет не людьми, а укладом
Главный ресурс семьи — не деньги
Деньги важны, но настоящий дефицит — время и внимание.
У каждого человека только один день.
Если Павел берёт дополнительные смены:
Доход растёт → Павел сильнее устаёт → меньше участвует в быту → нагрузка переходит на Миру → у Миры исчезает личное время → растёт раздражение → ухудшается атмосфера дома → Лена получает меньше спокойного внимания
Дополнительная работа была рациональным решением. Семье действительно нужны деньги.
Но локально правильное решение может сделать всю систему менее устойчивой.
Именно это меня интересует больше всего: момент, когда простые и понятные действия образуют сложные последствия, которых никто не планировал.
Даже еда — это цепочка
Персонаж не должен терять деньги в тот момент, когда ест домашний ужин. Деньги были потрачены раньше.
Полная цепочка выглядит так:
Работа → деньги Деньги + время → покупка продуктов Продукты + время + энергия → готовые порции + грязная посуда Готовая порция → снижение голода Грязная посуда + время + энергия → чистота
Если никто не купил продукты, готовить не из чего.
Если продукты есть, но никто не приготовил еду, ребёнок всё равно останется голодным.
Если еда приготовлена, но вся кухня завалена посудой, бытовая нагрузка никуда не исчезает — она просто перенесена в будущее.
Так из нескольких простых преобразований появляется домашняя экономика.
Главный ресурс семьи — не деньги
Что такое семейный климат
Кроме индивидуальных состояний, у дома есть общий эмоциональный климат.
Это не ресурс, который можно потратить, как деньги. Скорее, это температура семейной среды.
На неё влияют:
средний стресс;
близость;
совместное время;
неравномерность бытовой нагрузки;
накопившиеся конфликты;
забота;
выполненные и нарушенные обещания.
Климат меняется медленно.
Одна ссора не уничтожает семью мгновенно. Но если напряжение сохраняется, оно начинает воздействовать на всех:
Стресс людей → ухудшение климата → дома труднее отдыхать → стресс растёт ещё сильнее
Получается опасная петля обратной связи.
Но возможен и обратный процесс:
Помощь → снижение нагрузки → меньше раздражения → больше возможностей для общения → восстановление близости → улучшение климата
Игра заключается не в том, чтобы один раз заполнить шкалу счастья. Игрок должен заметить, в какой контур попала семья, и изменить условия раньше, чем система начнёт воспроизводить собственный кризис.
Что такое семейный климат
Семья как единый организм
В какой-то момент субъектом становится не только отдельный человек.
Вся семья начинает вести себя как организм:
Семейная система — Похожая функция
Доход — Получение энергии
Еда — Поддержание жизнедеятельности
Домашний труд — Обслуживание организма
Забота — Восстановление и развитие
Распорядок — Внутренний ритм
Семейный климат — Общее психическое состояние
Накопления — Запас устойчивости
При этом внешне благополучная семья может быть внутренне хрупкой.
Дом чист. Деньги есть. Ребёнок накормлен.
Но всё держится на одном человеке, который работает, готовит, убирает и заботится об остальных.
Система выглядит эффективной — до первой болезни.
Что считается победой?
Я не хочу делать единственную шкалу «идеальной семьи».
Потому что тогда игра очень быстро сообщит, что существует один правильный образ жизни.
Вместо этого семья постепенно формирует собственные ценности:
близость;
безопасность;
свобода;
порядок;
образование;
карьера;
взаимопомощь;
личное пространство.
Нельзя максимизировать всё.
Семья, постоянно проводящая время вместе, может подавлять автономию. Карьерный успех может уничтожить свободное время. Идеальный порядок может держаться на хроническом истощении одного человека.
Вопрос игры не в том, насколько семья совершенна.
Вопрос в другом:
Какой она стала — и какой ценой?
Что считается победой?
Что уже есть в прототипе
Сейчас собран браузерный MVP:
PHP;
JavaScript;
MySQL;
запуск на обычном хостинге;
автономная симуляция в браузере;
автоматические сохранения;
комнаты, действия и предметы, описанные в базе данных;
самостоятельный выбор действий персонажами;
приоритеты и распределение обязанностей;
бытовые ресурсы;
нагрузка;
семейный климат;
хроника событий.
Большую часть новых действий можно добавлять без переписывания движка.
Например, объект «посудомоечная машина» не просто повышает абстрактное счастье. Он изменяет конкретные процессы:
меньше времени на уборку → ниже бытовая нагрузка → больше времени на отдых → меньше стресс → выше вероятность общения
То есть предмет становится не бонусом, а вмешательством в систему обратных связей.
Самый важный тест
У проекта есть простой критерий качества:
Если игрок ничего не делает, устойчивая семья должна продолжать жить самостоятельно.
Игрок нужен не для того, чтобы отправлять каждого персонажа в туалет. Он нужен в моменты, когда меняется сама жизнь:
родился ребёнок;
кто-то заболел;
изменилась работа;
закончились деньги;
приехал пожилой родственник;
семья переехала;
старый распорядок перестал работать.
Прежнее равновесие разрушается, и приходится создавать новое.
Именно это я хочу симулировать: не идеальную семью, не бытовую рутину и не кукольный домик, а живую систему автономных людей, вынужденных делить пространство, время, труд и заботу.
Самый важный тест
Пока это только MVP, но сама модель уже начала выдавать маленькие истории, которых никто заранее не писал.
И теперь мне интересно:
Хотели бы вы играть в симулятор, где персонажи могут отказаться выполнять ваши планы?
Что должно сильнее всего влиять на атмосферу семьи?
Нужны ли прямые приказы хотя бы в экстренных ситуациях?
Какие жизненные события стоило бы добавить первыми?
Где проходит граница между интересной автономией и раздражающим поведением ИИ?
Потому что создать послушную куклу относительно просто.
Гораздо интереснее создать кого-то, с кем придётся договариваться.
