Hit enter to search or ESC to close

10 mistakes new Unreal Engine C++ developers make


In today’s Devlog, I want to take a break from more technical discussions and talk about more big picture things, which nevertheless affect our work performance as C++ programmers a lot.

So I have gathered a list of ten biggest mistakes and time-wasters in my UE development journey I’ve made myself in the past. And I’ve included a few that come up very frequently in game dev circles, too. They all reflect on critical areas of a healthy approach to programming with Unreal Engine that I wish someone had told me about when I first started. I hope my experience will be helpful to you!

Without further ado, here’s the ten:

1. Diving in head-first

It might seem counter-intuitive. But diving in head-first when we first start working with Unreal Engine is not the approach Sjoerd De Jong of Epic Games, and I recommend for current C++ developers. It’s probably better to get yourself acquainted with UE’s capabilities by creating a few prototype games in Blueprint first. And only take up C++ programming when you are comfortable with the game flow and the many object classes already available.

If you are very short on time, the free online Unreal Engine Kickstart for Developers course will give you a broad overlook of the systems in about seven and a half hours of watch time. But do not skip it if you are short on time, because debugging and rewriting is the real black hole of time.

2. Not using Blueprints

No Unreal Engine project should be written entirely in C++. It is not only impractical, but it might very well be infeasible. Most game designers and artists have picked up some skills with Blueprints over their time working with UE. Still, if you do not expose your functions to Blueprints or create Blueprint interfaces for your game logic, they will not contribute to your project’s development.

Try to look at Blueprints as the game’s content and your C++ work as the game’s framework. You wouldn’t want to “bake in” your gameplay logic into your game’s core systems. It’s far better for prototyping and iteration if we treat our gameplay logic as content, and everyone skilled in Blueprints can change it. Let alone that there are far more people in the industry skilled at Blueprints than those qualified in C++ for Unreal. Treat your time as a precious commodity, offload scripting work that others could do to other team members, and focus on implementing the core framework and more technical features of your game. That is what only your competency can do.

3. Following tutorials excessively

Unreal Engine’s C++ tutorials are plentiful online and sometimes very helpful to get a sense of how things work. But they also have severe drawbacks if we rely on them as a learning tool too much. Firstly, they can be hacky – some tutorials will not use the engine in the most straightforward and “best practices” way. Secondly, while there are many tutorials on doing things at the introductory level, you will find far fewer guides for the advanced aspects of your game. You need to develop or hard-to-read engine assertions and exceptions. Thirdly, following tutorials too much can lead to an incoherent structure of your project.

Over the long-term, it is much faster to learn the core concepts of Unreal Engine initially. Then your classes will have a logical structure, and you will be able to debug any issue that comes along. Especially when you cross the barrier into more advanced topics that are rarely touched upon by very casual enthusiasts for whom online tutorials are written.

One exception to this rule is the Inside Unreal playlist by Epic Games on YouTube. They not only focus on best practices but also dive into some advanced stuff. And they also frequently follow Allar’s Gamemakin style guide, which Epic Games use internally to keep their projects structured well. Treat them as overviews of different views toward game development with Unreal and game development in general, and you will learn a lot!

4. Reinventing the wheel

This point touches on good engine knowledge once again. As new programmers, we are prone to doing things our way if we do not know that they are already implemented in the engine. I occasionally see code that doesn’t use Unreal Engine’s garbage collection and people trying to dynamically link to functions from external libraries that already have their alternatives within UE. Do not try to remake or source parts of the engine yourself; it is much faster to use what is already in place and integrates well with other parts of the game. And even if the functionality is not in the engine yet, it may be available in Marketplace plugins. Save your time and effort, and let others maintain as much of your functionality as they can. And if you aren’t quite sure what functionality Unreal Engine has, I would recommend circling back to point #1 and getting some practice hours before diving into C++.

5. Focusing on what you can do instead of shipping

This insight we have made in our company borrows a lot from Eric Ries’s marvelous book “The Lean Startup.” In it, he claims that a lot of tech entrepreneurs focus on what their companies can make, instead of looking at what the customer demand, can they make it, will the customers buy it, and if the customers will buy it from them. It’s an approach destined to waste time and effort, because a product that we can make but no one will buy from us is not worth a lot. In the same way, code that we can write instead of code that ships the game is not worth much.

Focus on the big picture items when you start working on the new project. Ask yourself: do all artists have the tools they need to ship your game? Is the user flow facilitating the game? Is some basic version of the game playable? And many such similar questions. Even if we write the most fantastic object class, if that object class is written instead of object classes that will ship the game, it is worthless. And in many cases, time spent on non-essential programming is at risk of becoming time wasted. Only code that will ship has value. And the most important parts of your game are most likely to ship.


  1. Thanks Kaz, this article is so insightful.
    I have a couple of question.
    My first question is regarding assertions. I understand that with assertions we can investigate our code in development phase and figure out many of problems but probably not all of them. So the question is how we can get enough data from production when a crash happens? Is there any way that stack trace of the crash be reported by player while they are playing on production? This can help specially when the game is in alpha or beta testing phase, or at least this is what I think :D.

    Second question is you mentioned we should learn our way around the engine and not reinvent the wheel, however in first days of learning you usually are overwhelmed with new stuff which make you not understand everything clearly or even forget many of stuff. Do you have any method for not falling into that trap or you just used the regular, simple method of “repeat as much as it takes” to learn things in first days?

    My last question is about style guide. Is there any facilities, plugins or build tools, which help you apply the style guide restrictions on build time or compile time? Probably something like Sonar and Sonarqube rules which you can use in the combination with jenkins jobs and does not let the codes which are not following style guide restrictions be pushed to master branch or even get built. I am not that familiar with the build mechanisms of UE and my question might be totally irrelevant.

    1. Hi Ali,

      glad you enjoyed the article.

      With regards to Unreal assertions, so long as the game is built in the Debug, DebugGame, Development, or Test configuration, the assertions will print a stack trace to logs in Saved/Logs. If we run the game in Play In Editor, then the Unreal Engine Crash Reporter will also show a stack trace on the screen when an assertion fails. And if we have an IDE debugger attached, we will get the stack trace, a breakpoint, and memory access – the usual stuff.

      On the other hand, when we build our projects in Shipping configuration, all Unreal assertion macros are disabled and no logs are written by default. So for alpha and beta tests, we can build the game with the Development configuration. And then, our testers can send us the logs. We could enable Unreal asserts and logs in shipping builds, but I cannot recommend the practice as the logs will accumulate. If we need to crash even in Shipping builds, but we’d like not to enable logs or Unreal assertions, we can still throw C++ exceptions, but we have to set bForceEnableExceptions to true in [GameName].Build.cs.

      I remember when I was just starting, and it was indeed not very clear what the engine does for us and what it doesn’t do. But the Kickstart for Developers learning path on Unreal Online Learning and building a few prototype games will show you the main capabilities. I would also advise skimming over the Unreal Engine documentation at docs.unrealengine.com and, for less-known capabilities, the engine’s source code on GitHub and Inside Unreal playlist on YouTube. But don’t rush there before the Kickstart for Developers courses. They will give the broadest overview of the engine you can get in 7 hours.

      As for style restrictions, we have JetBrains Rider for Unreal Engine. Just like Sonarqube, it will do many generic code inspections like highlighting code that cannot logically execute. But it will also autocomplete Unreal’s function and property specifiers, highlight poor compliance with the garbage collector, suggest variable names in line with the Unreal’s coding standard, and help us in small ways like that. I haven’t personally used Sonarcube, so I hope this answer is relevant.

      Rider for Unreal Engine is in preview now, but it already works very well. And you can even use it without Visual Studio if you install the .net SDK and Microsoft C++ Build Tools. It’s free for the early preview period.

  2. Thanks for the reply.
    Regarding the latest part of your reply, as much as I am facsinated with jetbrains products, specially Rider, what concerns me is that leaning on the inspections which IDE provides will help a lot in development but for the sake of CI and being sure that whatever that has been pushed to the master branch is following the style guides, regardless of the IDE which has been used, it is good to have a building tools which is checking the style guides on th build time. By the way I am not sure if it is even possible for UE projects.

    1. If you find anything like that for Unreal, in particular, let me know. I’d be very excited to look into it!

      From my experience, indie dev teams usually rely on members developing with adherence to their style guide. In our team, we give each other advice if we see something that’s far from Unreal’s coding standard in our git commit history. But Rider’s code inspection utilities can do that for you to a large extent if you don’t have anyone else to give you this feedback.

Leave a Reply

Your email address will not be published.Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.