Кратко об проблемах нативности разработки в Unreal Engine. Быстропост.

Сразу обговорю формат изложения. Я не претендую на абсолютную истину. Цель поста - развлечение. Я пишу пост исходя из собственного опыта только Unreal Engine. 

Как разработчику- программисту на Unreal Engine, и, в прошлом, архитектору проекта, нативность разработки для меня имеет довольно важный аспект. Под нативностью я имею ввиду насколько просто менять состояние продукта на высших уровнях - это уровень, состояния BP, Assets, ect. Другими словами, нативность присутствует в большей степени для геймдизайнера, чем для программиста. При этом, разработка игр как ни одна профессия в IT требует нативности. Основной целью игры является достижение фана. И достижение фана слабо предсказуемо.  Поэтому, возможность геймдизайнера потрогать переменные, переключатели и тд является неотъемлемой частью правильной разработки. 

Что же нужно для достижения нативности? 

В целом, не так уж и много. В первую очередь это правильное именование, стандартизированный подход к группам, хорошо прописанная документация. Однако когда проект начинает развиваться, часто этого становится недостаточно. Здесь вступает в игру первое ключевое противоречие создания хорошей нативности в Unreal Engine - инстансирование против кеширования. По умолчанию, чем проще для геймдизайнера вести работу, тем лучше. Часто, для достижения упрощённой работы сразу со множеством объектов одного класса, их редактируют через переменные по умолчанию или например, используя Data Asset. Назовем этот процесс кешированием.  Однако, ваши действия для того, что бы организовать редактирование инстансов после кеширования данных можно только для очень ограниченного пула объектов - например, Actorов. Остальные варианты либо совсем не имеют возможности редактирования инстансов, как например Data Asset, либо имеют ее в довольно своеобразном (поломанным) формате - как например Inline Object. Есть ещё ограниченно используемый вариант с FInstanceStruct, но его мало где используют из за отсутствия адекватного наследования для структур. Разве что некоторые узкоспециализированные плагины, вроде Flecs. И адекватной альтернативы этому нет - что приводит к черезмерному инстансированию классов или Data Asset, что в свою очередь приводит к доп трате памяти на содержание часто нестатичных классов, CDO-обьектов и инстансов. 

Хотя, даже если отбросить этот ряд сущностей, тяжело поддающихся инстансированию, остальной ряд объектов также имеет проблемы в вопросе нативности, которые решаемы, но лучше были бы решаемы из коробки. Например, многие ключевые объекты и функции (WorldSettings, Game User Settings, добавление в Project Settings, редактирование компонентов скопом, ect) не доступны на уровне BP по умолчанию. Недоступность всякого на уровне BP в целом касается множества вещей в Unreal, поэтому уже к концу первого года каждый разработчик обрастает своим джентльменским плагинным набором из сериализации, реплецирующигося UObject и тд. Но об этом поговорим как нибудь в следующий раз. 

Наконец, что в целом логично, нативность вступает как третья сторона в вечный бой Скорости против Памяти программы, добавляя ещё один элемент головоломки для архитектора программы. 

В целом, ситуация с нативностью в последние года 3 в Unreal улучшается. Появилось множество хороших инструментов, которые теперь активно используются для упрощения нативности. Тем не менее, проблема все ещё существует и хотелось бы как минимум починки Inline Object в ближайшие годы.