I have an artist friend who is making a game on UE4 with entirely blueprints. If the blueprint system is so extensive, isn’t it faster than programming? I love programming and I’d never move to node-based game development unless I have to, but I would feel silly if I’m using an inferior system (programming).
Thoughts, opinions, facts?
there is many things you wont ever be able to do in blueprints only. So no, programming is not an “inferior system” (programming isn’t a system btw 
)
Blueprint is very powerful though but it is not an absolute of “only blueprint” vs “only C++”, discussions like these are never fruitful and don’t make sense.
You use whichever tool is better suited for your needs. Thanksfully blueprint makes a lot of stuff easier for a lot of people but when it comes down to it, to do certain things, code sometimes is a necessity.
At the moment my entire project is C++ only but I am planning to make use of Blueprints as often as possible , they are awesome!
And if your friend (or any other Artist for the matter) can finally have some fun getting things to work as a game then this is excellent!
happy coding/blueprinting
Chrys
No, they do not remove the need for programming at all. infact i say they improve the need for programming. blueprints can get you really far but at the end of the day, using blueprints alone, you’ll end up realizing how limiting they are and how powerful and freeing it is to be able to define how things work at the lowest level possible. Using one system alone will be detrimental to you in my honest opinion. You should be using both Programming and blueprints as they have their own separate ups and downs. and when used in conjunction to one another they make each other flourish into their own beautiful flowers.
Semantically I think the thread title isn’t correct since what you do in Blueprints is simply visual programming. You do the same stuff, just that one involves typing and the other doesn’t. Both exist to solve problems, both use the same logic to achieve that goal.
Along the same lines, Blueprints are only easier than something full fletched as C++ because they allow you to only use predefined and very task-specific nodes, can be dragged around and connected visually rather than having to wade through a lot of syntax. But the concepts are the same. Blueprints are even object oriented. If you understand what an Interface does in Blueprint, you’ll pretty much know what they do in code.
Granted, Blueprints and C++ are very much on opposite sides of the programming spectrum in terms of complexity. But something like the upcoming Skookum Script really is just going to be typed Blueprints. As for speed, code has advantages, at least once you know your way around the API, both in terms of speed and organisation. Blueprints can get unwieldy very quickly and if you port them to code you can see that a whole screen occupied by nodes can often be distilled into a a few lines of code.
A lot of times, yes Blueprints can be a good alternative to programming. There are many instances where that’s just not feasible, for instance complex game logic. Even for a simple game like Tic Tac Toe, that would be a nightmare to implement with blueprints compared to programming in my opinion.
Blueprints is a programming language. Unreal Engine, written in C++, is exposing a binding to this language, as well as an editing/debugging/compiling environment for this language.
Thus, anything you do in Blueprints is “programming” just as anything you write in C++ (or in PHP, or in Assembly, or whatever text-based programming language you prefer.)
Also, you can “perfectly” transport a blueprint into a textual form that looks like a textual programming language. You could then also translate this textual representation back into blueprint graphs. They would just be dual representations of the same program.
If the question is: “Does blueprints make C++ programming unneeded for Unreal Engine games?” then the answer is “for some games, yes; for other games, no.” There are no device driver or operating system bindings to Blueprints, and no generic “foreign function interface,” so if you find that you need to talk to some piece of hardware or software that the C++ side hasn’t yet exposed to blueprints, then you’d have to do some C++ programming to get that working.
The best approach is to use both. Most of your game foundation should be in C++, and Blueprint can be used to handle specific pieces of logic that either need to be continually tweaked or tweaked by designers without using code.
Blueprint is nice, and it’s fully capable of building small simple games and test-cases, but you will run into a lot of dead-ends where the data or functionality you require just doesn’t exist in Blueprint yet. The further I dug into it, the more I realized I needed to brush back up on C++ and convert a large number of my Blueprints. It’s kind of marketed as this platform you can use to make an entire game from - but that only really holds water if you’re making simple games like Tappy Chicken. The more complex the gameplay the more likely you’ll need to use C++.
That makes me feel a lot better about programming w/ UE4 now. Thanks a bunch! 