When to code and when to Blueprint?

As a programmer moving into Unreal Engine 4, When to code and when to Blueprint?..Blueprints feel wrong, but am I missing the point?

I learned to program with C++, opengl, directX etc.
Unreal does a lot for you. And I Know I should be using features it contains, but I keep feeling like I’m cheating and just not really understanding…
I’ve worked through tutorials on HOW to do things with pure code, and doing other things with pure blueprint, but I’m just unsure WHEN I should use either.

If you are totally new in ue4 and you are looking for what to start at, doesen’t matter cpp, or blueprint, you could just start of using cpp, you can almost do the same, " in terms of gameplay programming " with bp or cpp ".

You’ll end up learning Blueprints, since you have to use them for sure for example with the animation system that ue4 brings, you will no longer truly control the animation system from the code like UE3(UDK), i guess that at some point your game code will have to do animation related stuff.

Well i recommend you first learn cpp, for isntance 1 spawning your first Actor, 2 doing some vector rotator maths 3 Trace (Raycasting) against something, you’ll see that you will eventually be able to do it in blueprints.

Blueprints have a cool advantage and it’s that you debug, prototype, test stuff super fast. while in cpp you obiusly are slow, you will probably start prototyping your game with BP, later on you can send everything back to c++. you could just use cpp for the default values, default values of objects, then you will have less blueprint boxes around somehow, and everything with a core structure, since it will be written in cpp already. (Just like the cpp examples really).

Hey Neongho, thanks for the reply.
I’ve done a couple of tutorials in ue4, and made a 2d game as part of a game jam. But pretty new yeah
so you think that it’s helpful to do things as a proof of concept in blueprint first then move it into C++?
Is this transition easy to do? As I’d like to avoid doing everything twice

I usually create C++ classes for most of my main game objects and then have my blueprints inherit from those C++ classes.

As a programmer, you get to decide what you want to do in blueprints and what you want to do in code. Sometimes, blueprints are faster and better. You can iterate and test quickly without long compile times, but you are limited to what you can access via the blueprint system.

On the C++ side, you can access 100% of the engine features and implement some trivial things very quickly (such as “MyVar++;” or “MyVar += 3;”).

The thing I try to keep in mind is this: What do I want non-technical people to fiddle with? That goes in blueprints. Everything else goes in code.

I use the blueprints in my programming work flow.

First I usually create a the basic class, and then the basic functions that class is going to need(constructor / any engine related events).

Then, build it and use the blueprints like a piece of scratch paper. Since the Blueprints can go through so many iterations so quickly; you can block out
functions you need with ease. When you have them down you can port them over to code, and leave any other functions or other bits you want to have exposed in blueprints for artists to use.

Keeps people out of the code that dont need to worry about how a function or method specifically works.

Hmm, seems like I keep getting the same advice about prototyping quickly in blueprints.
I suppose I just don’t want to make something twice (once in blueprint, and again in code) and the potential of introducing errors.
I think the main thing is I’m yet to code anything significant, so I’ve not really seen much difference in build times, but if it starts eating into the development I might move to blueprint prototypes.