[=;17480]
I’m not sure exactly what you mean by dependencies in terms of Blueprints. Blueprints in C++ are just normal UObject classes that have some meta data via UPROPERTY and UFUNCTION macros that make blueprints aware of them so the engine can instantiate and connect them together. Any dependencies you have should only be your direct parent class.
You should be able to place any common code you want to reuse in non-blueprint cases in a simple class of your own that is called from your Blueprint class and your non Blueprint class (i.e. a class that has no blueprintcallable properties and functions).
Maybe I’m not understanding the complete picture?
[/]
Im not sure this is still a work in progress as I go through the prototype and port functionality I already have from UScript so I might have overlooked something. Ive been told to treat Blueprints as classes not objects but perhaps that advice was alittle misleading, Im not entirely sure. To call a blueprint as a UClass and that blueprint has to exist first for the code to compile, unless theres something more generic Im overlooking. I do think you have simplified alittle bit, the issue being like so:
Core C++ Classes -> Core Blueprints -> Extended Blueprints
Core C++ Classes -> Core Blueprints -> Extended C++ Classes -> Extended Blueprints
As you can see the extended c++ classes now rely on Blueprint Classes.
Core C++ Classes -> Extended C++ Classes /-> Core Blueprints
This breaks links to Core Blueprints.
Core C++ Classes -> Core Blueprints -> Extended Blueprints
Core C++ Classes -> Extended C++ Classes -> Extended Blueprints
This works but will take more management and might break merges more often when classes are created and blueprints shifted around.
[=;17538]
This is a great point, that an interop layer must necessarily be present at the interface between code and sufficiently powerful visual tools. The layer enabling C++ programmers to expose features to Blueprint layers is one example. Another example is the visual material system, where code generated for shader nodes is essentially strcat’d together behind the scenes into a shader program that is sent to DirectX or OpenGL for realtime execution on the GPU.
The big question for engine developers is whether to utilize different programming languages for different parts of the programming pipeline, introducing an interop layer where they are partitioned.
BTW: It’s fine to compare to Unity and other engines here. Each engine arrived at a very different solution to gameplay programming, and comparing their decisions is a valuable exercise that increases 's understanding of the tradeoffs.
[/]
Okay I just thought the conversation was drifting alittle far, Im certainly not against comparisons but I do come here to talk about Unreal Engine primarily for obvious reasons 
That is interesting, I have used the display source for materials so I knew it was alittle bit different to Blueprints but I had not realized it was actually working with the raw text kinda like macros. From how I see it though the visual scripting tools are a good reason to leave the real nitty gritty programming in C++, Ive seen tools come from DOS all the way through Windows to where they are now and game designers never have been so lucky as they are now with the amount of tools and the magnitude of the quality, not only that but there are really cohesive suites now compared to the past where the tools were nothing more than a gloried level design tool.
I think the additions people will make to this refound solid base is a great reason to choose C++, Im sure it certainly helped with the source release too not having to deal with a scripting language that is essentially obsoleted with C++ access. Blueprint on the other hand has enough going for it that its worth using in places instead of text based programming and in alot of ways its easier and more straight forward than UScript, its certainly not perfect as the spaghetti monster always looms but it can be just as hard to trace code even in C++ if its written poorly enough so hopefully we’ll see more people adopting good practices brought over from the school of C++.
I can certainly see UE4 having quite the longevity, thats important for me when committing to learn a toolset and part of the reason Im not sure about taking my 3dsmax knowledge any further is because of the uncertainty behind whether Autodesk will entirely shift focus to a more cohesive linear pipeline and product line at some stage. I know UE4 will change but I trust Epic to filter down changes in the best possible manner, Ive been working on monthly UDK releases for some time now so Im used to seeing changes and additions pop up at that rate. Ive always known we use what you guys use first, anything ontop of that tends to be gravy and there is a shift in focus to taking more input from the community but I always expected C++ to be the supported language because as long as Ive known its what Epic has been using. Im not sure if the fact Unreal Engine is a virtual machine has anything to do with it either, that it needs a more portable language to make it worth while.
For me though when we talk about gameplay programming, I cant help but see the future as a syntax independent mathematical modeled visual scripting tool which learns how its users work and adapts to that and gives them the best possible speed by staying as close to bare metal as it can. As much as people might disagree with me WYSIWYG is an extremely big thing in visualizing not just gameflow but program flow overall, so it helps on a number of different levels and I really took what you said about looking at children and the way they are picking up new technologies to mind. It just becomes clear to me that language can be a barrier we try to overcome and with that type of mentality in mind I can see why people like .net, it does have this unification theme to it in trying to remove those barriers but its still text based and programming flow is largely not done in pure text but block diagrams and flow graphs which are visual tools 
[= Zeigler;17702]
MonsOlympus has some good questions from the last page, so I thought I’d describe how Fortnite is mixing C++ and Blueprints. Here’s an example class hierarchy for one of our enemies:
AActor -> AFortPawn -> AFortAIPawn -> AFortAIPawn_Husk -> HuskGeneric -> HuskThrowing
FortPawn is C++ and has code to deal with things like our animation implementation. FortAIPawn is C++ and has the hooks for the behavior tree AI system. AFortAIPawn_Husk is very light and has a few things for increased performance. HuskGeneric is a spawnable blueprint, and has the majority of the data references built into it. HuskThrowing is a variant of HuskGeneric that throws bones, so uses most of the same data references and overrides some behavior. This structure has worked pretty well for us, but the specific decisions depend on how the team is setup. We could probably do without AFortAIPawn_Husk, it’s mostly there for historical reasons, or you could make that layer an abstract blueprint or “Core blueprint”. What basically happened for us is that the designers and programmers worked towards each other as we implemented new functionality, and we met in the middle. Most of the replication logic is inside the native code, most of the visual logic is in the blueprint, and most of the gameplay logic is inside other objects referenced by the blueprints. For instance the HuskGeneric blueprint actually dynamically decides what it should look like, based on random chance. That system works well the way the artists implemented it so it’s implemented in the blueprint event graph. But, if something was too complicated to implement efficiently in blueprint, we’d move it to C++ and refactor the blueprint.
A key part of the fortnite setup is that we try to avoid referenc data assets from C++ classes, and we’re currently removing most of the rest of the references. We do this primarily through Object Libraries, the Async Loading doc page has a good overview of how to set that up. We use Object Libraries for things like weapons, items, enemies, etc. We load an entire directory of assets, and then expose methods to find the desired asset based on game-specific queries. It’ll be something like “spawn the enemy named husk”. The other method we use extensively is to have data references hanging off of a GameSingleton, I discuss the general method over at this AnswerHub question. That singleton has pointers to things like the player’s initial inventory, what blueprint to use for the player’s pawn in different situations, etc. Using those two methods we’ve removed most of the data references from our C++ classes
If anyone has specific questions about to set up a hierarchy, ask away and I’ll reply. As an example, Mons I’m not entirely sure what you meant by “I might encounter the need to have C++ Blueprint dependencies like Archetypes and Id prefer not have those hard links between external and internal classes”. What specific pattern are you trying to avoid?
[/]
Ahh thank you that is extremely helpful. My main concern is Blueprint Classes and calling Blueprint functionality from within C++, I would prefer to keep those calls all C++ native and override in Blueprint. I think its similar to what you are saying about data objects but in this case its class references because of the need to call functionality, even if I cast I still need the class of Blueprint to call the appropriate function. I was having some issues calling through C++ into the blueprint layer but that may just be a project specific issue. With the Archetypes to explain that, is that you would have to:
- Create the class for the archetype compile.
- Then open the editor and create the archetype.
- Copy the reference to the asset to the clipboard close the editor and copy it into Uscript.
- Then recompile with the asset reference linked so you could access the archetype.
This is what creates the interdependency and if we are modifying blueprint callables or *native implemented events * I cant help but see us running into issues pretty quickly.