Hi :rolleyes:
I’m C++ Programmer and I want start develop my game with Unreal Engine 4, I want ask first:
Can I use C++ only for programming or I must use Blueprint beside C++ ? I have no experience in blueprint …
You can use only c++ and configs but I wouldn’t recommend it. You will save development time by using blueprints when appropriate. It is a good way to e.g. set default values and avoid hard coded values and references. Also if you use a component based design blueprints can be handy to add components and build actors.
if you use c++ correctly you use blueprint almost even without touch, i was in your same situation, and after some extensive use of blueprints, i really love, i never see before something soooo incredible, is like a perfect right hand for c++, indeed is!, if you want c++ made nodes, super useful for prototypes, right now my workflow involves just create complex functions on c++ creating funcionallity and blueprints to game logic and fun stuff
Cheers!
Blueprints are C++. They are nothing more than a Visual Interface for C++. Blueprints don’t have any knowledge of their own, instead they run C++ knowledge that they inherit, as they’re actually children of C++ classes.
So if you want to do pure C++, you can. It’s less documented right now, but it’s perfectly viable. However, ignoring Blueprints completely is a little silly as they are great for many things, including changing gameplay logic, or simply setting up children classes that modify Default Values for modified behaviors. But it’s completely doable.
When we initially started development of our game in UE4, we went straight for just using C++. It is completely viable and we found that knowing C++ made us more comfortable in this method. But as we began to understand the Engine more, there were certain things blueprints did (mainly allowing easy real-time changes) which made development a lot easier, so they are well worth checking out.
I strongly agree with these guys - I was in the same boat (not keen on using Blueprints), but it really has its uses.
I mostly use it for easily accessing asset references that would otherwise be hard-coded, as well as for creating specific versions of my C++ base classes.
It works very well.
The truth is that the C++ side of support is very limited. There is a lack of basic information about eg. engine initializing order, handling resources, how and when to use the different features to use their full power.
I’m not going to criticize blueprints, because it is something innovative and certainly very supportive for people less felt in the programming, but it would be good if the Epic team look with kinder eyes at the people more related to C++, who prefers typing code instead creating code with clicking and hiding it in assets 
I really love this engine, when I looking at the source I’m very impressed with what Epic has done and made available to us for free.
Just start learning blueprints! If you’re already a programmer it shouldn’t be that hard. Should it?
P.S. You are right though. Epic should pat a little more attention to this.
This is not a solution to the problem, which I described in the post above.
If the engine gives me the opportunity to choose between the blueprint project and the c++ project, so I wish that both options are treated equally.
BTW I never wrote that I don’t use blueprints
yes c++ support is limited, but we have source code!, is the better documentation, in my experience all source is perfectly nice commented, so read is enough!, i use the poor documentation just for find methods names and .header containers, nothing more!, after that reading the code and comments is wonderful, i think is enough info for easy understand the unreal c++ side, anyway i need add something. Unreal is indeed powerful in c++ and blueprints, but have lots weak points, i one of my projects i need take a screenshot and load as texture, i pass a half day trying to solve :), i thought this is fully implement in UE by blueprints, Ohh!! big mistake!, for solve this, i found a imagewrapper class for load the image, and a way to load the data as texture, is working but is absolutely slow, its take 300 milliseconds of processing, when i use i get a big delay, so i implement that in thread inside a FRunnable, that solve the problem but is NOT enough, load a image file with 10 to 300 kb of data, and spend 300 milliseconds, wtf!!!, i decide implement opencv for comparison, opencv take just 10 milliseconds for read a full HD image .png.
Unreals is powerful but need improve some tasks, some functionality is missed because at moment doesn´t have cool solutions yet. i think!
I agree. But sometimes it is strongly depressing if you everywhere see thousands of blueprints-related tutorials, but when you look into the API documentation and see this…
https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/Engine/UStaticMesh/index.html
Seriously ?! The class has only three fields? Ah yes, a quick look at staticmesh.h and we see more than twenty class fields!
I even do not ask that everything should be nicely described, because the names of methods or fields are mailny self-explaingin. Just want API ref corresponds to code in 1:1.
Epic, please… 
Again and again… No one say that blueprints are **** or sth.
What a time-saving method…
As always the right balance between both worlds will yield the best results. If you are already a C++ programmer catching with BPs is just a piece of cake learning the API, the API is actually easier in BP thanks the the wonderful contextual features.
It saves a lot of work, later on, once you know exactly what you want, doing it directly in C++ is sometimes faster than in BP but there is no golden rule for it. When I approach the decision to go the BP or the C++ route I think about what the team should be able to touch in BP and what not, it’s the same way like building a library and applying the BlackBox pattern.
No quotes, so i think your post is addressed to me. Peace 
There is a lot of patterns to make things simpler and easier in C++. For example, if I want to create bunch of weapons which are slightly differs I use simple factory pattern. When I want to create bunch of cars which are differs only by colors i use prototype pattern. Etc.
I have no idea, why when people ask for explain some C++ things they get “OMG! Use Blueprint! Blueprints are cool!”.
I understand that Blueprints can be used by people who dont feel strong in programming, but I dont understand why forcing programmers to use Blueprints. Hiding problem of lack documentation via “use Blueprint!” is not ok.
A simple thing - complete API reference with full list of classes, methods and field. And I’ll be happy. Like in example in one of my previous post: To find out that were UStaticMesh store raw mesh data I must finding it via FBX import plugin source. That’s horrible.
I don’t ask for it on forum because i know what the answer be: “Hey, use blueprint”.
Do ont treat it like attack. I came to UE4 because they give me a opportunity to use and practice C++ skills, but Im a little bit disappointment in fact of disregarding programming side of engine.
I don’t think lack of documentation is an issue for C++. You can easily use the blueprints documentation as a reference for C++. For example, the context menu of a blueprint function allows you to go look at the code definition. From there, you can just search for the function and look at how the blueprint is executed in C++. You can even import Kismet libraries into your code and directly use the C++ equivalent functions of the blueprints.
I have taken this approach for functions that are more intuitive. For example, if I use the linetrace from the kismet library, my code is shortened to a measly 3 lines and I can easily modify the parameters. The function itself is the exact name of what is inside of blueprints. As I have learned, there is no drawback to doing this, but in fact, since you are executing everything in C++ code, you get a 10x performance increase.
Regardless, I still extent my C++ classes through blueprints to modify certain things (like the mesh and how it appears or the various exposed properties).
I’m not saying that BP saves more work than native code, both have their place to be and sometimes I prefer doing things in BP and others in C++. The balance on how you use them is where you will get the best outcome, of course this is totally biased by my personal experience as a C++ programmer and by years of using Epics engines.
And I totally agree with you when it comes to C++ documentation, it’s far behind the code. Once you know each corner of the code base is does not really matter because you just search and find what you want but starting with this beast of an engine is really hard, so the best advice is actually what SentinelSigma said, use BP as a quick source for the API :D.
Even better, just use the blueprint functions that the engine calls when the blueprints are executed. You wouldn’t even need to worry about C++ documentation since all you will have to do is look at the BP documentation, just go to the code definition and call the respective functions.