Многие до сих пор думают, что под Linux игр нет, а если и есть то их мало. Сейчас я покажу, что это утверждение неверное и число игр под Linux измеряется тысячами. Причём выбор игр очень широк. От простых браузерных игр до новейших ААА игр. Причём некоторые из них идут даже плавнее чем под Windows.

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

Теперь перейду к нативным играм под Linux — они есть, причём высокого качества. Вот только некоторые из них.

SuperTux платформенная аркада в лучших традициях Mario.

Далее идёт SuperTuxKart гоночная аркада не требовательная к железу.

Ну и наконец Extreme Tux Racer ещё одна не требовательная к ресурсам гоночная аркада.

Так же под Linux есть все классические игры. Вот только некоторые из них.

Шахматы.

Шашки.

Тетрис.

Арканоид

А ещё под Linux великолепно идёт ряд Windows игр через слой совместимости PortProton. Причём некоторые идут даже плавне чем на Windows. Я играю только в гоночные игры и авиасимуляторы. И то, и другое под Linux отлично работает — есть под Linux поддержка игровых рулей, джойстиков и геймпадов.

Гонка CarX Street — великолепно запускается на Linux mint через Port Proton.

Ил- 2 — игра старая, но зато не требовательная к ресурсам и отлично запускается.

Ace Combat 7: Skies Unknown - более современная игра и тоже отлично идёт

Так что под Linux есть во что играть. А если этого мало, то под Linux есть эмуляторы всех старых игровых консолей — Sony PlayStation 1 и 2, Dendy, Sega и другие. А это библиотека из тысячи игр. Так же можно запускать игры для Android тоже через слой совместимости.

Так что да Linux это не только современная операционная система, но и актуальная игровая платформа.

Кстати Valve в Steam Deck и Steam Machine использует именно Linux для запуска игр.

Конечно, меня сейчас начнут спрашивать — зачем играть под Linux есть же Windows? А я отвечу — чтобы была жизнеспособная альтернатива дающая пользователю выбор и создающая здоровую конкуренцию. Потому что если появляется монополия, то, как показывает практика, монополист расслабляется и начинает делать не качественный продукт. Потому что незачем стараться его и так купят. Долгое время Windows удерживала прочные позиции на рынке именно благодаря тому, что играть на ПК можно было только на ней. Не Mac, ни тем более Linux для игр категорически не подходили. Так что ранее выбор был не большой или играть на Windows ПК или играть в одну из игровых приставок.

Но сейчас ситуация принципиально другая. Огромную популярность приобрели мобильные игры, запускаемые на смартфонах и переносных приставках типа Nintendo Switch. Секрет популярности в портативности — играть можно в любое время и в любом месте. Становятся все более популярными браузерные игры — они не требуют установки и работают прямо в браузере. Ну и альтернативные решения подтянулись, на MacOs Apple сделал API Metal — он позволяет запускать игры на компьютерах Mac. А на Linux появился API Vulkan, он позволяет запускать игры на Linux.

Все это суммарно разрушило монополию Windows как единственной доступной ПК платформы. Безусловно, Linux как игровая платформа ещё не идеален. Но и Windows тоже не идеален. А MacOS в плане игр теперь догоняет не только Windows, но и Linux. И тем не менее, у пользователя теперь появился реальный выбор — я для игр выбрал Linux. Потому что те игры, в которые я играю (в основном гоночные игры и авиасимуляторы) под Linux работают не хуже чем под Windows.

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

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

После этого дизайн документ на 1600 строк отправился в Vibecraft и разработка игры началась :)

Первый вариант игры

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

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

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

На практике именно в этот момент и началась большая часть работы.

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

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

После первого варианта я уже решил утащить проект из VibeCraft и с помощью ИИ агента доделывать его.

Интерфейс

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

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

В результате интерфейс пережил несколько серьёзных переделок. Основные вещи - население, ресурсы и текущая цель - остались постоянно видимыми, а остальные системы разъехались по отдельным вкладкам. Заблокированный контент начали явно отличать визуально, а для текущей цели появилась отдельная подсказка.

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

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

Механики

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

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

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

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

Метапрогрессия

А вот разные острова как раз не входили в самый первый вариант игры. К их появлению постепенно подтолкнула метапрогрессия.

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

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

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

Графика

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

Когда сама игра уже была проходимой, начался отдельный этап подготовки к публикации в Яндекс Играх. SDK, реклама, rewarded-реклама, сохранения, локализация, требования платформы к поведению страницы, иконка, обложка, gameplay-видео, русская и английская версия оформления. Почти ничего из этого не делает непосредственно игровой процесс интереснее, но без этих вещей игра всё ещё остаётся проектом на компьютере разработчика, а не законченным продуктом.

Немного о том, как всё устроено внутри

Технически проект получился довольно обычным веб-приложением на React и TypeScript. Сейчас он собирается через Vite. При этом игровая логика старается не зависеть от интерфейса: есть общее состояние игры и игровой tick, который занимается производством и потреблением ресурсов, строительством, таймерами экспедиций, временными эффектами и другими процессами.

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

По мере развития проекта вокруг этого довольно простого ядра начало появляться всё больше обычной продуктовой инфраструктуры. Появились автосохранения, русская и английская локализация, интеграция с SDK Яндекс Игр, реклама, rewarded-реклама, unit-тесты, E2E-тесты через Playwright и даже отдельный скрипт для симуляции баланса.

Отдельной технической историей оказался переход с Next.js на Vite. Изначально проект в VibeCraft использовал Next.js, и каких-то принципиальных проблем с ним не было. Просто формат публикации в Яндекс Играх довольно простой: нужно собрать готовые статические файлы, положить их в архив и загрузить на платформу. Внутри должен находиться `index.html`, JavaScript, стили и ассеты, причём желательно с максимально предсказуемыми относительными путями.

Для такого сценария Next.js оказался просто менее удобен, чем хотелось. Серверная часть игре была не нужна вообще, а задача фактически сводилась к получению максимально обычной папки со статическим билдом. После перехода на Vite процесс стал гораздо проще: собрал проект, получил готовую директорию, заархивировал и загрузил в Яндекс Игры.

И немного про AI

Почти весь проект делался с активным использованием AI-инструментов, и после этой разработки у меня осталось довольно чёткое впечатление: AI действительно очень сильно снижает стоимость реализации.

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

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

Добавить в игру ещё одну систему теперь очень легко. Иногда даже слишком легко. Поэтому одна из самых сложных задач постепенно становится не «как это реализовать», а «нужно ли это вообще реализовывать».

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

Самым важным для меня было не количество сделанных механик, а сам факт того, что игру удалось довести до состояния, когда можно перестать добавлять фичи, собрать архив и наконец нажать кнопку публикации. И на все это потратилось меньше недели времени.

Поиграть можно на Яндекс Играх.

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

Каждая рыбка рисуется одной математической формулой, которая раскладывает около 20 000 точек на плоскости. Для каждого индекса i вычисляется пара (x, y) через вложенные синусы, косинусы и расстояние. Точки растеризуются на маленьком холсте и окрашиваются в аквамариновый, коралловый, небесный или золотой цвет. Ручной спрайт-лист не используется: вся стая — чистая математика.

Как-то раз, блуждая по просторам Сети, я наткнулась на удивительную формулу, которая рисует вот этих рыбок, и сразу влюбилась в нее. Это было какое-то чудесное эхо из детства, того времени, когда я ходила в кружок программирования, где мы изучали Паскаль. Там наша учительница часто находила для нас подобные красивые математические формулы и учила нас писать программки, где они раскрывались, словно космические цветы.

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

Сама игрушка тоже задумана не случайно. Помню, в детстве мне всегда нравилось неспешно считать в уме, любуясь тем, как преобразуются числа при различных математических действиях, и подмечая закономерности и связи. Вот только считала я слишком медленно, и мне за это очень доставалось и в школе, и дома. Так вот, эта игрушка - она про расслабленный медленный счет в уме на фоне созерцания математической красоты. Таймера нет, никто не торопит. Любой пройденный уровень можно перезапустить заново.

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

Вот сама игра: Цифро-аквариум

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

Где меня найти: сайт - тг- макс

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

Те, кто играл (кто не играл оч рекомендую) в 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 продолжит выпускать из нее новых големов.

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

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

Открытие кейсов для получения чипов - залог быстрых побед!

Играйте на Яндекс Играх https://yandex.ru/games/app/zviozdnyi-rubezh-kosmicheskaia-o...

Месяц назад тут была демка на itch io. Модерацию прошли — игра в релизе.

https://yandex.ru/games/app/zviozdnyi-rubezh-kosmicheskaia-o...

Браузер, бесплатно, без установки.

Что в релизной версии против демо:

72 сектора, три звёздные системы, девять боссов.

Дерево навыков командира — 22 узла.

Чипы-прошивки со случайными аффиксами: три ненужных плавятся в один

новый. Кейсы пяти редкостей.

Бестиарий: чем больше убил конкретного врага, тем слабее он становится

в следующий раз.

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

Караваны, средовые события, уровень угрозы.

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

Ждем ваших отзывов.

Боссы входят с титром и замедлением времени. Стенкой из фрегатов не убираются.