Multiple blueprints per actor? (composition vs inheritance)

I just now realized something. We can only have one blueprint per actor.

I knew something was bothering me but I was having fun learning blueprints so it didn’t strike me.

Let me give you some background, I have been a game programmer for a LONG time. Back when we were working on Worms, we had a hell of a time thinking of how to structure the various weapons because the code ended up heavily inheritance based and quite often ended up where lots of functionality was pushed up the inheritance tree as we needed it in various use cases. This in the end was pretty bad and not very maintainable. When I left Team17 I looked for another way of structuring game code and started thinking about compartmentalization and eventually composition. I came up with a component system for my own game engine I was working on as an indie, having many conversations with other people who were doing the same kind of thing.

Fast forward a few years and I evaluate Unity and lo and behold it uses a composition based approach with components in almost an exact replica I’d been using. Only with the added benefit of live reload. It is VERY productive to use composition because you can code narrow scope features and then composite more complex behavior by simply adding/removing components. You tie components together by either delegates/events/message (better for interop) or via reference (better for performance).

Now when I first started looking at Unreal a few weeks back, I saw the “components” part and felt a bit relieved. Maybe Epic were thinking of this inheritance vs composition thing too? Only… “components” in Unreal engine are kind of half-baked right now. Sure you can composite an actor using multiple components and meshes and the like. But currently you cannot have multiple blueprints (afaik at least). Or at least you aren’t encouraged to think that way. Right now if you try and implement multiple graphs in the blueprint editor, only one graph can have the tick event for example.

My point is, I guess, that Unreal has some really nice architecture, but in many ways it has a lot of the throwback to inheritance-based code that gives me shivers these days. I don’t suppose it matters to many people who haven’t been through the pain of inheritance based game development, but it really gets to the heart of game engine architecture. Inheritance tends to make it harder to architect things where there are many similar things with minor changes to them, which is pretty much the exact use case for games.

Not that I am saying you can’t use inheritance, just that inheritance I’ve found through bitter experience isn’t the best way to architect a lot of games. I was happy in that Unity had seen the light about that, hopefully a few people here who were using Unity saw that part as useful too.

Anyway, just wanted to post this as an observation really. I’m not a zealot when it comes to these things. Just struck me as strange that I hadn’t noticed it, it was really just as I started to make a larger blueprint graph that it struck me. Blueprints I think for me personally are going to be really hard to structure and follow, so I’ll probably prototype in blueprint and then recode them in C++ when I feel I’ve gotten to the point where they are unmanageable (just at that point with my stealth character controller).

What I’d actually like to see, is a blueprint “component” that would essentially have its own set of graphs. So multiple blueprint components being allowed per actor, rather than one. That way you could have a blueprint for movement, one for AI control, one for physics handling etc. Use delegates to tie them together. It would change the editor somewhat in that an actor would then be slightly more composition based, but It seems reasonably do-able.

I feel pretty much the same way, did you ever figure out a workflow that satisfied you?

Not as yet no. I asked a question on one of the livestreams about multiple blueprints and basically they aren’t supported but there is a sort of semi-workaround by having multiple actorcomponents each with their own blueprint. Apparently there’s also another way but I can’t recall the details and it sounded even more hacky.

My intention when I get some free time, is to mess around with a new fork and see if I can implement a blueprintcomponent, but of course that will require a few editor changes (so that there’s no hard-coded reliance on an actor having any blueprints at all, or maybe just require a default blueprintcomponent per actor or some such).

Interestingly its on the roadmap to look at componentization but as most people wouldn’t have a clue what a component actually is, its naturally lower priority than some “make game now” button :slight_smile:

So I’ll probably do it for my own sanity, but I wouldn’t hold your breath for an official solution. Which is actually the best reason for having the source code. Imagine being in this position with Unity? :slight_smile:

When in the blueprint menu, you have the option to make and name a graph. Have you looked into that at all?
While it’s not a totally new blueprint it is a clean slate to work on that you can tag accordingly.

Yeah, I tried that. But you can’t have an event tick for that new graph. So there’s no way to do composition-based behaviors generally with that approach (its what I first thought of too).

When I first started using UE4, I had a quick try at getting blueprint components working, but didn’t spend much time on it or get far at all. However I would really like to see that in the future. At the moment I am mainly using the child actor component method, but as you said it is far from idea.

I have also thought about using the behavior tree task as a quicker way of being able to create blueprint components. At the moment I have tried using the standard Behavior tree component. Basically creating a Actor class that has a behavior Tree component and then basing all my actors on that. In the Actor’s blueprint I create a editable Array of Behavior Trees. Then created a set of behavior trees each with normally only a single Task, that are my “components”. Then assigned the ones that I want to each actor, and select what tree would be active at what time. But of course this only allows one “component” to be active at a time, although for some of my requirements that is all I need.

I haven’t tried adding multiple behavior tree components to a actor yet and it might work, however by looking at the code for that component and the blackboard one, there is some code in each that tries to fetch either the blackboard or behavior tree component from it’s parent actor and only expects there to be one component of each type. So I don’t have a lot of faith that multiple components will work properly.

However I wouldn’t think it would be too hard to create a custom component that doesn’t have that restriction. My idea at the moment is to maybe write such a component that instead of using a full behavior tree, just accepts a Behavior tree task assigned to it, and just runs that single task all the time. Of course all this is hacky still, and proper Blueprint components would be far better.

On a side note, if you want a tick event in more than one event graph, you can copy the tick event from the main event graph and paste it into another one. Doing so will create a new custom event called something like “Tick event copy”, you then need to call this event from the main tick event. So it is also hacky but might do what you want.

We do intend to fully support creating your own components via blueprints by extending off of Actor Component or Scene Component. My understanding is some of the teams that were source licensees before we released UE4 to everyone, are doing this already. I’m not sure what issues they may have fixed or worked around, but we haven’t had the time to go through and fully test and figure out any issues that come from it to confidently turn it on. If you wanted to try it out yourself now you could go ahead and mark UActorComponent as Blueprintable and see where you get from there.

That is basically what I did in my quick attempts, but most of the time I just ended up crashing the editor.

It doesn’t really make a lot of sense to use either scene or actor for blueprint components though does it? I mean a blueprint is essentially a script instance. Which would suggest that an actor should simply have a container of script instances that are ticked per-actor. enabled scripts are ticked, disabled ones not. I don’t think they should require anything like a transform (scene component or actor) because they potentially are just logic or code. Whats the reasoning behind requiring them to have a transform exactly?

Just adding my vote because I believe this is incredibly important. Composition is a far superior technique to inheritance for constructing behaviors which is what gameplay coding and scripting is largely all about.

This is not really a question of inheritance vs. composition such that one must clearly win to the exclusion of the other. Inheritance is a tool that is useful and necessary in many design patterns. However, it is not the only tool that should be in the tool box, and it should not be overused or misused, especially in contexts where another tool like composition would be more appropriate.

I love that Unreal already has a significant amount of code that deals with gameplay specifics, and much of this code is inheritance based, which is fine, as it is essentially an API from our perspective as game developers, but in our own game code and scripts, we should be able to compose more complex behaviors from discrete, independent behaviors which are loosely coupled as the OP has described, and both the UE4 editor and Blueprint system should have first-class support for this pattern and methodology.

If you agree, please add your vote to the Trello card related to this feature: Trello

… Any news on this?

This has been done a while ago. You can create a reusable component. Just like unity script components, albeit a bit different in the way it is done. Also I forget if it is the scene or actor component, but one of those can be used as just a code component.