When Unreal Engine 4 was made available to the public in early 2014, it held within its new features, a new major feature called the Blueprints editor. Everyone expected that the engine would still use and support the Kismet editor from Unreal Engine 3, but we found that Epic removed it and replaced it with a brand new and more powerful editor for game/gameplay logic scripting.
In the course of this book, we'll use this new system to build up our content and games, and in this chapter, we'll cover the following topics:
- Blueprints inside Unreal and its usage and types
- iOS platform-specific nodes
- Blueprints—tips and tricks
- iOS project pipeline with Unreal
- Setting up project settings
- Building into a device
Essentially, a blueprint makes everything in the game logic clear and easy to follow. When creating a game with UE4, a blueprint does exactly this: makes writing code or game logic much easier.
If you have had the chance to work with the free, limited version of Unreal Engine 3, which was UDK, you will know that the scripting inside UDK was based on one of two things: either using the scripting language called Unreal Script, or using Kismet.
The Blueprints system in UE4 is almost the only, and certainly the most common way to build game logic efficiently and fast. It is the new version of the old system in UE3 called Kismet, that was not efficient when it came to refactoring the logic for different levels inside the same game. The engine supports C++ game code as well, but in that case I would not consider it as scripting, as C++ cannot be a scripting language and is pure programming!
With a simple graph of four nodes like the following one, you will be able to save the time taken to write code. The following graph says that:
- If the player presses Jump, then the character controller executes the respective jump function
- If the player inputs Horizontal axis, then the controller will use the
Add Movementfunction with a specific amount of moment, and a direction (values passed through the function).
To write similar code in any programming language, you would spend 10 minutes and write at least 50 lines of code, but with a blueprint, all that you need is 4 nodes and 5 seconds of your time! For more efficient usage of the blueprints system, if you are a programmer, you can write your own blueprint node in C++ that executes a set of functionalities. This will save you the time taken to connect several nodes or write lots of code multiple times.
There are two types of blueprints; when you start building logic for each of them, you will be using the same nodes with similar mechanisms. However, each type has its own usage and its own way to execute. The different types of blueprints are:
- The class blueprint: This is the most commonly used blueprint type during the process of building the gameplay elements. The easiest way to think about it is that each entity in the world is a blueprint as long as the entity has to act, behave, or do any logic type. These types of blueprints are very powerful, as you can use them anywhere inside your project; you can even recycle them to be used in another project somehow! You can have any number of these; it depends on your game and world size and complexity. A good example of a class blueprint can be an enemy blueprint or a collectable object.
- The level blueprint: As the previous type is a per-entity or per-object blueprint, this one is a per-level blueprint. This means that each level has its own blueprint that can be used only in the same level, and is used to control the current level entities and blueprints. Connecting some cloud objects with raindrop particles is a good example of what a level blueprint can achieve.
As they are only exposed per-level, this means that their number will always be limited to your number of levels; so if your project contains 20 maps/levels, it means that you have exactly 20 level blueprints!
