I know the main fundamentals of the editor (creating a project and level, importing assets, animations, lighting the scene…) and now would like to program the gameplay.
I have prior C experience (writing OpenGL “fixed pipeline” programs) and as such a basic understanding of computer graphics concepts (matrix transformations, materials, lighting, creating/modifyng geometry, camera movement…).
I have however no C++ experience but managed to compile the QuickStart programming tutorial.
Could someone point me to a good, ideally game oriented, C++ book for beginners ?
For information I don’t want to use Blueprints, I prefer direct programming.
If you just want to get things done now, some say Udemy courses are good…
If you are serious about c++, subscribe to “CppCon” on youtube and watch everything because those are conference talks by the same people who actually maintain the C++ language.
Thanks for the information, I’ll ty both I think: Udemy for the practical side and CppCon for the longterm learning. I’m also reading the docs and making the tutorials.
In my experience, there are two “flavors” of C++ used in the software development industry.
The “CppCon” flavor is for people who write new C++ code using all the features of the language, typically in the context of a Google datacenter service or similar. This is known as “modern C++.” It is not particularly well used in many game development circles, because the goals of many Google server processes are different from the goals of many games. The modern style is more heavy on using templates, static polymorphism, and code generation compiler tricks that make “your code” look “simple,” while hiding a large amount of machinery in the “library code.” As a “user” you’re not supposed to “go into” the “library,” but instead treat it like magic provided by elder wizards who know everything about how your compiler actually best generates code. Modern C++ looks more like a language like ML or Haskell in many ways. For some use cases, this is absolutely the right trade-off!
The “C with objects” flavor is much more focused on manual object lifetime management, and virtual (runtime) polymorphism. The game “engine” is the “library” and you’re expected to trace your code into and out of the library all the time. This kind of code looks more like “C with structs that have magic function pointers in them,” or perhaps like a Java program. The goal here is to make everything that happens to your object (whether you wrote it or not) obvious to the reader, which means that abstractions that hide significant implementation details are less desirable. Similarly, game object systems generally have deep runtime polymorphism, where classical class hierarchies like “A Peasant is an NPC which is a Character which is a Pawn which is an Actor which is a GameObject” are common. Unreal engine uses this kind of C++.
If you follow the CppCon people, you will learn a bunch of things that aren’t used by Unreal. Similarly, they don’t focus on a bunch of things that Unreal DOES use. You’ll be learning the wrong dialect – a little bit like learning Castellan Spanish in preparation for a vacation in Mexico. (Maybe even worse, actually!)
My recommendation if you want to get started on Unreal quickly and you’re coming from C, would be to learn the very basics – new/delete, virtual functions, references, and the simple “generic containers” kind of templates. Write your own vector<> and hashtable<> templates. Then, start writing/using the Unreal Engine and trace through the code for your objects when they initialize, update, render, and die. This will teach you the bits you need to know much better than trying to first learn the full extent of the C++ language, and then “backtracking” into the subset used by Unreal.
Unreal Engine has some garbage collection, though. Basic UE4 library stuff doesn’t differ much from C++ standard library, besides using weird Hungarian notation.
Modern C++ features help exactly with making lifetime management obvious and safe. Explicitly managing memory is far from obvious to user and should not be used in 99% of cases. It’s important to understand that it’s not C anymore and there is std::unique_ptr, vectors, references and a lot of other cool convenient things.
I’ve debugged and fixed up too much over-abstracted code in my life to give the abstraction tool to anyone with less than five years of industry experience, and after that point, only with careful oversight. Abstractions have significant cost, and they always end up leaking underlying implementation properties, anyway.
Yes, UE has a resource management system. No, the UE libraries don’t look anything like the modern C++ standard libraries.
And those types are incompatible with the Unreal choices for object tracking and reflection. Thus, if your goal is to learn C++ so you can work with the Unreal engine, starting with those resources is just going to lead you astray.
Also, “modern C++” gives you things like the standard “random” type, which defaults to the bloated mt19937 implementation as default, when something like pcg256 is smaller, uses less cache, and at least as good. I could go on for a LOT of the choices they’ve made – yet, we still don’t have static introspection of product types, nor do we have constructs like sum types and pattern matching, which have worked out great in any language that adopts them. Asking the compiler “what are the members of this struct” would be much safer, faster, and more robust than the #define hellscape that every large application ends up finding itself in anyway with the current regime. (This includes Unreal and the Unreal Header Tool.)
In my more-than-five years of industry experience, you’re the first to step over benefits of abstraction like that. Anyone will be highly more likely to leave a bug in code that mixes low and high level operations.
There are a lot of tools such as templates and polymorphism, and even whole directions of programming language research that aim to nullify abstraction cost.
Inside. Interfaces of the same basic features look almost the same - I’m talking about smart pointers, arrays, etc. Yet I think it’s better to start with fundamentals of standard C++ library
std::variant. Not as convenient as in Haskell, but it does the job.
auto [x, y] = z; (yeah, that isn’t really pattern matching, but it shares some of it’s uses)
(yeah, that isn’t really pattern matching, but it shares some of it’s uses)