Límites realistas para mover proyectos de Blueprint a C++

Los artículos escritos en este blog fueron creados con el objetivo de enseñar. Además, la información del artículo puede ser incorrecta, así que tenga cuidado.

Al mover un proyecto Blueprint a C++, todos.uassetEs fácil fijar el objetivo de eliminar. Sin embargo, el costo de mover la lógica del juego y el diseño de la interfaz de usuario es diferente.

Partes que son buenas para pasar a C++

• Guardar y cargar reglas
• Verificación de combate y movimiento.
• Procesamiento de datos y funciones comunes.
• Conexión delegada
• Clases de subsistema y marco.
• Lógica copiada de múltiples planos.

En ProjectDT, los efectos secundarios se realizan después de procesar la respuesta correcta.UDTUISubsystem::ProcessSolvedProblem()coleccionado. En ProjectTB, las funciones de C++ son responsables de la compra, instalación y verificación de implementación.

Es mejor dejar las piezas en manos de WBP

• Diseño de árbol de widgets
• Tamaños y colores frecuentemente cambiados por los diseñadores.
• Widget Animation
• Activos de expresión como imágenes y fuentes.
• Elementos visuales colocados en el nivel.

Para transferir esta parte a C++WidgetTreeDebe escribirlo como código o escribir Slate. Es posible, pero la velocidad de modificación y la viabilidad del diseñador variarán mucho.

Organizar carpetas públicas y privadas.

ProjectDT crea un encabezado para exponerlo al exterior.Public, implementar cppPrivatetrasladado a

Source/ProjectDT/
├─ Public/
│  ├─ System/
│  └─ Investigate/
└─ Private/
   ├─ System/
   └─ Investigate/

Si solo los contratos que se utilizarán fuera del módulo se colocan en Público, la relación de inclusión se vuelve clara. No es necesario mantener el encabezado para la implementación interna en Público.

Pasar de Blueprint a C++ no es todo o nada. El límite de las reglas y estados que se recopilan en C++ y WBP y se mantienen como un shell de diseño es realista para la mayoría de los proyectos.