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


Every game company that I have applied to that has given a programming test, has done the test in C++. The school I went to used C++ as the main language. I have only used C# on business applications, enterprise web applications and the few Unity projects I’ve worked on. The games I’ve worked on have always been C or C++ for the engine, and then with a scripting language on top such as python, lua or UnrealScript.

Unity is a C++ application. All the people that whine about C++ being too hard and saying Unity does it right seem to forget that Unity is a C++ app that doesn’t give access to the average developer of the code, so you are very much just an end user.

So it’s bad that more people want to get into game development and UE offers something that can make this more accessible to new people? I don’t understand this kind of “If they are better than me they have no life, if they are worse they are noobs”-mentality that seems to plague so many communities. We don’t need elitists that think they are better than everybody else and does nothing but put others down for trying to learn just so they can feel superior. Live and let live.

You know, with all this whinging you’ve done, you could have gone and learnt C++ and made a game by now. Moderator or not sometimes you’ve just got to be bloody blunt with people. At the risk of wasting my breath on another thread like this I’m going to chime in regardless in the hope you might take something away.

I did that, coming from absolutely zero programming background. Without it, I’d never have learnt C++. Skip forward two years and I’ve now shipped two titles (both multiplatform and complex projects), and have at least three others on the go at any given time. Who knows, maybe I have a knack for it - or maybe it’s just that I knuckled down and got on with it?

Sigh. First sentence isn’t even worth an answer because that’s just blatant flamebait, lets be honest. As for the second half, I use hot reload every 5 minutes of every day, it (usually) always works. If it doesn’t it takes a few seconds to hit restart in VS and boot it back up again, providing you’re project isn’t a mess.

The extensive list of shipped Unreal Engine titles clearly disagrees with this. This is just nonsense, there are plenty of huge 100+ people teams working with these tools everyday. It integrates perfectly with Visual Studio and Source Control.

Bring back UnrealScript…? Insanity.

There’s a lot to be said for just getting your head down and getting on with it. I think it’s pretty clear by now that C# is not going to be a first class, officially supported feature of the engine and even if it was, it would still be absolutely nothing like the Unity implementation. In fact C# in Unreal more closely resembles C# than C# in Unity does.

If you want my absolutely professional, blunt and honest advice, find a toolset you like and stick with it. Don’t chop and change because you’ll end up being useless in both toolsets. Pick one, stick with it. It’s better to specialise in something rather than nothing.

EDIT #2: This image actually sums up my thoughts to be honest, in near-enough wording…

What he said. C# is also single-threaded , so you not only have the overhead of being a managed language that slows your code, it’s only working on a single CPU core so you have less resources available in the first place. Blueprints are even faster than C# managed code since you can convert them into native C++ code… awesome!

Going to chime in on this.

Programming languages over the next year or so is going to grow drastically for Unreal. This is just me looking at the programming languages that are coming out so far.

It would not surprise me If we see C# Support for Unreal.

To drive my point home -

Unofficial Python support was just released today - GitHub - 20tab/UnrealEnginePython: Embed Python in Unreal Engine 4

We have Skookum Script -

We also have UnrealJS - GitHub - ncsoft/Unreal.js: Unreal.js: Javascript runtime built for UnrealEngine 4

BP is non-readable, unique to ue4 and a pointless gimmick that will never be popular among serious developers even if some claim to ‘be having fun’ with it.

Totally agree with you.

^This^… Plus:

  1. You can color-code visual code, which is much faster to the eye when working, than scanning for text.
  2. You can visually layout code in shapes also, so even when zoomed out you can easily identify key zones.
  3. This can help when hunting for solutions to problems & does have unique advantages over text languages.
  4. Code added last minute can also be specially color coded to help with backing out changes if things go bad.
  5. Overall BP lets you focus or concentrate on ideas rather than technical syntax or constructs, which helps!
  6. As BP progresses, packs of high-level custom Blueprints will also let developers prototype games faster…

Maybe you won’t notice this as much or at all even if you’re solely the dedicated coder for a project.
But if you’re an Indie game designer wearing every hat, this is the difference between success & failure.
Games are a delicate balance of different ingredients: genre / visuals, emotion, mechanics, adventure…
So being shielded from conventional code & cryptic editor / compiler errors leaves crucial time for design.

What kind of games do you usually work on? I miss the simplicity of Unrealscript sometimes.
But so much was hidden from us (in Kismet too), that it was always a point of frustration.
So better to have C++ Source & evolve towards it, that way we can tweak whatever we need.

BP does have downsides. Creating loops etc is often more cumbersome as you lose time re-arranging nodes.
But you always want more, and having scripting languages natively supported by Epic would still be very cool.
Unreal.js & SkookumScript are still beta, so there are added risks in choosing them over BP just to be clear…

BP could be improved by allowing simple user customizations, optional user settings.
Allow for color-coding nodes & changing the style of wires or masking / hiding them.
Having variables connect left-to-right the same as execution, breaks the flow to the eye vs. Kismet.
It’d help to be able to drag connected pins to wherever you want them on a node to reduce clutter…

Your complaints can be answered with Skookum script and AHR it’s free and a beta(maybe an alpha) here we don’t charge $80 for a beta. If you say something like Skookum script isn’t what I meant will you ever be satisfied or is it more a I quit unity because I needed something better and now that I found that something better I’d rather not relearn everything. Anyway my two cents.

Unity is a toy.

Cryteck made it, i think Epic will take the plundge and C# will come into some major Unreal 4 release bringing the engine to a wider adoption.

As a person, who been working with unreal blueprints for a year now and have quite a big pure blueprint project (200+ blueprints, thousands of functions) i have to admit, pure blueprints are absolute trash developing on,there are way too many basic things missing, dozen things which one engineer from epic could implement in like a a month and make blueprints much better, but epic not willing to spend resources on optimizing blueprint workflow and add features purely for this, because epic use c++ as a core in their projects and this made them to avoid most of the issues which comes with complex blueprint project.

But even being trash, what blueprints good for, its giving people without any programming skills but with dedication, ability to actually make something and see results right away, which feels much better for a beginner.

I don’t see why “pure” Blueprints should be trash. I’m developing a whole game using only Blueprints. It’s like a proof of concept and currently it’s doing really well. We are going to ship our project in the near future and we never had problems with Blueprints. As a programmer you should have learned to find workarounds for minor missing things.

Serious developers do use blueprints, and use it as part of their overall content pipeline. Core game logic is generally implemented in C++, but a lot of behaviour is still driven by script.

Heck, when I was working on Fable, we repurposed Kismet in UE3 to behave like Blueprints do now, and give a scripting interface to our gameplay scripters. An enormous amount of that game was running through kismet scripts using bespoke nodes provided by gameplay programmers.

For people who want a scripting language that isn’t visual there are already plugins available and they have been mentioned in this thread. The constant insistence on C# I’m seeing here just reminds me of someone who’s had their cast removed but still insist on using their crutches.

I strongly question the validity of a computer science course that does not teach C / C++ in this day and age. Java is understandable, particularly if they did their degree a while back. C# just isn’t portable and most industries simply don’t (and won’t) use it.

Finding workarounds is not a good pipeline, especially if there you required to find workarounds for basic variable management, lets call few oblivious one : structs are atrocious to work with, especially arrays of structs, arrays does not have a lot of basic functionality as well, there no sort int/float array, there are not SWAP index in blueprint, and since there are no swap, each sort function need to be unique, because you need to store element locally.

Those things getting covered by just little bit of c++, which everyone has in terms of function libraries, because almost every ue4 dev use rama’s victory library or their own small patch for stuff which engine miss.

It works really well in this scheme, core done on c++ and some tweaks going on bp. But i do know a lot of people making games on ue4 without c++ core, they build everything on bp and they would strugle a lot, if not the community, we lucky that people spend enough their own time to cover problems with function libraries, but i do think basic stuff should be done in engine, for everyone.

I can agree on some weakness of blueprint over more classic scripting solutions, for me it miss some UX improvement.

  • no “auto-format” a full graph/auto format mode (Epic team should just impose some layout rule, like with coding standards for C++, recomandation for repositery hierarchy naming for the assets stuff)
  • comment node, they should be able to expand when I add a node inside.
  • it’s a nightmare in term of input, one hand on the keyboard and another that constantly jump from the mouse to the keyboard just to create simple graph

but for the rest the full source of the engine and editor are available… so even for my grievance the DIY solution is available ( but for now i’m too lazy and my knowledge of the editor API really too poor to try to create any plugins)

@HeadClot thx for pointing me the existence of the python plugin that really great thing ;).

I’ve got an impression that folks who keep saying UE4 needs C# or any other scripting language don’t even work with anything else in the engine besides fiddling with BP or C++. Not only UE4 full of bugs in many areas programmers don’t even touch, it also has specific bugs per platforms. Some platforms are severely lacking developers’ love.

I, personally, would rather see Epic fixing existing bugs and making sure all existing platforms get attention and maintenance needed, so that UE4 is a more complete and polished engine, rather than stretch even thinner and have a mess that only good for Windows platform (and still without decent real-time GI).

Adding yet another scripting language besides BP on top of C++ is waste of development resources and work hours.

The only reason CryEngine added C# is to attract more devs, since virtually no one want to work with CryEngine. UE4 doesn’t have popularity issue, so no need to shove in something that only small group of people keeps whining about. Better improve hot reload and BP.

Worth remembering that Blueprint is an Artist tool. The fact that you can make games with it alone is something of a happy accident, but nonetheless the extensiveness of it means it’s possible. Unity is actually the odd one out, for NOT having a Visual Scripting language. Snowdrop, Frostbite and Unreal all have their own similar Blueprint System, and their more core code alongside.

There’s an argument for making the Blueprint editor faster, but adding another third language is not the solution. In my mind it would be in the form of a new window in the BP editor, whereby as you type, it creates the nodes in front of you in the graph. Using the ‘friendly names’ of the nodes would make auto-complete / context sesitivity work well too.

That’s a big feature in itself though.

I can’t understand where all that anti blueprint rage is originating from. Blueprint system is the most powerful prototyping tool I’ve experienced. I don’t see any single reason for adding another scripting language on top of that.

I would say Blueprint and C++ in Unreal are very good match - they complement each other very well. You done some stuff in C++, exposes some variables via blueprint and you can let just any junior programmer or artist to play around with it.
The non-existent of script is understandable, it is as if not enough differentiation between C++ are made but duplicate efforts are everywhere (you create functions in C++ and expose it for script). Blueprint and C++ are different enough they may not easily overlap in your workflow.

Also, it is not necessary for BP to eventually be converted to C++ - the multi threading nature of Unreal make slow blueprint not necessarily hogging the frame rate, but GPU in majority cases does it. In my case, the ‘game frame time’ is only about 1/5 of ‘gpu frame time’.

  1. I’m a short fuse. That’s the only problem. I can understand things. Maybe, some things even better than you.

  2. I never said that BPs don’t do ANYTHING productive. I said they are not ideal compared to other solutions. Not ideal doesn’t mean that I don’t understand BPs, it means I just don’t like them. I never really said that what I do, is more than “I don’t like it”.

  3. How the heck do you know how much BPs I even created? Compared to the number of posts I wrote about them and complain? Because, fun fact is. I’m not so present in this forum that often in the fist place… So, I couldn’t complain that much instead of working…

  4. “Thought” is not “complain”

And about the thread you are talking about. The Scene Component thread. I provided an actual screenshot. That clearly showed the BP creation derived from a Scene Component. And all I got was jokers who seem to have thought that I’m talking about something else. I asked for examples… I got two jokers who only could say “trollo trollo noob”.

I asked many questions. I provided many thoughts and situation of a possible usage scenario. Yet nobody really quoted any of what I actually wrote down. And didn’t replied to those thoughts, with quote, and said “Why this?” , “No, because…”, “Yes, because…”, or “But…”. All I got was “help” of that **** I can read myself for the freaking BP creation window tooltip that was also visible in the same **** screenshot. This wouldn’t even require a look up to the documentation

I do like to question things. That’s what makes me already smarter than you ever may become. -.-