Разработка игр *

Игры на MacBook часто дёргаются даже тогда, когда счётчик показывает 100 кадров в секунду и больше. У меня так было с Counter‑Strike 2 на MacBook Pro 14 с M3 Pro: 110–120 fps, а на медленном повороте картинка всё равно идёт рывками.

Я записал, когда каждый кадр на самом деле появляется на экране. Дело оказалось не в нехватке мощности, а в том, как кадры ложатся на сетку экрана ProMotion. В цифрах это выглядит так:

Есть довольно интересная категория багов в играх, которые формально багами являются, но игрокам они нравятся, и они, наоборот, называют багом “нормальное поведение” и строчат про него репорты про криворуких погромистов. Там, где программист хорошо и физически корректно сделал свою работу, игрок видит ошибку своего восприятия игры, не физики, а именно восприятия.

Представьте самый обычный платформер, в котором персонаж бежит по платформе, приближается к краю и должен прыгнуть на следующую. Если вы сделаете правильную обработку прыжка в этом месте в стиле “персонаж стоит на земле - можно прыгать, персонаж на земле не стоит - прыгать нельзя”: if (IsGrounded() && JumpPressed()) then Jump(), то c точки зрения “корректной” физики здесь будет не к чему придраться, потому что если под ногами уже нет платформы и было бы довольно странно сообщать персонажу, что он всё ещё находится на земле.

А если кнопка прыжка была нажата после того, как система коллизий говорит нам о потере контакта с поверхностью, то прыжок должен быть запрещён. Про такую логику можно даже сказать, что она ведёт себя “физически корректно”, но потом приходит тестировщик и говорит: “Ребят, прыжок какой-то странный. Я чувствую, что стою на земле, но прыжка нет”.

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

«У меня игра на Flame, можно ли добавить в неё 3D?». Можно, и игру не придётся переписывать: корабль летает по трёхмерному двору со светом и тенями, а джойстик, HUD и вся игровая логика остаются на Flame. У двух движков одни часы, одна физика и один ввод, поэтому таран, который посчитала 3D-физика, приходит во Flame обычным onCollisionStart. Я разберу по шагам небольшую аркаду на flame_flutter3d, покажу рецепты, которые можно брать в свою игру, и неочевидные места, на которые наступил сам. В аркаду можно сыграть прямо в браузере.

Я играю в Counter‑Strike 2 на MacBook Pro 14 с M3 Pro. Кадров хватает, 100 с лишним в секунду, а прицел всё равно ощущается ватным: мелкие доводки то недолетают, то перелетают. Сначала я грешил на ускорение указателя, потом на лимит кадров, потом на саму игру. Не помогало ничего, и в какой‑то момент я просто записал, как события мыши доходят до приложения.

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

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

Поставил MelonLoader в демку на Unity 6, собрал мод — и он молчит: BadImageFormatException: Duplicate type with name '<>O'. За выходные я написал два чит-мода с почти одинаковым ТЗ: меню для Valheim (Mono, BepInEx) и трейнер для демки Go Next! (IL2CPP, MelonLoader). Код получился настолько разный, что набралось восемь мест, где всё ломается именно из-за отсутствия managed-кода: битая сгенерированная сборка, вырезанный GUILayout, падающий Input.GetKeyDown, цена интеропа. Плюс разбор того, где Unity на самом деле держит PlayerPrefs и почему SetGodMode() хуже собственного патча.

Изучая Adobe Photoshop (в частности любимый мною CS6 – так как запросто устанавливается на любой чайник), программы по монтажу (VSDC Video Editor, Wondershare Filmora, Movavi и Capcut), и другого типа редакторы мне не могла не прийти мысль об автоматизации. Как минимум потому, что я ленивый, а в общем и целом – для автоматического создания материалов и текстур. Создавая игры любой разработчик уткнётся носом в одну простую вещь: у него есть готовый и расписанный лор, персонажи и их дизайны, может даже саундтрек и примеры кода, но нет второстепенных текстур. Под второстепенными текстурами я имею в виду то, что не влияет на лор, но влияет на игровой опыт (к примеру, блок земли в Minecraft не поможет нам убить дракона, но данная текстура жизненно необходима игре).

Следовательно, нужно было научиться автоматизировать процессы обработки графических материалов. Последовательная обработка подразумевает код, а автоматизация – наличие функций. Желательно было всё это оформить на Python. Идея понятна: хочу обрабатывать визуал таким образом, чтобы целый ряд фильтров и сопутствующих преобразований накладывались по одному клику, без упорного затирания UI Photoshop до дыр. И что делать? Здесь на помощь приходит один известный форк PIL (Python Imaging Library) под названием Python Pillow.

Как оказалось, сообщество Python уже давно задумалось над тем, как можно через код работать с графикой. PIL – древняя библиотека для работы с растровой графикой, поддержка которой давно прекращена. Потому на её основе возник форк под названием Pillow, о котором сейчас и поговорим. Стоит отметить, что на мой субъективный взгляд Pillow лучше всего работает именно с форматом PNG, потому рассматривать работу библиотеки с файлами иных расширений мы не станем, по крайней мере в этой статье. Также отмечу, что это не совсем образовательная статья, а скорее Roadmap, потому что доступ к каким угодно учебным материалам сегодня есть из любой точки земного шара, и гораздо важнее поговорить именно про последовательность действий при освоении данной технологии – какой она должна быть, чтобы иметь достаточное понимание для выполнения определённого рода задач.

Телефон лежит на столе или в другой руке. Сбоку от него в воздухе ладонь. Двигаешь ладонью — корабль на экране поднимается и опускается. Экрана не касаешься. Камера не нужна: телефон пищит ультразвуком и слушает эхо своим микрофоном.

Играть: sonaroids.app (веб-приложение на iPhone; для Android есть .apk — ссылка на главном экране игры). Код: github.com/neokrasav4ik/sonaroids, MIT.

UPD. Заголовок устарел, и это хорошая новость: на Mi 9 Lite, середнячке 2019 года, играется так же, как на iPhone 16. Помогли широкий зонд (управление примерно вдвое чище) и приложение для Android со своим звуком, правильной громкостью и выбором микрофона. Новые разделы статьи — «Широкий зонд» и «Android: приложение вместо браузера».

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

Многие говорят о том, что современный пиксель‑арт часто выглядит неправильно. Например, пользователь TikTok mylifeisanrpg записал популярное видео, в котором объясняет, что раньше пиксельные художники учитывали физические свойства электронно‑лучевых трубок (ЭЛТ). Размытость ЭЛТ сглаживала грубые края пикселей низкого разрешения, благодаря чему объекты казались гораздо менее квадратными, чем на современных плоских дисплеях.

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

В 2020 году фильм Monster Hunter с Милой Йовович, снятый по одноименной игре, заработал за полтора дня в кинотеатрах Китая 5 млн долларов. Из-за расистской шутки его сняли с проката. Однако за пределами страны без каких-либо запретов сборы составили вообще 2,65 млн. Уже здесь виден огромный потенциал этого рынка, который распространяется и на видеоигры.

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

Разберем, почему Китай одновременно так притягателен и так сложен для входа и как российские разработчики проходили этот путь в 2022–2026 годах.

В литературе по оптимизации, работа с памятью стоит не на первом месте, и даже если вы добрались до этих глав там, с большой вероятностью будут рассказывать про пропускную способность, чтобы система могла перемалывать условные пять ГБ/с вместо трех. И в целом это правильная метрика, когда у вас потоковая обработка, или батчи данных вродя запекания освещения, сборки навмеша, или компиляция шейдеров. Там имеет значение сколько данных прошло через процессор за отведённое время, и все стандартные приёмы (SoA, плотные массивы, линейный обход, векторизация) работают на эту метрику.

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

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

«Ну, погоди!» («Электроника ИМ-02») — электронная игра, самая известная и популярная из серии первых советских портативных электронных игр с жидкокристаллическим экраном, производимых под торговой маркой «Электроника». Производилась с 1984 года. Сравним сегодня две флагманские модели в реализации популярной игры из моего детства.

В первой части мы собрали прототип интерактивного NPC на базе MetaHuman в Unreal Engine.

NPC “слышал” игрока (STT), обрабатывал распознанный текст при помощи LLM (инференс локальных моделей через llama.cpp) и озвучивал ответ (TTS + lipsync).

Но «говорящая голова» ещё не персонаж. Представление о мире у такого NPC статично (зашито в system prompt), на любой запрос он отвечает одинаково безэмоционально и вежливо и никак не влияет на происходящее в игре.

Именно эти проблемы мы и попытались решить.

Spoiler — у нас получилось.

По данным портала levelup.com, в 2026 году на Steam в среднем публикуется от 70 до 100 игр в день.

Если говорить о мобильных играх, то, по данным apptopia.com, в 2026 году в App Store в среднем публиковалось свыше 500 игр в день, а в Google Play Store - свыше 200 игр в день. Цифры приблизительные и консервативные - взяты мной в сторону уменьшения.

Если для Steam‑релизов признаки вайбкодинга не звучат явно, то, по мнению The New York Times, для мобильных приложений в App Store рост обусловлен во многом именно вайбкодингом. Полагаю, это применимо и к Google Play Store.

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

Представьте: в игре хорошо работает фича, которая приносит деньги. Команда хочет развить её дальше и ставит себе цель. Инженер, приценившись, говорит: «Нам нужно три недели». А бизнес вставляет: «Но у нас есть только две!».

Кто из них прав?

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

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

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

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

Число... например, 16 мс или 33 мс или 8 гигабайт, из которых 5 доступны, или «игра должна показать первый интерактивный кадр не позже чем через десять секунд после запуска, иначе сертификацию не пройдем». Как только у свойства системы появляется измеримая цель, простота перестаёт быть бесплатной и превращается в то, чем вы платите.

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

В предыдущей статье я писал про [5 вещей, которые не следует делать в LibGDX].

Поэтому логично продолжить тему и поговорить о вещах, которые, наоборот, стоит использовать при разработке 2D-игры на LibGDX.

Сразу оговорюсь: это не статья про архитектуру, паттерны проектирования, ECS, оптимизацию кода или правильную организацию проекта.

Здесь всё гораздо проще.

Я хочу поговорить о нескольких технических инструментах, которые способны относительно небольшими усилиями заметно улучшить визуальное восприятие игры:

Я пытался сделать NPC более реалистичными. Получился местами несмешной анекдот, а местами — психологический триллер. Я издевался над NPC, они издевались надо мной. Я запрещал им «думать о белой обезьяне», они меня газлайтили и давили моралью. Если готовы к большому тексту — добро пожаловать.