I learned programming basics in school with QBasic, including variables, arrays, loops, conditionals, and a brief introduction to functions, classes, objects, and OOP in C. I then focused on game development with Godot and have since made projects ranging from small experiments to more complex games. I have also collaborated with others, participated in game jams, worked with shaders, and even won a game jam.
On a larger project, I ran into a performance problem and started looking into writing performance-critical code in C++ through a Godot extension. That exposed gaps in my knowledge: I am not comfortable with memory management, pointers, structs, ownership, or what is happening under the hood when a C++ program runs.
I feel as though I skipped an important stage of learning low-level programming while still managing to become productive with a game engine. I am considering pausing Godot to fill in those gaps, but learning from LearnCpp.com feels difficult because the material is mostly reading and exercises without a motivating project.
What would be a practical learning path from here? Should I continue using Godot while studying C++, build a small standalone project, or learn C and computer architecture first? Are there ways to make the fundamentals more hands-on and engaging?
4 Answers
Do not abandon Godot while learning. Keep using it for gameplay and make a separate, disposable C++ project for the concepts that Godot hides. Once you understand the basics, create one very small extension and move only a measurable hot path into it. Profile first, though—many performance problems come from algorithms, excessive allocations, or unnecessary work rather than needing to rewrite everything in C++.
LearnCpp.com is a solid reference, but it becomes much less dry when you pair each section with a concrete exercise. After learning a topic, make something small with it: a command-line inventory, a particle simulation, a grid-based game, or a basic entity system. Focus especially on stack versus heap storage, pointers and references, structs and classes, constructors and destructors, RAII, containers, and debugging memory errors. Modern C++ generally favors standard containers and smart pointers over manually calling malloc and free.
You probably do not need to restart your entire programming education. Most of your existing knowledge transfers; the main missing pieces are C and C++'s model of memory, object lifetime, compilation, and ownership. Build a very small project in C or C++—perhaps a simple game using raylib—or write small programs that manipulate arrays, structs, files, and dynamic memory. Keep the scope deliberately tiny so the language concepts remain the focus.
If you want a deeper mental model, study computer architecture gradually rather than making it a prerequisite. A course such as Nand2Tetris can show how logic gates, a CPU, assembly, and higher-level code connect. Looking at simple compiler output or stepping through a small program in a debugger can also make pointers, function calls, and data layout more intuitive. You do not need to master assembly or write an operating system before making useful C++ extensions.
A useful milestone is being able to explain who owns every object, how long it lives, and what happens when it is destroyed. AddressSanitizer and UndefinedBehaviorSanitizer are excellent for catching invalid accesses while you experiment.