Mixing blueprints and C++

Hi, I started using Unreal Engine and I got this dilemma. What should I use? Blueprint or C++?

The best answer is... Yes! ;)

There's no dilemma. Your project should use both, if possible. Blueprint visual scripting hasn't been designed to entirely replace C++, although it's an amazing form of scripting. It allows people in non-programmer roles to script logic of the game.

Yes, it is possible to finish and publish a game using only blueprints.

• Blueprint-only project might an awesome way to develop game if you're hobbyist, solo dev or simply learning how to create games. There's a lot to learn in gamedev, so skipping learning of traditional programming language at the beginning would be a huge time-saver. And not everybody's mind is able to easily digest text-based programming. Visual scripting is more compatible with the brains of artists, level designers or writers.
• You might be interested in reading this: Solo dev Gwen Frey explains how she developed puzzle game Kine using only Blueprints
• However, a team of people would typically include a programmer. Or many of them.

If you have programmers in your team or anybody that spend time partially on C++ programming, you would simply mix both solutions. Visual scripting is meant to supplement text-based programming/scripting, free up programmers from scripting things that can be easily done by content creators.

Why projects still need programming and programmers?

• People working exclusively with visual scripting usually don't understand programming concepts and practices. That leads to messy scripting and very bad code architecture. They could learn proper programming, but blueprints are so easy to use, so many people love to script things "any way it just works". "Any way" is often a terrible way. Bad code simply means that is difficult to understand, even for its author. Changing small things in messy code takes much more time and it's error-prone. It's easy to create bugs if code is over-complicated and badly designed. Learning any regular programming language (it might be even C# in Unity) helps a lot to learn how to efficiently use blueprints.
• People who don't know even basic C++ are unable to read and debug engine code. It means they won't ever understand what happens in the engine, what actually happens when the given function is called in blueprints. They can only guess how the game works, so they need support for a programmer person. Engine documentation and the internet won't ever answer all the questions.
• In consequence, the team without programmer won't be able to modify the engine code - which is quite common practice when working with Unreal. It's totally optional but extremely useful.
  • A small change in the engine code might allow for implementing a game-specific feature that wouldn't be possible otherwise. The team would have to forget about that feature or implement it in a dirty way (workaround for unmodified engine code).
  • You can quickly fix bugs and crashes in the engine. Often is a matter of changing a few lines of code. That's might very important when the game is about to be released - you simply need to release the game on the current engine version, but there are some critical engine bugs to fix.
  • Sometimes you can easily integrate "changes from the future", a relatively small engine from developer branch of the engine (a bugfix or improvement to some system).
• Node-based scripting offers only a limited subset of possibilities possible in the underlying programming language. Blueprints offer so much of Unreal C++ that is possible to implemented prototypes and a large chunk of the game scripting with nodes. Still, it's only a portion of general-purpose, multi-paradigm language known as C++.
  • Only things exposed to Unreal Property System (Reflection) can be exposed to blueprints. That means we can use in blueprints only these data types and features of C++ that Epic handles in the engine. You might think you don't lack anything in blueprints only because you aren't aware of C++ features.
  • In effect, not every feature implemented in C++ can be exposed to blueprints, i.e. Programming Subsystems would be a simple example.
  • Blueprints support Object-Oriented Programming only. Every blueprint represents some kind of "object", inheriting after UObject class. Check Basic Object Classes to see the place of "actor" and "components" in this. Such setup is quite natural and intuitive for creating virtual worlds (everything in the real world is a kind of object, right?), but it's not the only way of programming.
  • Slate - UI framework used to create all the editor UI - utilizes another programming paradigm called "declarative syntax". There are no UObjects here, Slate can't exist in blueprints. Editor UI can be created and customized only in C++ and Slate.
  • In-game UI is created with UMG (see UMG UI Designer Quick Start Guide)) which is Slate exposed to UObjects through a special class called UWidget. Every in-game element created with UMG is a "widget", a kind of object that can't be placed in the world itself.