Unity *

Игры-симуляторы, построенные на простых, повторяющихся и визуально привлекательных задачах, стали одним из самых надежных жанров в мобильных играх. Среди них особое место занимают симуляторы автомойки и ухода за автомобилем. Они красочные, не требуют больших усилий и приносят бесконечное удовлетворение — именно поэтому они так популярны среди юных игроков. Если вы разработчик Unity, изучающий эту нишу, шаблон игры Car Wash Salon Unity Game Template стоит изучить подробно, как в качестве готового продукта, так и в качестве примера того, как создаются игры-симуляторы, ориентированные на детей.

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

Как самодельный фреймворк пережил первый коммерческий релиз — соло, в цейтноте и с вайб‑кодингом в финале.

4 сентября вышел мой первый коммерческий продукт, целиком написанный на Vortex, — симулятор свиданий с минииграми и интеграцией нарративного движка Naninovel. Причём вышел не «в срок», а раньше срока: релиз стоял на 11-е, уехал на 4-е. Досрочный релиз софта — зверёк редкий, а на самодельном фреймворке — вообще краснокнижный... Гордость! XD

Про сам Vortex и его принципы была отдельная статья — про «зачем вообще» и «почему не DI». Сейчас‑ про то, что случилось на переходе от теории к практике. Когда фреймворк первый раз проверили не рассуждением и не бенчмарком, а живым проектом с дедлайном.

Короткий вывод: оправдал. Дал ровно то, ради чего задумывался, — простоту и предсказуемость масштабирования по всем осям, которые понадобились. А понадобилось немало.

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

8 More Lives не появилась сразу как цельная, полностью сформированная игра. Её особенности выросли из нескольких прототипов, экспериментов и уроков, накопленных за последние десять лет. Вот несколько идей, которые сформировали игру такой, какой вы видите её сегодня.

Идея этой статьи пришла мне в голову, когда алгоритмы Ютуба подкинули мне видео со схожим названием, где автор рассказывал о своём 2-летнем пути в геймдев после 40 лет. Меня просто поразило – насколько у нас оказались схожие стартовые точки. Но вот двухлетний итог работы у меня и автора этого видео оказался почти диаметрально разным. Вот об этом, а также подвести итог моих двух лет разработки игры с полного нуля в 42 года я и хочу рассказать в своей новой статье.

Вот видеоверсия данной статья на YouTube, RuTube, VK Видео, т.к. полотно текста получилось довольно большое (отчетная статья, всё же), а многим будет более комфортно не читать, а смотреть.

Понятие разработки без кода сегодня все чаще звучит в разговорах о будущем цифровых профессий. Это направление открыло дорогу в IT для людей, которые раньше не считали себя техническими специалистами, но хотели создавать продукты и решать задачи без углубления в кодинг. О том, как стать no-code специалистом и и какие возможности открыты для них на российском рынке, рассказала Яна Смирнова, разработчик студии визуализации данных AkademiaDev.

Я сшил разрозненные карты MMO в один бесшовный мир: игрок выходит из города в пустыню и не замечает, что под ним уже работает другой сервер. А всю рутину картографа — импорт, разметку препятствий, разрезание карт и проверку связей — отдаю ИИ. Заодно проверил, что происходит, если доверить ему игровую графику

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

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

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

Создание и оптимизация рендеринга воксельного мира в Unity (на мобильном устройстве). Это техническая статья для Unity/C#-разработчиков, которые знакомы с процедурной генерацией геометрии, но не обязательно писали собственный воксельный рендерер в Unity.

Что же за статья такая была? Неужели там была какая‑то информация, нарушающая нормы законодательства? Ведь не дают перманентный бан просто так! Значит, была веская причина.

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

Вот об этом я и хочу рассказать в новой статье.

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

Казалось бы, уже столько всего сказано и написано про то, как быть разработчиком инди-игры в современное время. Только я написал 3 статьи на подобные темы. Что можно ещё сказать на данную тему?

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

Именно об этой «внутренней кухне» я и хочу рассказать в данной статье.

Ключевой компонент игры Getting Over It with Bennett Foddy — это молот главного персонажа. Именно с помощью этого приспособления игрок передвигается в окружающем пространстве и пытается взобраться на гору, а затем всё более абстрактную череду нагромождённых объектов. На днях разработчик в общих чертах объяснил принципы работы этой детали игры.

Что представляет собой разработка инди-игры в одиночку в 2026 году? Какие у инди-разработчика появились новые инструменты и какие возможности ему предоставляет современное развитие нейросетей? А также — что ждёт инди-индустрию в ближайшие годы? Своим мнением обо всех этих вопросах я и хочу поделиться в новой статье.

"О спорт, ты — мир!" — это замечательная фраза основателя современных Олимпийских игр Пьера де Кубертена.

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

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

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

Всем привет! Меня зовут Гриша Дядиченко, я технический директор и основатель White Label Games. Уже больше десяти лет работаю с компьютерной графикой, AR/VR и компьютерным зрением — в основном это заказная разработка, плюс собственные прототипы по вечерам, до которых дотягиваются руки.

Делал я как-то на работе, по вечерам в свободное время, VR-шутер. Стрельбу, понятное дело, заложил себе на выходные: ну а что, raycast из ствола, событие попадания, отнял здоровье — делов-то. К вечеру воскресенья оно даже работало. Только ощущалось так, будто тыкаешь противника палкой: ни веса, ни отдачи, ни чувства, что ты вообще попал. Знакомо, наверное, каждому, кто хоть раз ставил в сцену оружие и жал «выстрел» — механически всё верно, а стрельба вялая и какая-то ненастоящая. Половина лечения тут — чистая полировка: вспышки, звук, тряска камеры, импакт-эффекты. А вот вторая половина — невидимая математика под капотом: та, что решает, ощущается стрельба честной и отзывчивой или кривой и несправедливой. Спред, который мозг считывает как «нечестный». Отдача, которую можно выучить. Попадание, которое по сети то засчитывается, то нет. Вот это всё и разберём.

Сталкивались ли вы с ситуацией, когда в шутере вы точно попали по противнику, а сервер сказал «промах»? Или с тем, что AI-противник стреляет в вас сверхскоростным снарядом и ни разу не попадает в движущуюся цель? Или с тем, что AK-47 в Counter-Strike рисует «семёрку» из пуль вверх и влево — и это, конечно же, никакой не баг, а вполне продуманная механика? Под капотом у всех этих ситуаций — конкретная математика.

Творите в Unity на Windows и страдаете от долгих компиляций? Инструкция как без вложений и разгона сократить время билда в 2 раза.

Всем привет! Меня зовут Гриша Дядиченко, я технический директор и основатель White Label Games. Уже больше десяти лет работаю с компьютерной графикой, AR/VR и компьютерным зрением — в основном это заказная разработка, плюс собственные прототипы по вечерам, до которых дотягиваются руки.

Сталкивались ли вы с ситуацией, когда у вас в игре уже двести юнитов, а FPS почему-то уехал, хотя визуально на сцене ничего особенного нет? Или с тем, что хочется сделать настоящую орду — плотную, с реакцией на стрельбу, обтекающую укрытия — а получается стайка, которая либо разбегается как пыль, либо слипается в один шарик и едет им по всей карте?

Чтож, давайте по порядку. Как это устроено у настоящих скворцов над Римом и причём тут код, какие именно три правила Рейнольдса и как они балансируются весами, как сетка побеждает O(N²) и где она сама ломается, что такое ORCA и как она разруливает встречные потоки в коридоре, как steering behaviors дают агенту цель и обход препятствий, и что лежит под капотом конкретных шипнутых игр от AC Unity до World War Z.