I'm starting to learn Unreal Engine 4. Every time I use blueprints, I think "that's not right" and I need to use C++, but there are not as many tutorials with c++ code. So, is it ok to use blueprints as a programmer?

  • 31
    \$\begingroup\$ I like to think you meant "professional game developers". If you make any game, you are a real game developer. Be proud of yourself. I believe in you. \$\endgroup\$
    – liggiorgio
    Commented Jan 22 at 16:43
  • 9
    \$\begingroup\$ Why are you learning UE4 today? Why not use the latest version? \$\endgroup\$ Commented Jan 23 at 7:52

7 Answers 7


A real game developer is someone who manages to deliver a product.

Visual coding is a tool that can be used to achieve that. Some people use Chat GPT, some people use notepad, some people use blueprints, some use an IDE. Which tool you use boils down to personal preferences and the way you approach a problem.

As long as your game is running as you envisioned it in the end, the player will never know how you coded it.

  • 27
    \$\begingroup\$ And deep down, nobody actually cares. A relatively recent game that was widely successful, Undertale, is basically a case-study for some of the most horrid programming practice. Apparently, all the NPC dialogs are in a single giant text file. \$\endgroup\$
    – Nelson
    Commented Jan 23 at 1:50
  • 29
    \$\begingroup\$ @Nelson not just a single text file, a 1,000+ entry long switch-case statement \$\endgroup\$ Commented Jan 23 at 3:20
  • 21
    \$\begingroup\$ @fyrepenguin I found it... the horror! \$\endgroup\$
    – Nelson
    Commented Jan 23 at 3:31
  • 33
    \$\begingroup\$ And the people who use ChatGPT come to Stack Overflow when their nonsense advice doesn't work. \$\endgroup\$
    – qwr
    Commented Jan 23 at 5:16
  • 6
    \$\begingroup\$ @Peter-ReinstateMonica agreed - at the end of the day, the players don’t see the spaghetti behind the curtain, and it produced a much-beloved game. I would note, though, that good design will be appreciated by the devs themselves when they go to fix bugs/make updates. But you evidently don’t need “good code” to produce a “good game”. \$\endgroup\$ Commented Jan 23 at 20:14

Professional game development teams working in Unreal Engine typically use a mix of blueprint and C++.

One good strategy is for a designer to attempt to implement a feature in blueprint, then ask a programmer for review their prototype. The programmer can identify things that are inefficient, overcomplicated, or heavily used within the blueprint, and reimplement those in C++ in a reusable and maintainable way. The designer shouldn't hesitate to ask the programmer for C++ features that would make their job easier.

If you're the only developer on the team, of course, you have to wear both those hats. Use what works for you, as Zibelas suggests in their answer.


"Real" game developers always use the right tool for the job.

Even though it is perfectly possible to produce a professional game using only C++ or only blueprint graphs, most professional Unreal Engine projects use a mix of both. They both have their advantages and disadvantages.

One main advantage of blueprints is that they are very fast to compile, which makes it a lot more convenient to prototype and iterate with them. But C++ solutions are usually(!) much more performant at runtime. So when a feature that was initially prototyped with blueprints turns out to be a performance bottleneck, then redoing it as a C++ class can sometimes help.

And depending on what problem in particular you are trying to solve, either one might be easier to create, read and/or maintain. In general, blueprints excel at "simple" logic flows ("when B button is pressed, jump!"), while C++ is the better medium to convey logic that requires more complex algorithms and data structures ("when AI agent is idle, pick a job from the master job list using this rating function, break it down into steps using goal-oriented action planning and push them onto the task stack for the agent"). But there is a large grey area in between where either approach is reasonable.

And it's not uncommon either to use a mixed approach of creating a blueprint graph where some of the nodes are custom nodes implemented in C++ specifically for that one graph. This approach is particularly common in teams that contain both programmers and non-programmers who want to be able to tinker with the game mechanics without having to ask a programmer for every little change.

So the answer to the question "should I learn blueprints or should I learn c++?" is "Yes!"

  • 1
    \$\begingroup\$ "should I learn blueprints or should I learn c++?" is "Yes!" this should be in bold! xD \$\endgroup\$
    – Kromster
    Commented Jan 26 at 7:48

I like to think of games as "interactive art". (As once, EA used to mean.) A game developer is part programmer, part artist. We should explore a lot of different modes to reify the experience we wish upon the player. Let it come from hard code (like C++, Javascript) or assistance tools like Blueprints.

Professional game developers know many ways to manifest their ideation. Some even use pen and paper to prototype the game.

  • \$\begingroup\$ EA stands for Electronic Arts, not Interactive Art. \$\endgroup\$
    – Vaillancourt
    Commented Jan 25 at 10:37
  • \$\begingroup\$ @Vaillancourt "used to mean". In the formative years of the company, special emphasis was placed on the "art" aspect of games. Also, a letter (which I fail to find) demonstrated similar sentiment of leveraging this "interactive media" (computers) for making "art". Quoting - "When Gordon and others pushed for "Electronic Artists", in tribute to the film company United Artists, Steve Hayes opposed, saying, "We're not the artists, they [the developers] are..." This statement from Hayes immediately tilted sentiment towards Electronic Arts". \$\endgroup\$
    – user140738
    Commented Jan 25 at 11:00

In Unreal Engine - supported by the approach of the Fortnite team - the intended design of Blueprints is that C++ usually exposes functions, logic, events etc, into a blueprint ready for the game designer to make use of in the intended way. In Unreal Fest, this has been a topic raised quite often, and answered in this way.

Regardless - as others have stated - who cares. When the game works, is fun, makes money and is more often than not superceded by the next game... choices like this become a question of maintenance burden rather than anything else.

To summarise: Expose parts from C++, use in Blueprint, but most importantly, get the game made.


This answer is applicable to any software development task. As a general principal you should use the highest level language/tool that gets the job done. This will result in the fastest and cheapest development and the easiest maintenance. You should use lower level tools as needed to improve the performance of bottlenecks or to do things that are not supported in the high level tool/language. Do not base your decisions on idiology but let the task dictate the tool.

In your specific case, use blueprints wherever possible and only use C++ to do something that cannot be done with blueprints (or is more difficult) or where the performance would be unacceptable. And, as always, don't prematurely optimize code - always profile it first.

C++ is one of my favorite languages, but it is usually not the fastest or cheapest (in terms of development time) way to solve a problem with the required performance. This is the metric that should drive any 'professional' developer.

  • 2
    \$\begingroup\$ Visual programming tools like Blueprints are inherently clumsier than textual languages, so this generalisation doesn't work. Blueprints are quicker and easier than C++ for simple tasks but actually become more difficult to understand quite quickly. \$\endgroup\$ Commented Jan 25 at 18:40
  • \$\begingroup\$ @JackAidley, you missed my point. Any task that is quicker and easier to do with C++ should be done with C++ - that is my point. \$\endgroup\$
    – Trevor
    Commented Feb 28 at 5:15
  • \$\begingroup\$ then I suggest you rephrase your answer to make that clear, because as it stands you appear to be recommending C++ be used only on the basis of performance. \$\endgroup\$ Commented Feb 28 at 9:01
  • \$\begingroup\$ @JackAidley, done - although I think I would already be clear that 'things that are not supported in the high level tool' and 'something that cannot be done with blueprints' does not mean that you should use blueprints if it is 'in any way possible no matter how tortuous'. Common sense obviously applies. To be absolutely clear my point is that you should use the tool that is easiest to achieve the task and not be influenced by idiology or premature performance considerations - if that is c++ then use c++. \$\endgroup\$
    – Trevor
    Commented Feb 28 at 10:40

Starting with Blueprints in Unreal Engine is awesome! They're a visual way to learn core concepts without code, making it easier to grasp than diving straight into C++. Think of them as training wheels - building your understanding before transitioning to C++ for more control and efficiency. Don't be afraid to mix and match! Use Blueprints for faster iteration and C++ for performance-critical sections. This flexibility is key in Unreal, so have fun creating and learning!

  • 3
    \$\begingroup\$ I would say they are not trainings wheels. Else you can argue as well any ide are training wheels and only real coders use only plain text editors or notepad. \$\endgroup\$
    – Zibelas
    Commented Feb 1 at 8:29
  • 2
    \$\begingroup\$ Don't think of blueprints as "training wheels". Think of them as a tool that fits some problems while code fits others. They are not meant as a bridge for beginners to programming to be eventually get replaced. There are a lot of use-cases where blueprints are just the better solution, even if you are a master at C++ programming. \$\endgroup\$
    – Philipp
    Commented Feb 1 at 8:52
  • \$\begingroup\$ That's interesting \$\endgroup\$
    – mendzek
    Commented Feb 2 at 11:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .