Что на самом деле важно для игрового движка в разработке инди? Размышления от создателя RimWorld (2017)

Небольшой перевод поста на Reddit от создателя RimWorld (проект на данный момент принесший под $100M) который возможно будет полезен людям в принятии решений о выборе движка.

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

В этом посте хочу поделиться мнением настоящего разработчика™ и создателя RimWorld – Тайнана Сильвестра, который довел проект до успешного релиза практически в одиночку. Напомню что RimWorld был сделан на основе Unity. Ниже приведен перевод его поста написанного в 2017 по итогам его теста Godot и других движков в качестве основы для следующего проекта. Прошу учитывать что пост написан соло_разработчиком_2д_симулятора в контексте 2017 года, еще до полноценного выхода его игры на Steam (только в early access), но многие вещи актуальны и сейчас.

Тайнан Сильвестр:

Позвольте мне немного поразмыслить.

Для начала скажу, что где-то 18 месяцев назад я действительно занимался исследованием движков для своей следующей игры. Я очень внимательно изучал SDL2 и OpenTK, и сделал несколько небольших незаконченных проектов с каждым из них. Сразу скажу что они мне не подошли. В OpenTK не хватало многого, особенно графического интерфейса. В обоих есть поддержка C#, но она не ощущается как первоклассная функция.

Unity в целом мне подходит как игровой движок, но у него есть ряд серьезных проблем. Он довольно тесный; движок очень упрямый и его мнение не всегда очень хорошо продумано. Он изо всех сил старается не дать вам уйти от того, как он устроен внутри. Кроме того, то, Unity просто лишили меня бессрочной лицензии от обновлений после версии 2017, что оставило у меня неприятное послевкусие. Я не хочу покупать новую лицензию каждый год для каждого разработчика; я не хочу, чтобы моддеры были внезапно ограничены отсутствием проприетарного редактора.

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

Поэтому я все еще ищу что-то другое для своего следующего проекта.

Если посмотреть на Godot, то на данный момент меня больше всего беспокоит что его команда похоже, пытается быть всем для всех. Godot пытается привлечь внимание студенческого рынка "моей первой игры", используя простой скриптинг, GDScript и т.д. Но в то же время он стремится к AAA-функциям, таким как продвинутый пайплайн для рендеринга и система расчета частиц на GPU.

Отсутствие определенного фокуса Godot приводит к тому, что, по моему мнению, у его разработчиков неправильно тратятся усилия на вещи, которые почти никто из серьезных инди не должен использовать (продвинутый рендеринг, который красиво выглядит в демо-роликах и GDScript), и в то же время уходят на второй план вещи, которые должны использовать абсолютно все инди – поддержка C#.

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

GDScript выглядит неплохо для очень маленьких игр, но он явно никогда не будет масштабироваться до уровня RimWorld: его производительность слишком мала, а код недостаточно безопасен без нормальной типизации. Большинство инди-игр уровня "моя первая игра" не должны его использовать.

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

C# покрывает потребности 90% задач инди для серьезных проектов:

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

Я очень надеюсь, что команда Godot не зациклится ни на продвинутых возможностях рендеринга ААА, ни на простоте использования уровня "моя первая игра".

Этот движок станет популярен, когда небольшие, но профессиональные инди-команды начнут его использовать для создания действительно популярных игр - игр уровня Factorio, Don't Starve, RimWorld, Hotline Miami, Stardew, Terraria.

Нам не нужны ни анимация, ни частицы, ни PBR, ни визуальные скрипты, ни сетевые технологии. Нам нужны только основы. Нам нужна действительно надежная поддержка C#, с отладкой и всем остальным, и нам нужно, чтобы движок был в целом без ошибок. Я надеюсь, что когда-нибудь буду его использовать!

Я надеюсь более подробно поделиться своим мнением о Godot, как только я изучу его побольше. Но это было самое заметное и важное, что сразу же привлекло мое внимание при его использовании.