Godot *

Делаем Truck Sim 2D — 2D-симулятор грузоперевозок на Godot 4.6 для Android и ПК. Физический груз на RigidBody2D, который реально может выпасть из кузова, производственная цепочка от шахты до завода и первая сетевая версия на ENet — уже играбельная сборка 0.2.8. Рассказываем, как это устроено внутри и что планируем до MVP: превращаем LAN-конвой в настоящий кооператив

Godot — это 2D/3D игровой движок с открытым исходным кодом по лицензии MIT и большим сообществом, поддерживающий основные настольные и мобильные ОС, VR и веб (приставки с помощью сторонних компаний), ядро написано на C++, для скриптов поддерживается GDScript и C#, возможно подключение модулей практически на любом языке вплоть до Rust через GDExtension. Примеры игр — видеообзор 2025 года, 2024 года, 2023 года. Версия 4.7 вышла 18 июня 2026 года. Основные нововведения: поддержка HDR, магазин ассетов Asset Store, предпросмотр текстовых операций с шейдерами, новая нода для прямоугольных источников света, смещение трансформации нод Control, простой способ рисовать на текстурах, возможность создавать игры полностью на Android. Далее сделанный человеком (весь жирный шрифт проставлен вручную) перевод официального обзора нововведений с доступными объяснениями для новичков и ссылками на PR с исходным кодом на C++ для профессионалов.

Добро пожаловать в магазин ассетов. Библиотека ассетов была полезна, но отслужила свое. Пришло время уступить место новому Asset Store. Обновление привносит некоторые изменения, делающие просмотр ассетов более простым и приятным. Мы улучшили отображение ассетов и теперь вы можете увеличивать картинки из описания. Возможно вы не заметили, но что, если вы теперь можете видеть оценки ассетов? Потерялись в толпе бесконечных плагинов? Не уверены, как ориентироваться в свойствах объемных ассетов? Ответ уже здесь, прямо в магазине. За кулисами мы реализовали многопоточность. Теперь магазин ассетов может проводить определенные операции в фоновом режиме, не блокируя основной интерфейс редактора. Пока вы изучаете свой набор ассетов, кто-то расчищает путь и убирает помехи, чтобы вам было проще разобраться в происходящем. Загляните в магазин ассетов. Подробнее в PR. Авторы: Michael Alexsander

Всем привет! Меня зовут Саша, и я ML‑инженер. Современная разработка ML‑пайплайнов это уже давно не только обучение моделей. Хороший ML‑инженер, помимо всего прочего, пишет backend‑сервисы, настраивает Docker, занимается деплоем моделей, и иногда даже пишет автотесты для своих решений.

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

Сегодня мы закончим ковырять порт тайловых миров на F#. Правда, в прошлый раз мы исчерпали запас того, что вообще можно было «портировать», поэтому переключим внимание на совершенно новые фичи. Все они касаются UI (в узком смысле), ну или, говоря терминами игровой индустрии, HUD (Heads-Up Display).

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

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

В прошлой главе мы начали разбирать порт тайловых миров на F#, где познакомились с некоторыми малоизвестными возможностями Godot. В этот раз наш прицел сместится с технологических особенностей RenderingServer на обычную бытовуху (бизнес-логика + высокоуровневое рисование).

При этом следует понимать, что код разбираемого проекта предшествовал написанию текста и послужил первопричиной выбора тех тем, что попали в цикл. Поэтому нас ждёт очень много очень простого кода с примечаниями вида «это стало возможно благодаря <штуковине, что мы разбирали в цикле>». Конечно-же, я добавил некоторое количество экзотики, но сегодня наша задача — закончить с рисованием чего-либо (если не считать мини-карты, она вместе с GUI попала в последнюю главу) и собрать все заготовки в подобие игры.

Ambush! — быстрая дуэльная игра о боевых построениях и захвате фишек противника. Когда-то один из членов нашей команды создал настольную версию этой игры, а в рамках студенческого проекта в ФИИТ мы решили превратить её в полноценную компьютерную с мультиплеером. Рассказываем, почему выбрали не Unity, а Godot, что учились делать впервые без опыта и с какими проблемами столкнулись.

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

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

<Картинка не влезла в превью.>

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

За остаток цикла мы должны выяснить, как можно строить среднеразмерные игровые сцены на F#, а также почему этот цикл называется так, как называется. Конкретно в этой главе мы разберёмся с RenderingServer-ом (бывший VisualServer), но не с нуля, а с позиций достигнутых в «Godot — рисование без правил» и «Прямоугольные тайловые миры». Если вы уже прочитали эти статьи, то вам должно быть известно, что рисование через RenderingServer — это довольно экзотический подход, который воспринимает хождение сквозь стены как рядовое событие. Авторы движка этому не препятствуют, но и не содействуют, поэтому документации по этому серверу — кот наплакал. Мне так и не удалось выудить ответы на все интересующие меня вопросы в словесной форме и их пришлось выковыривать при помощи живых экспериментов. Последние ни в статью, ни в проект не влезли, но тут важна сама парадигма, при которой мы всегда отталкиваемся от практики, а не от теории, которой пока просто нет.

Привет, Хабр. Я — Андрей Макар-Уваров, Head of Frontend в Surf. Недавно решил проверить одну гипотезу: насколько далеко можно уехать на ИИ в разработке, если взять задачу, в которой ты абсолютный ноль.

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

«Ведь там в монастыре иноки, наверно, полагают, что в аде, например, есть потолок. А я вот готов поверить в ад только чтобы без потолка; выходит оно как будто деликатнее, просвещеннее, по-лютерански то есть. А в сущности ведь не всё ли равно: с потолком или без потолка? »

Ф. М. Достоевский, «Братья Карамазовы»

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

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

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

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

<Картинка не влезла в превью.>

Она написана с применением только тех приёмов, что уже были хотя бы надкусаны в цикле, поэтому концовка получилась очень щадящая.

Попробуем написать игру на Godot силами бесплатного ИИ: Visual Studio Code, Kilo-code, Gemini CLI, Qwen CLI.

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

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

Можно ли открыть эту дверь? Если да - как? Ключом, кнопкой, после выполнения квеста? А если нет - почему она вообще здесь? Является ли она просто частью декорации? Но тогда как игрок поймет, что одни двери - интерактивны, а другие - нет? Ведь если половина дверей в мире нерабочая, а другая - функциональная, но визуально они неотличимы, вы создаете фрустрацию, а не загадку.

А что, если дверь открывается только с одной стороны? Игрок проходит через неё, оборачивается - и видит, что обратно пройти нельзя. Это намеренное ограничение? Или баг? Как вы донесете до игрока, что это часть замысла, а не недоделка?

Или вот ещё: дверь закрывается за спиной. Это должно вызывать напряжение - как в Resident Evil. Но если игрок не был готов к этому, он может подумать, что застрял. Где тут грань между атмосферой и плохим UX?

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

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

С наступающим!

В юности, когда я увлекался компьютерными играми, играл в Moba Dota ещё на движке Warcraft III. В редакторе карт с помощью макросов и кода хотел сделать своих героев с уникальными умениями. Было интересно разрабатывать и смотреть как мои фантазии воплощаются в жизнь. Но всё же редактор карт накладывал свои ограничения и не так свободно можно было сгенерировать 3d персонажей и внедрить их в проект.

С появлением Dota 2, герои стали более детализированными, умения героев более эффектными, а карта интереснее. Меня это вдохновило на создания своих игр, я пробывал создавать в Unity, Unreal. Но знаний и времени изучить эти движки не было. А знаний по 3D моделингу вообще не было, поэтому игровые проекты я забросил, так как необходимо было разрабатывать более "приземленные" коммерческие проекты: веб сервисы, мобильны приложения и так далее,

С появлением игрового движка Godot, разработка игр получила вторую жизнь. Игры можно делать сразу на все популярные платформы: PC, Mac, IOS, Android, web. Управление объектами сцены можно полностью через код, что очень подкупало, так как редактировать сцены в 3d редакторе не всегда удобно, тыкая по UI, а можно быстро написать код сцены и объектов ней.

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

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

В прошлой главе мы избавились от необходимости непрерывно соприкасаться с C#-генераторами Godot, после чего пришли к выводу, что нам нужен адекватный задаче DSL. Я дам небольшую вводную по написанию самого дешёвого, но при этом крайне эффективного варианта, а все возможные навороты и прочую крутотень оставлю для DLC статей за пределами текущего цикла (иначе он никогда не закончится). Начнём мы с инициализации нод, настройки статических характеристик и выстраивания иерархии, а в следующий раз разберёмся с описанием их поведения.

Привет, хабр!

Это моя первая статья, поэтому для начала представлюсь. Меня зовут Виктор, мне 40 лет, из которых почти 20 я на разных ролях участвую в разработке различного программного обеспечения для крупных корпораций (в основном финтех). Путь был долгий и тернистый, но сейчас я занимаю роль Системного архитектора и по совместительству Руководителя направления интеграции.

Я всегда любил игры, у меня даже был собственный канал с летсплеями и обзорами разных игр, который, к сожалению, не сыскал успеха. Несмотря на это, около двух лет назад я решил с ноги ворваться в мир геймдева. Ничто не предвещало беды, просто одним февральским вечером будто щелкнуло что-то в мозгу - ХОЧУ… ДЕЛАТЬ… ИГРЫ…

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

Приветствую тебя, читатель, меня зовут Вадим Бельский, и я уже больше полугода делаю свою небольшую 4-x стратегию MyCivGame, вдохновленную играми Civilization и Total War. Сейчас я расскажу тебе, как устроен мир в нашей любимой игре Civilization, и мы с тобой вместе подумаем, можно ли сделать его лучше (а самое главное, нужно ли это)!