Приветствую тебя, читатель, меня зовут Вадим Бельский, и я уже больше полугода делаю свою небольшую 4-x стратегию MyCivGame, вдохновленную играми Civilization и Total War. Сейчас я расскажу тебе, как устроен мир в нашей любимой игре Civilization, и мы с тобой вместе подумаем, можно ли сделать его лучше (а самое главное, нужно ли это)!
Недавно я написал статью в трех частях о том, как мы с нейросетью Qwen делали игры: аналог Pong!, платформер и клон «Героев меча и магии 3». Это вдохновило меня на то, чтобы еще детальнее погрузиться в возможности использования нейросетей в геймдеве и написать об этом.
Godot — это 2D/3D игровой движок с открытым исходным кодом по лицензии MIT и большим сообществом, поддерживающий основные настольные и мобильные ОС, VR и веб (приставки с помощью сторонних компаний), ядро написано на C++, для скриптов поддерживается GDScript и C#, возможно подключение модулей практически на любом языке вплоть до Rust через GDExtension. Примеры игр — список раз, список два. Версия 4.5 вышла 15 сентября 2025. Главные нововведения: трафаретный буфер (stencil buffer), поддержка средств чтения с экрана, обратная трассировка скриптов и пользовательские логгеры, запекатель шейдеров (shader baker), живой предпросмотр интернационализации, поддержка Apple Vision, физика сегментированных тайловых карт (chunk tilemap physics), фовеальный рендеринг (foveated rendering) на Vulkan Mobile, поддержка WebAssembly SIMD в веб. Далее сделанный человеком перевод официального обзора нововведений с доступными объяснениями для новичков и ссылками на PR с исходным кодом на C++ для профессионалов.
Поддержка трафаретного буфера (stencil buffer). Как нам «прорезать дыру» в этой стене, чтобы посмотреть на игрока на другой стороне? Теперь вы можете сделать это с трафаретными буферами! Представьте невидимую сферу, которая окружает нашего персонажа. Даже если геометрия не отрисовывается на экране, мы вставляем ее форму в трафаретный буфер. Теперь сделаем так, чтобы наши шейдеры отрисовывались, только если целевой пиксель не покрыт трафаретом. Вот так! Трафаретный буфер — это специальный буфер, в который меши могут писать для последующего сравнения. Он похож на существующий буфер глубины, но в него можно записать произвольные значения и у вас больше контроля над тем, что можно сделать со сравнениями. Подробнее и код. Добавлено Apples.
F# и C# в плане выразительности ООП различаются не так радикально, как некоторым кажется. Но у них разные дефолты, и мы вольны как бороться с ними, так и эксплуатировать их на полную катушку. Для этого необходимо понять, что F#-ный подход ориентирован на симуляцию процессов, а C#-ный — на симуляцию данных. Формально от нас требуется и то, и то, но по моему мнению, моделирование процессов — это 80% моей работы. Оставшиеся 20% — это данные, которые затачиваются под те же самые процессы.
C#-еры то ли обитают в другом мире, то ли как-то пропустили этот момент, поэтому систематически пишут код в обратном направлении — от данных к процессам. Первое время я думал о Godot в том же ключе, но чем больше ковырял <Prefix>Server-ы (там их много, VisualServer — это лишь один из подобных), тем больше у меня складывалось ощущение, что где-то в недрах его команды сидит вменяемый ФП-программист. Уж слишком сильно некоторые решения напоминали наши. К сожалению, я ещё многое не расковырял из того, что нужно расковырять для потенциального разрыва с дефолтным API. Поэтому в рамках текущего цикла мы не будем избавляться от ООП-нагромождений. Вместо этого мы нагородим новых, но так, чтобы нам было удобно работать в ФП-парадигме.
В прошлой главе мы ненадолго прервали изучение синтаксиса F#, но в этой всё с лихвой нагоним, так как сегодня у нас в программе первичный конструктор, расширения типов (снова) и их архитектурные следствия. Я попытался описать их в одном тексте, но обычно они раскиданы по разным частям документации, что серьёзно мешает целостному восприятию, в результате чего даже весьма башковитые ребята тупят как мальчики с Википедией при обсуждении истории древнего Рима. То есть формально у них есть доступ ко всем знаниям человечества, но фактически они соображают слабее, чем человек, прочитавший трижды устаревшего Моммзена.
Начиная с этой главы мы будем постепенно отказываться от того сценария разработки, который предлагает Godot по умолчанию. Итогом отказа будет почти полное исчезновение C# (пока только в рамках проекта) и переход на удобную и идиоматически правильную архитектуру.
Собрали большую подборку бесплатных и платных инструментов для создания игр разных жанров и форматов. Разделили их по задачам, чтобы было проще понять, какой подойдёт под ваш проект и уровень подготовки.
Кратко рассказываем, как устроен каждый, чем удобен и какие есть ограничения. А в конце — таблица для сравнения, если нужно быстро сориентироваться.
Разработка игр — это процесс, сочетающий творчество, логику и технические навыки. Если вы хотите попробовать себя в создании игр, это руководство может помочь вам сделать первые шаги. Давайте разберем все по порядку.
Мы ковыряли поиск пути через A* на протяжении двух глав и при этом были сосредоточены на синтаксических изысках F#. В этой главе мы отдохнём от синтаксиса и посмотрим на то, как этот алгоритм мог бы развиваться в более функциональном стиле.
Создание сотен локаций вручную непрактично для инди-разработчиков, а алгоритмы шума о которых я писал ранее ограничены. Искусственный интеллект, такой как MidJourney и NVIDIA GauGAN2 (интегрирована в NVIDIA Canvas, бесплатно доступный для пользователей с видеокартами NVIDIA RTX), предлагает новые возможности: нейросети генерируют текстуры, биомы и концепт-арт с высокой детализацией.
Когда мне было 16, я устроился работать в небольшую студию. Это была по факту официальная работа: с реальными задачами, пайплайном, дедлайнами и даже большим издателем. Тогда это казалось чем-то невероятным. Игра, над которой мы работали, выглядела амбициозно. У неё были красивые промо, целевая аудитория, маркетинг — всё как у взрослых.
А в центре команды был парень, старший разработчик, которому на тот момент было 23. Для меня он был почти как герой: я только начинал, а он уже 7 лет программировал. Уверенный, спокойный, очень самостоятельный. Я всерьёз думал, что именно к этому и стоит стремиться.
Но потом к нам присоединились более опытные ребята. Разработчики, у которых за плечами были и запущенные проекты, и провальные — но главное — была реальная практика и мышление архитектора. Они сразу начали задавать вопросы: — Почему у нас 6000 строк в одном скрипте? — Почему нет нормального разделения логики? — Почему переменные называются a, b1, mainLogic, veryImportantManager?
Код, который мы считали рабочим, оказался большой горой хрупкого говнокода, которая могла рухнуть от любого изменения. И когда она рушилась — её латали так же вслепую. Без юнит-тестов, без понимания, почему оно работает. Главное, чтобы запускалось.
🧨 А потом проект провалился. Несмотря на издателя
MyCivGame - Как я сделал свою Civilization! Я расскажу, как я в одиночку делаю свою пошаговую стратегию, вдохновленную играми Civilization и Total War...
В прошлой главе мы перенесли A* на F#, после чего в образовательных целях занялись выдёргиванием его «кишок» наружу. Тогда процесс «потрошения» не был завершён до конца, но сегодня мы его добьём. Что касается метагейма, то мы продолжим путь от функции к конструктору и даже успеем слегка залезть на «ту сторону».
Концепция этого цикла начиналась с простого переноса тайловых миров на F#. Однако в процессе его описания я основательно растёкся по древу, за счёт чего у нас образовался большой подготовительный этап из пяти глав про языковые фичи и прочую «фундаменталочку». Думаю, что с подготовкой закончено, поэтому сегодня мы обратимся непосредственно к тайловым мирам.
Но начнём мы практически с конца — с адаптации поиска пути. Это несложная задачка, но в процессе её решения мы успеем закрепить пройденный материал и по инерции заскочить в новый.
Меня зовут Алексей Цуцоев, я разработчик мобильных приложений в KODE, и я хочу поделиться историей того, как мы внедряли игру в уже готовое React-Native приложение. Как выбирали технологию, с какими трудностями столкнулись и к каким выводам пришли.
Мы закончили обсуждать тело функции, и теперь пришло время вывода данных. Простые сценарии мы сразу отбросим, так как по ним уже хорошо прошлись, когда изучали выражения. Мы начнём с косяков выполнения, под которыми я подразумеваю не баги, а непреодолимые препятствия с различной степенью неожиданности. Это может прозвучать странно, так как аварийный выход не подпадает под определения output, codomain и т. д. Я с этим согласен и пересматривать эти термины не собираюсь. Однако меня интересует не только легитимная часть, но и вообще всё, что выходит из функции. Вплоть до того, что в следующих главах я начну включать в это аморфное понятие сайд-эффекты, фоновые процессы и много чего другого.
Я начал с ошибок, потому что Godot эту тему фактически проигнорировал, и вряд ли за ненадобностью, так как несколько раз мне уже было очень больно. У меня всё ещё не дошли руки покопаться в GDScript, так что я понятия не имею, вызван ли этот пробел ограничениями языка или архитектурным решением, но в любом случае нам его надо закрывать.
C# и ФП пропагандируют разные подходы к ошибкам. F#, будучи на перепутье, испытывает влияние обоих. Можно много говорить про плюсы взаимного обогащения культур, но судя по публичным баталиям, это не совсем наш случай. Вместо синтеза я куда чаще наблюдаю эмоциональные взрывы в среде представителей то одного, то другого лагеря. Я не буду ввязываться в эту борьбу (в этот раз) и сосредоточусь на решении более насущной задачи. Мне нужно доработать интероп так, чтобы он соблюдал привычную систему распределения ответственности. Так что сегодня только рутина, без красивых ходов и эффектных бросков.
В прошлых частях мы подключились к Godot, обсудили адаптацию к API и разобрались с устройством тела функции. Дальше в планах было перейти к входным и выходным данным, от них к общей архитектуре и далее снова к особенностям API. Если бы я отстрелялся быстрее, то так бы и было, но я возился слишком долго (об этом чуть ниже), из-за чего до моей телеги успел доползти читатель с типовым набором набивших оскомину вопросов. Допускаю, что я собрал всю коллекцию практикующих читателей, но мне хочется верить, что где-то прячется «молчаливое большинство» с аналогичными проблемами. Поэтому я решил передвинуть некоторые рассуждения из конца цикла в середину.
Это задержит кульминацию, но не критично, так как финальные части цикла я планировал запостить без длительных пауз. Поэтому эта глава пролежит в ожидании до тех пор, пока не будет готов черновик всего цикла. Если этот текст появился на Хабре, то остальные главы уже на подходе.
Этой статьёй я хочу внести некоторые правки в алгоритм развёртывания, который я описывал год назад вот здесь. Статья тогда получилась объёмная, и я искал способы её сократить, в результате чего опрометчиво пренебрёг несколькими сценариями, которые пригодились мне в дальнейшей разработке. Они образовали техдолг, который мне необходимо закрыть ввиду грядущего продолжения.
Прототип походовой радиусной тактики на движке Godot 3x, продвинувшийся от концепта до улучшающейся демоверсии. Передвижение персонажей, как и применение способностей, происходит не по клеткам, а в пределах определённого радиуса. Герои могут менять профессии - на данный момент это Странник, Волшебник, Сказочник или Рыцарь.
Несколько game-ready low-poly моделей, которые делал вручную с применением разделённой покраски: цвет и монохром отдельно. Используется Blender, без каких-то дополнительных штук.
Разбираю один из многообразных способов создания инвентаря в игре на примере движка Godot. Рассматривается вариант написания его вручную, относительно простым образом, без использования классов и каких-то плагинов.
