Creating classes or structs that can be subclassed in Blueprint

While this book focuses on C++, when developing with Unreal, a more standard workflow is to implement core gameplay functionality as well as performance-critical code in C++, and expose those features to Blueprint to allow designers to prototype gameplay, which can then be refactored by programmers with additional Blueprint features, or pushed back down to the C++ layer.

One of the most common tasks, then, is to mark up our classes and structs in such a way that they are visible to the Blueprint system.

How to do it…

  1. Create a new Actor class using the editor wizard; call it BaseEnemy.
  2. Add the following UPROPERTY to the class:
    UPROPERTY()
FString WeaponName;
UPROPERTY()
int32 MaximumHealth;
  3. Add the following class specifier to the UCLASS macro:
    UCLASS(Blueprintable)
class UE4COOKBOOK_API ABaseEnemy : public AActor
  4. Open the editor and create a new blueprint class. Expand the list to show all classes and select our BaseEnemyclass as the parent.
    How to do it…
  5. Name the new Blueprint EnemyGoblin and open it in the Blueprint editor.
  6. Note that the UPROPERTY macro we created earlier still aren't there because we haven't yet included the appropriate markup for them to be visible to Blueprint.

How it works…

  1. The previous recipe demonstrated the use of BlueprintType as a class specifier. BlueprintType allows the type to be used as a type within the Blueprint editor (that is, it can be a variable or a function input/return value).
  2. However, we may want to create blueprints based on our type (using inheritance) rather than composition (placing an instance of our type inside an Actor, for example).
  3. This is why Epic provided Blueprintable as a class specifier. Blueprintable means a developer can mark a class as inheritable by the Blueprint classes.
  4. We have both BlueprintType and Blueprintable instead of a single combined specifier, because sometimes, you may only want partial functionality. For example, certain classes should be usable as variables, but performance reasons forbid creating them in Blueprint. In that instance, you would use BlueprintType rather than both specifiers.
  5. On the other hand, perhaps we want to use the Blueprint editor to create new subclasses, but we don't want to pass object instances around inside the Actor blueprints. It is recommended to use Blueprintable, but omit BlueprintType in this case.
  6. As before, neither Blueprintable or BlueprintType specifies anything about the member functions or member variables contained inside our class. We'll make those available in later recipes.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.119.138.123