Consider this my wrap-up to the Blueprint/C++ fiasco I liked to bring up in the past twice or thrice.
Until now, I disagreed with Blueprints graphs as being “enough”. After having spend many weeks exclusively learning BP. My feeling about nodes instead of text, actually even shifted from “not enough” to “it never should have existed in the first place”.
Blueprints nodes are more of a toy than anything text based could offer. Doing prototyping first with BP, and then moving to C++, who the heck would do such a thing? Only if more performance is needed. Because otherwise this would be only extra work to make up for a graph’s short comings. A Unity dev wouldn’t have to do that. C++ ain’t even on par with C#. Needles to say, this is so anti productive. C++ can’t do the rapid iteration C# allows and many professional indie devs NEED.
Epic Games may think that Blueprints are a plus!? But in reality, if anything, it is more of a minus. Because of Blueprints there is no text based scripting now in UE4. Why the heck would a serious Unity dev consider UE4 over Unity? What was even wrong with C# or UnrealScript (yes it had it’s problems in UE3) that could justify the time and cost to implement nodes instead of text?
UE4 does have a very nice editor, a robust graphics render, a very robust game framework. Do you know what Unity got? An asset store that saves it from its short comings now for a trillion’s time! Yeah, I’m talking about the real time voxel based global illumination plugin called SEGI. It is already in beta… it sells for flimsy $80… What does UE4 have? Nvidia VXGI a.k.a. “I’m going to trash your FPS and raise conspiracy theories within the AMD fangirl community, after you are done compiling me from GitHub”? Seems to me that this “amateur” game engine called Unity, is kind of fighting back and hitting UE4 very, very hard. Unity never was this modular in the past, not even UE4 seem to be it even now. Yet Unity can get stark changes via asset store such as global illumination.
I’m an artist and programmer. I used Unity and then tried UE4. I’m going to stay now with UE4 for my current project. But for the next game, I actually may go back to Unity. UE4 is suppose to be for professionals, yet the programing experience with this engine is anything else, but not professional, it’s a hassle. Because BP nodes are a toy. I may I feel this way because I know beside of doing art stuff, also how to program with C#. But node graphs are supposed to be easier than a freaking C#? Nope… Because it would take an artist only a few flimsy tutorials for C# to do what one could do with BPs. The funny thing, even about C++, is that the difficulty of the implementation, hugely depends what you want to implement in the first place. A solid language will help, a well written API/framework will help even MORE! Unity doesn’t really have a game framework…
Yeah, the standard assets are extended now in Unity. You may find an existing script for camera stuff and such. But my point is that BPs don’t give any advantage. The nodes are never an advantage, they are always in the way, but make use of other excellent parts in UE4 that are the actual advantage Unity can’t deliver.
I do like it though, how well the node graphs are embed into a BP window. The idea of declaring variables with mouse clicks, and then setting a few checkboxes, is very good. And this should stay on a possible text based BP in the future. Because, if one wanted to provide such extra information to the framework over a texted based script, one would need something like C# grade Attributes. But that is extra typing. The editor should just create a partial class, and generated those attributes for the user along the variables themselves. Since I’m already talking about code typing reduction. I want to mention that Micro$oft’s F# is object oriented and also is into code noise reduction. So even less typing here than in C#. As an example, In F# there are far less semi-colons or curled braces. I only have little experience with F#. I can’t tell if that is a good choice for a text based BP, but people use that weird SkookumSript for scripting, and F# is quite similar just Death Star grade like C#. I would love to see such code noise reduction in a possible texted based BP if this kind of language makes sense for gameplay code. Here is a small F# games and apps guide.
Blueprints run on a VM. This tells me that they are actually managed code, generated out of nodes instead of text. A fairy told me that Unity, although it does support native code plugins, it’s a mess for C++ gameplay programming though. Now UE4 actually seem to be able to run managed code and native code for gameplay just fine. It is quite convenient how one can write C++ and “managed code” for the same game. Unity can’t do this without hassle. Many Unity devs could move to UE4 without too much thought, and continue making their games that might end up being performance heavy. It’s easier to move code within one project of one engine, instead of having to switch to another entirely different game engine. Too bad that this feature, is now being spoilt because of BP nodes. And devs would only move who have the need for a performance boost via C++.
I have to admit that I sorta underestimated Unity myself. Well I was gone for a year, so I spotted SEGI only now. However, I just hope Epic Game won’t do the same mistake. Unlike UE4 noobs may think, Unity can do a lot more if one wanted it. Yes, this is something I knew myself already, too. It’s just that professional Unity devs figured this out a long time even before me. This narrows down UE4’s appeal by a lot! Leaving nothing else but a UE4 community with AAA devs who don’t mind C++ because they never really knew anything better (not entirely true, though). And invites more freaking indie noobs who think they can program now because nodes are just awesome.
If a C# or the old UnrealScript as text based BP, ain’t “different” enough to C++, then use F# or a new UnrealScript offering code noise reduction. UE4 does have a lot of advantages by delivering many features. Yet it also seem to have a bad habit of adding more hassle somewhere else, and therefore being less of a clear winner as a game engine.