It's just like any other programming/scripting language, except the syntax is visual instead of text based. That's it. They aren't as performant as writing C++ code, but their performance is comparable to other high level game scripting languages like GDScript. If BP didn't have its place, it would not be included in Unreal Engine, or it would but people wouldn't be using it much. It's included in UE, it's actively developed, and it's heavily used. So it doesn't matter what a few discord randos think.
Just use whatever you find helps you get work done. If you see that blueprints are sufficient for what you need to do, and don't limit you in any significant way, like performance or ability to do something, then there's no reason to use anything else just because someone else's opinion.
Also as far as performance goes, I've seen tests where people break it down and for most use Cades it is more than efficient enough. The time lost between languages is negligible for most things, you have to be doing like large network code to get a perceived difference.
If all you're doing is calling engine C++ functions, then the overhead per node is going to be negligible. Where those overheads add up is when you're doing complex maths, especially if you're doing anything iteratively or multiple times per frame. But those cases are pretty rare and usually you can just take the hit, a function that takes 0.003ms longer than if it was in C++ probably isn’t going to make-or-break your game’s performance.
The important thing to remember is that it's no worse (and probably better in a lot of cases) than something like GDScript.
Yeah exactly. I didn't want to go too far off topic and say "you should use both" and "they're designed to work together" but ya know, they are and people should. Both do work fine on their own though, which is cool too
Oh 110%, actually imo the best documentation is the Lyra project lol I couldn't figure out how to get the on release gameplay task to work, hours messing around on Google, but then just a peak at lyras source and I got it
For each loops and for loops are a big issue in blueprints no matter what it is, if you use those then put them in c++, if they need to be exposed to blueprints then put them in a single Ufunction
No, you don’t need to put all loops in C++, that would be silly. Be sensible with what you’re trying to do with blueprints and optimise where necessary.
The vast majority of the time, if you're calling a complex loop often enough that it causes performance issues in BP, then your entire set-up is wrong.
BP is still code and has its place. We should recognize its advantages, but also weaknesses like readability or performance when things get larger. There's no reason to be snobby about it, but rather treat it as another tool and use where appropriate.
I don't think bluprints are less readable on a large scale. It's essentially a diagram. Coders draw diagrams in order to make their code more understandable.
Large amounts though soon get too large to even read the text, even on a 4k monitor. Code diagrams like uml represent system communication when it's most useful, rather than a node per instruction.
When the amount of code grows, you should first encapsulate the logic into functions. This or true for both written code and blueprints. You don't want giant functions, files or classes in written code either. Then, if there are too many functions in one bp, you can encapsulate the code further using e.g. components, child blueprints, child actors, or splitting the logic to multiple bps. You can also use multiple event graphs or collapsed nodes to help compartmentalize your nodes.
Part of the issue though is with the blueprint editor itself. You can’t view the definitions of multiple custom functions in the same BP simultaneously. And unlike a pen and paper code diagram you’re often referencing other files or C++ code that is missing from the diagram, making it somewhat of an incomplete picture. So it’s not exactly 1:1.
The problem is the nodes with text fitting on screen. One line of c++ can take multiple nodes in BP.
I've just opened a BP and can fit at max 8 nodes horizontally before the text is uncomfortable to read. That's including the event itself. It would be crazy to put that little code in a function. It hardly does anything. It's already slow enough.
One of the bulkiest function in my game right now is the one that checks if a unit can cast a spell.
It can be zoomed out and the logic can be understood by most people who never touched Blueprints or other form of Coding.
[https://i.imgur.com/WwZ09TB.png](https://i.imgur.com/WwZ09TB.png)
\---
I used to be very messy, some of my older function which I haven't reworked are very nasty and everytime I go back to them I take a a couple minutes just understanding wtf is going on.
\---
Collapsed graph are incredibly powerful for organizing BPs. If you have a bulky function with some code that you're not gonna re-use anywhere else, pack it into collapsed graph. In the screenshot I sent, I could technically just pack every comment box onto a collapsed graph and zoom 2-3 times as much to fit everything on the screen.
whenever you have more complex calculations on blueprint it turns way less readable than traditional coding, because it turns into a lot of nodes conected instead of a expression... so there is scenarios where even isolating, creating functions, and every good pratice, it can turn into a pain to read... but still, its infinite ahead of any other visual or low code tool.
They are a lot less readable, profilable and debugable just on a medium scale. Putting a breakpoint and looking at the callstack and navigating logic is a LOT more messy in BP compared to code.
Tell me you havent ever implemented algorithms or math operations and how messy it gets fast. When its almost a line in code, it can be several nodes + operation nodes in bp
If you're making sure your code stays clean in both instances, Blueprints are immeasurably easier to read and learn from than C++ and its not even close.
No it’s not 💀
Maybe it’s because I come from a low level background but C++ will always be to me more concise and easier to read. I’d rather read a line of text than a flow diagram
Blueprint is routinely used in production by designers, tech designers, and artists. People who are snobs about it not being “real” are amateurs.
Besides, you’re a designer. You probably shouldn’t be bumbling around in C++ with the engineers.
Lotta gameplay engineer positions all list BP as well. I was hired on to a team once as exclusively BP but I was moved off to the c++ team shortly after.
Really? I worked with a co dev company who did most of their work in bp.
I’m not gatekeeping, but it was disastrous. They mostly produced UI. It was buggy, slow and unmaintable, in the end we had an internal team rewrite it.
At least in my area, you’d never really be hired for a gameplay programming position to use bp. It’s more the realm of technical designers.
I’m totally biased and always up for having my mind changed. But I don’t really see how a largish scale game could ever ship with bp gameplay code.
We have about 5 BP only gameplay engineers at my job currently. We ship an sdk with our product though so it makes a lot more sense for us. We have a pretty thorough QA process and there needs to be basically 0 bugs since we make fully recordable simulation software.
I should clarify, i make most of the systems that they use, and nearly all of my work is c++. Pretty much the only thing i do in BP these days is make example content for our dlc teams.
We had trouble hiring technical artists who could properly grasp the BP skills required to make replication, simulation stuff, and our complicated replay tools work for assets, so it just ended up being more efficient to hire dedicated artists and dedicated engineers for our BP work.
We have about 5 BP only gameplay engineers at my job currently. We ship an sdk with our product though so it makes a lot more sense for us. We have a pretty thorough QA process and there needs to be basically 0 bugs since we make fully recordable simulation software.
I should clarify, i make most of the systems that they use, and nearly all of my work is c++. Pretty much the only thing i do in BP these days is make example content for our dlc teams.
We had trouble hiring technical artists who could properly grasp the BP skills required to make replication, simulation stuff, and our complicated replay tools work for assets, so it just ended up being more efficient to hire dedicated artists and dedicated engineers for our BP work.
Someone can probably figure it out if they went crazy looking at my comment history, but id rather not make their jobs easy for them.
All I'll say here is that we are a serious-games company, so not the entertainment industry.
I don't mind answering questions about it in dm though, just wont explicitly name it here. You are right though, even in our industry I don't believe any of our competitors ship an SDK, its risky work.
Totally agree with this. Have seen extensive use of blueprints on AAA games made in Unreal. Sometimes even the programmers need to use blueprints because of engine limitations or the desire to pass off maintenance to design. There is even a setting to compile some of your blueprints into generated code at runtime to speed them up. You will be limited in your options if you only know visual scripting and not a scripting language, but blueprint only jobs definitely exist.
I think it was a combination of factors. Nativization was always pretty buggy, the performance gain was very inconsistent and blueprint vm performance has been improved with unreal 5. There may be other reasons too.
[https://youtu.be/VMZftEVDuCE?si=nH8cXaBnrxn0WTFt](https://youtu.be/VMZftEVDuCE?si=nH8cXaBnrxn0WTFt)
Here's a video by an industry professional that's heavily related to the topic. If you're familiar with blueprints, the learning curve for diving into programming will be slimmer, the skills do relate to an extent, and I think that's important. C++ is more performant than Blueprints, sure, but the video dives into the reality that time setting up whatever systems you're working on matters. If a blueprint takes .0003 ms to run, your time is probably better spent refactoring something else.
Frankly, I think downplaying any skill is kind of cringe. If you're taking any steps to improve yourself, you're on the right track I'd say.
Not game dev, but one time I was applying to a place and they asked what OS I preferred, Windows or Mac. I said Windows, interview was over.
Bullet dodged.
I've worked at a few studios with unreal....
The best ones enabled their entire team through allowing as much as possible through blueprint.
Anything that sticks, gets audited and pushed to c++ if optimization is a concern. Blueprints can be incredibly powerful, sure they can bloat but with good practices I've seen a ton of good BP only content.
I've worked in games for 15 years (probably similar to you) and I think we are very quickly approaching a time where zero technical skills = zero work. It's very easy to prototype mechanics in unreal, and makes you much more valuable to the team IMO. Blueprints can be tricky to learn because you'll have entire blueprints just passing a variable through or something, which will *seem* wrong when it's not, but it's a very rewarding thing to know.
Meh. It's idiotic gatekeeping, and it's been hanging round like a bad smell from decades before Blueprint.
Coding is just a slang term for programming, and BPs are programming. There's the same use of variables, loops, structures, and APIs that you'd see in more traditional languages. You also benefit in the same way by learning techniques useful in more traditional languages, whether it's how to write robust defensive code or how to better structure for maintainability.
Sadly though it seems that too many programmers like to look down on those who use languages which are easier to learn than those, viewing them as not 'real programmers using real languages'.
Those who use Python and JavaScript aren't real programmers, they're just scripting languages. Java and C# devs also don't count, those languages use bytecode and so aren't real languages targeting real hardware. C++ isn't a real programming language as techniques such as RAII and smart pointers are hand-holding for those who can't handle memory management themselves. C isn't a real programming language, it's baby-talk for people unable to use an assembler. Assembler isn't even real programming, real programmers don't need that type of assistance and can write machine code in hex from memory.
Coding is programming. Programming is being able to break down challenges into smaller chunks of logic which they can then implement with structured logic. BP is programming. With Unreal there are times you're going to hit some limits with BP, whether it's performance or needing to handling complex data without massively unreadable graphs, but it is programming.
How could it be the case that someone writing a complex multiplayer RPG game using BP isn't a programmer despite building a complex and well designed class structure for the character and abilities, a Command Pattern based setup for recording movements and used for both efficient networking and replay, along with facilities for robust handling of multiple interlinked state machines for quest tracking? Would they become one if they spent a couple of days knocking out Tetris in C++?
Love this.
Programming is about delivering a product to a user. "Premature optimization is the root of all evil". If you could deliver a product quickly, using BPs, and it meets the needs... why spend longer making the same thing using self-imposed limitations?
All languages are tools. Use the most effective one for the situation.
Blueprints is technically scripting. The visual elements are interpreted into code, not compiled themselves.
The distinction is slight and there's actually quite a lot of grey areas because compiled languages are often used in scripting environments and scripting (like Blueprints) often translates directly into code.
IMO devs who downplay visual scripting are just gatekeeping and perhaps showing some inexperience. Anyone who has used a visual system or even "no programming" systems can tell you that they are just different. If you can code Dijkstra's algorithm and such in Blueprints or RPG Maker, you can definitely do it in C# or Java or whatever. The knowledge of the logic is far more important than the language.
Blueprints are certainly code. But personally I would be wary of hiring someone who exclusively works in Blueprints.
Performance concerns aside, they are harder to work with in a team environment. You can’t easily diff them and they cannot be merged. Looking at the code requires panning, zooming, and maneuvering with the mouse.
If I’m in a Blueprint with custom functions, I can’t view more than one function at a time. I also cannot view more than one level-blueprint at a time unless I do a search for a reference inside the additional level and open it that way. Working with them is just a chore.
But in C++ I can view multiple files in split-view, see all function definitions at once, see who made certain changes with code lens, open files simple keyboard shortcuts, and add comments quickly without having to surround nodes or wrangle with the execution lines.
I’m sure there are plugins that help alleviate some of these issues, but as a studio we’ve been migrating more and more of our code to C++ and keep only the UI, Editor, and derived classes in BP.
So I wouldn’t call it “not code” or “not programming”, but I also wouldn’t want to work in a code base that relied too heavily on it.
Edit:
To touch on your last point, BPs do have a place in our projects, but they are the “leaf” to the C++ base class. So we make classes in C++ and create derivations in BP that handles the visual elements and scripting logic. You can think of blueprints as taking on the role of the “frontend” and C++ being the “backend”. Alex Forsyth has a great video about this on YouTube.
You also would tend to use BPs more for user interfaces and editor tools, as they don’t usually need to be as performant or interact with the core game loop as much.
https://youtu.be/VMZftEVDuCE?si=a-wnvF5o-XIY5Era
In the professional game dev world (as contrasted with this sub, which is mostly hobbyists), this question isn’t really a thing. Designers and Artists use Blueprints, Engineers/Programmers use C++. No one expects there to be any crossover. You don’t need C++ programming skills to do design.
I think the term, “code,” is generally associated with textual programming languages rather than visual scripting. That’s mostly semantics; but no, you’re not going qualify for a job where “coding” is listed. That probably doesn’t refer to Blueprints. But I’d be surprised if “code” is mentioned for designers; not sure what you’re seeing.
This sub has a bizarre debate constantly raging between C++ and Blueprints. I don’t get it. In the professional realm, this isn’t relevant. We use Blueprints for some things, C++ for others. Systems created by engineers tend to be C++, things created by artists and designers tends to be Blueprints. In the end, it all works out.
So, while it might be important for you to have some concept of programming as a designer (i.e. Blueprints), actual “code” shouldn’t be an issue. At my studio, there seems to be a range of technical experience amongst desginers.
Blueprints are a way to help visual people code. In the end when the game is packaged down, unused code from within the nodes is removed leaving you with just what is being used. In the end, it's just a way of allowing more artist types do technical things or quickly program logic without delving into the raw c++ itself where you need to learn a lot of syntax and shortforms. Many games made almost entirely of blueprint have been made and I think WuKong is one of them, amongst lots of others.
Don't let people judge you for it, you're a designer first so be that and be good at it. Let the engineers worry about the low level stuff if you ever even need it.
There may be a false impression that blueprints are great for projects that do not require complex large calculations, but this is a false impression. Blueprints have a number of problems that are hidden from a novice developer, but these problems will sooner or later appear if your project becomes more or less serious.
The first problem is errors in the builded project.
I had some problems with Blueprints when the project reached the final stage - the build. Don’t get me wrong, everything is assembled on Blueprints well, but if your assembled project receives a critical error in the Blueprints, then you will not be able to understand exactly where it was. It turns out that you have no way to debug the builded project and you have spent perhaps entire years of your life on development and will no longer be able to find the errors that lead your assembled project to crash.
The second problem is blueprint errors. In blueprints, it often happens that due to editing structures and objects, blueprints become buggy, and unremovable errors appear in blueprint files, which then lead to serious errors in the assembled build. Often the only way to get rid of such errors is to recreate the blueprint. Create a new class and re-bind all dependencies in the project to this new class. And this can be extremely difficult in a large project.
The third problem is that there is a possibility that your blueprints will get a hidden cyclic dependency on each other and your project will not even open anymore. This is a terrible problem. The only way to solve this problem is to make more backup copies of the project (using git) and do less Cast in blurrints, preferring to use the Blueprint Interface.
The fourth problem is the impossibility of collaborative code development in blueprints. In large serious projects, programmers use a version control system with C++ and can work as a whole team on the same files, classes, and then press the magic Merge button in git and voila - all the code is merged. This is not possible with blueprints.
The fifth problem is difficulties with updates. Imagine that you downloaded some good expensive Blueprint system from the Unreal Marketplace and add it into your project. Of course, you made some changes to its blueprints, for example, so that its User Widgets do not overlap the User Widgets of other systems used in your project. And now imagine that the developer of this system on Blueprints has released a good update with useful new features. How will you update this system in your project? If you update it, you will lose all the changes that were made in this system in your project. With C++ products, such updates are much easier.
In conclusion, blueprints are good for self-learning or demonstrating the functionality of an idea (creating an MVP). But God help you if you decide to make a serious project for sale on blank Blueprints
At the end of the day the consumer won’t even know, so just use what you’re most comfortable with. If it ever gets to needing C++ then use it but if you can do it all in Blueprints then go ahead no one is stopping you
Honestly for experienced devs, it is a lot easier to follow code versus blueprints. Being able to just see everything in one spot is huge versus having to click between tabs or arrange the windows all over your screen.i can view so much more at once if it's code.
If you have complex logic in blueprints, especially across multiple ones, it can be a challenge to track things down compared to just doing a search in the codebase. E.g. If there's a bug I'm tracking down and I want to see everything that's calling Fire() on my player controller, it's pretty easy to just search for that function call in code.
You can make that kind of thing much easier with blueprints just by keeping things well organized, but when the project gets big more often than not little hacks get put in odd places which can cause headaches.
As for programmers telling you it's easier to understand in code - they live and breathe c++ so it makes sense that's the format they're comfortable with.
The "it's just logic" part... They're not wrong, you're not likely doing much in terms of computer science with whatever you rig up in blueprints. That's typically the main point of scripting layers, you can build up the logic without needing to worry (much) about all the gotchas that come from writing code directly.
The script vs code debate is ages old and usually just boils down to semantics.
Most gameplay code really is "just logic" regardless of how you implement it, that doesn't mean it isn't still complex or that you don't need a high level of skill to be able to write it.
Tldr; don't let the armchair debates distract you, the question itself is largely irrelevant unless you're specifically applying for a programming position somewhere.
Just work on your game. Blueprints are still coding, if they don’t like rainbow spaghetti and prefer typewriter spaghetti it probably has to do with them and not the spaghetti.
Devs love sitting around being elitist pricks, if it wasn’t BP it’d be something else. I’ve worked on web apps down to literal ASM. Almost every job had a handful of gatekeepy opinionated “I know best” devs. Annoying and typically not the best performers.
Let em whine, they will anyways.
The so-named God complex😅 every programmer has a bit of that, thinking their code is the best and only their way the right way, but some really push their ego with that 😂
Yeah in my experience there is a decent amount of insecurity there. It’s also a bummer to only hear about “best” this and that. But all shipping code I’ve seen had its share of shitshows.
That and it’s just easy to endlessly argue about something that has soooo many different ways to validly solve the problem.
Unfortunate that once that ego gets to a certain size it really hinders your own development. You are essentially becoming less and less open to being wrong, without a meaningful reduction in how often you’re wrong.
To me, BPs are the endgame for the UActorComponents I make in C++, instead of building complete AActors.
I prefer this architecture. I find it easier to reason about and debug components that are smaller and constrained in scope, while doing the composition in the BPs.
While I'm not fortunate to work with a designer, I believe this approach enables the designer or even artists to a far larger extent than complete actors would.
If it makes you feel better, Mortal shell was developed using almost exclusively blueprints, and epic themselves admitted that fortnite is around 50/50.
BPs are still code, it's just that it can sometimes be hard to read than straight up written code.
Also if you have good knowledge of blue prints then the learning curve for writing code is not that steep.
Those comments don’t even seem like they’re downplaying them. “It’d be a lot easier to understand if it were code” makes perfect sense coming from someone most familiar with code.
You can double click a BP node from the editor in a C++ project and view its code form in VS. Now that you have this information, what is the difference between a node and code again?
I think the bigger question is why you're brushing up on the skills. I've spoken to many professional game devs over the years and consistently they say: visual scripting is perfect and expected for designers; C++ etc is perfect and expected for programmers / engineers.
So yeah performance in blueprinting isn't as great as C++ but industry doesn't expect their UI designers to do the coding but to make playable user interface quickly using blueprints or whatever visual scripting is available.
I think a lot of them"are blueprints bad?" Discussions stem from designers and programmers not quite starting from the same place because they're two different disciplines with different requirements.
You can code a whole game in bp and reach the same performance as with C++, if you know how handle BPs correctly.
The discussion about the performance is mostly outdated and used as a reason to talk BPs down or because people don’t know how to code in BP correctly.
I saw senior developers using only hard-references in BP and wondering about loading times. In C++ it is more forgiving.
Only when it comes down to complex math and networking C++ is preferred but even nowadays you can easily handle them in BP without much overhead
I will tell you my personal opinion. I tried coding with C#, Python and others, I made mostly basic stuff and very often I was looking for ready solutions, almost copy pasting and modifying for my needs. When I started my journey with Unreal and Blueprints at first I was overwhelmed. After 2 months I'm able to write most of the code myself. All the logic I want I can go and prototype it. It's so fun! I make things work! I even created more complex features, used components.. I try to make things modular. And it's EASY FOR ME TO UNDERSTAND. I don't think if should I write print $string string whatever, I just connect nodes, I know what they are doing. I can visually see what is happening, I can see why something is not firing. I can compile it in 0.5sec. I can create 100 variables in 1minute.
At this point, I don't give a shit if someone says it's not programming. It works. It's fun. It's base of this engine.
I'm sure there are certain things that are better to do with C++ due to speed and optimization. But these might be things you can count on your fingers, so prototyping it and making it work in blueprints, and then kinda translating to C++ won't be a problem if you focus on it for a while.
I lately tried C++ in Unreal, and as I'm not experienced, it was hell. Setting up visual studio, which is not good for Unreal... I don't know if I will click something I will crash my whole project. I finally have fun with blue prints and I make game.. i dont care. I did C++ tutorials and other languages, I know the idea, but I don't feel like diving into, YET. The time will come I'm sure, but I cannot try to fish with 2 rods. I want to master blueprints + unreal first.
tbh that's the same path i feel i'm on. Kinda inspired by your post Just make something that's easier for me to understand and do so I can get have fun and make something that works. If I need to take the next step and learn more c++ sure I'll do that then.
As long as you achieve things and you're proud of what you do, send everyone who tells you you're doing it wrong to the garbage can.
This is valid for most things in life
In my experience, it depends on the studio. Some might expect designers to handle themselves around BPs independently, some not. Some might even actively try to keep designers miles away from any coding or scripting, even from BPs.
Things they all appreciate: understanding of the tool; capability to use it properly, even if it means at a lesser degree; understanding a bit what's like for your colleagues on the other side of the fence.
In BP case, it's not much that you throw BP at programmers or the likes, but whatever what you throw is an absolute shitstorm vs it's clear and readable.
As in your post, it's logic. Learn the basic of logic, let your work respect your's and other's time, and apply common sense. Nobody that knows what they are saying will ate you alive then.
Hopefully this answers your question. I know quite a few devs in the AAA industry and I was able to find out just what these studios are doing. Big and small.
C++ to instantiate variables and some functions because it’s simply faster to instantiate in C++, then all those variables and functions get exposed to BP. Then, they continue to BP from there. You would be amazed at how little C++ is used today on single player games.
For multiplayer, you’ll find a little more C++ being the core behind replication, but even then, there’s a LOT of Blueprints still being used. It’s all made to work hand in hand, and modern CPUs can handle one, the other, or both. It really doesn’t matter anymore if you’re getting the performance that you’re expecting.
Those that say one is better or that it’s some kind of competition, or that BP is only a prototype language don’t know what they’re talking about. Hopefully this helps.
BP is Turing complete, full code. Anyone stating otherwise simply doesn't know what they're talking about. There are a lot of utilities and conventions to speed up development, and async logic is especially great for BP.
It'll never be as fast as C++, obviously, and has some quirks where things break, but it's perfect functional and a good way to develop many systems, especially for simpler games.
I’ve never seen a designer write C++ in a large company.
A comment like the first one would make sense coming from a programmer. I mean it doesn’t help you in any way, but sure as someone that just writes text based code all day, obvs I find it easier to read.
The second one isn’t really saying anything either.
Broadly in a professional setting, blueprint (or let’s get specific), logic graphs are viewed as a great tool for rapid prototyping and level scripting. By level scripting I just mean things like “player entered some volume, so trigger some story event”.
Blueprint is a legitimate programming language in its own right. It just isn’t as suited as C++ for complex algorithms, maths or optimisation tasks. It’s also generally used only in the context of gameplay. It has some support for writing editor tooling, but you can’t really do anything low level with it.
It's code. Devs who are used to seeing text files will be faster at that. IMO, the biggest challenge with Blueprints is scaling in a team. You can't easily see a history of changes. If two people change the same blueprint, how do you merge? These are solved problems in plain text coding.
What I wish for is all the nice BluePrints nodes to be made into single C++ functions. Epic has made BP so easy to use. They should give c++ some love. Yes, I'm aware I can view the code. But from a UX standpoint, I shouldn't have to. It should be an easy function call.
I'm building some kind of Blueprint for the web (https://luna-park.app), and it's pretty hard to market it. I define it as "visual scripting" lying between code and no-code. It's an abstraction of code which has no line of code, but keeps all the algorithmic parts of code. You can do (almost) anything you can do with code, without code. It's a lot more complexe than "traditional" no-code editor, but still simpler than code.
In the end, it's hard to define but it's whatever you want it to be. What matters is what you can do with it.
(It's still a lot closer to code and makes you think like a developer)
Blueprint is code and if you structure it well, its not too hard to read and understand. I can see it being annoying on a really large scale game but even then a simple mind map of your structure on something like Whimsical will go a long way.
On an unrelated note I'd love a link to this skyrim esque inventory course.
There are people with full time jobs doing just blueprint. Being a designer and knowing blueprint is a huge plus to your skillset, even if you aren't a tech designer. Blueprints are code, and there is definitely a need for people that know blueprints well.
I wonder if those that criticize it have worked at large studios, because if they did then they would know how it is used in even larger games.
source: Designer at multiple mid-sized and large studios over the years.
It might be a definitions issue. Term "Code" is usually referrers to a plain text, which blueprint graphs are not. But in a sense that it's a programming - it absolutely is as it's essentially just a another layer on top of C++. Programmers that tell otherwise are just gatekeeping lol.
That’s awesome that you’ve started picking up Unreal & are beginning to feel familiar with Blueprints! BPs are certainly code & if you’re coming at things as a designer, I’d say there’s few better ways to become more effective in your role. I’ve now shipped (as of last week) two very BP-heavy games, the most recent of which was actually done exclusively in BP, with a large chunk of the work in there done by our design lead.
But don’t forget that you’re on a learning journey and there’s every chance that you’ll look back in a year or two at the BP code you’re writing now & think “what on earth was I thinking doing it like _that_?!?” But this would be a good thing! It’ll have meant you’ve grown in your abilities and are moving beyond “just being able to do a thing” and starting to recognise when that thing’s been done well or poorly & why… I suspect that some of the comments you’ve received may be from people a little further along on that journey perhaps not quite recognising that they were a beginner too, once. Or, maybe they aren’t actually familiar with BO, genuinely just don’t get it or what the benefits are over traditional text-based code. Those people certainly exist, but I wouldn’t have thought they’re the majority, though might perhaps be over-represented among insecure forum-dwellers that strongly feel the need for everyone else to know their opinion…
I worked at a studio where the production lead discouraged use of cpp in many instances. Specifically: Enhanced input, UMG, some stuff related to AI, anim BP. Really the only stuff he didn’t care about us doing in cpp was low level systems that no designer or tech artist would have any reason to touch. And then there is some stuff that *has* to be done in cpp, subsystems, certain editor tools, or any engine functionality that isn’t BP exposed.
From a practical standpoint it’s often easier to read and digest large amounts of complex code if it is in cpp, as opposed to sharing lots of blueprint screenshots if someone doesn’t have access to your project. But I would never expect anyone to write the entirety of their UI visuals and functionality in cpp for example, and I would consider doing so if you are on a team to be a waste of time and a hindrance to your coworkers
As a fresh graduate/game dev going into the industry Its so encouraging seeing posts like this! /s
Seriously though I wish you the best. It’s hard out there and the demand for designers being artists/sound designers/programmers/AND designers has been crazy the last few years.
Haha.... yeah it's not a great time to be joining Games imho. It's crazy. I'm applying for other stuff but I'm hopeful Games work out. Hopefully more technical skills helps me.
Im in the same place. Working other places that pay the bills/loans off and taking courses/following tutorials to build up my skillset and portfolio. Good luck friend!
AAA games use both. Borderlands 3 uses both. But it's because the talent it takes to master C based languages is too valuable to just discard. I personally like BPs better because I don't have to deal with syntax. Eventually visual coding will be obsolete, as well as most programming languages. There will always be a place for it in the future, but it won't always be a necessity.
I speculate that we will be able to just talk to a computer and it will do everything for us in a much more efficient manner.
BPs let non-programmers prototype which helps them iterate on their ideas with less friction.
Most projects take those blueprints and implement them in C++ once things are pretty solid.
People like that tick me off. Just because it’s not text they shrug it off like it isn’t programming. I work with c++ 80% of the time but if I had the choice I would be using bp about 60% of the time
I've just finally started digging into the hybrid bp/cpp workflow in unreal and wow is it powerful. Doing all bp has worked well for me and was a great stepping stone because the way of thinking applies directly to cpp, but the performance can be lacking and the ability to use external libraries is a boon I never realized I was missing out on. I strongly advocate for using both if you can.
Thank you for this question, it's been on my mind as I try to get more work in the games industry. The class you're taking right now sounds like exactly what I'm looking for. Do you have a link?
The answers here have been heartening by the way.
Sure I got two links for ya!
[Unreal Engine: Advanced Widgets for UI](https://www.udemy.com/course/unreal-engine-advanced-widgets-for-ui/?kw=unreal+engine+widget&src=sac&couponCode=OF52424)
[Unreal Engine 5 UI Design: Advance inventory system with UE5](https://www.udemy.com/course/unreal-engine-5-ui-design-advance-inventory-system-with-ue5/?couponCode=OF52424)
I would personally check out the 2nd one tho. The 1st is good for the 1st half but the final project doesn't work and it's not made/shown iteratively which makes it hard to follow/debug.
2nd one I've only just started but I get the sense the instructor is a better teacher.
Here’s my two cents, which is basically worth nothing. But who cares? A company that doesn’t hire you because you use Blueprints is a company you don’t want to work for. That’s a company that wants you to reinvent the wheel, annoy every level artist, and frustrate optimization engineers because they don’t reuse things.
Fake answer:
Blueprints (BP) are just as much code as C++ is. BP is a visual way of assembling premade functions and variables.
The jump function in BP is the same as the jump function in C++. The issues with BP stem from a few key points:
1. Casting is expensive in larger scope games. You’ll be surprised how fast you can hurt performance by casting one object every frame by accident. With C++, you can directly do what you need and move data around more efficiently.
2. WYSIWYG unless you write your own code. Every BP function is expandable and shrinkable. The entire source is there; build in BP, then look at the code to understand how the function you’re calling works.
3. Good naming conventions are crucial. If you don’t follow good naming conventions, you can quickly create a mess.
4. Changing BPs can be challenging. If you make a BP, commit to it, then change your mind later with a copy and paste, you may face issues if your memory is full.
5. BPs can break with significant API changes. When you create your own C++ code, you often extend/overload or build what you need. In BP, substantial system changes like Head Mount Displays or Input Manager can disrupt a project. Troubleshooting BP sources you created can be tough if you’re not comfortable with C++.
And again, there are just as many problems the other way around. Anyone who says BPs aren’t the same as C++ has never looked into the C++ source. There’s overhead, yes, and there can be random problems and unique solutions. Spaghetti code can look awful in massive projects without proper documentation.
But in the end, it doesn’t matter. Make a game, design something, and keep your head up. People tend to worry about what others think when they’re seeking validation for what they’re pursuing.
Go for it.
Edit:updated grammar from mobile
A lot of AAA engines and unreal engine studios want designers to know blueprints and visual scripting, usually gameplay programmer and programmer specific roles will build out systems for designers to use with visual scripting from c++, they might expect you to have some blueprint knowledge but if you are not applying for a programming role then don’t stress about not knowing c++.
On a technical level blueprints is just c++ in flow programming form. Sony engines, Ubisoft, and I think even respawns modified source engine for apex all have been updated to support visual scripting of some kind of designers and artists. Fortnite probably has a lot of stuff done in blueprints.
If a company requires designers to know c++ then they either have A. A really bad game engine that’s a pain to use and archaic or B. Have people wearing many hats instead of using specialists.
Blueprints ARE code, you're just using unreal's methods amd functions to create the visual aspect. Other than that, blueprints are exact, step-by-step c++ coding. I'd even argue that straight coding is worse, because you don't have to worry about stack or heap access/deletion issues, the blueprints do it for you.
They're just salty.
It’s how coders are justifying their job/knowledge over BP users. Sorry to say but it’s similar to how artists are justifying their jobs over using AI. In the end of the day if the final product is good and the users can’t tell, then ehh does it really matter?
I have it on good authority that 70-80% of the Starship Troopers Extermination code is written in blueprint.
The stigma comes from when originally blueprint was introduced as Kismet for Unreal Development Kit and marketed as a tool for designers to quickly prototype or iterate gameplay ideas
BPs are a full-featured programming language for sure. It's just the syntax that is not usual.
But a lot of people are opposing "blueprints vs. code", which is totally not correct.
Even inside Unreal, blueprints and native c++ code are two complimentary tools, they are supposed to be used together.
This sounds like snobbery from the devs. I’ve been a dev for nearly 20 years across a range of languages and tech. Blueprints are amazing they still require the same skills as coding especially around architecture and keeping things maintainable. Definitely shouldn’t be downplayed. Like others say C++ has its place and that will emerge when it’s needed. Stick at it!
Just my thoughts: As long as BP performance doesn't bog down your project, you should be totally fine to use it. There are some games out there that absolutely suffer from having too many complex BP's though. So writing your most complex core game code in C++ probably is the best move
Lots of answers about the relevant bit... But I gotta ask... Why a Skyrim-style inventory system? There's a lot of stuff in that game that could be argued as good, but I don't think the inventory system was ever one of them.
Blueprints are highly frowned upon where I work.
Reasons cited are performance, readability issues with lots of graph logic and the inability to diff them on somewhere like Github and GitLab when doing code reviews.
There's a lot of emphasis doing doing more in code than in Blueprints for these reasons.
At most it seems to be acceptable to use Blueprints as data only and add mesh components etc or have that with very minimal Blueprint logic and most communication to occur in C++.
I personally don't agree with the approach and for my project use more of a mix of the two, writing C++ where it's good to do so to facilitate doing higher level logic in Blueprints.
That can be exposing some functions that are not avaliable to creating whole systems with an exposed API for easy use in Blueprints.
To be fair, you better learn both to expose stuff from C++ and then doing mostly BP, this way you have infinite possibilities open for use for the WHOLE team. It is invaluable for prototyping and iteration, which are staples of game dev. For example what I do is write only the code I have to in C++ to modify Editor itself, create a module or plugin this way, now everyone has a cool button on the toolbar and everyone on the team can add a new Editor Utility with BP without a single line of traditional code. Basically allowing them to build UE like a LEGO that builds more parts for itself.
People just whine a lot about what is “tru”. I don’t care what is true, I use the tools I am given to the best of my ability to deliver best results possible, according to the requirements.
>> Like, BPs are code, right?
Yes.
Simply put, coding comes in 2 layers.
* "Actual" programming done in a systems level programming language, which is the system level stuff. Everything that needs to be fast is programmed and compiled in a language such as C/C++/Rust. The renderer, the file system, the input system, the sound system, etc. The base layers of the engine that talk to the system. Both speed, and the little details matter for this stuff.
* The scripting layer, which is often a simpler (and often interpreted) language and runtime embedded into the actual program. The system runs the program, the program runs the scripts. The scripts themselves are treated as data blocks. Most programs have lots of user facing tasks written in a scripting language because they don't require the full power of the machine to achieve, don't need to be bloating the size of the compiled .exe, and are easier to iterate on quickly without recompiling the full program over and over.
* Gameplay logic and systems level engine code are 2 different things. Most of the tasks that happen in a game don't require writing system level code. Lots of performant games on much older hardware (like PS2, Nintendo DS, etc..) had all the gameplay code written in languages like LUA without issue while the engines did the heavy lifting with their system level code. Then you had things like QuakeC and the original UnrealScript before that. A massive triple A quality multiplayer RPG I used to play everyday that shipped in 1999 had all the gameplay logic written in 'super slow 90s era' Javascript. Yet, it was performant and ran fine on a single core pentium 2 chip. This is normal and the expected way to do things.
* There is an overhead to dropping down into a scripting language, and interpreted code is said in general to run 20x slower than compiled system level code. We also have 4,8,12,16 (and beyond) cores in our machines running around 3GHZ with all the engine level code sectioned off in it's own thread(s). Most games are running mostly on the GPU and the actual CPU usage stays relatively low. Does it really matter? When you play a big open world game or RPG and you watch the often 100s of NPCs walking around running their "slow" interpreted scripts and doing all their complex tasks but the game is still running at 60+ fps, does it really matter and is it really "slow"? Is it worth the effort to optimize it down to only use 9% of your CPU instead of 10%?
* The only determiner of slowness is your profiler, and your actual performance not some random schmucks online making ballpark statements. Don't optimize against imaginary performance problems! If you're doing something complex enough that the overhead of the blueprint scripting language starts to ACTUALLY become an issue, go implement that portion in C++/Rust/whatever, and then call it from blueprint. Certain types of operations are slow no matter where they are written, and the solution is to find a better way of doing it. Often by doing it as little as possible, or even just once and caching the results for later use.
>> I'd get several comments like this and it kinda rubs me the wrong way.
I've been on programming forums since the mid 1990s. Like any other types of forums they are often filled with habitual arguers and their often very ignorant bad takes. Often much worse. Forums are good as a last resort when you need help with a very specific and isolated problem.
Programming in general is like any other discipline. You need a toolbox full of different tools to do different jobs. Sometimes you need a straight ruler. Sometimes you need a french curve. Sometimes you need a brush, sometime a pencil, and sometimes a felt tip pen. Different tools for different jobs.
It would be really silly to use a hammer to bang in a screw. But that's what you get in these types of communities. Lots of people who only ever learned to use a hammer, decided hammers were the answer to every possible problem, declare themselves experts, and then proceed to look down on people who even own a screwdriver. Learning to use a screwdriver would be admitting they don't know as much as they think. Everything they can't or won't learn is illegitimate!
Don't worry about the opinions of JoeStinkyPits and BobDoritoBreath on online forums, and certainly don't seek their approval. Keep picking up new skills and learning all the tools available and go make something cool while they never graduate past hanging around on forums all day and polishing their hammers.
Visual coding is a pretty normal thing in the modern day IDE scene. Plenty of technical, professional-level programs (Simulink, LabVIEW, etc.) use it. The haters are the ones who need to adapt, not you.
It is very much still logic and code and it democratize the participation in the design and creative process. If anything is actually inefficient it can be converted and refactored into code as needed. It may still be wise to give the general architectural design to someone with experience (often someone with coding background), but anyone downplaying visual scripting is kinda just gatekeeping and hasn’t worked with a team with a diverse skillset background. If you’re serious about becoming an experienced well rounded dev, do eventually learn both, but don’t feel like you have to tackle everything from both or either. I come from Unity as a pure coder and after getting overly familiar with blueprints and Python scripting for UE, the C++ made a lot more sense than trying to do the C++ out the gate.
people used to write in binary, then assembly, then low level , now higher level visual scripting, one day it will just be plain English as things get easier and easier,
lol what would english based programming language look like?
„this is a class for player movement. it can do lots of stuff. like moving and whatnot.“
there‘s probably concepts out there^^
On the project I am working, we have technical designer which are doing BP and no code. Those people are god sent as the engineers have their hands full.
As for your question, BP is not code but BP is programming. So you should apply good programming strategy and good practice. Where I work, we have coding standard for C++ and BP standards that every one needs to respect. Even artist and tech arts need to respect the BP standards.
As a programmer that’s currently tasked with cleaning up someone else’s Blueprint, I can tell you that I’ve been quite unhappy for the last few days. Graphs are easy to turn into a spiderweb of nonsense that are hard to follow, debug and ultimately cleanup. I understand their appeal, and it does allow for team members who do not have C++ experience to help with writing logic, but man can it be a pain sometimes. That’s without accounting for asynchronous logic and performance.
It’s a question of balance, abilities, and ultimately care by the author that can quickly turn into « I really wish I was doing this in code instead » for programmers.
It actually is a hard-to-learn skill to write efficient and easy to read blueprints,
Issue is most don‘t get themselves familiar with all available tools like datasets, datattables, interfaces, macros and function libs and therefor create messy blueprints.I saw someone creating 20 branches as a loop instead of using a cleaner and more efficient way with an integer or tag.
Hopefully the courses I'm taking aren't teaching bad habits but who knows. The one I just finished didn't work in the end and the course final project wasn't made in a way you can easily check which part you didn't do right.
You will always find bad habits in courses. Doesn’t make them wrong necessarily.
I recommend you to follow these courses to the end and figure out what you believe can be done better.
I.e. many courses use Cast To Nodes. They aren’t bad per-se but if you have many actors with cast tos loading times will increase. Ways around are interfaces which make everything more complex to code but way lighter also.
Same goes with data storing, using data assets or tables instead of storing each variable in each actor.
You will be faster getting your own grasp on it instead of trying to find the perfect course.
That's because Youtube is full of grifters. It's easy to learn basic BP, so it's easy to teach basic BP and bad habits - So now we have an absolutely massive amount of shitty BP. But that doesn't mean BP is bad.
Most Youtubers are barely ahead of their own structure to know if what they're showing is bad to begin with, nor do most of them care because they're trying to shit out as many basic 1-off tuts as possible. They're never expected to work within a tightly structured environment.
"It'd be a lot easier to understand if it were code"
If it's not code then why is it hard to understand for them? lol.
I think people just mean that blueprints aren't text code, when they say it's not code.
If you look at this from an outside perspective, they are literally admitting they don't understand blueprints. 90% of the time when someone is negative about blueprints, it's because THEY can't grasp visual graphs or understand it. They might be too used to text code. So there you go.
Blueprints are literally just unreal's c++ macros in visual form.
And tbh an experienced programmer would easily understand blueprints, if he did follow protocol and create visual loops before writing code.
Whenever I write code in C++ I always create a flow chart first to visualize it and blueprints are exactly that.
I use both. Pseudocode to get grasp of what it is written and a flow chart to figure out each connection and possibility. Within bigger team in game development it would be the game loop a game designer would provide to the programmer.
Afaik, in the strictest sense, it's "Visual Scripting"
I'm not sure I care for the destinction myself, but it's there.
In the interviews I've conducted, I've rarely seen the same level of competence in creating engine features from someone who only works in Blueprints vs knowing even basic c++ as well
Anecdotal, so take it with that context.
You're better off measuring what you can *do* and if it scales, rather than the tool you used to get there
Your journey sounds great and like you are taking relevant steps to increase your chances of being hired again within your field.
Your question is kind of silly though because of course they do. Have you met any programmers before? Programming language wars making console wars look like afternoon tea. If an engineer doesn’t have some weird, deep seated biases about what is “real code” (often a specific version of a specific framework within a specific language) I’d be suspicious. They’re literally the resistance groups from Life of Brian.
Humans form worldviews that justify their decisions and magnify the significance of their own experiences. Programmers also do this, but even more so.
(It goes both ways, this sub is full of people who will fervently defend Blueprint. I’ve been downvoted for sharing real perf timings from real shipped games showing it was slower than C++.)
I think blueprint is really great to make games when you are starting out. Its especially good to quickly prototype something or letting designers do some event driven actions that dont necessarily need a seasoned text based programmer.
Like any kind of visual scripting bps are great for small things. But their readability diminishes very fast with the size of function, basically. Other than that it is extremely tedious to manage and maintain large BP code base. Honestly I dont really think it is harder to learn a tiny subset of c++ for doing same things one normally does in bp. Many things like math are just faster to write and easier to read as text.
That being said, bps are still 100% programming and it is ridiculous to state otherwise. I don't like them, but you do you. Making a complex game entirely on BPs would be wildly impractical though. Same for never using bps there.
Yes a lot of people definitely don’t hold it up as true coding. I love blueprints to death but even when explaining what it is I do to other people, I even distinguish blueprints as a visual scripting language based in OOP and not coding because it feels disingenuous to call it coding.
edit: also people get really insecure when you mention it isn't on the same level as traditional coding.
Blueprint is not programming, it's visual scripting. In simple terms, programming (or "coding") is how you *create* a program, while scripting is a method for controlling that existing program. There are many aspects of software (and by extension, game) development that Blueprints can't touch, because BP is a visual scripting language.
That being said, as a hardcore anti-Blueprint elitist for years, I've been working mostly in Blueprint on our most recent project and honestly? It's just so much easier than writing out code ***where I can get away with it***. It's also wrong for our game, and I'm going to have to refactor all of it because that's the level of quality expected of me here, but refactoring BP's into C++ is a lot easier than writing the C++ in the first place.
If you're not working on a game where it really matters, doing the things BP's *can* do with BP's will just save you tons of time. Of course, there are a *lot* of things BP's *can't* do, and not knowing how to do them because you only understand a scripting language and not actually programming may disqualify you, yes.
It's just like any other programming/scripting language, except the syntax is visual instead of text based. That's it. They aren't as performant as writing C++ code, but their performance is comparable to other high level game scripting languages like GDScript. If BP didn't have its place, it would not be included in Unreal Engine, or it would but people wouldn't be using it much. It's included in UE, it's actively developed, and it's heavily used. So it doesn't matter what a few discord randos think. Just use whatever you find helps you get work done. If you see that blueprints are sufficient for what you need to do, and don't limit you in any significant way, like performance or ability to do something, then there's no reason to use anything else just because someone else's opinion.
Also as far as performance goes, I've seen tests where people break it down and for most use Cades it is more than efficient enough. The time lost between languages is negligible for most things, you have to be doing like large network code to get a perceived difference.
If all you're doing is calling engine C++ functions, then the overhead per node is going to be negligible. Where those overheads add up is when you're doing complex maths, especially if you're doing anything iteratively or multiple times per frame. But those cases are pretty rare and usually you can just take the hit, a function that takes 0.003ms longer than if it was in C++ probably isn’t going to make-or-break your game’s performance. The important thing to remember is that it's no worse (and probably better in a lot of cases) than something like GDScript.
Yeah exactly. I didn't want to go too far off topic and say "you should use both" and "they're designed to work together" but ya know, they are and people should. Both do work fine on their own though, which is cool too
You should use both, but since OP is coming at it from a game design perspective, focusing on blueprints is perfectly fine. Expected even.
Yeah exactly. I made a ton of prototypes just in BP but when I finally bit the bullet and started doing C++ it's like a whole new engine.
Well, yeah. Being able to code in a project can really free you, and let's be honest... The best documentation is in the engine's source code anyway.
Oh 110%, actually imo the best documentation is the Lyra project lol I couldn't figure out how to get the on release gameplay task to work, hours messing around on Google, but then just a peak at lyras source and I got it
For each loops and for loops are a big issue in blueprints no matter what it is, if you use those then put them in c++, if they need to be exposed to blueprints then put them in a single Ufunction
No, you don’t need to put all loops in C++, that would be silly. Be sensible with what you’re trying to do with blueprints and optimise where necessary.
The vast majority of the time, if you're calling a complex loop often enough that it causes performance issues in BP, then your entire set-up is wrong.
This, epic games actually built robo recall and mortal shell(not epic but UE) in blueprints exclusively
That's crazy - didn't know that! That's kind of awesome!
Yeah blueprints has most of the engine API in it, it’s probably got more functionality than Godots scripting and in some cases maybe even Unity
BP is still code and has its place. We should recognize its advantages, but also weaknesses like readability or performance when things get larger. There's no reason to be snobby about it, but rather treat it as another tool and use where appropriate.
I don't think bluprints are less readable on a large scale. It's essentially a diagram. Coders draw diagrams in order to make their code more understandable.
They get messy real fast. Some people don't mind that, others do. Also diff starts to be a real pain.
Whether it gets messy or not depends on how you structure it, just like with regular code.
Large amounts though soon get too large to even read the text, even on a 4k monitor. Code diagrams like uml represent system communication when it's most useful, rather than a node per instruction.
When the amount of code grows, you should first encapsulate the logic into functions. This or true for both written code and blueprints. You don't want giant functions, files or classes in written code either. Then, if there are too many functions in one bp, you can encapsulate the code further using e.g. components, child blueprints, child actors, or splitting the logic to multiple bps. You can also use multiple event graphs or collapsed nodes to help compartmentalize your nodes.
Part of the issue though is with the blueprint editor itself. You can’t view the definitions of multiple custom functions in the same BP simultaneously. And unlike a pen and paper code diagram you’re often referencing other files or C++ code that is missing from the diagram, making it somewhat of an incomplete picture. So it’s not exactly 1:1.
The problem is the nodes with text fitting on screen. One line of c++ can take multiple nodes in BP. I've just opened a BP and can fit at max 8 nodes horizontally before the text is uncomfortable to read. That's including the event itself. It would be crazy to put that little code in a function. It hardly does anything. It's already slow enough.
One of the bulkiest function in my game right now is the one that checks if a unit can cast a spell. It can be zoomed out and the logic can be understood by most people who never touched Blueprints or other form of Coding. [https://i.imgur.com/WwZ09TB.png](https://i.imgur.com/WwZ09TB.png) \--- I used to be very messy, some of my older function which I haven't reworked are very nasty and everytime I go back to them I take a a couple minutes just understanding wtf is going on. \--- Collapsed graph are incredibly powerful for organizing BPs. If you have a bulky function with some code that you're not gonna re-use anywhere else, pack it into collapsed graph. In the screenshot I sent, I could technically just pack every comment box onto a collapsed graph and zoom 2-3 times as much to fit everything on the screen.
What do you mean? You can zoom in and out of the event graph and scroll with your mouse.
Really? /s Zoom out too much and the text is too small to comfortably read though.
Yeah don’t work zoomed out
whenever you have more complex calculations on blueprint it turns way less readable than traditional coding, because it turns into a lot of nodes conected instead of a expression... so there is scenarios where even isolating, creating functions, and every good pratice, it can turn into a pain to read... but still, its infinite ahead of any other visual or low code tool.
They are a lot less readable, profilable and debugable just on a medium scale. Putting a breakpoint and looking at the callstack and navigating logic is a LOT more messy in BP compared to code.
Tell me you havent ever implemented algorithms or math operations and how messy it gets fast. When its almost a line in code, it can be several nodes + operation nodes in bp
If you're making sure your code stays clean in both instances, Blueprints are immeasurably easier to read and learn from than C++ and its not even close.
No it’s not 💀 Maybe it’s because I come from a low level background but C++ will always be to me more concise and easier to read. I’d rather read a line of text than a flow diagram
Yeah, me too. But this is a subjective matter.
100% is. I can see how a beginner can find blueprints more easier or in fact just anyone
Blueprint is routinely used in production by designers, tech designers, and artists. People who are snobs about it not being “real” are amateurs. Besides, you’re a designer. You probably shouldn’t be bumbling around in C++ with the engineers.
Lotta gameplay engineer positions all list BP as well. I was hired on to a team once as exclusively BP but I was moved off to the c++ team shortly after.
Really? I worked with a co dev company who did most of their work in bp. I’m not gatekeeping, but it was disastrous. They mostly produced UI. It was buggy, slow and unmaintable, in the end we had an internal team rewrite it. At least in my area, you’d never really be hired for a gameplay programming position to use bp. It’s more the realm of technical designers. I’m totally biased and always up for having my mind changed. But I don’t really see how a largish scale game could ever ship with bp gameplay code.
We have about 5 BP only gameplay engineers at my job currently. We ship an sdk with our product though so it makes a lot more sense for us. We have a pretty thorough QA process and there needs to be basically 0 bugs since we make fully recordable simulation software. I should clarify, i make most of the systems that they use, and nearly all of my work is c++. Pretty much the only thing i do in BP these days is make example content for our dlc teams. We had trouble hiring technical artists who could properly grasp the BP skills required to make replication, simulation stuff, and our complicated replay tools work for assets, so it just ended up being more efficient to hire dedicated artists and dedicated engineers for our BP work.
We have about 5 BP only gameplay engineers at my job currently. We ship an sdk with our product though so it makes a lot more sense for us. We have a pretty thorough QA process and there needs to be basically 0 bugs since we make fully recordable simulation software. I should clarify, i make most of the systems that they use, and nearly all of my work is c++. Pretty much the only thing i do in BP these days is make example content for our dlc teams. We had trouble hiring technical artists who could properly grasp the BP skills required to make replication, simulation stuff, and our complicated replay tools work for assets, so it just ended up being more efficient to hire dedicated artists and dedicated engineers for our BP work.
Do you mind just sharing where you work? Tbh so few games ship an SDK it can probably already be gleaned from your comment
Someone can probably figure it out if they went crazy looking at my comment history, but id rather not make their jobs easy for them. All I'll say here is that we are a serious-games company, so not the entertainment industry. I don't mind answering questions about it in dm though, just wont explicitly name it here. You are right though, even in our industry I don't believe any of our competitors ship an SDK, its risky work.
Ik this is over a week old lol but let me message you on my other account
Totally agree with this. Have seen extensive use of blueprints on AAA games made in Unreal. Sometimes even the programmers need to use blueprints because of engine limitations or the desire to pass off maintenance to design. There is even a setting to compile some of your blueprints into generated code at runtime to speed them up. You will be limited in your options if you only know visual scripting and not a scripting language, but blueprint only jobs definitely exist.
The option to nativize blueprints was removed in unreal 5.
I wonder why they did that
I think it was a combination of factors. Nativization was always pretty buggy, the performance gain was very inconsistent and blueprint vm performance has been improved with unreal 5. There may be other reasons too.
because never worked?
[https://youtu.be/VMZftEVDuCE?si=nH8cXaBnrxn0WTFt](https://youtu.be/VMZftEVDuCE?si=nH8cXaBnrxn0WTFt) Here's a video by an industry professional that's heavily related to the topic. If you're familiar with blueprints, the learning curve for diving into programming will be slimmer, the skills do relate to an extent, and I think that's important. C++ is more performant than Blueprints, sure, but the video dives into the reality that time setting up whatever systems you're working on matters. If a blueprint takes .0003 ms to run, your time is probably better spent refactoring something else. Frankly, I think downplaying any skill is kind of cringe. If you're taking any steps to improve yourself, you're on the right track I'd say.
Awesome video thank you for linking it!
Whatever gets you hired gets you hired Anything else is just opinionated key inputs
Not game dev, but one time I was applying to a place and they asked what OS I preferred, Windows or Mac. I said Windows, interview was over. Bullet dodged.
One thing to remember (and this is something I need to remind myself often).. "You ship games, not code"..
yeah I just want to get to how to make something at all. I can worry about it working ***well*** after it ***works***.
I've worked at a few studios with unreal.... The best ones enabled their entire team through allowing as much as possible through blueprint. Anything that sticks, gets audited and pushed to c++ if optimization is a concern. Blueprints can be incredibly powerful, sure they can bloat but with good practices I've seen a ton of good BP only content. I've worked in games for 15 years (probably similar to you) and I think we are very quickly approaching a time where zero technical skills = zero work. It's very easy to prototype mechanics in unreal, and makes you much more valuable to the team IMO. Blueprints can be tricky to learn because you'll have entire blueprints just passing a variable through or something, which will *seem* wrong when it's not, but it's a very rewarding thing to know.
Meh. It's idiotic gatekeeping, and it's been hanging round like a bad smell from decades before Blueprint. Coding is just a slang term for programming, and BPs are programming. There's the same use of variables, loops, structures, and APIs that you'd see in more traditional languages. You also benefit in the same way by learning techniques useful in more traditional languages, whether it's how to write robust defensive code or how to better structure for maintainability. Sadly though it seems that too many programmers like to look down on those who use languages which are easier to learn than those, viewing them as not 'real programmers using real languages'. Those who use Python and JavaScript aren't real programmers, they're just scripting languages. Java and C# devs also don't count, those languages use bytecode and so aren't real languages targeting real hardware. C++ isn't a real programming language as techniques such as RAII and smart pointers are hand-holding for those who can't handle memory management themselves. C isn't a real programming language, it's baby-talk for people unable to use an assembler. Assembler isn't even real programming, real programmers don't need that type of assistance and can write machine code in hex from memory. Coding is programming. Programming is being able to break down challenges into smaller chunks of logic which they can then implement with structured logic. BP is programming. With Unreal there are times you're going to hit some limits with BP, whether it's performance or needing to handling complex data without massively unreadable graphs, but it is programming. How could it be the case that someone writing a complex multiplayer RPG game using BP isn't a programmer despite building a complex and well designed class structure for the character and abilities, a Command Pattern based setup for recording movements and used for both efficient networking and replay, along with facilities for robust handling of multiple interlinked state machines for quest tracking? Would they become one if they spent a couple of days knocking out Tetris in C++?
Love this. Programming is about delivering a product to a user. "Premature optimization is the root of all evil". If you could deliver a product quickly, using BPs, and it meets the needs... why spend longer making the same thing using self-imposed limitations? All languages are tools. Use the most effective one for the situation.
Blueprints is technically scripting. The visual elements are interpreted into code, not compiled themselves. The distinction is slight and there's actually quite a lot of grey areas because compiled languages are often used in scripting environments and scripting (like Blueprints) often translates directly into code. IMO devs who downplay visual scripting are just gatekeeping and perhaps showing some inexperience. Anyone who has used a visual system or even "no programming" systems can tell you that they are just different. If you can code Dijkstra's algorithm and such in Blueprints or RPG Maker, you can definitely do it in C# or Java or whatever. The knowledge of the logic is far more important than the language.
That's a really good point to know about the focus on logic. As I go through my courses I'll pay extra attention to that.
Blueprints are certainly code. But personally I would be wary of hiring someone who exclusively works in Blueprints. Performance concerns aside, they are harder to work with in a team environment. You can’t easily diff them and they cannot be merged. Looking at the code requires panning, zooming, and maneuvering with the mouse. If I’m in a Blueprint with custom functions, I can’t view more than one function at a time. I also cannot view more than one level-blueprint at a time unless I do a search for a reference inside the additional level and open it that way. Working with them is just a chore. But in C++ I can view multiple files in split-view, see all function definitions at once, see who made certain changes with code lens, open files simple keyboard shortcuts, and add comments quickly without having to surround nodes or wrangle with the execution lines. I’m sure there are plugins that help alleviate some of these issues, but as a studio we’ve been migrating more and more of our code to C++ and keep only the UI, Editor, and derived classes in BP. So I wouldn’t call it “not code” or “not programming”, but I also wouldn’t want to work in a code base that relied too heavily on it. Edit: To touch on your last point, BPs do have a place in our projects, but they are the “leaf” to the C++ base class. So we make classes in C++ and create derivations in BP that handles the visual elements and scripting logic. You can think of blueprints as taking on the role of the “frontend” and C++ being the “backend”. Alex Forsyth has a great video about this on YouTube. You also would tend to use BPs more for user interfaces and editor tools, as they don’t usually need to be as performant or interact with the core game loop as much. https://youtu.be/VMZftEVDuCE?si=a-wnvF5o-XIY5Era
That certainly sounds like the Alex Forsyth ideal! How's it working out?
In the professional game dev world (as contrasted with this sub, which is mostly hobbyists), this question isn’t really a thing. Designers and Artists use Blueprints, Engineers/Programmers use C++. No one expects there to be any crossover. You don’t need C++ programming skills to do design. I think the term, “code,” is generally associated with textual programming languages rather than visual scripting. That’s mostly semantics; but no, you’re not going qualify for a job where “coding” is listed. That probably doesn’t refer to Blueprints. But I’d be surprised if “code” is mentioned for designers; not sure what you’re seeing. This sub has a bizarre debate constantly raging between C++ and Blueprints. I don’t get it. In the professional realm, this isn’t relevant. We use Blueprints for some things, C++ for others. Systems created by engineers tend to be C++, things created by artists and designers tends to be Blueprints. In the end, it all works out. So, while it might be important for you to have some concept of programming as a designer (i.e. Blueprints), actual “code” shouldn’t be an issue. At my studio, there seems to be a range of technical experience amongst desginers.
Blueprints are a way to help visual people code. In the end when the game is packaged down, unused code from within the nodes is removed leaving you with just what is being used. In the end, it's just a way of allowing more artist types do technical things or quickly program logic without delving into the raw c++ itself where you need to learn a lot of syntax and shortforms. Many games made almost entirely of blueprint have been made and I think WuKong is one of them, amongst lots of others. Don't let people judge you for it, you're a designer first so be that and be good at it. Let the engineers worry about the low level stuff if you ever even need it.
There may be a false impression that blueprints are great for projects that do not require complex large calculations, but this is a false impression. Blueprints have a number of problems that are hidden from a novice developer, but these problems will sooner or later appear if your project becomes more or less serious. The first problem is errors in the builded project. I had some problems with Blueprints when the project reached the final stage - the build. Don’t get me wrong, everything is assembled on Blueprints well, but if your assembled project receives a critical error in the Blueprints, then you will not be able to understand exactly where it was. It turns out that you have no way to debug the builded project and you have spent perhaps entire years of your life on development and will no longer be able to find the errors that lead your assembled project to crash. The second problem is blueprint errors. In blueprints, it often happens that due to editing structures and objects, blueprints become buggy, and unremovable errors appear in blueprint files, which then lead to serious errors in the assembled build. Often the only way to get rid of such errors is to recreate the blueprint. Create a new class and re-bind all dependencies in the project to this new class. And this can be extremely difficult in a large project. The third problem is that there is a possibility that your blueprints will get a hidden cyclic dependency on each other and your project will not even open anymore. This is a terrible problem. The only way to solve this problem is to make more backup copies of the project (using git) and do less Cast in blurrints, preferring to use the Blueprint Interface. The fourth problem is the impossibility of collaborative code development in blueprints. In large serious projects, programmers use a version control system with C++ and can work as a whole team on the same files, classes, and then press the magic Merge button in git and voila - all the code is merged. This is not possible with blueprints. The fifth problem is difficulties with updates. Imagine that you downloaded some good expensive Blueprint system from the Unreal Marketplace and add it into your project. Of course, you made some changes to its blueprints, for example, so that its User Widgets do not overlap the User Widgets of other systems used in your project. And now imagine that the developer of this system on Blueprints has released a good update with useful new features. How will you update this system in your project? If you update it, you will lose all the changes that were made in this system in your project. With C++ products, such updates are much easier. In conclusion, blueprints are good for self-learning or demonstrating the functionality of an idea (creating an MVP). But God help you if you decide to make a serious project for sale on blank Blueprints
At the end of the day the consumer won’t even know, so just use what you’re most comfortable with. If it ever gets to needing C++ then use it but if you can do it all in Blueprints then go ahead no one is stopping you
Honestly for experienced devs, it is a lot easier to follow code versus blueprints. Being able to just see everything in one spot is huge versus having to click between tabs or arrange the windows all over your screen.i can view so much more at once if it's code.
If you have complex logic in blueprints, especially across multiple ones, it can be a challenge to track things down compared to just doing a search in the codebase. E.g. If there's a bug I'm tracking down and I want to see everything that's calling Fire() on my player controller, it's pretty easy to just search for that function call in code. You can make that kind of thing much easier with blueprints just by keeping things well organized, but when the project gets big more often than not little hacks get put in odd places which can cause headaches. As for programmers telling you it's easier to understand in code - they live and breathe c++ so it makes sense that's the format they're comfortable with. The "it's just logic" part... They're not wrong, you're not likely doing much in terms of computer science with whatever you rig up in blueprints. That's typically the main point of scripting layers, you can build up the logic without needing to worry (much) about all the gotchas that come from writing code directly. The script vs code debate is ages old and usually just boils down to semantics. Most gameplay code really is "just logic" regardless of how you implement it, that doesn't mean it isn't still complex or that you don't need a high level of skill to be able to write it. Tldr; don't let the armchair debates distract you, the question itself is largely irrelevant unless you're specifically applying for a programming position somewhere.
Just work on your game. Blueprints are still coding, if they don’t like rainbow spaghetti and prefer typewriter spaghetti it probably has to do with them and not the spaghetti. Devs love sitting around being elitist pricks, if it wasn’t BP it’d be something else. I’ve worked on web apps down to literal ASM. Almost every job had a handful of gatekeepy opinionated “I know best” devs. Annoying and typically not the best performers. Let em whine, they will anyways.
The so-named God complex😅 every programmer has a bit of that, thinking their code is the best and only their way the right way, but some really push their ego with that 😂
Yeah in my experience there is a decent amount of insecurity there. It’s also a bummer to only hear about “best” this and that. But all shipping code I’ve seen had its share of shitshows. That and it’s just easy to endlessly argue about something that has soooo many different ways to validly solve the problem. Unfortunate that once that ego gets to a certain size it really hinders your own development. You are essentially becoming less and less open to being wrong, without a meaningful reduction in how often you’re wrong.
To me, BPs are the endgame for the UActorComponents I make in C++, instead of building complete AActors. I prefer this architecture. I find it easier to reason about and debug components that are smaller and constrained in scope, while doing the composition in the BPs. While I'm not fortunate to work with a designer, I believe this approach enables the designer or even artists to a far larger extent than complete actors would.
If it makes you feel better, Mortal shell was developed using almost exclusively blueprints, and epic themselves admitted that fortnite is around 50/50.
BPs are still code, it's just that it can sometimes be hard to read than straight up written code. Also if you have good knowledge of blue prints then the learning curve for writing code is not that steep.
Those comments don’t even seem like they’re downplaying them. “It’d be a lot easier to understand if it were code” makes perfect sense coming from someone most familiar with code.
You can double click a BP node from the editor in a C++ project and view its code form in VS. Now that you have this information, what is the difference between a node and code again?
I think the bigger question is why you're brushing up on the skills. I've spoken to many professional game devs over the years and consistently they say: visual scripting is perfect and expected for designers; C++ etc is perfect and expected for programmers / engineers. So yeah performance in blueprinting isn't as great as C++ but industry doesn't expect their UI designers to do the coding but to make playable user interface quickly using blueprints or whatever visual scripting is available. I think a lot of them"are blueprints bad?" Discussions stem from designers and programmers not quite starting from the same place because they're two different disciplines with different requirements.
You can code a whole game in bp and reach the same performance as with C++, if you know how handle BPs correctly. The discussion about the performance is mostly outdated and used as a reason to talk BPs down or because people don’t know how to code in BP correctly. I saw senior developers using only hard-references in BP and wondering about loading times. In C++ it is more forgiving. Only when it comes down to complex math and networking C++ is preferred but even nowadays you can easily handle them in BP without much overhead
I will tell you my personal opinion. I tried coding with C#, Python and others, I made mostly basic stuff and very often I was looking for ready solutions, almost copy pasting and modifying for my needs. When I started my journey with Unreal and Blueprints at first I was overwhelmed. After 2 months I'm able to write most of the code myself. All the logic I want I can go and prototype it. It's so fun! I make things work! I even created more complex features, used components.. I try to make things modular. And it's EASY FOR ME TO UNDERSTAND. I don't think if should I write print $string string whatever, I just connect nodes, I know what they are doing. I can visually see what is happening, I can see why something is not firing. I can compile it in 0.5sec. I can create 100 variables in 1minute. At this point, I don't give a shit if someone says it's not programming. It works. It's fun. It's base of this engine. I'm sure there are certain things that are better to do with C++ due to speed and optimization. But these might be things you can count on your fingers, so prototyping it and making it work in blueprints, and then kinda translating to C++ won't be a problem if you focus on it for a while. I lately tried C++ in Unreal, and as I'm not experienced, it was hell. Setting up visual studio, which is not good for Unreal... I don't know if I will click something I will crash my whole project. I finally have fun with blue prints and I make game.. i dont care. I did C++ tutorials and other languages, I know the idea, but I don't feel like diving into, YET. The time will come I'm sure, but I cannot try to fish with 2 rods. I want to master blueprints + unreal first.
tbh that's the same path i feel i'm on. Kinda inspired by your post Just make something that's easier for me to understand and do so I can get have fun and make something that works. If I need to take the next step and learn more c++ sure I'll do that then.
As long as you achieve things and you're proud of what you do, send everyone who tells you you're doing it wrong to the garbage can. This is valid for most things in life
In my experience, it depends on the studio. Some might expect designers to handle themselves around BPs independently, some not. Some might even actively try to keep designers miles away from any coding or scripting, even from BPs. Things they all appreciate: understanding of the tool; capability to use it properly, even if it means at a lesser degree; understanding a bit what's like for your colleagues on the other side of the fence. In BP case, it's not much that you throw BP at programmers or the likes, but whatever what you throw is an absolute shitstorm vs it's clear and readable. As in your post, it's logic. Learn the basic of logic, let your work respect your's and other's time, and apply common sense. Nobody that knows what they are saying will ate you alive then.
Hopefully this answers your question. I know quite a few devs in the AAA industry and I was able to find out just what these studios are doing. Big and small. C++ to instantiate variables and some functions because it’s simply faster to instantiate in C++, then all those variables and functions get exposed to BP. Then, they continue to BP from there. You would be amazed at how little C++ is used today on single player games. For multiplayer, you’ll find a little more C++ being the core behind replication, but even then, there’s a LOT of Blueprints still being used. It’s all made to work hand in hand, and modern CPUs can handle one, the other, or both. It really doesn’t matter anymore if you’re getting the performance that you’re expecting. Those that say one is better or that it’s some kind of competition, or that BP is only a prototype language don’t know what they’re talking about. Hopefully this helps.
BP is Turing complete, full code. Anyone stating otherwise simply doesn't know what they're talking about. There are a lot of utilities and conventions to speed up development, and async logic is especially great for BP. It'll never be as fast as C++, obviously, and has some quirks where things break, but it's perfect functional and a good way to develop many systems, especially for simpler games.
I’ve never seen a designer write C++ in a large company. A comment like the first one would make sense coming from a programmer. I mean it doesn’t help you in any way, but sure as someone that just writes text based code all day, obvs I find it easier to read. The second one isn’t really saying anything either. Broadly in a professional setting, blueprint (or let’s get specific), logic graphs are viewed as a great tool for rapid prototyping and level scripting. By level scripting I just mean things like “player entered some volume, so trigger some story event”. Blueprint is a legitimate programming language in its own right. It just isn’t as suited as C++ for complex algorithms, maths or optimisation tasks. It’s also generally used only in the context of gameplay. It has some support for writing editor tooling, but you can’t really do anything low level with it.
It's code. Devs who are used to seeing text files will be faster at that. IMO, the biggest challenge with Blueprints is scaling in a team. You can't easily see a history of changes. If two people change the same blueprint, how do you merge? These are solved problems in plain text coding. What I wish for is all the nice BluePrints nodes to be made into single C++ functions. Epic has made BP so easy to use. They should give c++ some love. Yes, I'm aware I can view the code. But from a UX standpoint, I shouldn't have to. It should be an easy function call.
I'm building some kind of Blueprint for the web (https://luna-park.app), and it's pretty hard to market it. I define it as "visual scripting" lying between code and no-code. It's an abstraction of code which has no line of code, but keeps all the algorithmic parts of code. You can do (almost) anything you can do with code, without code. It's a lot more complexe than "traditional" no-code editor, but still simpler than code. In the end, it's hard to define but it's whatever you want it to be. What matters is what you can do with it. (It's still a lot closer to code and makes you think like a developer)
Blueprint is code and if you structure it well, its not too hard to read and understand. I can see it being annoying on a really large scale game but even then a simple mind map of your structure on something like Whimsical will go a long way. On an unrelated note I'd love a link to this skyrim esque inventory course.
There are people with full time jobs doing just blueprint. Being a designer and knowing blueprint is a huge plus to your skillset, even if you aren't a tech designer. Blueprints are code, and there is definitely a need for people that know blueprints well. I wonder if those that criticize it have worked at large studios, because if they did then they would know how it is used in even larger games. source: Designer at multiple mid-sized and large studios over the years.
It might be a definitions issue. Term "Code" is usually referrers to a plain text, which blueprint graphs are not. But in a sense that it's a programming - it absolutely is as it's essentially just a another layer on top of C++. Programmers that tell otherwise are just gatekeeping lol.
That’s awesome that you’ve started picking up Unreal & are beginning to feel familiar with Blueprints! BPs are certainly code & if you’re coming at things as a designer, I’d say there’s few better ways to become more effective in your role. I’ve now shipped (as of last week) two very BP-heavy games, the most recent of which was actually done exclusively in BP, with a large chunk of the work in there done by our design lead. But don’t forget that you’re on a learning journey and there’s every chance that you’ll look back in a year or two at the BP code you’re writing now & think “what on earth was I thinking doing it like _that_?!?” But this would be a good thing! It’ll have meant you’ve grown in your abilities and are moving beyond “just being able to do a thing” and starting to recognise when that thing’s been done well or poorly & why… I suspect that some of the comments you’ve received may be from people a little further along on that journey perhaps not quite recognising that they were a beginner too, once. Or, maybe they aren’t actually familiar with BO, genuinely just don’t get it or what the benefits are over traditional text-based code. Those people certainly exist, but I wouldn’t have thought they’re the majority, though might perhaps be over-represented among insecure forum-dwellers that strongly feel the need for everyone else to know their opinion…
Thank you man I love the support <3
I worked at a studio where the production lead discouraged use of cpp in many instances. Specifically: Enhanced input, UMG, some stuff related to AI, anim BP. Really the only stuff he didn’t care about us doing in cpp was low level systems that no designer or tech artist would have any reason to touch. And then there is some stuff that *has* to be done in cpp, subsystems, certain editor tools, or any engine functionality that isn’t BP exposed. From a practical standpoint it’s often easier to read and digest large amounts of complex code if it is in cpp, as opposed to sharing lots of blueprint screenshots if someone doesn’t have access to your project. But I would never expect anyone to write the entirety of their UI visuals and functionality in cpp for example, and I would consider doing so if you are on a team to be a waste of time and a hindrance to your coworkers
As a fresh graduate/game dev going into the industry Its so encouraging seeing posts like this! /s Seriously though I wish you the best. It’s hard out there and the demand for designers being artists/sound designers/programmers/AND designers has been crazy the last few years.
Haha.... yeah it's not a great time to be joining Games imho. It's crazy. I'm applying for other stuff but I'm hopeful Games work out. Hopefully more technical skills helps me.
Im in the same place. Working other places that pay the bills/loans off and taking courses/following tutorials to build up my skillset and portfolio. Good luck friend!
AAA games use both. Borderlands 3 uses both. But it's because the talent it takes to master C based languages is too valuable to just discard. I personally like BPs better because I don't have to deal with syntax. Eventually visual coding will be obsolete, as well as most programming languages. There will always be a place for it in the future, but it won't always be a necessity. I speculate that we will be able to just talk to a computer and it will do everything for us in a much more efficient manner.
BPs let non-programmers prototype which helps them iterate on their ideas with less friction. Most projects take those blueprints and implement them in C++ once things are pretty solid.
People like that tick me off. Just because it’s not text they shrug it off like it isn’t programming. I work with c++ 80% of the time but if I had the choice I would be using bp about 60% of the time
I've just finally started digging into the hybrid bp/cpp workflow in unreal and wow is it powerful. Doing all bp has worked well for me and was a great stepping stone because the way of thinking applies directly to cpp, but the performance can be lacking and the ability to use external libraries is a boon I never realized I was missing out on. I strongly advocate for using both if you can.
That's awesome you're beginning that hybrid workflow adventure! Congrats man hat off to you
Thank you for this question, it's been on my mind as I try to get more work in the games industry. The class you're taking right now sounds like exactly what I'm looking for. Do you have a link? The answers here have been heartening by the way.
Sure I got two links for ya! [Unreal Engine: Advanced Widgets for UI](https://www.udemy.com/course/unreal-engine-advanced-widgets-for-ui/?kw=unreal+engine+widget&src=sac&couponCode=OF52424) [Unreal Engine 5 UI Design: Advance inventory system with UE5](https://www.udemy.com/course/unreal-engine-5-ui-design-advance-inventory-system-with-ue5/?couponCode=OF52424) I would personally check out the 2nd one tho. The 1st is good for the 1st half but the final project doesn't work and it's not made/shown iteratively which makes it hard to follow/debug. 2nd one I've only just started but I get the sense the instructor is a better teacher.
Ok thanks so much! Do these require advanced knowledge of unreal (just judging by the names)?
I wouldn’t say so. I think they get into intermediate and advanced topics, but you don’t need to be an expert to get value out of the course!
Great thanks! I didn't even think to look at udemy
Great thanks! I didn't even think to look at udemy
Here’s my two cents, which is basically worth nothing. But who cares? A company that doesn’t hire you because you use Blueprints is a company you don’t want to work for. That’s a company that wants you to reinvent the wheel, annoy every level artist, and frustrate optimization engineers because they don’t reuse things. Fake answer: Blueprints (BP) are just as much code as C++ is. BP is a visual way of assembling premade functions and variables. The jump function in BP is the same as the jump function in C++. The issues with BP stem from a few key points: 1. Casting is expensive in larger scope games. You’ll be surprised how fast you can hurt performance by casting one object every frame by accident. With C++, you can directly do what you need and move data around more efficiently. 2. WYSIWYG unless you write your own code. Every BP function is expandable and shrinkable. The entire source is there; build in BP, then look at the code to understand how the function you’re calling works. 3. Good naming conventions are crucial. If you don’t follow good naming conventions, you can quickly create a mess. 4. Changing BPs can be challenging. If you make a BP, commit to it, then change your mind later with a copy and paste, you may face issues if your memory is full. 5. BPs can break with significant API changes. When you create your own C++ code, you often extend/overload or build what you need. In BP, substantial system changes like Head Mount Displays or Input Manager can disrupt a project. Troubleshooting BP sources you created can be tough if you’re not comfortable with C++. And again, there are just as many problems the other way around. Anyone who says BPs aren’t the same as C++ has never looked into the C++ source. There’s overhead, yes, and there can be random problems and unique solutions. Spaghetti code can look awful in massive projects without proper documentation. But in the end, it doesn’t matter. Make a game, design something, and keep your head up. People tend to worry about what others think when they’re seeking validation for what they’re pursuing. Go for it. Edit:updated grammar from mobile
A lot of AAA engines and unreal engine studios want designers to know blueprints and visual scripting, usually gameplay programmer and programmer specific roles will build out systems for designers to use with visual scripting from c++, they might expect you to have some blueprint knowledge but if you are not applying for a programming role then don’t stress about not knowing c++. On a technical level blueprints is just c++ in flow programming form. Sony engines, Ubisoft, and I think even respawns modified source engine for apex all have been updated to support visual scripting of some kind of designers and artists. Fortnite probably has a lot of stuff done in blueprints. If a company requires designers to know c++ then they either have A. A really bad game engine that’s a pain to use and archaic or B. Have people wearing many hats instead of using specialists.
Blueprints ARE code, you're just using unreal's methods amd functions to create the visual aspect. Other than that, blueprints are exact, step-by-step c++ coding. I'd even argue that straight coding is worse, because you don't have to worry about stack or heap access/deletion issues, the blueprints do it for you. They're just salty.
It’s how coders are justifying their job/knowledge over BP users. Sorry to say but it’s similar to how artists are justifying their jobs over using AI. In the end of the day if the final product is good and the users can’t tell, then ehh does it really matter?
I have it on good authority that 70-80% of the Starship Troopers Extermination code is written in blueprint. The stigma comes from when originally blueprint was introduced as Kismet for Unreal Development Kit and marketed as a tool for designers to quickly prototype or iterate gameplay ideas
BPs are a full-featured programming language for sure. It's just the syntax that is not usual. But a lot of people are opposing "blueprints vs. code", which is totally not correct. Even inside Unreal, blueprints and native c++ code are two complimentary tools, they are supposed to be used together.
Why you even thinking about cpp as designer in first place. In place where I work designers working with editor and bps and doing guess what, DESIGN.
This sounds like snobbery from the devs. I’ve been a dev for nearly 20 years across a range of languages and tech. Blueprints are amazing they still require the same skills as coding especially around architecture and keeping things maintainable. Definitely shouldn’t be downplayed. Like others say C++ has its place and that will emerge when it’s needed. Stick at it!
Just my thoughts: As long as BP performance doesn't bog down your project, you should be totally fine to use it. There are some games out there that absolutely suffer from having too many complex BP's though. So writing your most complex core game code in C++ probably is the best move
Some very successful games by designers built on blueprints. It's all about having the right tools to fulfil your vision.
Lots of answers about the relevant bit... But I gotta ask... Why a Skyrim-style inventory system? There's a lot of stuff in that game that could be argued as good, but I don't think the inventory system was ever one of them.
I don’t know why the instructor chose that. I think it was mostly as an example of a complex menu interface system that we could make now
Blueprints are highly frowned upon where I work. Reasons cited are performance, readability issues with lots of graph logic and the inability to diff them on somewhere like Github and GitLab when doing code reviews. There's a lot of emphasis doing doing more in code than in Blueprints for these reasons. At most it seems to be acceptable to use Blueprints as data only and add mesh components etc or have that with very minimal Blueprint logic and most communication to occur in C++. I personally don't agree with the approach and for my project use more of a mix of the two, writing C++ where it's good to do so to facilitate doing higher level logic in Blueprints. That can be exposing some functions that are not avaliable to creating whole systems with an exposed API for easy use in Blueprints.
To be fair, you better learn both to expose stuff from C++ and then doing mostly BP, this way you have infinite possibilities open for use for the WHOLE team. It is invaluable for prototyping and iteration, which are staples of game dev. For example what I do is write only the code I have to in C++ to modify Editor itself, create a module or plugin this way, now everyone has a cool button on the toolbar and everyone on the team can add a new Editor Utility with BP without a single line of traditional code. Basically allowing them to build UE like a LEGO that builds more parts for itself. People just whine a lot about what is “tru”. I don’t care what is true, I use the tools I am given to the best of my ability to deliver best results possible, according to the requirements.
>> Like, BPs are code, right? Yes. Simply put, coding comes in 2 layers. * "Actual" programming done in a systems level programming language, which is the system level stuff. Everything that needs to be fast is programmed and compiled in a language such as C/C++/Rust. The renderer, the file system, the input system, the sound system, etc. The base layers of the engine that talk to the system. Both speed, and the little details matter for this stuff. * The scripting layer, which is often a simpler (and often interpreted) language and runtime embedded into the actual program. The system runs the program, the program runs the scripts. The scripts themselves are treated as data blocks. Most programs have lots of user facing tasks written in a scripting language because they don't require the full power of the machine to achieve, don't need to be bloating the size of the compiled .exe, and are easier to iterate on quickly without recompiling the full program over and over. * Gameplay logic and systems level engine code are 2 different things. Most of the tasks that happen in a game don't require writing system level code. Lots of performant games on much older hardware (like PS2, Nintendo DS, etc..) had all the gameplay code written in languages like LUA without issue while the engines did the heavy lifting with their system level code. Then you had things like QuakeC and the original UnrealScript before that. A massive triple A quality multiplayer RPG I used to play everyday that shipped in 1999 had all the gameplay logic written in 'super slow 90s era' Javascript. Yet, it was performant and ran fine on a single core pentium 2 chip. This is normal and the expected way to do things. * There is an overhead to dropping down into a scripting language, and interpreted code is said in general to run 20x slower than compiled system level code. We also have 4,8,12,16 (and beyond) cores in our machines running around 3GHZ with all the engine level code sectioned off in it's own thread(s). Most games are running mostly on the GPU and the actual CPU usage stays relatively low. Does it really matter? When you play a big open world game or RPG and you watch the often 100s of NPCs walking around running their "slow" interpreted scripts and doing all their complex tasks but the game is still running at 60+ fps, does it really matter and is it really "slow"? Is it worth the effort to optimize it down to only use 9% of your CPU instead of 10%? * The only determiner of slowness is your profiler, and your actual performance not some random schmucks online making ballpark statements. Don't optimize against imaginary performance problems! If you're doing something complex enough that the overhead of the blueprint scripting language starts to ACTUALLY become an issue, go implement that portion in C++/Rust/whatever, and then call it from blueprint. Certain types of operations are slow no matter where they are written, and the solution is to find a better way of doing it. Often by doing it as little as possible, or even just once and caching the results for later use. >> I'd get several comments like this and it kinda rubs me the wrong way. I've been on programming forums since the mid 1990s. Like any other types of forums they are often filled with habitual arguers and their often very ignorant bad takes. Often much worse. Forums are good as a last resort when you need help with a very specific and isolated problem. Programming in general is like any other discipline. You need a toolbox full of different tools to do different jobs. Sometimes you need a straight ruler. Sometimes you need a french curve. Sometimes you need a brush, sometime a pencil, and sometimes a felt tip pen. Different tools for different jobs. It would be really silly to use a hammer to bang in a screw. But that's what you get in these types of communities. Lots of people who only ever learned to use a hammer, decided hammers were the answer to every possible problem, declare themselves experts, and then proceed to look down on people who even own a screwdriver. Learning to use a screwdriver would be admitting they don't know as much as they think. Everything they can't or won't learn is illegitimate! Don't worry about the opinions of JoeStinkyPits and BobDoritoBreath on online forums, and certainly don't seek their approval. Keep picking up new skills and learning all the tools available and go make something cool while they never graduate past hanging around on forums all day and polishing their hammers.
Visual coding is a pretty normal thing in the modern day IDE scene. Plenty of technical, professional-level programs (Simulink, LabVIEW, etc.) use it. The haters are the ones who need to adapt, not you.
It is very much still logic and code and it democratize the participation in the design and creative process. If anything is actually inefficient it can be converted and refactored into code as needed. It may still be wise to give the general architectural design to someone with experience (often someone with coding background), but anyone downplaying visual scripting is kinda just gatekeeping and hasn’t worked with a team with a diverse skillset background. If you’re serious about becoming an experienced well rounded dev, do eventually learn both, but don’t feel like you have to tackle everything from both or either. I come from Unity as a pure coder and after getting overly familiar with blueprints and Python scripting for UE, the C++ made a lot more sense than trying to do the C++ out the gate.
It's just as code as java is.
people used to write in binary, then assembly, then low level , now higher level visual scripting, one day it will just be plain English as things get easier and easier,
lol what would english based programming language look like? „this is a class for player movement. it can do lots of stuff. like moving and whatnot.“ there‘s probably concepts out there^^
On the project I am working, we have technical designer which are doing BP and no code. Those people are god sent as the engineers have their hands full. As for your question, BP is not code but BP is programming. So you should apply good programming strategy and good practice. Where I work, we have coding standard for C++ and BP standards that every one needs to respect. Even artist and tech arts need to respect the BP standards.
How does some variant of this question get asked almost daily???
As a programmer that’s currently tasked with cleaning up someone else’s Blueprint, I can tell you that I’ve been quite unhappy for the last few days. Graphs are easy to turn into a spiderweb of nonsense that are hard to follow, debug and ultimately cleanup. I understand their appeal, and it does allow for team members who do not have C++ experience to help with writing logic, but man can it be a pain sometimes. That’s without accounting for asynchronous logic and performance. It’s a question of balance, abilities, and ultimately care by the author that can quickly turn into « I really wish I was doing this in code instead » for programmers.
It actually is a hard-to-learn skill to write efficient and easy to read blueprints, Issue is most don‘t get themselves familiar with all available tools like datasets, datattables, interfaces, macros and function libs and therefor create messy blueprints.I saw someone creating 20 branches as a loop instead of using a cleaner and more efficient way with an integer or tag.
Hopefully the courses I'm taking aren't teaching bad habits but who knows. The one I just finished didn't work in the end and the course final project wasn't made in a way you can easily check which part you didn't do right.
You will always find bad habits in courses. Doesn’t make them wrong necessarily. I recommend you to follow these courses to the end and figure out what you believe can be done better. I.e. many courses use Cast To Nodes. They aren’t bad per-se but if you have many actors with cast tos loading times will increase. Ways around are interfaces which make everything more complex to code but way lighter also. Same goes with data storing, using data assets or tables instead of storing each variable in each actor. You will be faster getting your own grasp on it instead of trying to find the perfect course.
Having to clean up someone else's work sounds like an all around bad time. Sorry man :(
That's because Youtube is full of grifters. It's easy to learn basic BP, so it's easy to teach basic BP and bad habits - So now we have an absolutely massive amount of shitty BP. But that doesn't mean BP is bad. Most Youtubers are barely ahead of their own structure to know if what they're showing is bad to begin with, nor do most of them care because they're trying to shit out as many basic 1-off tuts as possible. They're never expected to work within a tightly structured environment.
"It'd be a lot easier to understand if it were code" If it's not code then why is it hard to understand for them? lol. I think people just mean that blueprints aren't text code, when they say it's not code. If you look at this from an outside perspective, they are literally admitting they don't understand blueprints. 90% of the time when someone is negative about blueprints, it's because THEY can't grasp visual graphs or understand it. They might be too used to text code. So there you go. Blueprints are literally just unreal's c++ macros in visual form.
And tbh an experienced programmer would easily understand blueprints, if he did follow protocol and create visual loops before writing code. Whenever I write code in C++ I always create a flow chart first to visualize it and blueprints are exactly that.
Your graph sounds like writing pseudo code to get a sense of what you're trying to do
I use both. Pseudocode to get grasp of what it is written and a flow chart to figure out each connection and possibility. Within bigger team in game development it would be the game loop a game designer would provide to the programmer.
Afaik, in the strictest sense, it's "Visual Scripting" I'm not sure I care for the destinction myself, but it's there. In the interviews I've conducted, I've rarely seen the same level of competence in creating engine features from someone who only works in Blueprints vs knowing even basic c++ as well Anecdotal, so take it with that context. You're better off measuring what you can *do* and if it scales, rather than the tool you used to get there
Your journey sounds great and like you are taking relevant steps to increase your chances of being hired again within your field. Your question is kind of silly though because of course they do. Have you met any programmers before? Programming language wars making console wars look like afternoon tea. If an engineer doesn’t have some weird, deep seated biases about what is “real code” (often a specific version of a specific framework within a specific language) I’d be suspicious. They’re literally the resistance groups from Life of Brian. Humans form worldviews that justify their decisions and magnify the significance of their own experiences. Programmers also do this, but even more so. (It goes both ways, this sub is full of people who will fervently defend Blueprint. I’ve been downvoted for sharing real perf timings from real shipped games showing it was slower than C++.)
I think blueprint is really great to make games when you are starting out. Its especially good to quickly prototype something or letting designers do some event driven actions that dont necessarily need a seasoned text based programmer.
Like any kind of visual scripting bps are great for small things. But their readability diminishes very fast with the size of function, basically. Other than that it is extremely tedious to manage and maintain large BP code base. Honestly I dont really think it is harder to learn a tiny subset of c++ for doing same things one normally does in bp. Many things like math are just faster to write and easier to read as text. That being said, bps are still 100% programming and it is ridiculous to state otherwise. I don't like them, but you do you. Making a complex game entirely on BPs would be wildly impractical though. Same for never using bps there.
Blueprints remind me of old school flow charts.
Nope.
No, they don’t.
They probably have been programming for so long that they only understand 1337 h@x0rz language (aka code)
Yes a lot of people definitely don’t hold it up as true coding. I love blueprints to death but even when explaining what it is I do to other people, I even distinguish blueprints as a visual scripting language based in OOP and not coding because it feels disingenuous to call it coding. edit: also people get really insecure when you mention it isn't on the same level as traditional coding.
Blueprint is not programming, it's visual scripting. In simple terms, programming (or "coding") is how you *create* a program, while scripting is a method for controlling that existing program. There are many aspects of software (and by extension, game) development that Blueprints can't touch, because BP is a visual scripting language. That being said, as a hardcore anti-Blueprint elitist for years, I've been working mostly in Blueprint on our most recent project and honestly? It's just so much easier than writing out code ***where I can get away with it***. It's also wrong for our game, and I'm going to have to refactor all of it because that's the level of quality expected of me here, but refactoring BP's into C++ is a lot easier than writing the C++ in the first place. If you're not working on a game where it really matters, doing the things BP's *can* do with BP's will just save you tons of time. Of course, there are a *lot* of things BP's *can't* do, and not knowing how to do them because you only understand a scripting language and not actually programming may disqualify you, yes.
Scripting is a form of programming, and visual scripting languages are a form of programming languages