When creating a Blueprint, you need to decide what its responsibilities will be. This refers to what it will do and what it will not do. You need to make the Blueprint as independent as possible. A Blueprint must be responsible for its internal state.

To illustrate the concept of Blueprint responsibilities, let's work with a simple example created for teaching purposes. In a game, the player is represented by the FirstPersonCharacter Blueprint. If the player collides with an Enemy Blueprint, then the player will die and an explosion effect will be spawned. The following screenshot shows the Event Hit that was implemented in the Enemy Blueprint:

Next, you create another Blueprint that can also kill the player. So, you copy Event Hit and the nodes of the previous screenshot and paste them in the new Blueprint. Then, you create another different type of Enemy Blueprint and copy and paste Event Hit again. But, you decide to change the way the player dies. The player does not explode anymore, but a death animation is executed. However, to make this change in your game, you will have to search for all Blueprints that can kill the player and modify the script of all of them. This is a problem because you might forget one of the Blueprints, and the script may have frequent changes.

There is a way to avoid this type of problem. The script that defines how player deaths work must be implemented in the player Blueprint, which, in this example, is the FirstPersonCharacter Blueprint. The point is that the player Blueprint is responsible for the way the player dies. Let's redo our example, but now, we will create a custom Event named Death in the FirstPersonCharacter Blueprint, as shown in this screenshot:

This way, if there are changes in the way the player dies, then these changes will need to be done only in the Death Event of the FirstPersonCharacter Blueprint.

When a collision occurs, the other Blueprints that can kill the player will just have to trigger the Death Event of the FirstPersonCharacter Blueprint. The following screenshot shows the new version of Event Hit of the Enemy Blueprint:

So, you can use Events and Functions to define how a Blueprint can communicate with other Blueprints. And if you need to send data between Blueprints, then it can be sent through input parameters.

Another topic related to Blueprint responsibilities is Level Blueprint. Each Level has its Level Blueprint, so if you create your game rules logic inside a Level Blueprint, then when you add another Level, you will need to copy and paste all Blueprint nodes to the Level Blueprint of the new Level. If your game rules logic changes, then you will need to modify all the Level Blueprints, and this can become a maintenance nightmare.

A Level Blueprint must be used only for logic and situations specific to one Level. A typical example is to put a hidden trigger on a Level. When the player overlaps it, an enemy is spawned in another room.

A better place to implement game rules logic is in a GameMode Blueprint class. The logic for other Actors should be implemented in Blueprint classes rather than being implemented in the Level Blueprint because instances of a Blueprint class can be added to any Level, so you do not need to copy and paste Blueprint nodes to use the same functionality in another Level.