Realistic boundaries for moving Blueprint projects to C++

The articles written on this blog were created with the goal of teaching. Also, the information in the article may be incorrect, so please be careful.

When moving a Blueprint project to C++, all.uassetIt is easy to set the goal of eliminating . However, the cost of moving game logic and UI layout is different.

Parts that are good to move to C++

• Save and Load Rules
• Combat and movement verification
• Data processing and common functions
• Delegate connection
• Subsystem and framework classes
• Logic copied from multiple Blueprints

In ProjectDT, side effects are performed after processing the correct answer.UDTUISubsystem::ProcessSolvedProblem()collected. In ProjectTB, C++ functions are responsible for purchasing, installation, and deployment verification.

Parts better left to WBP

• Widget Tree Layout
• Sizes and colors frequently changed by designers
• Widget Animation
• Expression assets such as images and fonts
• Visual elements placed in the level

To transfer this part to C++WidgetTreeYou need to write it as code or write Slate. It is possible, but the speed of modification and designer workability will vary greatly.

Organize public and private folders

ProjectDT creates a header to be exposed to the outside.Public, implement cppPrivaterelocated to

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

If only contracts to be used outside the module are placed in Public, the Include relationship becomes clear. There is no need to keep the header for internal implementation in Public.

Moving from Blueprint to C++ is not all or nothing. The boundary of rules and states being collected in C++ and WBP maintained as a design shell is realistic for most projects.