Here is something that surprises a lot of new developers: the game engine behind Fortnite, Gears of War, and dozens of blockbuster titles ships with roughly 3 million lines of source code that anyone can download and read for free. So when people ask what programming language does Unreal Engine use, the honest answer involves more than one language working side by side. C++ sits at the core, but a visual system called Blueprints handles a huge share of real gameplay work, and newer options keep arriving.
That mix confuses beginners, and confusion costs time. Pick the wrong starting point and you might spend six months fighting compiler errors when a visual node graph would have shipped your prototype in six weeks. In this guide, you will learn exactly which languages Unreal supports, how C++ behaves differently inside the engine than in a normal program, when Blueprints beat handwritten code, where Verse and Python fit, how professional studios split the work, and what mistakes trip up almost every newcomer. By the end, you will know which language to learn first for your specific goal.
The Core Answer: C++ Runs the Show
Unreal Engine is written in C++, and C++ is the primary programming language you use to build games with it, backed by a built-in visual scripting system called Blueprints that compiles down to bytecode the engine runs at runtime. Epic Games wrote the renderer, the physics integration, the networking stack, the animation system, and the editor itself in C++. When you download the engine source from GitHub, you are downloading a giant C++ codebase.
Because of that, C++ gives you the deepest access. You can modify the engine itself, write custom rendering passes, build gameplay systems that run thousands of times per frame, and integrate third-party libraries. Nothing in Unreal stays hidden from a C++ developer.
Blueprints, meanwhile, act as a full scripting layer built on top of that C++ foundation. You connect nodes with wires instead of typing semicolons. Blueprints can call C++ functions, inherit from C++ classes, and override C++ behavior. The two systems talk to each other constantly, which is why most real projects use both rather than choosing one.
Here is the quick breakdown of every language you might touch in an Unreal project:
- C++ – the engine’s native language and the main tool for gameplay code, systems, and performance-critical work
- Blueprints – visual scripting for gameplay logic, UI, level scripting, and rapid prototyping
- Verse – Epic’s newer language, currently used in Unreal Editor for Fortnite, with wider rollout planned
- Python – editor automation, asset pipelines, and build tooling (editor only, not shipped in games)
- HLSL – shader code for custom materials and post-process effects
- C# – used by UnrealBuildTool and UnrealHeaderTool, the programs that compile your project
How C++ Actually Works Inside Unreal Engine
If you already know standard C++, brace yourself. Unreal C++ looks familiar but behaves like its own dialect. Epic layered a reflection system, a garbage collector, and a custom build pipeline on top of the language, and those additions change how you write everyday code.
The first thing you notice is the macros. You sprinkle keywords like UCLASS, UPROPERTY, UFUNCTION, and USTRUCT through your headers. Those macros feed a tool called UnrealHeaderTool, which scans your code before compilation and generates extra C++ that gives the engine information about your classes at runtime. That generated data powers the editor’s property panels, Blueprint exposure, serialization, and networking replication.
Memory Management the Unreal Way
Standard C++ makes you manage memory by hand or with smart pointers. Unreal adds a garbage collector for anything that inherits from UObject. If you mark a pointer with UPROPERTY, the collector tracks it and keeps the object alive. Forget the macro, and the collector may delete your object while you still hold a pointer to it, which produces one of the most common crashes new Unreal programmers hit.
Naming Rules and Prefixes
Unreal enforces class prefixes that carry real meaning. Miss one and the code will not compile:
| Prefix | Meaning | Example |
|---|---|---|
| U | Class derived from UObject | UStaticMeshComponent |
| A | Actor – an object you can place in a level | ACharacter |
| F | Plain struct or non-UObject class | FVector |
| I | Interface | IInteractable |
| E | Enum | EMovementMode |
| T | Template container | TArray, TMap |
Custom Containers Instead of the Standard Library
Unreal ships its own replacements for most of the C++ standard library. You use TArray instead of std::vector, TMap instead of std::unordered_map, FString instead of std::string, and TSharedPtr instead of std::shared_ptr. Epic built these to work with the engine’s memory allocators, serialization, and platform support. You can still use standard library types in isolated code, but engine APIs expect the Unreal versions.
Modern versions of the engine target C++17 and C++20 features, so lambdas, auto, range-based for loops, and structured bindings all work. Unreal Engine 5 raised the minimum standard, which means you get cleaner modern syntax than the engine allowed a decade ago.
Blueprints: Visual Scripting That Is Still Real Programming
Blueprints deserve more respect than they usually get. This is not a toy layer bolted on for kids. Blueprints support classes, inheritance, interfaces, custom events, functions with parameters and return values, arrays, maps, timelines, and network replication. Epic’s own designers build enormous amounts of shipped gameplay with them.
When you compile a Blueprint, Unreal turns your node graph into bytecode. A virtual machine inside the engine then executes that bytecode at runtime. Every node you place ultimately calls into C++ functions, so a Blueprint that mostly triggers heavy engine operations runs nearly as fast as C++ doing the same thing. The overhead shows up in the glue between nodes, not in the work the nodes perform.
That distinction matters. A Blueprint that calls a line trace once per second costs you nothing measurable. A Blueprint that loops 50,000 times per frame doing math will crawl. Developers commonly measure the Blueprint VM at somewhere between 5 and 10 times slower than equivalent native C++ for raw logic and arithmetic, though the real gap depends heavily on what the code does.
Here is a practical scenario. Imagine you are building a door that opens when a player walks near it. In Blueprints, you drop a trigger box, drag out an overlap event, add a timeline, and feed that into a rotation node. Ten minutes, no compiling, and you can tweak the rotation curve while the game runs. Writing the same door in C++ takes longer, requires a compile cycle for every tweak, and gains you nothing because the logic runs a handful of times per session. That is the sweet spot for Blueprints.
Where Blueprints Genuinely Shine
- Prototyping gameplay ideas fast without waiting on compiles
- UI logic with UMG widgets, where designers need to iterate on layout and behavior
- Level scripting, cutscene triggers, and one-off scripted moments
- Animation Blueprints, state machines, and blend logic
- Data-driven tweaking, since designers can adjust exposed variables without touching code
- Materials and particle effects, which use their own node-based editors
C++ Versus Blueprints: Picking the Right Tool
The endless debate about C++ versus Blueprints misses the point. Experienced Unreal teams do not choose one. They draw a line: C++ builds the foundation, Blueprints build on top of it. A programmer writes a base character class in C++ with movement, health, and inventory systems, then exposes clean functions and variables. Designers subclass that in Blueprints and assemble specific enemies, weapons, and behaviors.
This split gives you the best of both worlds. Core systems stay fast, testable, and version-control friendly. Content stays flexible and accessible to non-programmers. Here is how the two compare across the factors that actually affect your project:
| Factor | C++ | Blueprints |
|---|---|---|
| Runtime performance | Fastest available | Slower for heavy logic loops |
| Iteration speed | Slow, needs compiling | Instant, compiles in seconds |
| Learning curve | Steep | Gentle |
| Version control merging | Clean text diffs | Binary assets, hard to merge |
| Engine access | Complete, including source | Limited to exposed functions |
| Debugging | Full debugger, breakpoints, call stacks | Visual breakpoints and wire watching |
| Team accessibility | Programmers only | Designers and artists too |
One factor deserves extra attention: version control. Blueprints save as binary uasset files. If two people edit the same Blueprint, your source control system cannot merge the changes, and someone loses work. Teams solve this with file locking or by keeping shared systems in C++ where text merges work normally. On a solo project this barely matters. On a ten-person team it matters enormously.
Also worth knowing: Unreal Engine 4 offered Blueprint nativization, a feature that converted Blueprints to C++ at packaging time. Epic removed it in Unreal Engine 5 because it caused build problems and delivered inconsistent gains. Do not plan your architecture around it.
Verse: The New Language Epic Is Building
Epic introduced Verse in 2023 alongside Unreal Editor for Fortnite. It is a brand new programming language designed by a team led by Simon Peyton Jones, one of the people behind Haskell. Epic describes Verse as a language built for the metaverse, meaning it aims to run code from many different creators safely in the same shared world.
Verse looks unusual if you come from C++ or Python. It uses a functional-logic design where expressions can succeed or fail, and failure is a normal part of control flow rather than an error. It supports strong static typing, a transactional memory model that lets the engine roll back changes cleanly, and a concurrency model built for gameplay events. That transactional design is the interesting part, because it means a script that misbehaves cannot corrupt the shared world state.
Right now, Verse works inside Unreal Editor for Fortnite. Epic has publicly stated that Verse will eventually come to the full Unreal Engine, which raises an obvious question: will Verse replace C++? The realistic answer is no, at least not for a long time. The engine itself is C++, and rewriting millions of lines is not happening. Verse will more likely become a scripting layer that competes with Blueprints for gameplay code while C++ stays underneath.
If you build Fortnite islands, learn Verse now. If you build standalone games, keep an eye on it but invest your main effort in C++ and Blueprints. Watching Epic’s roadmap and the official Verse documentation costs you nothing and keeps you ready.
Other Languages That Show Up in Unreal Projects
Beyond the big three, several other languages appear in real Unreal workflows. Knowing what they do keeps you from getting lost when you open an unfamiliar project folder.
Python for Editor Automation
Unreal ships with an embedded Python interpreter that runs inside the editor. Technical artists use it to batch-rename thousands of assets, generate levels from spreadsheets, automate import settings, run validation checks, and hook the editor into studio pipelines. Python does not run in packaged games. It is strictly an editor and tooling language, and that limitation is by design.
HLSL for Shaders
Materials in Unreal use a node graph, but underneath, the engine generates HLSL, the shading language originally from DirectX. You can drop a Custom node into any material and type raw HLSL directly. Engine shader files use a .usf extension and live in the engine’s Shaders folder. Anyone doing serious rendering work eventually writes HLSL.
C# in the Build System
Here is a fun detail that trips people up: UnrealBuildTool and AutomationTool, the programs that compile and package your project, are written in C#. Your Build.cs and Target.cs files are C# scripts. So even a pure C++ Unreal project contains C# files. That does not mean you can write gameplay in C#, though third-party plugins like UnrealSharp aim to add that.
Community Language Plugins
- Angelscript – an open source integration maintained by Hazelight, the studio behind It Takes Two and Split Fiction. It offers C++ like syntax with instant hot reload, and Hazelight shipped full commercial games with it.
- Lua – several plugins bring Lua scripting to Unreal, popular with teams migrating from engines that used it.
- UnrealSharp and similar C# plugins – community projects that expose the engine to .NET, appealing to developers coming from Unity.
- JavaScript and TypeScript bindings – niche plugins used mostly for tooling or web-adjacent projects.
Use these with clear eyes. Unofficial language bindings can break when Epic ships a new engine version, and you inherit the job of maintaining them. Angelscript stands out because a shipping studio depends on it, but the rest carry real risk for long-term projects.
Common Mistakes and Misconceptions About Unreal Languages
Certain wrong ideas circulate constantly in forums and comment sections. Clearing them up early saves you months of wasted effort.
The biggest myth says Blueprints are only for hobbyists and real developers use C++ exclusively. Fortnite, a game generating billions in revenue, contains an enormous amount of Blueprint logic. Epic built the system for professional use, and professionals use it. Judging code by whether it has semicolons is a beginner habit, not a mark of skill.
The opposite myth is equally wrong: that you never need C++. You can absolutely ship a small game in pure Blueprints, and people do. But the moment you need a custom networking behavior, a third-party SDK, a heavy simulation, or an engine modification, C++ becomes the only door. Growing past a certain project size without C++ gets painful.
Other frequent errors worth avoiding:
- Learning C++ from a general tutorial and expecting Unreal C++ to match. Unreal’s macros, containers, and garbage collection change the daily experience significantly.
- Putting expensive loops or per-frame math inside Blueprint Tick events, then blaming the engine for poor performance.
- Forgetting UPROPERTY on object pointers, which lets the garbage collector delete objects you still reference.
- Casting to specific classes everywhere instead of using interfaces, which creates hard references that bloat memory at load time.
- Building a giant single Blueprint with hundreds of nodes instead of splitting logic into functions and components.
- Assuming Python or a community plugin can ship inside a packaged game when it cannot.
- Skipping source control because Blueprints feel like art assets rather than code. They are code, and you will lose work without backups.
How to Start Learning Unreal Programming Step by Step
Order matters when you learn. Jumping straight into C++ with no engine knowledge makes everything twice as hard, because you fight the language and the framework at once. Here is a sequence that works for most people.
- Learn the editor first. Spend a week placing actors, building a small level, adjusting materials, and playing in editor. Understanding actors, components, levels, and the game framework classes gives every later lesson a home.
- Build three small things in Blueprints. A door that opens, a pickup that adds score, and a simple enemy that chases the player. These teach events, variables, casting, and collision, which are the same concepts you will use in C++.
- Learn core C++ basics separately. Variables, functions, classes, pointers, references, and headers versus source files. Two or three weeks of focused study is enough to start.
- Convert one Blueprint to C++. Take that pickup you built and rewrite it as a C++ actor. You now see exactly how the same idea maps between systems, which is the fastest way to learn Unreal’s C++ dialect.
- Learn the hybrid pattern. Write a C++ base class, mark variables with UPROPERTY(EditAnywhere, BlueprintReadWrite), then create a Blueprint child. This is how real projects work, and mastering it changes everything.
- Read engine source code. When you wonder how ACharacter handles jumping, open CharacterMovementComponent and read it. Epic’s own code is the best Unreal textbook available.
Tools You Will Want
Your editor choice affects your daily happiness more than beginners expect. Visual Studio on Windows remains the default and integrates through Epic’s free Visual Studio Integration Tool. JetBrains Rider has become extremely popular among Unreal developers because it understands Unreal macros, Blueprint references, and reflection data far better than most alternatives. Visual Studio Code works well on Linux and macOS, and Xcode handles macOS and iOS builds.
Also turn on Live Coding, which compiles small C++ changes while the editor stays open. It replaced the older Hot Reload system and cuts iteration time dramatically. Pair that with the Unreal Insights profiler and the built-in stat commands, and you can find performance problems instead of guessing at them.
Real Projects and How Studios Split the Work
Theory helps, but seeing how shipped games handle language choices helps more. Different teams draw the C++ and Blueprint line in different places, and each approach makes sense for its situation.
Epic’s own Fortnite leans heavily on Blueprints for weapons, items, and gameplay features, with C++ handling the core systems, networking, and platform layers. That design lets a large content team ship weekly updates without every change requiring an engineer and a full rebuild. Speed of iteration is the whole point.
Hazelight took a different path with It Takes Two and Split Fiction. The studio built Unreal Angelscript because the team wanted C++ style code with the instant reload speed of a scripting language. They open sourced the integration, and other studios have adopted it. That decision shows something important: when the standard options do not fit your workflow, the open source engine lets you build your own answer.
Meanwhile, plenty of successful indie games ship almost entirely in Blueprints. Small teams without a dedicated programmer often get further with visual scripting than they would fighting compiler errors alone. The tradeoff is real, but so is shipping.
A useful rule of thumb emerged from years of community discussion: put anything that runs every frame for many objects in C++, put anything a designer needs to tune in Blueprints, and put anything touching the engine’s guts in C++. Follow that and you rarely paint yourself into a corner.
Questions Beginners Ask Most Often
These questions come up constantly, so here are direct answers.
Do I need to know C++ before starting Unreal?
No. You can start with Blueprints on day one and build working games. Learn C++ when Blueprints start feeling limiting, which usually happens around your second or third project. Starting with Blueprints also makes learning Unreal C++ easier later, because you already know what the classes and functions do.
Is Unreal C++ harder than regular C++?
In some ways it is easier. Garbage collection removes a whole category of memory bugs, and the engine gives you rich containers and utilities out of the box. In other ways it is harder, because you must learn the macro system, the module structure, and the build tool on top of the language. Most people find the framework harder than the language.
Can I use C# like I did in Unity?
Not officially. Community plugins exist, but Epic does not support C# for gameplay. Unity developers moving to Unreal usually find Blueprints a comfortable landing spot, then pick up C++ gradually. The concepts transfer even when the syntax does not.
Which language should I learn for a game industry job?
C++ without question, paired with solid Blueprint fluency. Gameplay programmer job listings for Unreal studios almost universally require C++. Technical designer roles often center on Blueprints. Tools programmer roles frequently want Python alongside C++.
Will Blueprints slow down my finished game?
Only if you use them badly. Keep heavy per-frame logic out of Blueprint Tick, avoid huge loops, use events instead of polling, and profile with Unreal Insights. Most performance problems in Unreal games come from rendering, asset loading, and bad architecture, not from Blueprints existing.
Where Unreal Programming Is Heading
The language landscape around Unreal keeps shifting, and a few trends look clear. Verse represents Epic’s biggest long-term bet. If it lands in the full engine with strong tooling, it could reshape how gameplay code gets written, especially for teams that want scripting speed without giving up type safety.
At the same time, C++ is not going anywhere. Every major engine subsystem depends on it, hardware keeps demanding more performance, and Epic continues modernizing the codebase with newer C++ standards. Learning C++ for Unreal remains a durable investment, not a temporary one.
AI assisted coding is changing the learning curve too. Tools that explain unfamiliar engine code, suggest Unreal specific patterns, and catch macro mistakes lower the barrier for beginners. They do not replace understanding, but they shorten the gap between confusion and working code, which matters most in the first six months.
Watch three things going forward: Verse expanding beyond Fortnite, community language integrations like Angelscript maturing further, and Epic continuing to blur the line between visual and text based scripting. Whichever direction the tools move, the underlying concepts of actors, components, events, and the gameplay framework stay the same, and those concepts are what really transfer.
Bringing It All Together
So what programming language does Unreal Engine use? C++ builds the engine and powers its most demanding code, Blueprints handle a huge share of everyday gameplay logic through visual scripting, Verse is arriving as Epic’s new purpose-built language, Python automates the editor, HLSL drives shaders, and C# quietly runs the build system. Real projects blend several of these rather than picking just one, and the professionals you admire almost certainly work that way.
The best move you can make right now is simple: open the engine, build something small in Blueprints this week, and start reading C++ next month. Every hour you spend inside the editor makes the languages easier to understand, because they all describe the same underlying world of actors, components, and events. Pick a tiny project, finish it, and let your language skills grow around the games you actually want to make.
