company_banner

JetBrains Rider — теперь для Unreal Engine

    Привет Хабр!

    На прошлой неделе, после релизов версии 2020.1, для всех наших десктопных продуктов случилось еще одно большое событие — мы открыли публичный доступ к пробной версии Rider for Unreal Engine. На данный момент это отдельный продукт, версия нашей среды для разработки Rider, но с поддержкой C++ и Unreal Engine.

    Rider for Unreal Engine

    Так, стоп! Среда разработки на C++. Еще одна?! Давайте разбираться по порядку.

    Начнем с небольшой истории. Несколько лет назад мы собрали всех, кто в JetBrains делает инструменты для C++, чтобы обсудить, насколько пользователям тяжело ориентироваться в многообразии наших предложений. Ведь есть и CLion, и ReSharper C++, и поддержка для C++ в AppCode. Через несколько часов обсуждений пришли к таким выводам:

    • Хотя универсальный инструмент и выглядит заманчиво, при расширении таргетинга, увеличении количества интегрированных сторонних инструментов, поддерживаемых случаев использования становится очень сложно искать баланс между удобством, интуитивностью интерфейса и обилием возможностей.
    • Мир разработки ПО уже давно не имеет четких границ по языкам разработки. Многие проекты мультиязыковые. Важнее — область применения ПО и технологии, которые в ней используются.

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

    • CLion — наше основное предложение для разработки на C и C++. Кроссплатформенная среда разработки ориентируется на нативную разработку, проекты финансового сектора, встроенную разработку, проекты AI, разработку библиотек, утилит и пр. При этом существующие ограничения на тулчейны и, особенно, проектные модели (поддерживается CMake, Gradle Native, compilation database, существует плагин для Bazel, в разработке находится поддержка Makefiles) являются скорее техническими. Проще говоря, мы не видим проблем с тем, чтобы в CLion появилась поддержка того же msbuild, если это нужно нашим пользователям, но ее сейчас попросту некому делать.
    • ReSharper C++ — выбор тех, кто занимается именно разработкой на Windows, в специфическом стеке инструментов, и кто не готов отказаться от Visual Studio. Зачастую эти люди еще и комбинируют разработку на C++ и на C#. Этим разработчикам мы предлагаем расширение для Visual Studio, версию широко известного нашего продукта ReSharper, но для C++.
    • AppCode — вообще отдельная история, так как это среда для разработчиков под iOS/macOS. C/C++ тут скорее часть общего mac-специфичного стека разработки.

    Так, а при чем тут Rider? Какое отношение к C++ может иметь кроссплатформенная среда для разработки на .NET? На практике, около 30% пользователей Rider — это игровые студии и компании по разработке игр. Оно и понятно, ведь Rider во многом популярен именно как среда для разработки под Unity. Уже не первый год команда Rider кастомизирует инструмент именно под этот игровой движок. Результат нравится не только программистам под Unity, но и самим Unity Technologies, с которыми мы давно и плодотворно взаимодействуем по части самой технологии.

    Заходя ко многим нашим пользователям из области разработки игр, мы заметили, что у многих студий нет четкого разделения — делать игры только на Unity или только на Unreal Engine. Сегодня у них игра на одной технологии, а завтра — на другой, или одна команда использует Unreal Engine, а другая Unity или вообще свой кастомный движок. При этом понятно, что разработчикам и компаниям в целом очень не нравится “прыгать” между разными средами разработки. И вот тут-то мы и решили, что, если мы смогли сделать Rider успешным для Unity, то мы можем пойти дальше и сделать его успешным в целом для мира игровой разработки. Так родилась идея Rider как универсальной среды разработки для Game Dev.

    Из чего состоит Rider for Unreal Engine


    Дальнейшее развитие событий довольно очевидно для тех, кто знаком с технологией, на которой построен Rider. Rider состоит из front-end части на базе платформы IntelliJ и back-end части на базе ReSharper. Все языковая поддержка работает на back-end. Поэтому мы просто подключили уже имеющуюся в ReSharper C++ поддержку C++ и Unreal Engine к Rider по той же технологии. Из специфичного пришлось дополнительно реализовать:

    • Плагин для выбора Rider как среды разработки в Unreal Editor (Rider Source Code Access) для версий движка 4.22-4.24. Начиная с версии 4.25 эта функциональность уже будет включена в сам движок UE.
    • Плагины UnrealLink для Rider и RiderLink для Unreal Editor, которые обеспечивают интеграцию с Blueprints в Rider и в целом отвечают за коммуникацию между Rider и Unreal Editor.
    • Отладчик.

    Стоит отметить, что сейчас превью Rider for Unreal Engine доступно только на Windows, открывает файлы .sln и полагается на сборку компилятором от Microsoft. В будущем, к моменту релиза, мы постараемся расшириться до всех трех платформ и реализовать поддержку .uproject как основной проектной модели.

    Отладчик на основе LLDB


    Значительная часть разработки игр происходит сейчас на платформе Windows и в рамках тулчейна от Microsoft. Если посмотреть на то, какие инструменты для отладки существуют для кода, который скомпилирован с помощью компилятора Microsoft Visual C++, то мы увидим:

    1. В своих собственных инструментах Microsoft использует инструменты отладки на основе vsdebugeng.dll. Лицензия не позволяет использовать эти инструменты в сторонних средах разработки.
    2. CDB и WinDbg используют dbgeng.dll. И именно этот вариант мы изначально пробовали для написания своего отладчика для MS стека. Но столкнулись с плохой производительностью на больших бинарных файлах с большим количеством файлов символов (.pdb), и, что еще более важно, с частым аварийным завершением приложения.
    3. Существовали также наработки в LLVM-сообществе по поддержке отладки для тулчейна Visual Studio с помощью LLDB. Ими мы и воспользовались, и буквально года за полтора написали первую версию в общем-то работающего отладчика. Он включает начальную и еще пока сырую поддержку формата NatVis (такие MS-специфичные pretty printers). При этом сейчас Rider for Unreal Engine сам находит NatVis-ы в проекте на Unreal Engine и подгружает их отладчику. Этот же отладчик мы сейчас используем в CLion для тулчейна Visual Studio (он включен по умолчанию в этом случае начиная с версии 2020.1).

    Новый отладчик еще, безусловно, сыроват, в нем пока случаются и существенные проблемы, и замедления. Но мы надеемся довести его до ума к релизу.

    Поддержка C++


    Повторю — вся функциональность языковой поддержки из ReSharper C++ теперь доступна в Rider for Unreal Engine Preview. Она включает:

    • Около 170 различных инспекций кода и более 50 быстрых исправлений.
    • Рефакторинги, учитывающие все контекстные использования символа (переименование, изменение сигнатуры метода, вынос метода, добавление поля / переменной / typedef, подстановка (Inline) переменной или typedef, и другие).
    • Генерация кода (методы getters/setters, конструкторы, операторы сравнения, шаблоны документации кода).
    • Действия для помощи в написании кода, навигация, форматирование и поддержка стилей именования, сортировка #include директив.

    Generate action

    Поддержка HLSL, C#, диалектов uproject/uplugin


    В этом году мы начали работать над поддержкой языка для написания шейдеров HLSL в ReSharper C++, и она сразу попала и в раннее превью Rider for Unreal Engine. Поддержка включает в себя подсветку синтаксиса, тултипы с документацией, подсказки имен параметров и типов, действия навигации, автодополнение, поддержка виртуальных путей файлов, и даже рефакторинги.

    Так как в основе Rider for Unreal Engine среда для разработки на .NET, то языковая поддержка работает и в файлах Build.cs, и в Target.cs.

    И наконец, если говорить о поддержке языковых диалектов, Rider for Unreal Engine понимает диалекты файлов .uproject/.uplugin, предоставляя опции автодополнения и тултипов документации.

    uproject dialect

    Интеграция с Blueprints


    Файлы Blueprints представляют собой данные в бинарном формате, редактирование которых происходит как правило в визуальном редакторе внутри Unreal Editor. Объекты в этих файлах наследуются от классов на C++, переопределяют проперти из C++ части игры. И вот тут Rider for Unreal Engine является той уникальной средой разработки, которая зачитывает все необходимые файлы Blueprints и показывает эти связи в редакторе кода на C++:

    BP derived classes

    При этом, если поменять, например, значение свойства в редакторе Unreal Engine и сохранить asset, то значение тут же автоматически обновится и в Rider (у нас повешены watchers на изменение asset-файлов):

    BP properties

    Без сохранения файлов, мы надеемся, это тоже скоро заработает (подготовка к этому сейчас ведется в плагине UnrealLink).

    Вызов поиска использований (Find usages) включает не только использования в коде на C++, но и в файлах Blueprints. Двойной клик по таким использованиям открывает Unreal Editor.

    Понимание механизма рефлексии UE4


    Рефлексия в Unreal Engine реализована с помощью специальных макросов (UCLASS, UFUNCTION, UPROPERTY и др). Rider знает, что параметры таких макросов — это не просто текст. Парсер языка C++ в ReSharper C++ и Rider умеет действительно “понимать” значение этих макросов, даже не запуская Unreal Header Build tool (то есть еще до того, как реально сгенерируется содержимое файлов .generated.h).

    Кстати, говоря про файлы .generated.h, ReSharper C++ и Rider знают, что автоматически добавляемые пропущенные директивы #include надо вставлять строго до подключения файлов .generated.h. А также учитывают эти генерируемые файлы в рефакторингах переименования.

    Возвращаясь к механизму рефлексии, стоит сказать, что спецификаторы рефлексии — это в ReSharper C++ и Rider тоже не просто текст. Для них есть автодополнение и подсказки документации:

    Reflection doc

    Подсказки документации доступны и для самих макросов рефлексии.

    А еще анализатор кода проверяет использование макросов рефлексии и указывает на связанные с этим ошибки. Например:

    • Классы UCLASS должны быть публично унаследованы от UObject или любого его класса наследника. При этом такой родитель должнен быть ровно один.
    • Спецификаторы UCLASS должны быть использованы для классов, USTRUCT – для структур.
    • Классы UE4 не могут быть объявлены внутри других классов.
    • Объекты, сохраненные в полях, не отмеченных UPROPERTY, могут быть собраны сборщиком мусора в любое время.

    Поддержка вызовов удаленных процедур (RPC) в действиях навигации и генерации кода


    Если рассматривать вызовы удаленных процедур с точки зрения обычного парсера C++, то довольно быстро можно заметить неосведомленность парсера о том, что объявлению функции может соответствовать несколько имлементаций с отличающимися именами (например, суффиксами _Validate и _Implementation). В ReSharper C++/Rider мы обучили парсер идентифицировать RPC по спецификаторам Client, Server и NetMulticast в параметрах макроса UFUNCTION. Благодаря этому:

    • В навигации предлагаются все необходимые варианты имплементации функции.
    • Генерация кода умеет создавать функции с суффиксами _Validate и _Implementation или только те из них, которые отсутствуют:
      RPC generation
    • Рефакторинги кода Rename и Change Signature обновят все необходимые функции и тем самым сохранят ваш код в корректном состоянии.

    Знание правил именования Unreal Engine 4


    ReSharper C++ и Rider осведомлены об официальных правилах именования в коде Unreal Engine. Эти правила используются средой разработки во всех действиях по работе с кодом, вроде генерации getters и setters или рефакторинге добавления переменной (Introduce Variable). А главное, что существует проверка кода Inconsistent UE4 naming inspections и соответствующее быстрое исправление, которое вызовет рефакторинг Rename и переименует все использования имени, не соответствующего правилам.

    Производительность редактора


    Мы довольно давно делаем поддержку разработки на Unreal Engine в ReSharper C++ и, конечно, видим, что производительность редактора является основной жалобой. Rider в силу особенностей архитектуры избавлен от многих проблем с производительностью, которые присутствуют в ReSharper (там они есть отчасти из-за ограничений студии на 32-разрядные процессы, в рамках которых происходит работа ReSharper, но не только).

    Помимо этого, мы специально настраиваем работу IDE для улучшения производительности на Unreal Engine. Мы сначала индексируем код пользовательской игры, мгновенно включая все умные действия редактора на пользовательском коде. А индексация уже кода самого движка происходит после этого в фоне. Есть и еще несколько дополнительных опций по управлению индексацией:

    Performance options

    В результате, те, кто уже начал пользоваться Rider for Unreal Engine, отзываются о производительности редактора очень положительно! А мы уверены, что можем сделать еще лучше.

    Видеодемо и еще раз о том, как получить доступ


    Эти и многие другие возможности можно посмотреть в действии в демо-ролике (на английском) от нашего девелопер-адвоката:


    А чтобы попробовать эти возможности самостоятельно, достаточно заполнить простую форму и получить от нас письмо со ссылкой на билд и активацию бесплатной лицензии на раннее превью. Переходите, заполняйте, пробуйте, пишите отзывы! Для ваших отзывов, как обычно, есть комментарии тут, трекер (ReSharper C++ и Rider) и почта нашей поддержки (rider-cpp-support@jetbrains.com).

    Спасибо за внимание!

    Команда Rider
    The Drive to Develop
    JetBrains
    Делаем эффективные инструменты для разработчиков

    Комментарии 42

      0
      На докладе осенью ПМ ридера говорил, что Майкрософт начали вставлять вам палки в колеса с вашими продуктами. И ребята с Юнити между поддержкой от маков и сотрудничеству с вами, выбирают маков. Я как понимаю, это ответ на действия маков?
        +1

        Мы редко делаем что-то на зло или вопреки) Просто рынок кажется интересным. К тому же Epic Games с нами по техническим вопросам активно сотрудничают.

        +6
        Выглядит очень круто, прямо захотелось попробовать.
        Но подписочная модель, конечно, должна умереть. Поэтому нет.
          +1

          Ну это не совсем классическая «подписочная» модель насколько я понял их объяснения. Покупается текущая версия и возможность обновить ее в течение какого-то срока. После истечения срока купленной версией можно пользоваться без проблем она не превратиться в тыкву что ожидается от обычных подписок. То есть это обычная покупка софта и оплата какого срока его поддержки.


          Они что-то поменяли?

            –2
            Ну я вижу обычную подписку только.
              +3
              Perpetual лицензия только за 12 оплаченных месяцев дается и дает активировать только ту версию, которая вышла на момент начала 12-месячного периода.
              sales.jetbrains.com/hc/en-gb/articles/207240845-What-is-perpetual-fallback-license-
                +2
                + все bugfix апдейты для этой версии
                  0
                  Плохо что если не продлить свою лицензию сразу, то потом цена становится такой же как и за первый год использования
              +2

              Подписочная модель не так уж и плоха и, зачастую, может быть выгодна не только производителю, но и покупателю. Разработка ПО меняется очень быстро – появляются новые языки, фреймворки, старые меняются до неузнаваемости и все это требует поддержки со стороны сред разработки. В случае с разовой покупкой, она с большой вероятностью, устареет в течение двух-трех лет, и придется покупать новую версию. С подпиской же, у вас всегда будет самая актуальная версия. К тому же надо учитывать, что технологический стек может полностью поменяться и продукт перестанет быть актуальным.
              Для бизнеса так и вообще сплошная выгода – капитальные затраты сразу превращаются в операционные.
              Безусловно, все преимущества может убить неадекватная стоимость подписки, но такие ошибки рынок всегда исправляет (так или иначе).

                +1
                Согласен. Я за подписку.
                +10

                Позанудствую немного.


                Я с вами согласен как пользователь, потому что тоже хочу платить меньше и один раз. Однако, количество людей, и разработчиков тем более — конечно.
                Когда какая-то критическая масса людей/компаний купит лицензии на продукт и будет им пользоваться (зарабатывая, между прочим, деньги не один раз, а продолжительно), на какие средства разработчики JB будут существовать, обновлять продукты, кушать в перерывах?


                Стоит учитывать, что модель подписки JB довольно удобная по сравнению с Adobe, Miscrosoft, Unity опять же и прочими ребятами.
                Они не вставляют палки в колёса в нормальной рутине и вы можете и оффлайн пользоваться с активной подпиской довольно долгое время. Вы можете пользоваться предыдущей версией вообще без ограничений, даже когда больше не оплачиваете. Если не нужны новые фичи — почему бы и нет.
                Это разительно отличается от дичайших практик, когда некоторые разработчики вставляют палки в колёса, и без постоянного доступа к интернету инструмент превращается в тыкву, несмотря на то, что вы за него платите деньги, а те, кто тоже самое качают на торрентах таких проблем не имеют. Есть и другие подобные моменты, и у JB в этом плане подписки удобнее хотя бы тем, что не мешают работать.


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

                  +1

                  К слову, сам Unreal Engine бесплатный для освоения и изучения: расходы будут, только если от игры доход типа $3000. Было бы идеально, если бы с rider для UE было что-то аналогичное.
                  А то получается, что новички rider вряд ли себе купят — а потом привыкнут к какой-то другой среде разработки и останутся на ней.
                  P.s. Я сам пользуюсь продуктами jetbrains и после них очень некомфортно пользоваться visual studio, но я так же встречал людей, которые привыкли наоборот и их всё полностью устраивает.

                    +1

                    У нас действительно другая модель. Стоимость продукта существенно меньше, но она берется сразу, а не когда софт, написанный с его использованием начинает существенно зарабатывать. Хотя при этом у нас есть бесплатные лицензии для студентов и проектов с открытым кодом, а так же 50% скидка для стартапов.
                    Отчасти такая модель проще, потому что мы не Microsoft, например, чтобы контролировать кто и как использует наши программы и проверять, должны ли они уже платить или нет. И не Unity/Unreal Engine, которым гораздо проще контролировать как именно используется их же движок в играх на рынке. Но это, конечно, не единственная причина.
                    Более того, для некоторых случаев, мы в целом рассматривали возможность такой модели платежей. Но это пока только мысли и разговоры на тему, ничего конкретного.

                      0
                      Возможно получится договориться о сотрудничестве, и заложить стоимость разработки/поддержки Rider в комиссию, которую берут за выстрелившие проекты на UE.
                      Как минимум это может быть интересно в контексте популяризации распространения UE, чему и способствует такая комиссия.

                      Знаю, что продукты jetbrains стоят адекватных денег даже для пользователей РФ, и лицензия вполне удобная.
                      Но большинство пользователей UE — одиночки, любители, зачастую вообще без бюджета.

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

                      Возможно то, что Rider обойдет стороной любителей, и не сыграет никакой роли.
                      Мало кто из любителей выходит за границы блюпринтов, а до успешных проектов добираются единицы.
                      Комиссия UE просто позволяет попробовать себя в геймдеве каждому.

                      Неизвестно, будет ли готов UE поделиться частью комиссии или увеличить комиссию на пару процентов в случае если проект разработан на community версии Rider — в любом случае тут множество юридических тонкостей. И как минимум это усложнение модели лицензирования.
                      Возможно все это окажется сложно, или даже невозможно, разрешить, но конкретно с UE есть шанс такого варианта развития событий.
                –5
                ребята прекратите ломать с каждой версией триал ресет.
                  0

                  Каждая мажорная версия и так ресетит триал. В чем именно проблема?

                  0
                  del
                    +1
                    Спасибо что не забываете про поддержку всех трёх платформ. Надеюсь ваши усилия повлияют и на игровые студии.
                      +1

                      Сейчас кажется, что Epic Games тоже очень интересна кроссплатформенность. Так что мы с ними активно общаемся и надеемся, что Rider for Unreal Engine на основе uproject в качестве проектной модели появится уже до конца этого года.

                      0

                      Поддержка hlsl это очень крутая фича. Когда начал писать шейдеры, столкнулся с отсутствием нормальной ide. Поддержка unity cg будет или ограничитесь чистым hlsl?

                        0

                        Спасибо. Unity cg есть в планах. Вопрос лишь времени/приоритетов и наших ресурсов.

                        0
                        Rider — для геймдева. CLion — для нативной разработки. А что делать мне, если у меня хобби писать игровые движки (ну, или скорее сами игры без наличия каких-либо движков)?
                          +1

                          Тот же CLion. «Движок» в современном геймдеве это же не только рендеринг, но и набор инструментов (редактор ассетов, шейдеров, звуков и т.п.). Если хотите — пишите свои редакторы или подключайте внешние.

                            0

                            В целом, все так.


                            Еще добавлю, что в общем четкой границы все равно нет. Поддержка "языковых" фич UE4 может вполне появиться и в CLion, но вот заниматься интеграциями с Unreal Engine мы там вряд ли будет, чтобы не размывать фокус продукта.

                              +1

                              Спасибо. Немного оффтопик, но всё равно пожелание — делайте почаще акции со скидками, хотя бы для разработки pet-proejct’ты :). Я в своё время подсел на CLion, когда у вас были серьезные скидки. Теперь это моя любимая IDE для кросс-платформенной разработки.

                          +1

                          А установка Rider for Unreal Engine будет же опциональной? Если я хочу использовать Rider только для NET, оно же не будет устанавливать ненужные мне компоненты для C++ и Unreal Engine?

                            0

                            C++/UE4 будет плагином, включенным по умолчанию. Но мы постараемся сделать так, чтобы те, кто разрабатывает на .NET его никак не замечали и работе с .NET проектами он не мешал.

                            0

                            А я правильно понимаю, что раз планируются все платформы, то можно и на потдержку GLSL надеяться, или как там у UE с шейдеоами под Linux устроено?

                              0
                              Они транслируют шейдеры из HLSL в GLSL с помощью HLSLcc.
                                0

                                Мы вот в 2020.1 только-только сделали начальную поддержку HLSL и успели недавно обсудить, что GLSL тоже было бы хорошо. Но наверное, чуть-чуть попозже.

                                  0

                                  Очень рад это слышать. Есть где проголосовать за фичу, или это пока только на словах обсуждалось? ;)

                                    0

                                    Вот тут тикет в CLion, то есть в IntelliJ платформе — CPP-1536, а вот тут в ReSharper C++ / Rider — RSCPP-30242. Возможно, это будет одна имплементация, а может две разных, так как пока это два полностью различных языковых движка.

                                      +1

                                      Спасибо!


                                      За CPP-1536 я уже даже проголосовал когда-то, оказывается :)

                                        0

                                        Или просто в интерфейсе запутался и подумал, что голосую за RSCPP-30242, а проголосовал за CPP-1536 и только потом к ней перешёл :facepalm:

                                    0

                                    Так же надеюсь, что эта потдержка будет достатосно отчуждаемой, чтобы glsl можно было еще и с lwjgl под IDEA использовать. ;)

                                  0
                                  Я как С++ linux разработчик скажу, что очень не хватает нормального профайлера, у вас есть это в планах?
                                    +1

                                    А что не устраивает в Perf? Чтобы понимать, как сделать хорошо, было бы неплохо понять, что не устраивает в текущих решениях.

                                    0
                                    Как-то не очень обосновали зачем в Rider пихать два движка.
                                    Переключаться между, скажем, ридером и идеей — вообще проблем нет, хоткеи одинаковые и отлично. Я даже специально разные темы поставил чтобы подсознательно отличать где я нахожусь в данный момент. Соответственно, IntelliJ Unreal IDE был бы вполне не плох, зачем стесняться новый продукт добавить? Может проблема в том что слишком много лицензий придётся покупать? Но тогда можно было бы просто пак game-dev лицензий сделать.

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

                                      В смысле сделать отдельную IDE для Unreal Engine? Можно, но кажется еще +1 продукт как раз усложняет жизнь, а не облегачает. К тому же, многие гейм студии используют и Unity, и Unreal Engine, и они как раз очень просили "всё в одной IDE". А если нарезать по IDE на каждый игровой движок — это как-то много получится. Тем более, есть не очевидные случай — вот Godot, там смесь языков. Да и Unreal Engine не так прост. Там файлы сборки Build.cs и Target.cs вообще на C#, как и плагины к редактору (но это уже на любителя).

                                        –1
                                        1. Пользователю как раз всё равно — всё равно отдельные окна для разных проектов. Гейм-студии может быть удобно из-за лицензий?
                                        2. Да, по IDE на движок. Например. Джава обрастает джава-спецификой, спрингом и всей остальной дребеденью. Так и IDE для движков — у каждого что-то своё, какая-то своя специфика по связке с HLSL, свои тулзы, это всё будет добавлять сложности само по себе. А если смешать два движка вместе — это ещё большее усложнение. Т.е. я не уверен что вся сложность IDE идёт от этого самого ядра (язык, рефакторинги, итп). Основная сложность это ото всей вот этой мелочи, которая работает не совсем так как ожидается, которая постоянно меняется и её много, и которую IDE вынуждена склеивать.
                                        3. Ещё и годот в планах закинуть? А не развалится это всё на пол-пути? А ваши разработчики не сойдут с ума?
                                        Ну, это всё взгляд со стороны, может у вас там внутри всё сияет и красиво. Просто иногда бывает что заявлено что-то красивое и логичное, но разработчики потом просто не будут вытягивать. Или пользователи будут плеваться.
                                          0

                                          Чтобы не перегружать пользователя, мы просто кастомизируем IDE на лету, в зависимости от проекта. Так сейчас сделано для Unity — при открытии Unity проекта, все ненужное прячется подальше. Теоретически, там можно будет и для UE сделать.
                                          Gogot в целом уже как-то работает. У нас есть несколько отдельных людей, которые этому время уделяют, так как им самим интересно.

                                            0
                                            Просто чтобы уточнить. Я говорил исключительно про разработчиков IDE, не пользователей IDE.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое