GameDev: разработка игр

Что-то меня на этой неделе на крутые демки прёт, вот вам ещё одна: показывает как выглядит движение со скоростью света вокруг гигантской кольцевой структуры.​

Масштаб: кольцо радиусом 695 700 км (радиус Солнца), ширина 71 492 км (диаметр Юпитера). Летишь со скоростью 300 000 км/с и видишь релятивистские искажения в реальном времени.

Что происходит визуально: при движении со скоростью света работает эффект Доплера — объекты впереди уходят в синий спектр (blueshift), позади — в красный (redshift). Плюс аберрация света: поле зрения сжимается, картинка «стягивается» к точке впереди. Это не художественное преувеличение — так реально выглядела бы Вселенная на околосветовых скоростях.

Технически: всё рендерится в реальном времени через compute shaders на Shadertoy. Если GPU не тянет — есть 360° видео на YouTube, можно крутить головой.

Демо:
🔘Speed of light in Ring | YT 360
🔘Speed of light in Ring v2 | YT 360

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

@make_game

Particle Life — симуляция, где из примитивных правил взаимодействия частиц возникают структуры, похожие на живые клетки. Теперь её запустили на WebGPU с поддержкой 100 000 частиц прямо в браузере.​

Как работает: есть частицы разных цветов, и матрица сил между ними. Красные могут притягиваться к жёлтым, а жёлтые — убегать от красных. Силы асимметричные, в отличие от реальной физики. Из этих простых правил спонтанно появляются «клетки», «организмы», деление, даже что-то похожее на экосистемы.​

Что сделал автор: перенёс симуляцию на compute shaders в WebGPU. Главная проблема — расчёт сил между всеми парами частиц это O(N²), что убивает производительность. Решение: spatial hashing — частицы раскидываются по ячейкам, и каждая взаимодействует только с соседями. Реализовано через atomic linked lists и counting sort.​

Результат: 20 000 частиц с нормальным радиусом взаимодействия, до 100 000+ если радиус уменьшить. Всё в браузере, никаких установок.

Код на гитхабе, демо на сайте.

Залипательная штука — можно наблюдать как из хаоса рождается порядок.

@make_game

Два разработчика без опыта в геймдеве выпустили кооп-хоррор «We Escaped a Twisted Game» и за 6 недель собрали 3000+ продаж, 90 позитивных отзывов и ноль негативных. Работали на основной работе, бюджет минимальный, издателя нет. И написали разбор, что в их случае сработало, а что нет.

Что сделали правильно

🔘Выбор ниши: взяли за основу We Were Here (асимметричный кооп с головоломками), но добавили хоррор. Увидели дыру в рынке — никто не делал такое в этом жанре.

🔘Раннее тестирование: как только появился играбельный билд — позвали друзей. Как появился полированный — позвали незнакомцев. Результат: «not too hard, not too easy» в отзывах. Отдельно охотились на баги — большинство негативных отзывов у конкурентов было про баги.

🔘Демо + Steam Next Fest: выложили демо через 14 месяцев разработки. Первый буст вишлистов: с 300 до 4000. На Next Fest выросли до 7000. К релизу — 8000 вишлистов.

🔘Агрессивные патчи после релиза: первую неделю патчили каждую ночь. Отслеживали ачивки (каждая комната = ачивка), читали все отзывы, смотрели стримеров. Completion rate вырос с 62% до 72%, медианное время игры — с 2ч до 2ч 34м.

🔘Переписали код: начинали со спагетти, но по мере роста скиллов рефакторили. Это окупилось на этапе полировки.

Где ошиблись

🔘Визуальный стиль: использовали Synty Assets — удобно, но игра выглядит как сотни других
🔘Локализация: не заложили с начала, теперь добавлять дорого и больно
🔘Капсулы Steam: арт неплохой, но не оптимизирован под маленькие превью — CTR ниже, чем мог бы быть
🔘Next Fest слишком рано: пошли, думая что до релиза пара месяцев. На деле оставался год разработки

Главные выводы

🔘Маленький скоуп = можно довести до конца = выше качество
🔘Демо + маркетинг дают первый импульс
🔘Тестирование с незнакомцами фиксит 90% проблем с дизайном
🔘На Next Fest идти только когда реально готов к релизу
🔘Визуал и локализация — планировать с первого дня

Игра доступна в сторе, на видео демо.

@make_game

Miziziziz (инди-разработчик, известный по YouTube) устал от того, что документация Steam по загрузке билдов устарела лет на 10 — видео там датированы серединой 2010-х. Написал актуальный гайд по работе со SteamCMD и butler (CLI для Itch.io).​

Гайд покрывает полный пайплайн: структура VDF-файлов для Steam (app_build, depot_build), настройка ContentBuilder, авторизация через Steam Guard и собственно загрузка. Для Itch — установка butler и пуш одной командой. Всё заточено под автоматизацию: можно прикрутить к CI/CD и деплоить билды автоматически.​

В комментариях подтвердили боль — официальная документация Valve реально в плохом состоянии, а GUI-инструменты (SteamPipe GUI) для многих сценариев неудобны. CLI-подход позволяет скриптовать релизы и не проходить квест заново каждый раз.​

Гайд в репо на GitHub или ИИ-перевод на русский в прикреплённой PDF-ке.

@make_game

Пост с разбором, зачем id Software выпустили отдельный winquake.exe, когда уже был quake.exe, работавший и в DOS, и в Windows 95.​

Проблема: quake.exe под Windows 95 работал на 25% медленнее, чем из-под DOS (38 vs 48 fps). Виртуализация DOS-приложений съедала производительность. Плюс доступ к TCP/IP стеку был через костыли, а на Windows NT вообще не запускалось — DPMI-клиент от DJGPP не дружил с NT Virtual DOS Machine.​

WinQuake решил это через нативный win32-бинарник с кучей бекендов на выбор:
🔘Видео: GDI/DIB (безопасно, но медленно), DirectDraw (быстрее), VGA/VESA через WinDirect (прямой доступ к железу в обход GDI)
🔘Звук: DirectSound (низкая задержка, -10% fps) или WinMM (выше задержка, но fps лучше)
🔘Ввод: стандартный WinAPI или DirectInput для плавности​

Секретный соус — библиотека MGL от SciTech за $499. Она умела отключать GDI и писать напрямую в видеопамять через технологию WinDirect. Те самые WDIR32.DLL в папке с игрой — это оно.​

Результат: 45 fps под Windows 95 вместо 38, разрыв с DOS сократился до 6%. И да, winquake.exe до сих пор запускается на Windows 11 — Microsoft и их обратная совместимость.​

@make_game

Снова суббота и снова рассказываем про свои проекты!

Что сделали за неделю? Над чем работаете сейчас? Можно со ссылкой на канал или предзаказ, но обязательно со скрином или видео-демкой.

На dos.zone добавили Norton Commander и Volkov Commander — те самые синие панели с F8 для удаления. Внутри каждого ещё по 10 DOS-игр.​

Работает на js-dos — обёртка над DOSBox, скомпилированным в WebAssembly. Проект опенсорсный, живёт на гитхабе. Поддерживает несколько бекендов: обычный DOSBox и DOSBox-X. Тянет даже Diablo и Dune 2000, есть мультиплеер и облачные сейвы.​

Интеграция элементарная: Dos(element).run("game.jsdos"). Если нужно встроить ретро-игру в свой проект или поэкспериментировать с эмуляцией DOS в вебе — вполне рабочий вариант.

Больше не могу говорить, ушёл играть в GOLDEN AXE 💃

@make_game

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

Камера и FOV

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

🔘Добавьте опцию полного отключения head‑bobbing, качания камеры при беге, получении урона, залезании по лестнице и т.п. Даже небольшой остаточный «кач» в скриптах может ломать игру чувствительным игрокам.​

🔘Старайтесь избегать принудительного резкого поворота камеры без контроля игрока; если нужно показать сцену — используйте мягкий пан или делайте такие моменты пропускаемыми.

Эффекты и визуальный шум

🔘Обязательные тумблеры: motion blur, depth of field, chromatic aberration, vignette, резкие FOV‑эффекты на спринте или ускорении. Многие играют с ними «ради красоты» пару минут, а потом получают головную боль.​

🔘Не злоупотребляйте покачиваниями, шейк‑камерой и дёрганием экрана при каждых действиях. Если очень хочется оставить — повесьте это на отдельный «camera shake intensity» слайдер.​

🔘В замкнутых пространствах (шахты, коридоры, стелс) можно компенсировать дискомфорт чуть более широким FOV, стабильным горизонтом и более мягкими поворотами.​

Интерфейс и управление

🔘Добавьте фиксированный прицел/точку в центре экрана (даже в играх от третьего лица) — это простой визуальный «якорь», который многим сильно помогает.​

🔘Обеспечьте стабильный FPS: лучше пониженные настройки по умолчанию, чем красивая, но рвущаяся картинка. Низкий и нестабильный фреймрейт — один из главных триггеров укачивания.​

🔘В VR — поддерживайте удобные режимы локомоции: телепорт, snap‑turn, маску/туннелинг по краям экрана при движении. Не заставляйте всех идти только «free locomotion + smooth turn».​

Настройки и тестирование

🔘Вынесите основные опции (FOV, head‑bob, blur/DOF, camera shake, ретикл) в первый запуск или раздел «Accessibility», а не закапывайте их в третий уровень меню.​

🔘Если у вас есть QA или знакомые, которые легко укачиваются — дайте им поиграть и относитесь к их отчётам как к багам, а не «индивидуальной особенности».

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

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

По материалам треда на реддит.

@make_game

Скриншотник открыт! 💃

Закидывайте в комментерии демки, скриншоты или просто рассказы о своих успехах за последнюю неделю. Над чем работаете? Когда планируете релиз? Чем в своей игре вы особенно гордитесь?

Facepunch выкатили мощный подарок геймдеву: s&box официально стал открытым игровым движком под лицензией MIT.

В репозитории весь высокоуровневый код движка на C#: редактор, сцены, UI, сетевой слой и прочее, а под капотом он опирается на Source 2 и современный .NET. Код Valve при этом не открыт — только то, что написали сами Facepunch, так что Source 2 остаётся проприетарной базой, поверх которой вы работаете.​

Если коротко, s&box — духовный наследник Garry’s Mod и одновременно движок + платформа для игр с пользовательским контентом: можно собирать свои режимы/игры как в Unity, но с фичами Source 2 и встроенным редактором. MIT даёт вам право форкать проект, править его под свои нужды, делать самостоятельные игры и даже строить на его базе собственный движок без роялти, при этом часть низкоуровневых бинарников остаётся под лицензиями Valve и это надо учитывать, если целитесь в полностью независимый коммерческий релиз.​

Практически сценарий такой:
1️⃣Клонируете репо, собираете по инструкции и получаете редактор, сцену и инструменты.​
2️⃣Пишете геймплей на C#, собираете сцены, UI и сетевую логику через встроенный редактор, как в привычных движках.​
3️⃣Либо форкаете код и используете его как основу для своего самостоятельного проекта, постепенно отвязываясь от того, что вам не нужно из экосистемы s&box.

В свежем апдейте заодно подтянули технику: переписали нативный аллокатор (перешли с jemalloc на mimalloc), починили VR и режим Play, добавили анти‑тайлинг для террейна, так что база для движка уже довольно зрелая.

@make_game

Оказывается, шрифты — это такое же лицензионное минное поле, как музыка, и тот же Arial требует отдельную платную лицензию, если вы вшиваете его в игру или приложение. И не важно, что он по умолчанию есть в Windows, для распространения в своих продуктах нужно отдельное разрешение, вы знали?

Для коммерческого релиза, особенно на международный рынок, намного спокойнее сразу опираться на открытые гарнитуры:
🔘Google Fonts — сотни семейств под открытыми лицензиями, официально разрешены для коммерческих проектов, веба и встраивания в приложения.
🔘Fontsource — 1500+ open‑source шрифтов в виде npm‑пакетов, удобно для SPA/Frontend.
🔘Open Font Library — сервис от Indian Type Foundry с качественными шрифтами, которые позиционируются как «free for all».
🔘Open Foundry — модерируемая платформа именно с open‑source шрифтами.
🔘The League of Moveable Type — исторически первая open‑source студия шрифтов, весь каталог позиционируется как бесплатный и открытый к использованию и доработке.
🔘Списки и обзоры у типографов, вроде подборки open‑source шрифтов у Tofu Type и похожих статей.​

И даже с этими ресурсами базовое правило одно: качаете шрифт → читаете LICENSE → кладёте её рядом с ассетом в репо, особенно если у вас коммерческий релиз или международный рынок.

@make_game

Дверь, которая сломала Half‑Life 2

Бывший разработчик Valve Том Форсайт рассказал, как в 2013 году они делали VR‑порт Half‑Life 2 и внезапно наткнулись на баг прямо в самом начале игры. В сцене, где охранник должен провести Гордона через дверь, створка просто не открывалась, и игрок намертво застревал — ни вперёд, ни назад. Самое странное началось, когда они запустили обычную (не‑VR) версию на том же железе и увидели, что теперь та же сцена сломана и в «обычном» HL2, хотя в 2004 году все проходили её без проблем, а код вроде бы никто не трогал.​

Разобравшись, они выяснили, что баг родился на стыке двух классических источников боли в геймдеве: дверей и чисел с плавающей точкой. Оригинальный HL2 собирали под старый x87 FPU, где часть вычислений шла в 80‑битной точности, а более новые билды компилировались с использованием SSE, где всё жёстко обрезалось до 32 бит. В результате крошечное отличие в вычислениях физики привело к тому, что NPC сдвигался буквально на доли миллиметра, дверь чуть по‑другому поворачивалась — и персонаж больше не попадал в нужный триггер, который должен был открыть проход.​

Такой вот «баг из будущего». Двери и вычисления с плавающей точкой, коллеги. Гремучее сочетание, аккуратнее с этим.

@make_game

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

Если упростить весь тред до практических правил:​
1️⃣делайте понятный геймплей и смотрите, что реально нравится людям, а не вам самим после 500 часов в редакторе;​
2️⃣не влюбляйтесь в фичи: если механика «на бумаге крутая», но играть скучно или непонятно — режьте или переделывайте;​
3️⃣показывайте билд сторонним людям как можно раньше и принимайте честную критику про геймплей, арт и трейлер, даже если больно;​
4️⃣начинайте с маленьких проектов и добивайтесь завершения, вместо того чтобы первым делом пилить «огромное RPG/MMO мечты» в одного.​

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

@make_game

Традиционный субботний скриншотник объявляется открытым! 💃

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

Инди‑разработчик с 20+ лет опыта объясняет, почему совет «делай то, что сейчас популярно» в геймдеве почти всегда плох как долгосрочная стратегия. Он рассказывает, как сам когда‑то гнался за трендами и вирусными механиками, в итоге выгорел и делал кучу разрозненных «странных» игр без единого лица.​

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

Оригинал на YT, если вам там удобнее смотреть.

@make_game

SteamReviewGuesser — сайт, где ты видишь страницу игры в Steam и пытаешься угадать, сколько у неё отзывов.

Есть трекинг серии угадываний, ачивки за правильные ответы, переключатели для фильтрации NSFW‑игр, издателей и прочего. Автор планирует ещё и таблицу лидеров, когда дойдут руки.​ Прям настоящая игра про игры для игроделов!

Пробуем: https://steamreviewguesser.com/

@make_game

Поклонники ретро-игр сделали браузерную версию мультиплеера культовой Unreal Tournament 99

Разработчики смогли полностью перенести шутер в браузер:
— 37 классических карт;
— четыре режима игры: Deathmatch, Capture the Flag, Domination, Assault;
— продвинутые ботов;
— возможность создания собственного сервера для игры;
— запуск с любого современного браузера.

Поиграть: https://dos.zone/mp/?lobby=ut

@make_game

В соседнем Нейроканале написал про Steve — это ИИ, который за вас играет в Minecraft. Указываете что делать, агенты сами строят дома, добывают руду и организовывают фермы.

Как думаете, можно что-то такое применить, чтобы сделать умных противников в своих играх? Чтобы не скриптовать, а дать ИИ-агентам команду: «Окружите игрока и сделайте вид, как будто он в последний момент смог убежать невредимым».

Применяете ли вы в своих играх ИИ-агентов? Не для разработки и написания кода, а для нахождения внутри игрового мира.

@make_game

Свежий «недельный геймдев» от Tproger. Как всегда обзор новостей, бесплатных раздач, занятных статей и видео для разработчиков игр.

Microsoft открыла внутреннюю документацию по публикации и сертификации игр на Xbox — теперь гайд по выходу на Xbox и Xbox PC лежит в открытом доступе, без регистрации и NDA. Там расписан полный путь: от регистрации в ID@Xbox и заведения проекта в Partner Center до требований сертификации, работы с вишлистами, предзаказами, Xbox Insider и релизной конфигурацией.​

Для инди и небольших студий это серьёзная смена правил: раньше понять, что именно хочет платформа можно было только после одобрения и подписания бумажек, теперь можно заранее посмотреть чек‑листы, спланировать продакшен и оценить, потянете ли релиз на Xbox вообще. Похоже на подход Steam — больше прозрачности, проще онбординг, и можно уже на этапе прототипа понимать, какие требования придётся выполнять.

@make_game