Blueprints are a toy. Which serious Unity dev would use UE4 without C#/F# or UnrealScript!?

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.

Last Update

Although I think I could never go back to unity, at least for this decade, I could admit that if there had been a native scripting language for the engine, I never ever had touched Blueprints

Unreal never used C#, I’d like it to but C++ was what the engine was made with so I understand the amount of work needed to add C#. Unrealscript doesn’t have as good of performance of Blueprints and is much more limited which is why Blueprints were created. They’re still an option for people who don’t want to learn programming it’s a much faster way to do many things.

Thing is that you need to learn programing anyways. But just in a more visual way.

Yes, you learn some of the principles but you don’t have to learn the syntax which is one of the things that can be confusing

I get your point. Blueprints are fine. Epic putting all development power in Blueprints is not.
An engine needs

  1. a solid base in C++ for unlimited programming on the ‘metal’ without restrictions.
  2. a textual programming system= scripting language which wraps the C++ architecture and allows common functions without recompiling.
  3. a visual system which builds on the script (blueprints)

Script and Blueprints need to have import & export, so they can be converted to each other.
A text based programming flow is always superior, at least if you have a game with decent codebase.
It’s amazing and terrifying at the same time :wink: to see people doing number crunching and code duplicating with blueprints.

There is no need for intermediate scripting language in UE4. Either be a programmer and learn C++, or be a designer and use BP (for which you still need to know how to make algorithms and such). I bet there is still a lot of stuff that could be exposed to BP, which I am sure will be exposed in time (AI stuff expose to BP is on the roadmap already).

Not saying C++ programmer can’t be an artist or animator or jack of all trades, but generally programmers are programmers and artists/designers are artists/designers. BP allows for artists/designers to create apps/games without programmers involved. Very good solution for indies.

I think you guys are missing the point. The professional way to use UE4 (i.e not just use it as a learn-how-to-make-games tool) is to lay out the entire game logic as a set of C++ classes based on solid programming principles. Then expose tweakable aspects to Blueprint where level designers can rapidly tweak the behavior using familiar UI widgets generated by the BP. You now get the speed and robustness of a solid programming language (C++11/14) which has stood the test of time and also the tweakability of a high level visual scripting language. This c++/BP combo beats anything that is out there. Period.

Comparing just the BP bit to C# etc makes no sense. It doesnt exist in isolation and should not be viewed as such. If you cannot fully exploit the C++/Blueprint nexus then UE4 is not for you.

Everyone is entitled to have their opinion… :rolleyes:

While what you said true and ideal scenario, most games can be made using BP only and still be performant enough where you don’t have game grinding to halt (especially with BP>C++ compiler). At least on PC.

Funny how if you spend more time criticizing things instead of trying to use them, how they never do anything productive for you. Also, it seems that when you can’t understand something painfully obvious to everyone else, you blame their lack of communication skills!

I can guarantee you that when you had run into a problem with BP that if- instead of whining about C# not being in UE4- you had either truly tried to make use of BP or truly tried to use C++, then you’d be done with whatever it is that you want to do in UE4 by now. Maybe not a shipped game. Maybe not even a prototype. But you’d have more to show than insulting people who are trying to help you, and crying that the ‘toy’ isn’t what you wanted.

That, or perhaps team up with somebody who actually understands Unreal in order to have them do all the scripting/programming for your game. No shame in delegating tasks, y’know.

I totally disagree with your sentiments, but realize everyone is entitled to their opinion.

Personally, I think Blueprints are disruptive game changing technology (pun intended). For like 80% of non-performance critical game code they are amazing. On our current team of 25, it empowers the artists and level designers to be effective and contribute significantly. To me, Blueprints are one of the true gems when using Unreal. Blueprints and the material editor are simply a cut above.

Furthermore, I think c++ is an outstanding powerful language. It is powerful, flexible, and performant. (Although it can be wordy and complex, but some of the new features like auto and lambdas help with that. )
Most importantly, access to the source code is another game changer. It is critical for understanding, for troubleshooting, and for building custom tools and extending the engine.

Overall, in my opinion, Unreal is significantly more powerful than Unity. Things like the blueprints, the material editor, Sequencer, Persona, access to the source code, the list goes on…

On the other hand, if you prefer Unity, I encourage you to utilize it for your next project.
The most import part of game development is to utilize tools that you enjoy using - tools that you understand and which empower you - and that sounds like it might be Unity for you.

But for me, it is Unreal :slight_smile:

Hi there, I just wanted to chime in to this thread to say I’m watching the conversation going on here about blueprints and scripts. Though UE4 does not have plans to support C# natively or with Mono, we’re still supporting plugins for scripting languages like Skookum and Javascript.

Also, for complete transparency, I made an edit to the OP to remove a line that was reported. Keep the feedback coming :slight_smile:

I’ve seen this exact topic few times now, it had no impact previous times, i don’t see why it should be different now.

ps: i’m really interested what kind of offencive phrasing was in OP post.

I’m a very strong C++ programmer in general. I’ve written several large shipping systems in C++. I’ve even worked on C++ compilers and debuggers in the past.

I think Blueprint Scripting is great, and it fills a hole very well. C++ developers provide the components needed to implement gameplay. Designers use Blueprint Scripting to actually implement and tweak that gameplay.
Blueprint Scripting is very helpful, because it doesn’t have syntax errors, and it makes it much easier to “follow the thread” of what’s going on for non-programmers.
If you don’t appreciate those benefits, then just write everything in C++ and don’t worry! (But you will be missing out.)

“Blueprints,” the larger concept, is more akin to “prefabs” in Unity; the “scripting” bit is just one of many facets, btw.

well said!

You are missing the something:
BP is an addition, not a requirement.

You’re seeing this from your perspective, understandably. But you need to see the broader picture. In this broader picture, lots of UE4 users have no programming experience whatsoever. For them, Blueprint is a dream come true. And if I’m not mistaken, even if you’re already a programmer doing everything in C++ (or C# or whatever) Blueprints should not be a barrier or a nuisance but just an interface to communicate with the rest of your team.

BPs are awesome.
I develop alot of very complicated things in PHP and C#; naturally C++ is hard for me to understand. People who learned C/C++ before any high-level language would never understand this.
So basically i think about my goal in C# and then i easily re-do it with BPs, although i miss the clear object-oriented approach with this.

EPIC did what they aimed for - it is unbeliavable easy to get started. With nativizing BPs and more nodes with each update, one day BPs could replace spaghetti code with actual spaghetti visualisation.
Although for full BP functionality we currently greatly depend on our community heros like rama.

Oh yeah … the very funny thing about this is that you actually could integrate C# inside of BPs with ease (nodes to code and code to nodes). It is basically the absolute same workflow. Just imagine a blueprint as C# class.

I think the way it’s setup now is great.

For my projects I do the framework in C++ and then have a Blueprint Class that extends from one of them. It is much easier to work with the assets from Blueprints and I like the decoupling of the game data from the code. It is flexible enough that it let’s you structure your project how you want to. If you want, you can do it almost entirely in C++, or the other way around.

I agree, visual scripting has some big drawbacks. But, that’s not specific to Blueprints, that’s any Visual Scripting language.

Any argument of C# being easier than C++ 11 is invalid as far as I’m concerned. I’ve worked on several UE3 games and it always was very hard to find someone with UnrealScript experience. Almost everyone with a Computer Science degree has C++ experience though and it is the normal for the Game Industry. It is much easier to find a programmer with C++ experience.

Kindly allow me to correct you:

All students i know either learned C# or Java in university. While the jump onto other languages is not really hard, mainly students stick with PHP or Java, either as a hobby or in their job. I do know some C++ programmers … They do router firmware or linux kernel black magic, but i can count these people with one hand.