I’m a few months into a real project using #UE4, and where I put code (C++ or Blueprints) has evolved a fair bit. In short, I’m doing far more C++ than I thought I’d be happy with, and my use of BP is now more down to the subject matter than the workflow. Here’s why: 1/x

The first reason is simply that I’m getting used to C++ again. After using more friendly / tolerant languages, going back to a product of the 90s is painful at first. But as with everything kinda bad that you have to use, you get used to it & start to think it’s OK maybe? 2/x

More importantly, I’ve arrived at a workflow I’m happy with. Hot Reload is out (too unpredictable), Live Coding for small change + restarting the editor is in. I’d got so used to in-editor reload in Unity, restarting the editor seemed like a major step backward at first, but 3/x

Firstly, the UE4 editor loads much faster than Unity, no doubt due to no asset import time. Second, you can reduce that time just by skipping the project dialog (just make a shortcut including the project file, or run from IDE). Launch-to-ready in our current project is ~7s 4/x

When I just have to do small C++ bugfixes (cpp files only), Live Coding is fast. When I know I have to make header changes, I close the editor before I do it, edit, build & start the editor again. It’s more hassle than Unity but once you’re used to it it doesn’t feel slow 5/x

This means BPs have less of an obvious workflow benefit than they used to. It’s not zero; BP changes are noticeably faster & convenient. But the C++ benefits - easier diffs, better undo, more control, *some* performance (depends on task) - are on the other side of the scale. 6/x

So now, I write core “obviously programmy” things in C++ first. Game mechanics that aren’t in dispute (beyond data tweaks). Everything in GameMode / GameState, subsystems, some of PlayerController, all the essential scaffold. Some things move there from BP if they become core 7/x

I use Blueprints for:

1. Orchestration. High level behaviour, sequencing, especially with delays or other single-use async behaviour
2. Tests. I wrote my own system for testing game rules in-level and drive it via BP, because it’s mostly orchestration

8/x

3. Experiments: things that straddle any part of the game are faster to try out in BP, because I don’t know where they fit yet, & they may not pan out so creating C++ classes could be a waste of time. I’ll refactor if it works with the lower levels maybe becoming C++ 9/x

4. Covered under 1 but worth explicitly mentioning - anything I’d want a non-programmer to be able to experiment with is BP. We’re not doing this much yet, but Marie’s tinkered with node graphs before and has fiddled with my BP tests a bit, I want to leave this door open 10/x

I’m aware this is how larger teams work with UE, we just happen to have compressed the roles. The key has been to find a way to make C++ dev workflow-efficient where it makes sense, and I’m glad we’re there now. When I started I thought I’d have to do more in BP for sanity 11/x

In months 1&2 I was writing ~80% Blueprints, with C++ mostly there for future expansion. Now it’s more like 40% BPs and I’m getting more consistent. Remembering *where* you put code can be challenging until you’ve normalised your style I’m feeling increasingly productive /end