Download

What is the correct approach?

I’m coming form a Unity background and would like some advice on how to approach a problem.

I’ve got a scene that will have 20-30 different static meshes, each representing a product - each product will have it’s own media associated, text, video , audio whatever.

I want it to set things up so that when one of those objects can be interacted with (on collision, mouse pick, whatever) the object gets some type of effect (similar to the glow here https://staticdelivery.nexusmods.com/mods/952/images/351-0-1439991292.jpg)

So my question is what is the preferred approach for accomplishing the above? Someone suggested I make a custom actor blueprint and just swap out static meshes, but the problem with that is if I want any of those meshes to have some additional behaviors I’m not quite sure how to add them. In the Unity world, everything is a component so it’s very easy to add and remove behaviors, but in Unreal it seems like inheritance is favored which makes it harder to apply to multiple behaviors. I’m very new to unreal so I imagine I’m not representing something correctly. Would it make more sense to tag all the objects that can glow and then have a blueprint that is responsible for querying those objects and applying the effects on events (a more functional approach)?

The second part of my question is what is the best way to handle the custom data that should be associated with each product? Is that something that should be taken care of at a component level?

I know there’s a lot here but I’m mostly looking for broad advice. Thanks in advance.

Inheritence would be the easiest solution imo.

For example:

  1. Create a new Actor Blueprint, call it InteractiveObject.
  2. In InteractiveObject, create a **Function **or Custom Event (“HighlightObject”) that takes an array of Static Mesh Components as an input, and loops through the array and turns on your glow effect (you’ll have to figure out how you want to do that part yourself, but I recommend the Outliner package on the marketplace, I bought it and I think it’s worth the money). The idea behind taking an array of static mesh components as an input instead of just one static mesh component is if some of your objects are made of multiple meshes, while others are made of just one. With an array you can handle both cases.
  3. In InteractiveObject, create the logic for when the object gets interacted with. This logic should call a custom event that you created (“ObjectInteractedWith”), but for now that event will not be plugged into anything because it will be overridden in the children.
  4. Create a new Blueprint that inherits from InteractiveObject, let’s call it InteractiveObject01.
  5. In InteractiveObject01, add as many static mesh components as you want and do whatever object-specific setup you want there.
  6. In InteractiveObject01, override the **ObjectInteractedWith **event that’s in the parent by right-clicking and searching for Event ObjectInteractedWith (whenever you see “Event” in front of a custom event name in the right-click menu, it means its an event that’s in the parent, otherwise it would just be the name of the event).
  7. In InteractiveObject01, connect the Event ObjectInteractedWith event to the HighlightObject function (you will not see parent functions in the list of functions on the left, you need to right-click and search for it to drop it in your graph).
  8. In InteractiveObject01, connect all the Static Mesh Components you have in your object to the **HighlightObject **function (you can use the Make Array node to create a temporary array from multiple objects).

Now if you drop InteractiveObject01 in the world and interact with it, it should highlight your objects correctly, and since the interaction and highlighting logic itself is in the parent, you don’t have to constantly re-create that logic in the children. And whatever extra behaviors you want in your objects, you can do in the children themselves.

Ok, that sounds totally reasonable, but why would I not put that functionality in a component rather than as an actor? Then I can add that component to all meshes I want to manipulate? If there is already a static mesh in my scene I’d need to place it with the blueprint version and then I’d need to attach the appropriate mesh and re-position it. With the component approach I can just add the functionality to an already existing Static mesh. What would be the downside to that approach?

You can’t, that’s the downside. UE4 is both inheritance and components, but you need the right thing at the top, which in your case is probably a Blueprint extending Actor.

You can make a component with your behavior and then add that component to an ActorBlueprint, or put the behavior directly on the Blueprint which is probably simpler. The ActorBlueprint can then also have a static Mesh component, which different instances of can have a different actual mesh.

Components in UE4 are meant to be part of Blueprints, not “attached” to actors out in the world. The Static Meshes in your scene should just be Blueprints that have a Static Mesh Component in them.

You could encapsulate the highlighting functionality in a Blueprint Component that you then add to your Blueprint, but as mikepurvis said it’s not really more simple. I didn’t suggest it because you should learn to use the inheritance structure of UE4 before digging into BP components in my opinion.

JParent - That’s cool, I want to do things the “Unreal way” so if inheritance is how to do that, no problem. It just feels a little bit limiting, I’d think that composition would be favored over inheritance but I guess Epic has their reason for this design decision.

If I were to do what you’re proposing myself, I would probably use Components and make it automatically get the mesh components from its owner, so that its basically all automatic. But I suggested the inheritance solution because if you’re just starting with UE4, you need to learn that part because a lot of what you will do will be inheritance-based. However once you’re comfortable with that, definitely look into Blueprint and C++ Components. They’re fairly new in the engine but they’re very useful for modular functionality.

Can someone fill me on on why Unreal would have an inheritance approach vs composition?

Let say I want to make an it ‘Glowable’ So I create a Blueprint for my Actors I want that feature.
Then If I want it to be “Throwable” & “Glowable” I need to create a new blueprint which inherits from ‘Glowable’ and add my ‘Throwable’ code/blueprint stuff in there.
Well If I want a new object that is ‘Eddible’ and ‘Throwable’ but not ‘Glowable’ I need to go back to my ‘Glowable’ blueprint stuff and make a boolean to toggle it on and off- there is a dependency that ‘Throwable’ requires ‘Glowable’

The complexity increases as you want to add many additional behaviors. It seems like using the ‘Component’ architecture already built into ‘Actors’ would be the way to go but I don’t want to do things that way just cause I think it’s correct. There are a lot of people smarter than me working at Epic so I’d like to get a better understanding of the motivations.

You could just have the Glowable, Throwable and Edible logic all in one parent/base class, and turn them on or off with boolean parameters that all of the children of that parent will have.

The component approach can work too but it’s not the easiest or most efficient way of doing everything.

Jparent - what you described creates an undesirable situation. What does glowable have to do with throwable? Nothing, so they should not be together in the same class - I’m thinking from the perspective of the ‘Single Responsibility Principle’

If you’re planning on having vastly different things being throwable/glowable/edible, then yes, but that is not a common situation in most games. Usually all your pickupable objects would inherit from the same class and have common behavior, with specific behavior implemented in the children.

The scene you described in your original post does not seem like it would benefit much from a component based approach versus an inheritance one.

You are correct that my original scene is not that complicated but lets say I create functionality that I would like to port to another application, it would be a lot easier if I could separate responsibilities.