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.
