Spiiin's blog

• С++ в геймдеве — предыдущий пост на похожую тему

Несколько общих статей от разработчиков игр:
[1] - Leaving Rust gamedev after 3 years — про то, что фичи Rust-а не особо помогают для геймдева, а периодически и мешают.
[2] - Life and Death of a Graphics Programmer — взгляд на геймдев со стороны графического разработчика. Достаточно высокий, чтобы быть интересным любому разработчику игр.

Важные моменты из статей:

Generalized systems don’t lead to fun gameplay

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

Making a fun & interesting games is about rapid prototyping and iteration, Rust’s values are everything but that

Строгие требования языка мешают прототипированию. Геймдев — не про выражение строгих требований, а про простые эксперименты и быстрые итерации.

Rust gamedev ecosystem lives on hype

Больше даже не про Rust, а про open-source библиотеки в принципе. Большая часть из них не готова к использованию в продакшене. Код в продакшене сильно сложнее за счёт того, что в нём заложено решения множества возникавших проблем.

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

Касается и других систем рефлексии.

Как графический программист я добавлял бесконечное количество чекбоксов, слайдеров и кнопок для множества редакторов объектов. И намного более важно в этом, чтобы элемент был добавлен в корректную категорию, имел правильные ограничения на ввод и понятные подсказки, что то, как выглядит код, это абсолютно неинтересно и неважно артисту.

Как и с любыми тулзами. Невозмжно, что под капотом, важно что тот, как работает с программой (фактически, ДЕЛАЕТ игру) имел то, что удобно для него. Программисты типично пытаются делать тулзы для себя, а не для других. Один из симптомов такого перекоса — желание выбрать/создать скриптовый язык, похожий на C++.

Проектирование под команду

Проектирование (в частности, выбор языка и инфраструктуры) в геймдеве сильно зависит состава команды. В [2] есть сравнение команд, в которых шейдеры могут трогать только программисты с теми, в которых к ним есть доступ у технических артистов, и просто артистов. Если в Doom шейдеры модифицируют только программисты, то в нём и будет около 100 типов шейдеров (и не будет серьёзного инструмента для работы с ними), тогда как в Unreal вышедшие проекты могут содержать до 10к материалов, но и тулзы, в которых делаются шейдеры, будет выглядеть сильно по разному.

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

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

Геймдев проблематика

This Problem Changes Your Perspective On Game Dev — обзор процесса поиска в дизайне. Критична простота экспериментов, и скорость итерации. В видео нет никаких новых идей — это стандартные требования геймдизайнеров к инструментам, чтобы иметь возможность создавать интересный геймплей. Причём не только к инди или инновационным играм, а вообще к играм любого жанра.

Tomorrow Corporation Tech Demo — небольшой пример хот-релоада
Inventing on Principle — еще пример
NimForUE 101: uStructs — перезагрузка в vm unreal с помощью кода на nim

• Системы поиска сокровищ — системы поиска сокровищ в песочницах

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

Дополнительно, так как геймдев требователен к производительности:
- возможность оптимизации быстро написанного кода — Just-in-Time, Ahead-of-Time

Про волны развития технологий

C++ находится на достаточно поздней стадии развития — много лет использования, развитые компиляторы с оптимизациями, стандартная библиотека. Периодически предлагаются языки-наследники (Carbon, Cpp2, Val). Но при этом он плохо подходит для решения специфичный для современного геймдизайна проблем, перечисленных выше.

- долгая компиляция. Заменить include на модули стоило бы лет 15 назад. Тем не менее, модули все ещё не используются.
- рефлексия в стадии "обсуждаем, как стандартизовать". Из-за особенностей C++ можно ждать возможности использовать то что настандартизируют ещё очень долго. Причём только рефлексию, без кодогенерации и полноценного compile-time выполнения, которые тоже нужны. Лучшее решение сейчас — внешний инструмент.
- менять код на лету можно очень ограниченно. Интерпретации не планируется, hot-reload на уровне подмены динамической библиотеки (доступной не на всех платформах). Требуется внешнее решение.

Вообще ждать появления чего-то в стандарте — очень ненадёжно. Может быть отложено, принято криво, после принятия еще несколько лет до исправления багов во всех реализацией, и еще — на обновление библиотек

Как сделать разработку легче?

Не пытаться использовать C++ там, где это неудобно, использовать другой язык или языки для описания игровой логики. Такой на котором проще решать проблемы гейм-дизайнеров, не программистов (этот язык даже скорее всего будет менее удобен программистам, во всяком случае вначале).

что-то типа такого (доклад сам по себе про похожие идеи). автор языка lobster, также flatbuffers и программист в нескольких AAA-проектах

Lua in Grim Fandango — история первого использования lua в качестве скриптового языка.

Телефоны/консоли также на поздней фазе развития — запаса мощности часто хватает для того, чтобы запихнуть “дорогие” абстракции, увеличивающие как время компиляции, так и время выполнения кода. Для казуальных и прочих “простых” игр — раз в 5-10. Т.е. в принципе можно вообще использовать в 5-10 раз более медленный язык для реализации всей логики, ради того, чтобы сделать удобнее гейм-дизайнерам.