To be fair, Blueprint Editing IS programming. When you’re starting on the programming side of things, you have to remember the most basic aspect of what you are doing is Data IN → Data OUT. For example integer goes in, something else comes out. That’s essentially all you’re doing all day long.
When it comes to game development, you will have to learn how to handle this data in a certain sequence so that it behaves like a game. To understanding the order of things, I recommend learning the following terms.
Tick - Code that runs every cycle in code. Sometimes it is every frame, other code “substeps” and runs several times between frames. (for example physics) In Blueprint you can think of it as once per frame. It is in the tick where you need to handle things that has to be calculated constantly.
DeltaTime, DeltaSeconds - How long it has been since last update. Necessary for many things, for example player movement. You can use this value to make sure something moves a specific speed or velocity per second, if you’re not using existing movement components.
Construction - When a blueprint instance is created. This is a good place to set default values that does not depend on any external asset.
Begin Play - When the asset is spawned and before it ticks the first time. This is where you initialize your asset in the game world.
The order of events for a blueprint is usually this:
Construction → Begin Play → Tick → Tick → Tick (until destroyed or stopped)
On top of this, you have Variables, Functions, Events, Event Dispatchers (Delegate in C++) and Blueprint Interface messages. Functions typically happens synchronous, which means it happens directly when you call them. Events and other messages on the other hand can be asynchronous, which mean they get queued and called when possible. Usually not a noticeable delay, but should be considered when trying to sync things up in code. A blueprint may be ticking, but can still receive events aside from that at any time.
I know this is still abstract stuff and may be hard to get at first. I recommend thinking of a basic functionality that you want to implement in Blueprint, then break it down into a sequence! You want to spawn an object when pressing a button?
- First understand where you have access to input. (level blueprint, pawn or player controller for example)
- Then fetch input for your button press.
- Either A) Do all your logic in this place or B) Send a message to another blueprint that takes care of the task.
- Spawn object in world by using existing functions.
The last point is usually the hard part with programming, because you do not know what functions are available for you. So this is where you read the documentation, API or use the right click menu to try to find the functionality that you need. A lot of time in programming is spent reading code and learning what is available to you and how you can use it. As you write more code, you will get a repository of features in your head that you can default to before trying to write it from scratch yourself.
Remember that functions are not something magical! They just take care of a certain data in, data out sequence. Existing functions in the engine are there because they are common actions, so we don’t have to rewrite them every time we need them.
I recommend looking up some of the blueprint nodes in the C++ API on GitHub, they are in the kismet libraries, to get a sense of how they are created. The more code you read, the more you will understand the engine.
This stuff is daunting when you start out! Trust me though, a month or two down the road you will be swimming in code.
I hope this gives you a sense of direction.
