Собрали большую подборку бесплатных и платных инструментов для создания игр разных жанров и форматов. Разделили их по задачам, чтобы было проще понять, какой подойдёт под ваш проект и уровень подготовки.
Кратко рассказываем, как устроен каждый, чем удобен и какие есть ограничения. А в конце — таблица для сравнения, если нужно быстро сориентироваться.
Разработка игр — это процесс, сочетающий творчество, логику и технические навыки. Если вы хотите попробовать себя в создании игр, это руководство может помочь вам сделать первые шаги. Давайте разберем все по порядку.
Мы ковыряли поиск пути через 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. Рассматривается вариант написания его вручную, относительно простым образом, без использования классов и каких-то плагинов.
Два разных проекта на движке Godot. Первым был Tesserfact — попытка перенести урезанную часть механик из настольно‑ролевой тактической игры в игру компьютерную. Но в процессе, в силу принципиальной невозможности переноса всех аспектов, подумал переориентировать его в игровой стол (Монстробой: Тактика — второй проект), где игрок управляет всем мануально и может «эмулировать» любые, незакодированные, правила. Что из этого лучше — вопрос открытый, как и то, что обязательно ли компьютерные игры должны быть именно играми общераспространённого вида, где весь интерактив целиком автоматизирован.
Прототип adventure-rpg в мире маленьких планет, где игрок управляет разумным звездолётиком, который посещает различные планетки.
Однажды было настроение собрать проект с управлением в стиле WoW, геймплеем куда-то в направлении Skyforge, экспериментальными игромеханиками и игрой за чистых magic user'ов - получился экшен-рогалик с заклинаниями от комбинаций. Также в этом деле оказалась замешана настольно-ролевая система "Неоновый миф" и её необычные герои.
Что если вместо Невангеров делать аналог Вангеров, подумал я и сделал прототип торгово-гоночной игры на движке Godot. Собрав в нём некоторое комбо из различных наработок за все годы и заложив в игру классический вангерский процесс - развоз грузов. Естественно, с какими-то своими особенностями тоже.
О том как серия игровых прототипов по мотивам (и не по мотивам) небезызвестных сюрреалистических "гоночек" из 98-го пробовала различные концепции, механики и игровые движки.
