Я рассматриваю свои варианты игрового движка. Я сделал Twin Stick Shooter учебник. Больше всего меня расстроило то, что большая часть программирования выполняется в Blueprints, что является уродливым (будучи здесь субъективным, но не долгим) графическим программированием. Вся логика игры была сделана с коробками … и я нахожу это ужасным! Я даже убегаю от Qt Designer и проектирую свой графический интерфейс с чистым кодированием и компоновкой.
Возвращаясь к объективности, проблема в том, что Twin Stick Shooter — очень и очень простая игра. Тем не менее, диаграммы были очень сложными и большими в конце. Я не нахожу это очень легко обслуживаемым без проблем, таких как отслеживание изменений во времени с помощью git или любого другого инструмента управления версиями. В отличие от C ++, где поддержка большого кода — это очень старая проблема, которая решается многими способами, и системы контроля версий хорошо с ней справляются.
Мой вопрос: Может ли эта же игра в учебном пособии (или любая игра в целом) быть выполнена со всей логикой, развернутой в C ++ (или, возможно, с менее чем 5% чертежей), вместо развертывания всего этого на диаграммах Blueprints (например, Twin Stick Shooter)? Учитывая, что я не эксперт в Unreal Engine, я думаю, что есть хороший ответ на этот вопрос от эксперта, который может объяснить, что можно и нельзя делать чисто в C ++, и почему это было бы хорошо или плохо тот.
Основываясь на моем опыте с UE4, я отвечу: да.
Первичные узлы и объекты Blueprints создаются с помощью C ++ и обычно доступны через API механизма C ++. В действительности версии узлов BP на С ++ обычно более сложны в использовании (т. Е. Имеют больше возможных параметров).
Я лично обнаружил, что любой важный аспект игры, такой как сетевое взаимодействие, пользовательский интерфейс, игровая логика и переходы уровней, может быть реализован в C ++.
(…) и почему это было бы хорошо или плохо.
Создатели UE4 говорят, что система Blueprint была разработана, чтобы помочь художникам и не разработчикам использовать движок. Система Blueprints также очень полезна в прототипировании игровой логики.
Благодаря гибкости Blueprints и времени создания многие разработчики (включая меня) решили использовать смешанный подход, когда вы создаете низкоуровневый, сложный или дорогой код на C ++ и выставляете его API для системы Blueprint. Это помогает отделить основной код от высокоуровневых функций, которые являются предметом многочисленных изменений и корректировок (преимущество: BP легче отлаживать, а время компиляции намного быстрее).
Одна проблема, которую я обнаружил при смешивании BP и C ++, — это проблема с использованием классов BP в коде C ++, обсуждаемая более подробно. Вот.
Я не нахожу это очень легко обслуживаемым без проблем, таких как отслеживание изменений во времени с помощью git или любого другого инструмента управления версиями.
UE4 имеет Инструмент слияния чертежей но я никогда не использовал это.
С точки зрения программиста с 20-летним опытом работы с C ++, но только с несколькими месяцами практики UE4 … Я бы сказал, да, но нет.
Я согласен с вами по поводу Blueprints — для простых операций, которые занимают одну или две строки кода, требуется пять или шесть узлов Blueprint, а программисту гораздо сложнее читать.
Вы можете сделать что-нибудь в C ++ с Unreal. Но вы должны учиться и работать с существующим корпусом кода движка, а Unreal — сложный и мощный зверь. Даже с многолетним опытом в C ++ мне действительно трудно делать простые вещи, потому что движок требует, чтобы они выполнялись определенным образом.
Честно говоря, для чего-то вроде шутера с двумя палками я бы полностью порекомендовал Unity.