Get best of the week

JetBrains Rider - Ahora para Unreal Engine

Hola habr

La semana pasada, después del lanzamiento de la versión 2020.1, ocurrió otro evento importante para todos nuestros productos de escritorio: abrimos el acceso público a la versión de prueba de Rider para Unreal Engine . Por el momento, este es un producto separado, una versión de nuestro entorno de desarrollo para Rider, pero con soporte para C ++ y Unreal Engine. ¡Así que para! Entorno de desarrollo C ++. ¡¿Uno mas?! Vamos a resolverlo en orden.

Jinete para motor irreal



Comencemos con una pequeña historia. Hace unos años, reunimos a todos los que fabrican herramientas C ++ en JetBrains para analizar lo difícil que es para los usuarios navegar por la variedad de nuestras ofertas. Después de todo, hay CLion, ReSharper C ++ y soporte para C ++ en AppCode. Después de varias horas de discusión, llegamos a las siguientes conclusiones:

  • Aunque la herramienta universal parece atractiva, con la expansión de la focalización, el aumento en el número de herramientas de terceros integradas, casos de uso compatibles, se hace muy difícil encontrar un equilibrio entre la conveniencia, la interfaz intuitiva y muchas características.
  • El mundo del desarrollo de software no ha tenido límites claros en los lenguajes de desarrollo. Muchos proyectos son multilingües. Más importante es el alcance del software y las tecnologías que se utilizan en él.

Como resultado, decidimos unificar la experiencia del usuario en nuestras herramientas para C ++, pero acordamos que el enfoque para hacer diferentes herramientas (aunque con un núcleo común o en una plataforma común) para diferentes áreas de desarrollo de software es la correcta. En la práctica, se ve así:

  • 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- .

Entonces, ¿qué tiene que ver el Jinete con él? ¿Cuál es el entorno de desarrollo multiplataforma para .NET relacionado con C ++? En la práctica, alrededor del 30% de los usuarios de Rider son estudios de juegos y compañías de desarrollo de juegos. Es comprensible, porque Rider es en gran parte popular precisamente como un entorno de desarrollo para Unity . Este no es el primer año en que el equipo de Rider ha personalizado un instrumento específicamente para este motor de juego. El resultado es del agrado no solo de los programadores de Unity, sino también de las propias Tecnologías de Unity, con quienes hemos interactuado durante mucho tiempo y fructíferamente en términos de la tecnología misma.

Dirigiéndonos a muchos de nuestros usuarios en el campo del desarrollo de juegos, notamos que muchos estudios no tienen una separación clara: crea juegos solo en Unity o solo en Unreal Engine. Hoy juegan con una tecnología, y mañana con otra, o un equipo usa el Unreal Engine y la otra Unity, o incluso su propio motor personalizado. Está claro que a los desarrolladores y las empresas en general realmente no les gusta "saltar" entre diferentes entornos de desarrollo. Y aquí decidimos que si podíamos hacer que Rider fuera exitoso para Unity, podríamos ir más allá y hacerlo exitoso en general para el mundo del desarrollo de juegos. Entonces, la idea de Rider nació como un entorno de desarrollo universal para Game Dev .

En qué consiste Rider para Unreal Engine


El desarrollo adicional de los eventos es bastante obvio para aquellos que están familiarizados con la tecnología en la que se basa el Rider. Rider consta de una parte de front-end basada en la plataforma IntelliJ y una parte de back-end basada en ReSharper. Todo el soporte de idiomas funciona en el back-end. Por lo tanto, acabamos de conectar el soporte existente de C ++ y Unreal Engine en ReSharper C ++ a Rider usando la misma tecnología. Desde lo específico, tuve que implementar adicionalmente:

  • Complemento para seleccionar Rider como entorno de desarrollo en Unreal Editor ( Rider Source Code Access ) para las versiones del motor 4.22-4.24. A partir de la versión 4.25, esta funcionalidad ya estará incluida en el propio motor de UE.
  • Los complementos de UnrealLink para Rider y RiderLink para Unreal Editor, que proporcionan integración con Blueprints en Rider y generalmente son responsables de la comunicación entre Rider y Unreal Editor.
  • Depurador

Vale la pena señalar que ahora la vista previa de Rider para Unreal Engine está disponible solo en Windows, abre archivos .sln y se basa en la compilación del compilador de Microsoft. En el futuro, en el momento del lanzamiento, intentaremos expandirnos a las tres plataformas e implementar soporte para .uproject como el modelo de diseño principal.

Depurador basado en LLDB


Una parte importante del desarrollo del juego está sucediendo ahora en la plataforma Windows y como parte de la cadena de herramientas de Microsoft. Si observamos qué herramientas de depuración existen para el código compilado usando el compilador Microsoft Visual C ++, veremos:

  1. Microsoft usa herramientas de depuración basadas en vsdebugeng.dll en sus propias herramientas . La licencia no permite el uso de estas herramientas en entornos de desarrollo de terceros.
  2. CDB WinDbg dbgeng.dll. MS . (.pdb), , , .
  3. También hubo desarrollos en la comunidad LLVM para el soporte de depuración de la cadena de herramientas de Visual Studio usando LLDB. Los usamos, y solo año y medio escribimos la primera versión de un depurador que generalmente funciona. Incluye soporte inicial y aún sin procesar para el formato NatVis (tales impresoras bonitas específicas de MS). Al mismo tiempo, Rider para Unreal Engine ahora encuentra NatVis en el proyecto en Unreal Engine y los carga en el depurador. Ahora estamos usando el mismo depurador en CLion para la cadena de herramientas de Visual Studio (está habilitado de forma predeterminada en este caso a partir de la versión 2020.1).

El nuevo depurador todavía está húmedo, por supuesto, todavía tiene problemas significativos y ralentizaciones. Pero esperamos traerlo a la mente para su lanzamiento.

Soporte C ++


Repito: toda la funcionalidad de soporte de idiomas de ReSharper C ++ ahora está disponible en Rider para Unreal Engine Preview. Incluye:

  • Alrededor de 170 inspecciones de códigos diferentes y más de 50 soluciones rápidas.
  • Refactores que tienen en cuenta todos los usos contextuales de un símbolo (renombrar, cambiar la firma del método, eliminar el método, agregar un campo / variable / typedef, sustituir (en línea) una variable o typedef, y otros).
  • Generación de código (métodos getters / setters, constructores, operadores de comparación, plantillas de documentación de código).
  • Acciones para ayudar a escribir código, navegación, formateo y soporte para nombrar estilos, ordenar #includedirectivas.

Generar acción

Compatibilidad con dialectos HLSL, C #, uproject / uplugin


Este año, comenzamos a trabajar en el soporte de idiomas para escribir sombreadores HLSL en ReSharper C ++ , e inmediatamente entró en la versión preliminar de Rider para Unreal Engine. El soporte incluye resaltado de sintaxis, información sobre herramientas con documentación, información sobre herramientas para nombres y tipos de parámetros, acciones de navegación, autocompletado, soporte para rutas de archivos virtuales e incluso refactorización.

Dado que Rider para Unreal Engine se basa en el entorno de desarrollo para .NET, el soporte de idiomas funciona en los archivos Build.cs y Target.cs.

Y, por último, cuando se trata de admitir dialectos de idiomas, Rider para Unreal Engine comprende los dialectos de los archivos .uproject / .uplugin, brindando opciones de autocompletado y herramientas de documentación.

dialecto uproject

Integración de planos


Los archivos de planos son datos binarios que generalmente se editan en un editor visual dentro del Editor irreal. Los objetos en estos archivos se heredan de las clases en C ++; redefinen las propiedades de la parte C ++ del juego. Y aquí Rider para Unreal Engine es ese entorno de desarrollo único que lee todos los archivos Blueprints necesarios y muestra estos enlaces en el editor de código C ++:

Clases derivadas de BP

si cambia, por ejemplo, el valor de la propiedad en el editor de Unreal Engine y guarda el activo, entonces el valor aquí también se actualizará automáticamente en Rider (tenemos observadores colgados para cambiar los archivos de activos):

Propiedades de BP

sin guardar los archivos, esperamos que esto también funcione pronto (la preparación para esto ahora se está haciendo en el complemento UnrealLink).

La llamada Buscar usos incluye no solo usos en código C ++, sino también archivos Blueprints. Al hacer doble clic en dichos usos, se abre el Editor irreal.

Comprender el mecanismo de reflexión de UE4


Reflection in Unreal Engine se implementa utilizando macros especiales (UCLASS, UFUNCTION, UPROPERTY, etc.). Rider sabe que los parámetros de tales macros no son solo texto. El analizador de C ++ en ReSharper C ++ y Rider realmente puede "comprender" el significado de estas macros sin siquiera iniciar la herramienta de compilación Unreal Header Build (es decir, antes de que se genere realmente el contenido de los archivos .generated.h ).

Por cierto, hablando de archivos .generated.h , ReSharper C ++ y Rider saben que las directivas #include que faltan automáticamente se deben insertar estrictamente antes de conectar archivos .generated.h . Y también tenga en cuenta estos archivos generados al cambiar el nombre de la refactorización.

Volviendo al mecanismo de reflexión, vale la pena decir que los especificadores de reflexión no son solo texto en ReSharper C ++ y Rider. Hay sugerencias de autocompletado y documentación para ellos: las

Documento de reflexión

sugerencias de documentación también están disponibles para las macros de reflexión.

Y el analizador de código verifica el uso de macros de reflexión e indica los errores asociados con esto. Por ejemplo:

  • Las clases UCLASS deben heredarse públicamente de UObject o cualquiera de sus clases descendientes. Además, tal padre debe ser exactamente uno.
  • Los especificadores UCLASS deben usarse para clases, USTRUCT para estructuras.
  • Las clases UE4 no pueden declararse dentro de otras clases.
  • Los objetos almacenados en campos no marcados como UPROPERTY pueden ser recolectados en cualquier momento por el recolector de basura.

Soporte de llamada a procedimiento remoto (RPC) para acciones de navegación y generación de código


Si consideramos las llamadas a procedimientos remotos desde el punto de vista de un analizador de C ++ normal, notará rápidamente la ignorancia del analizador de que varias funciones con diferentes nombres (por ejemplo, sufijos _Validatey _Implementation) pueden corresponder a una declaración de función . En ReSharper C ++ / Rider, hemos formado un programa de análisis para identificar RPC a través de especificadores Client, Servery NetMulticasten los valores de la macro UFUNCTION. De este modo:

  • La navegación ofrece todas las opciones necesarias para implementar la función.
  • La generación de código puede crear funciones con sufijos _Validatey / _Implementationo solo aquellos que faltan:
    Generación RPC
  • Las refactorizaciones de código Rename and Change Signature actualizarán todas las funciones necesarias y, por lo tanto, mantendrán su código en el estado correcto.

Conocimiento de las reglas de nomenclatura de Unreal Engine 4


ReSharper C ++ y Rider conocen las reglas oficiales de nombres en el código de Unreal Engine. El entorno de desarrollo utiliza estas reglas en todas las acciones para trabajar con código, como generar captadores y definidores o refactorizar una variable (Introducir variable). Y lo más importante, hay una comprobación del código de inspecciones de nomenclatura UE4 inconsistentes y una solución rápida correspondiente que hará que Rename refactorice y cambie el nombre de todos los usos del nombre que no cumplan con las reglas.

Rendimiento del editor


Hemos estado haciendo soporte de desarrollo para Unreal Engine en ReSharper C ++ durante bastante tiempo y, por supuesto, vemos que el rendimiento del editor es la principal queja. Debido a su arquitectura, Rider está libre de muchos problemas de rendimiento que están presentes en ReSharper (están en parte debido a limitaciones de estudio en procesos de 32 bits, dentro de los cuales funciona ReSharper, pero no solo).

Además, ajustamos específicamente el IDE para mejorar el rendimiento en Unreal Engine. Primero indexamos el código del juego del usuario, incluyendo instantáneamente todas las acciones inteligentes del editor en el código del usuario. Y la indexación del código del motor en sí ocurre después de eso en segundo plano. Hay varias opciones adicionales para administrar la indexación:

Opciones de desempeño

¡Como resultado, aquellos que ya comenzaron a usar Rider para Unreal Engine responden muy positivamente sobre el rendimiento del editor! Y estamos seguros de que podemos hacerlo aún mejor.

Video de demostración y una vez más sobre cómo acceder


Estas y muchas otras características se pueden ver en acción en un video de demostración (en inglés) de nuestro abogado desarrollador:


Y para probar estas características usted mismo, simplemente complete un formulario simple y reciba una carta de nosotros con un enlace a la creación y activación de una licencia gratuita para una vista previa anticipada. Ir, completar , probar, escribir comentarios! Para sus comentarios, como siempre, hay comentarios aquí, un rastreador ( ReSharper C ++ y Rider ) y nuestro correo de soporte ( rider-cpp-support@jetbrains.com ).

¡Gracias por la atención!

Jinete
El impulso para desarrollar equipo

More articles:


All Articles